Robert Burrell Donkin ha scritto:
On Sat, Mar 29, 2008 at 2:02 PM, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
So, what to do if junit.pom is under an unacceptable license? Should we
create our own pom including almost the same informations and using the
same groupId/artifactId ? Should we instead use different
groupId/artifactIds
i'd be happy not ship poms and let maven download any meta-data it
needs. but i don't really understand why we need to shop poms so i'm
probably missing something important...
I would be happy too. I don't have any special preference. I like to
have the stage in the distribution, but I'm also happy with no stage
folder at all. I introduced the stage folder as you see it now because
JAMES PMC required to have a distribution that could be built offline.
I just want a solution that allow me to release jspf: I don't care of
what we ship in addition to the main jar.
>> 2) What licenses should we allow for pom.xml in order to make *legal*
>> the current use of the central maven repository?
>
> again, this question is too broad and open ended: any number of
> licenses could be created to achieve this goal.
>
> apache policy is clear on this point: artifacts distributed from
> apache should be under the apache license.
I still don't understand if maven central is an ASF resource or not. It
includes many non apache licensed products and many poms with unknown
license.
if isn't hosted by apache on apache hardware then it isn't an apache
resource. AIUI the maven central repository is an offshore resource
used by maven rather than an apache resource.
Then maybe the main asf pom should not include central as the main
repository, but some ASF specific repository that only include known
artifacts that we know we can safely use in our projects.
Unfortunately I understood that the use of the ASF repository
(http://people.apache.org/repo/m2-ibiblio-rsync-repository/) is discouraged.
How can ASF improve this?
Furthermore many ASF products include 3rd party artifacts: the 3rd party
documents and the category A/B classification is exaclty for this, isn't it?
If we find that junit.pom is a CPL licensed file we could include it as
long as we don't alter it, right?
possibly: xml documents are the subject of some controversy.
personally speaking, i'm reasonably happy including them but this is
not a consensus opinion.
This is my opinion too. Unfortunately I guess the junit.pom has not been
created by the junit authors and is unlikely a CPL artifact.
>> 3) Can the license for the pom.xml be described in the xml itself or we
>> need the whole license header like the one we would prepend to any other
>> xml file? The pom.xml is often a redistributable "as is", without being
>> included in a package: does this need a special "license header" ?
>
> again, too broad and open ended
>
> a license header is just legal boiler plate that effectively describes
> the license for the document
All this legal stuff is boring: everything is too broad and open ended ;-)
I really don't know how to make this question more specific: if JAMES is
going to distribute a pom.xml for james as a standalone artifact (and
not as part of a zip/package) what kind of header should we use?
answer: the standard apache boilerplate text
The "standard ALv2" header is not ok IMHO because it make references to
files that will not be there. IMHO a reference in the xml to an URL
including the license or the full ALv2 LICENSE file are better solutions
but IANAL, yet ;-)
the only file which isn't there is the NOTICE and that's not a big problem
ok.
>> The technical/procedural issues for the repository management are:
>>
>> A) How to tweak the current procedures to avoid publishing of new
>> pom.xml without a license or without an acceptable license (BSD, MIT,
>> ASL, W3C..., depending on answers about #2 above)
>
> upload to the apache maven repository should be reasonably covered by
> CCLAs, CLAs and JIRA but the audit trial is lacking and so it is
> impossible to demonstrate that it's covered
>
> IMO the maven [EMAIL PROTECTED] should be under version control
Let's make a step back: "apache maven repository" is the repository
where we only place ASF products and that is rsynced to central, right?
yes
The repository I was referring to is instead this one:
http://repo1.maven.org/maven2/
this is not an apache repository
So this seems the main issue.
Let's say we can't use the junit.pom because it is in central but we
don't know its license. At the same time we can use (and redistribute)
the junit jar because CPL is declared compatible by the ASF 3rd party
policy.
Either we are able to replace the pom in central with one created by us,
or we are able to create a new pom+jar in central under a different
groupId/artifactId or we are unable to use the "maven way" to ship junit
based products (I guess 99% of maven2 projects use that junit.pom during
the build).
>> B) How to deal with the current poms not having a license.
>
> IMO asking uploaders to add a license header would not be unreasonable
For new uploads this could be enforced by rejecting any file without a
license: but what we can do to fix the current "mess"? There are
thousands poms without license informations (like the junit one we are
using in jspf): how can we fix this? Remove all of them from central?
Who is responsible for repo1.maven.org/maven2/ ?
AIUI maven.org is not an apache repository. i'm not involved with the
admin of maven.org so i don't know for sure.
Do you think we should care of this? Maven is an ASF product and use
that repository as the "central". Is this an issue we should care of?
Who is sued by the author of junit.pom if this file had all right
reserved and repo1.maven.org is redistributing it?
AIUI it's the US, so the basic rule is sue everybody involved and let
the courts sort out liability. in practice (though) a takedown notice
would be issued and the contentious IP removed from the site and the
original uploder persued.
It is not clear who "the original uploader" is here. I guess both who
uploaded to MAVENUPLOAD JIRA and who published the file to
repo1.maven.org have their responsibilities, but more likely the second one.
I think this very person (and if I'm not wrong he is an ASF member, too,
so easier to contact) should be made aware of this responsibility he
takes by publishing content under unknown copyright/license. Maybe this
responsibility is the key to a real solution.
>> C) What to do when a pom is already published in a 3rd party repository
>> under an incompatible license: we cannot copy it, and probably is not a
>> good practice to create another pom with the same artifactId/groupId but
>> with different informations.
>
> either create a new clean pom or accept that we can't ship a pom for
> that artifact
clean pom make sense: same artifactId/groupId or different one?
Most time a pom is really simple and contains basic informations:
creating a new pom with the same artifactId/groupId will OFTEN result in
a file identical to the original one.
In our specific case junit pom is really simple: excluding the
"<description>" tag I think that everything else would be created
exactly as is in a new pom. They are simply metadata that we write using
a standard format.
I can create a new pom for junit.
The main issue is the artifactId/groupId issue: if we reuse the same
artifactId/groupId then we end up with different poms for the same
identifier and maven will not be happy with this. At the same time if we
use different artifactId/groupId we end up with many duplicates and
big issues in manually managing transitive dependencies by replacing
"origianl" artifactId/groupId with our "fairly licensed"
artifactId/groupIds.
Is my doubt clear?
yes
we need to ship those transitive dependencies so this isn't such a worry to me
I don't understand.
I add another info: every pom used is installed in the local repository
by maven, so it is important that a given
groupId:artifactId:version:specifier identificator always results in the
same pom or a pom with identical informations to the one published in
the central repository (that is what maven declare as official by using
it by default).
So if we ship our own junit.pom using the same artifactId/groupId but
with different dependencies (in this case there are no dependencies, but
I'd like to better analyze anyway this scenario anyway) we will probably
brake other maven2 builds (no good)
>> D) How to "evangelize" projects to make sure that future pom.xml (and
>> other resources like site.xml) includes the license header (e.g: make
>> sure maven plugins bugs are solved ASAP and high priority)
>
> step up and code the required changes...?
I don't have (currently) enough knowledge of the maven internals to
manage this. My main concern is that my impression is that the maven
core team is not aware of this specific issues and they simply are
scared of everyone in the ASF telling their own interpretation of what
maven have to do or not.
If the ASF as a whole could *summarize* what are the minimal "required"
steps to make maven usage *legal* and compliant to ASF policies I bet
they would be happy to prove that maven can fix this in few changes.
different organisations see legal risk in different ways. apache is a
long way towards the conservation end of the spectrum: we try to avoid
legal action by operating clearly and transparently in a lawful and
ethical manner.
it's a tradeoff. in order to protect release managers at apache, time,
effort, rules and paperwork are required. apache is often rightly
criticised for being slow and unagile. this is the price paid. it's
fine for people to start stuff offshore in a more agile environment:
the risks are probably minimal or at least it's a reasonably tradeoff.
- robert
I clearly understand this, but this doesn't change my opinion about ASF
as a whole should help maven (an ASF product used by many ASF projects)
to be able to make releases protecting ASF committers.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
