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:
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
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.
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-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-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org
