Robert Burrell Donkin ha scritto:
On Fri, Mar 28, 2008 at 11:40 AM, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
Robert Burrell Donkin ha scritto:
apache has access to lawyers but the question needs to be clear and
> one of legality not policy
Here is the summary I wrote to legal-discuss and repository lists the
past october. I already referenced it in previous mail but maybe a
copy&paste is more explicit:
--------------------------------------------------------------
"legal issues" summary is:
1) Are the "simplest" pom.xml (artifactId+groupId+license
information+dependencies) copyrightable?
this is a poor question: too broad and open ended. the correct answer
is it depends
under US copyright, IMHO many simple pom.xml cannot be copyrightable.
however, the only way to be sure would be to test it in court.
avoiding court is a major apache aim.
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
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.
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?
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?
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 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?
The repository I was referring to is instead this one:
http://repo1.maven.org/maven2/
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/ ?
Who is sued by the author of junit.pom if this file had all right
reserved and repo1.maven.org is redistributing it?
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?
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.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
