On Tue, Apr 23, 2013 at 12:31 AM, Sergio Fernández <sergio.fernan...@salzburgresearch.at> wrote:
>> 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: > > 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? As sebb notes, it's fine either way. >>> - 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? The answer as to whether a dependency requires something in NOTICE varies according on its license. There's no official definition anywhere as to what "additional attribution requirements" might mean, so I can't answer directly. What I can say is: * Don't put anything in NOTICE for the sake of an MIT-licensed dependency. * Don't put anything in NOTICE for the sake of a three-clause BSD dependency. * For an ALv2 dependency, follow the instructions in the licensing howto. * For all other licenses, either guess :( or ask. I say "guess" because that's what the ASF currently forces PMCs to do, not because it's a good idea. With the exception of MIT, three-clause BSD, and ALv2, we don't yet have documentation about what various licenses require as far as NOTICE. Assembling that information will take time. We'll probably need to open an individual LEGAL Jira issues for each license, e.g. Does bundling a dependency under the Python Software Foundation license require any additions to the ALv2 NOTICE file? http://opensource.org/licenses/PythonSoftFoundation.php >> 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 Thanks for that. At a glance, many of those dependencies seem to be available under MIT and three-clause BSD licenses, so inclusion in NOTICE at all is unnecessary. The CouchDB folks would be getting the same critique as Marmotta if their NOTICE came through here today. >> Third, if you get complaints about your RC, you can blame the howto. :) > > We blame ourselves ;-) Well, that stinks. :P The Marmotta community -- both core developers and Mentors -- worked really hard to get this right. The amount of effort you folks put in should have been enough. >> 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 :-) I don't relish the prospect of sweeping through TLP licensing, but if podlings continue to be misled by poor examples, that's what we'll need to do. Probably auditing a dozen of our highest profile projects would go a long way. > 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. The inclusion of unnecessary information in NOTICE is a licensing documentation bug. It makes life harder for downstream consumers of your product who are reading LICENSE and NOTICE and trying to ensure that they comply with our licensing requirements. Personally, I don't intend to vote -1 on this specific Marmotta release candidate because of the NOTICE file. You worked hard to follow the instructions as best you could. The Incubator had its *own* documentation bug, and its unfortunate that you fell afoul of it. I may be failing to uphold Roy's directives by abstaining, but that's my plan for now. In the future, I may vote -1 on other podling release candidates that have similar issues, if the podling does not have similar extenuating circumstances. Marvin Humphrey --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
