On Wed, Apr 17, 2013 at 11:00 AM, Sebastian Schaffert <sschaff...@apache.org> wrote: >>> We had long discussions about the content of the NOTICE files. We followed >>> as much as possible the guidelines on the ASF websites (which are >>> sometimes a bit contradictory) >> >> Please can you advise where the contradictions are so they can be sorted >> out? > > Yes, sure.
Thank you very much for working hard to get LICENSE and NOTICE right, and for providing us with this valuable feedback. > There are currently the following documents (at least the ones I > am aware of) that are somehow related to LICENSE and NOTICE: > > 1. http://www.apache.org/dev/licensing-howto.html > 2. http://www.apache.org/legal/3party.html > 3. http://www.apache.org/legal/src-headers.html > 4. > http://incubator.apache.org/guides/releasemanagement.html#best-practice-license For what it's worth, the last document in your list is significantly less reliable than the others. It's a goal of ours to remove all those "best practice" recommendations and (frequently erroneous) duplicated policy assertions from that page, whittling it down until it contains only Incubator-specific requirements. > While similar in the most important issues, all four documents vary in some > of the details. For example: > > - The section "NOTICE file" in [3] says that "The NOTICE file may also > include copyright notices moved from source files submitted to the ASF". > The 3rd party Javascript files we include are "submitted to the ASF", but > they are often under MIT license and therefore category A in [2]. If I > read the document correctly, category A only requires to include notices > if a NOTICE file is contained in the product. According to [1], MIT and > New BSD even can have a reduced entry in LICENSE. [4] says, however, that > "All the licenses on all the files to be included within a package should > be included in the LICENSE document. " Here's Roy Fielding, ASF Board member and author of the Apache License 2.0: http://s.apache.org/Hqj Pointers are sufficient. Roy elaborates here: http://s.apache.org/Iw6 By pointers, I mean a relative path reference to the license file within some subdirectory of the package being redistributed. It used to be quite common for such license files to be alongside the respective jar in a "lib" or "srclib" directory, or inside the third party directory containing the source. The top-level LICENSE can simply point to those files (with a simple description like "under the MIT license") rather than include all of the text verbatim, particularly when the same license is repeated for many optional libraries. In any case, the intention is to allow use of whatever form seems most appropriate for the given distribution form, while still satisfying the legal requirements for each licensed work. Some projects will want to include all the text in one file. Others may not. The releasemanagement.html page is wrong. I will delete the offending section, as it offers no information that isn't available elsewhere. > - for dependencies of category B, [2] specifies that "Although the source > must not be included in Apache products, the NOTICE file, which is > required to be included in each ASF distribution, must point to the source > form of the included binary (more on that in the forthcoming "Receiving > and Releasing Contributions" document).", a fact that is not mentioned in > any of the other documents. This passage has somehow escaped my notice until now. Based on my understanding about the origins of the NOTICE file, it does not ring true. It seems to me that what works for category A should also work for category B: reference/quote the license in LICENSE and address mandatory attribution requirements in NOTICE. The goal is to satisfy the licensing requirements of the dependency, not to give credit -- so IMO linking only makes sense if that's a requirement of the dependency's license. Does anybody know any TLPs that are actually following the advice to link to source for category B dependencies in binary NOTICE files? I suspect we will want to bring this up on legal-discuss and see if we can't get that recommendation removed. > - The labelling requirement "source access" in [2] requires that the NOTICE > file contains pointers to the location of the source code for any 3rd > party library that is bundled in a binary distribution (not only category > B). [1] on the other hand does not mention this requirement and says that > everything that is not legally necessary does not belong into NOTICE. Here's Roy again: http://s.apache.org/ZEA Hey, I'm all for people having opinions on development and credits and documentation. NOTICE and LICENSE are none of those. They are not open to anyone's opinions other than the copyright owners that require such notices, and they must not be added where they are not required. Each additional notice places a burden on the ASF and all downstream redistributors. Please, folks, I am not even a Sling committer. I am speaking as the author of the Apache License. Don't screw with what I have changed. I have way more experience in these matters than everyone else at the ASF combined. If you put stuff in NOTICE that is not legally required to be there, I will remove it as an officer of the ASF. If you add it back in, I will have to duplicate the effort of removing it again. That will not make me a happy camper. It seems that we might want to make the language in the licensing howto similarly scary in order to dissuade people from adding unnecessary copyright notices to NOTICE. ;) > - [1] says that NOTICE must only include notices not satisfied by > "licensing information embedded within the dependency subtree". [2] says > "Users of Apache products must be provided with all licensing terms > applicable to any part of the product and must be given prominent notice" > as fourth guiding principle (emphasis on *prominent*, which for me means > not somewhere in the dependency subtree) I appreciate your drive to adhere to the documentation in both letter and spirit. However, the approach that I would urge podlings to take is to follow the licensing howto recipe as best they can. First, if the Incubator can make this task formulaic, success will be more predictable and achievable for individual podlings. Second, there is not exactly one right way to handle licensing, but it is costly to debate the merits of legitimate alternatives. We'll all be better off if we can find one way that works and stick to it. Third, if you get complaints about your RC, you can blame the howto. :) > Maybe "contradictory" was too strong a word. But all the four documents are > incomplete in the guidance they provide. What I found very helpful, though, > are the 4 guiding principles mentioned in [2]. Also very helpful was > looking at how other projects are doing it, in particular we looked at SOLR > and Geronimo, as they are also web frameworks bundling many different > libraries. For example, SOLR has a very extensive NOTICE file: > > http://svn.apache.org/repos/asf/lucene/dev/trunk/solr/NOTICE.txt If Solr's NOTICE file came through the Incubator today, it would be rejected. Perhaps I should go provide a patch to Solr. But I have a question -- if Solr's NOTICE had been empty, would you have kept looking at TLP NOTICE files until you found one that had the examples you were looking for? The impression I've gotten over the years is that people REALLY REALLY REALLY want to put a lot of stuff in NOTICE and it's very hard to convince them not to. > For future podlings, what would be very helpful is to improve the document > [1] as a "single point of guidance" that collects all the information from > the other documents (if it is correct). +1, with the proviso that whenever possible it should link to policy documents rather than duplicate their content. > In particular, best practices for different types of projects would also > help a lot, especially to people who are not legal experts (like me). > Because apparently, many of the top level projects (like SOLR) are not > really best practices. * Practices have changed over time. * There is no central authority auditing LICENSE and NOTICE for TLPs on a regular basis. > What would also help is to give more understanding what a notice actually > means. The word "notice" doesn't have one specific legal definition which applies in all contexts. It's going to depend on what all those wonderfully diverse licenses out there require. :P Nevertheless, perhaps this paraphrase of Roy helps to illustrate the kind of thing that goes in NOTICE: http://s.apache.org/jP While at ApacheCon NA 2013 in Portland, I buttonholed Roy and asked him to expand on this comment. Here is my understanding of his answer, phrased as an FAQ entry: -- What are the historical motivations behind the NOTICE file? The NOTICE file serves several purposes, but the primary reason for separating NOTICE out of LICENSE in the Apache License 2.0 was to preserve the attribution requirement spelled out in section 3 of the Apache License 1.1 in a way that would otherwise have been incompatible with the GPL. When carried by the LICENSE, the attribution language constitutes an additional requirement which conflicts with the GPL. However, when carried by the optional NOTICE file instead of the license, the attribution requirement does not conflict with the GPL because the GPL requires the preservation of notices even when it subsumes all other licenses. -- > For example, if I understand correctly, the Apache License, when > used by 3rd party libraries, always requires notice. How can I see whether > other licenses also require this notice? As an example, consider the MIT > license. It explicitly says "The above copyright notice and this permission > notice shall be included in all copies or substantial portions of the > Software.". Does this mean that a copyright notice must go into the NOTICE > file (under guiding principle number 4 I would read it like "yes")? If so, > then there is a contradiction with [1]. Well, the licensing howto contains this passage... However, elements such as the copyright notifications embedded within BSD and MIT licenses need not be duplicated in NOTICE -- it suffices to leave those notices in their original locations. ... which also links to the two LEGAL Jira issues where that recommendation was hashed out. https://issues.apache.org/jira/browse/LEGAL-59 https://issues.apache.org/jira/browse/LEGAL-62 But that _still_ wasn't enough to keep those duplicated copyright notices out of Marmotta's NOTICE. :) > We followed this document very closely (I can almost recite it in my > sleep). If the recipe was complete, yes :-) But recipes typically do not > contain sentences like "NOTICE is reserved for a certain subset of legally > required notifications". :-P Perhaps it would help to mention that the "widely unpopular advertising clause from the original 4-clause BSD license" is the kind of thing that goes into NOTICE? > Thanks for checking, BTW. From your point of view, is the NOTICE and > LICENSE we have for Marmotta too extensive? Most of those duplicated copyright lines in NOTICE are not necessary and should be removed. Pointers would have sufficed for the extra licenses in LICENSE, but verbatim copies are acceptable. I didn't review the binary redistributions, nor did I run RAT, nor did I verify that only bundled dependencies were represented in LICENSE and NOTICE. I figured it was more important to get this reply out rather than delay it further in order to perform a comprehensive review. Marvin Humphrey --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
