On 23 April 2013 08:31, Sergio Fernández < sergio.fernan...@salzburgresearch.at> wrote:
> Hi Marvin, > > thanks for your time analysing our release. Please, find my reply inline. > > On 18/04/13 02:30, Marvin Humphrey wrote: > >> On Wed, Apr 17, 2013 at 11:00 AM, Sebastian Schaffert wrote: >> >> - 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. >> > > Right this would make the LICENCE files shorter. So, if I understood > correctly, we should switch from licenses text to pointers, something like: > > No; it's not necessary to switch. Roy says that pointers are sufficient. He does not say they are necessary. >From LEGAL-155: "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." > For the D3.js component, > > located at: path/to/foo/ > > Copyright (c) 2013 Foo Author, http://foo.net > > License at: path/to/foo/LICENSE > > Would be that fine? > > > - 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. >> > > So keep in NOTICE only those which require additional attribution > requirements? > > > Does anybody know any TLPs that are actually following the advice to link >> to >> source for category B dependencies in binary NOTICE files? >> > > Not sure if it is what you are looking, but we are doing it in a quite > similar way that CouchDB, since they have a quite similar setup. See its > NOTICE at: > > https://svn.apache.org/repos/**asf/couchdb/trunk/NOTICE<https://svn.apache.org/repos/asf/couchdb/trunk/NOTICE> > > > 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 > > > First, if the Incubator can make this task formulaic, success will be more >> predictable and achievable for individual podlings. >> > > Actually now it is not, at least from my point of view. Too many > subjective opinions open a huge window for potential errors. > > AFAIK, the only possible point of difficulty is whether or not a license requires an entry in NOTICE or not. > > 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. >> > > We understand that. Every single project has concrete details that need to > be addressed. But similar project should have something in common, that's > what we thought. > > > Third, if you get complaints about your RC, you can blame the howto. :) >> > > We blame ourselves ;-) > > > If Solr's NOTICE file came through the Incubator today, it would be >> rejected. >> > > :-O > > > 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? >> > > True :-) > > > 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-59> >> >> https://issues.apache.org/**jira/browse/LEGAL-62<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. :) >> > > I think now I see it more clear... > > > 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. >> > > Agree now. > > > 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. >> > > Before properly reviewing the binary releases, in the PPMC we are > discussing if such details we are discussing are something that MUST be > fixed, or just something we SHOULD improve in upcoming releases. This is > something I personally don't have clear now. Of course, we'll be wiling to > fix whatever it is necessary; but at the same time we need to move on and > continue working and improving the project. > > Thanks so much for your support! > > Cheers, > > -- > Sergio Fernández > Salzburg Research > +43 662 2288 318 > Jakob-Haringer Strasse 5/II > A-5020 Salzburg (Austria) > http://www.salzburgresearch.at > > > ------------------------------**------------------------------**--------- > To unsubscribe, e-mail: > general-unsubscribe@incubator.**apache.org<general-unsubscr...@incubator.apache.org> > For additional commands, e-mail: > general-help@incubator.apache.**org<general-h...@incubator.apache.org> > >
