All, It would be great if we could get a resolution on some of the JIRA's in legal, e.g.
https://issues.apache.org/jira/browse/LEGAL-26 https://issues.apache.org/jira/browse/LEGAL-27 https://issues.apache.org/jira/browse/LEGAL-31 https://issues.apache.org/jira/browse/LEGAL-136 Legal-discuss, As PMC Chair of a TLP I find the situation with regards to these very confusing. We have had some people state the opinion that our current practice with regards to LICENSE & NOTICE files is not "correct" yet these issues are still unresolved in the LEGAL JIRA and thus, I presume, no legal decision has been formed. Absence a clear decision from the legal PMC we have no choice but to presume that our current interpretation is just as valid as any other interpretation and therefore are continuing with our current practice, e.g. The most critical one to the Maven PMC is LEGAL-26: we have a number of SCM primary roots, for example all our plugins are within http://svn.apache.org/repos/asf/maven/plugins/trunk/ individual plugins are sub-folders within the whole, e.g. http://svn.apache.org/repos/asf/maven/plugins/trunk/maven-deploy-plugin/ We currently view the primary roots as "expected checkout points" and the individual plugins as not being so. Most developers familiar with Subversion will know that /trunk/ is a root identifier and should expect to find the LICENSE and NOTICE information at that point. Maven tooling generates a project site for every component, so you will have a page such as http://maven.apache.org/plugins/maven-deploy-plugin/source-repository.htmlwhich tells you how to checkout the code of the specific module. In some cases we have multiple modules released together as one operation, e.g. http://maven.apache.org/surefire/index.html, so you have http://maven.apache.org/surefire/source-repository.html as the real root (though in this case this is a GIT based project and at least with GIT the situation is more clear, namely put a LICENSE & NOTICE file in the root of the GIT repository... since you cannot checkout a "partial" GIT repository) So the net result is that http://svn.apache.org/repos/asf/maven/plugins/tags/maven-deploy-plugin-2.8.1/does not have a LICENSE & NOTICE file *because* it is a tag of http://svn.apache.org/repos/asf/maven/plugins/trunk/maven-deploy-plugin/which is only a partial of the "root" http://svn.apache.org/repos/asf/maven/plugins/trunk/. FTR, "best effort" can result in nothing happening at all... after all we can be an incompetent PMC, as long as we are doing our "best effort" there is no guarantee that "our best" is "good enough"... LEGAL-26 needs a very clear and exact ruling. "Expected checkout points" is too vague... I may only be interested in the java code of Maven's deploy plugin... is now http://svn.apache.org/repos/asf/maven/plugins/tags/maven-deploy-plugin-2.8.1/src/main/java/an expected checkout point? what about http://svn.apache.org/repos/asf/maven/plugins/tags/maven-deploy-plugin-2.8.1/src/main/java/org/apache/maven/plugin/deploy/or even http://svn.apache.org/repos/asf/maven/plugins/tags/maven-deploy-plugin-2.8.1/src/main/java/org/apache/maven/plugin/deploy/DeployRequest.java IMHO we should just put a standard LICENSE and NOTICE file at the root of the ASF SVN tree and projects that need to be exceptions to that general LICENSE and NOTICE should have to put the file at the point where it makes sense that is closest in scope to the content requiring the altered LICENSE and NOTICE... so, as examples are better at divining meaning, *if* we had copy&pasted some BSD code into the Maven Deploy Plugin *then* it would require a custom LICENSE and NOTICE file as the one inherited from the root would no longer be valid within that subtree... but in this case we do not have any such code, so we are fine to retain the inherited code. On 11 December 2013 05:24, Marvin Humphrey <mar...@rectangular.com> wrote: > On Tue, Dec 10, 2013 at 8:10 PM, P. Taylor Goetz <ptgo...@gmail.com> > wrote: > > It's kind of interesting to see how this has changed over time and varies > > from project to project. > > Here's Roy Fielding in June 2008, saying exactly the same thing you'll hear > from us now: > > http://s.apache.org/Y4v > > If the notices aren't required by the bits in the package, then they > don't belong in NOTICE. That means there will be a different NOTICE > file > required for each differently packaged set of bits. We must do this by > hand. > > Because the file is named "NOTICE", people tend to think it's for anything > notice-ish. This is a pernicious misconception which keeps coming back > over > and over like a weed, and it used to be that not a lot of people besides > Roy > were effective at combatting it. Here's Roy in 2008 again: > > http://s.apache.org/ZIU > > > Furthermore, I assume it is not problematic to have more stuff in the > > NOTICE file(s) than is really required. > > Yes, it is problematic. Consider it a tax on all downstream > recipients. > > Roy can't be everywhere, though, and there are a lot of TLPs who have messy > licensing documentation because they didn't get proper guidance. > > The Licensing How-To, added earlier this year, provides a cookbook approach > which is supposed to yield appropriately sparse LICENSE and NOTICE files. > > http://www.apache.org/dev/licensing-howto.html > > Hopefully the Incubator is now more consistently graduating projects whose > licensing documentation approaches the unchanging minimalist ideal. > > Marvin Humphrey > > --------------------------------------------------------------------- > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > >
