On Sat, Mar 29, 2008 at 2:02 PM, Stefano Bagnara <[EMAIL PROTECTED]> wrote: > 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
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... > >> 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. > 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. > >> 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 > >> 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 > >> 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. > 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. > >> 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 > >> 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 --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
