You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@incubator.apache.org by Marvin Humphrey <ma...@rectangular.com> on 2013/04/18 02:30:16 UTC
LICENSE/NOTICE revisited (was Release Apache Marmotta
3.0.0-incubating (RC8))
On Wed, Apr 17, 2013 at 11:00 AM, Sebastian Schaffert
<ss...@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-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: LICENSE/NOTICE revisited (was Release Apache Marmotta
3.0.0-incubating (RC8))
Posted by Fabian Christ <fc...@apache.org>.
Hi,
and thanks Marvin for all the valuable information. This is really helpful!
2013/4/24 Marvin Humphrey <ma...@rectangular.com>:
> 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
+1
And making such information from legal issues available in a
processible form that could be re-used by (new) tools, e.g. in Apache
Creadur, would be a huge step forward. I guess that legal issues are
always hard to be precisely handled by tools but having (more) tools
that at least provide analysis and give pointers would already help.
Best,
- Fabian (Marmotta Mentor)
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: LICENSE/NOTICE revisited (was Release Apache Marmotta 3.0.0-incubating
(RC8))
Posted by Sergio Fernández <se...@salzburgresearch.at>.
Hi Marvin,
On 24/04/13 03:30, Marvin Humphrey wrote:
> On Tue, Apr 23, 2013 at 12:31 AM, Sergio Fernández wrote:
>> Right this would make the LICENCE files shorter. So, if I understood
>> correctly, we should switch from licenses text to pointers (...)
>>
>> Would be that fine?
>
> As sebb notes, it's fine either way.
Well, since both are fine, the PPMC will discuss which way (full text
vs. linking) would be preferable in the future. Thanks for clarifying
this point.
>> 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
Perfect. I created MARMOTTA-213 to address such issue. Hopefully this
experience could contribute to clarify and improve the documentation
about that :-)
> 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.
We did our best, which I'm pretty sure is enough. In many years
developing open source I never faced with these problems with such
detail. So, even it is a nasty thing, personally I found the experience
pretty interesting and instructive.
> Probably auditing a dozen of our highest profile projects would go a long way.
Does ASF have any periodic (annually or whatever) control over the TLPs?
Setup such checking points would detect many potential issues. But you
are right, it's a too heavy task.
>> 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.
We will have that in mind ;-)
Thanks!
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
For additional commands, e-mail: general-help@incubator.apache.org
Re: LICENSE/NOTICE revisited (was Release Apache Marmotta
3.0.0-incubating (RC8))
Posted by Marvin Humphrey <ma...@rectangular.com>.
On Tue, Apr 23, 2013 at 12:31 AM, Sergio Fernández
<se...@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-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: LICENSE/NOTICE revisited (was Release Apache Marmotta 3.0.0-incubating
(RC8))
Posted by Sergio Fernández <se...@salzburgresearch.at>.
Hi sebb,
On 23/04/13 15:07, sebb wrote:
> On 23 April 2013 08:31, Sergio Fernández wrote:
>> Right this would make the LICENCE files shorter. So, if I understood
>> correctly, we should switch from licenses text to pointers
>>
> 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."
Perfect, understood.
>> 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.
So... I would really appreciate any other vote, in one way or in the
other, to know how we should proceed.
Thanks!
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
For additional commands, e-mail: general-help@incubator.apache.org
Re: LICENSE/NOTICE revisited (was Release Apache Marmotta
3.0.0-incubating (RC8))
Posted by sebb <se...@gmail.com>.
On 23 April 2013 08:31, Sergio Fernández <
sergio.fernandez@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<ge...@incubator.apache.org>
> For additional commands, e-mail: general-help@incubator.apache.**org<ge...@incubator.apache.org>
>
>
RE: LICENSE/NOTICE revisited (was Release Apache Marmotta 3.0.0-incubating (RC8))
Posted by "Dennis E. Hamilton" <or...@apache.org>.
I agree, I didn't mean to generalize about Category B "notice" requirements.
With regard to there being a standard notice for MPL, I was careless. MPL 1.1 had a template notice. MPL 2.0 just has section 3.2(a):
If You distribute Covered Software in Executable Form then:
a. such Covered Software must also be made available in Source
Code Form, as described in Section 3.1, and You must inform
recipients of the Executable Form how they can obtain a copy
of such Source Code Form by reasonable means in a timely manner,
at a charge no more than the cost of distribution to the
recipient; [...]
The license is careful to discriminate between Source Code Form and Executable Form, and there is little detail on notifications associated with an Executable Form for MPL 2.0.
I would think that providing the information in NOTICE satisfies the requirement. It would be much easier than coming up with another artifact beside LICENSE and NOTICE, which knowledgable folks already know to look for. I don't have any insight on dealing with the fact that the dependency is build-specific, however the information is provided.
- Dennis
-----Original Message-----
From: sebb [mailto:sebbaz@gmail.com]
Sent: Tuesday, April 23, 2013 10:43
To: Marvin Humphrey
Cc: orcmid@apache.org; Sergio Fernández; Roy T. Fielding; general@incubator.apache.org
Subject: Re: LICENSE/NOTICE revisited (was Release Apache Marmotta 3.0.0-incubating (RC8))
On 23 April 2013 18:05, Marvin Humphrey <ma...@rectangular.com> wrote:
> On Tue, Apr 23, 2013 at 8:39 AM, Dennis E. Hamilton <or...@apache.org>
> wrote:
> > Not so fast about dispensing with Category B requirements for pointers to
> > source code.
>
> Thank you for the specific information about the MPL. What I said was
> this:
>
> 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.
>
> We must not treat linking as a requirement of ALL category B licenses
> because
> SOME of them require it.
>
>
If the source code URL is required, then the question arises: does it
*have* to go in the NOTICE file?
Indeed is this one of the functions of the NOTICE file?
Or should it be documented somewhere else?
> Marvin Humphrey
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: LICENSE/NOTICE revisited (was Release Apache Marmotta
3.0.0-incubating (RC8))
Posted by sebb <se...@gmail.com>.
On 23 April 2013 18:05, Marvin Humphrey <ma...@rectangular.com> wrote:
> On Tue, Apr 23, 2013 at 8:39 AM, Dennis E. Hamilton <or...@apache.org>
> wrote:
> > Not so fast about dispensing with Category B requirements for pointers to
> > source code.
>
> Thank you for the specific information about the MPL. What I said was
> this:
>
> 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.
>
> We must not treat linking as a requirement of ALL category B licenses
> because
> SOME of them require it.
>
>
If the source code URL is required, then the question arises: does it
*have* to go in the NOTICE file?
Indeed is this one of the functions of the NOTICE file?
Or should it be documented somewhere else?
> Marvin Humphrey
>
Re: LICENSE/NOTICE revisited (was Release Apache Marmotta
3.0.0-incubating (RC8))
Posted by Marvin Humphrey <ma...@rectangular.com>.
On Tue, Apr 23, 2013 at 8:39 AM, Dennis E. Hamilton <or...@apache.org> wrote:
> Not so fast about dispensing with Category B requirements for pointers to
> source code.
Thank you for the specific information about the MPL. What I said was this:
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.
We must not treat linking as a requirement of ALL category B licenses because
SOME of them require it.
Marvin Humphrey
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
RE: LICENSE/NOTICE revisited (was Release Apache Marmotta 3.0.0-incubating (RC8))
Posted by "Dennis E. Hamilton" <or...@apache.org>.
Not so fast about dispensing with Category B requirements for pointers to source code.
In MPL 2.0, a common case, it is very clear that location of the source code is one of the requirements for distribution of the code in executable form or within a larger work (distributed in binary), that there must be identification of the origin of the code and where source code is available. It is insufficient to simply include the license (by reference or otherwise).
MPL 2.0 has a handy Appendix (which I have never seen followed, but I don't get out much) that stipulates a suitable notice. The key is that it must be possible for a recipient of the executable to directly find the specific source code at a suitably archival location.
This is also a requirement for distribution of most Category X works in binary form, and that applies in some cases where Category X licenses are bundled in binary distributions under sanitary conditions that satisfy ASF requirements.
- Dennis
PS: That these requirements are typically satisfied in the breach is not, it seems to me, something that is appropriate for the ASF to countenance. That there are projects out there that have never complied with such requirements is not justification. For me, it does not serve the public interest, nor does it demonstrate the care for the provenance of contributions (and dependencies) that should be the norm. Most of all, being careless about this undervalues the gift that such dependencies represent to projects that find reuse more convenient than not.
PPS: There is also a forensic value to satisfying these license requirements. In these days of rapid disclosures of security flaws all over the landscape, it is important for a recipient of executable code to know whether or not vulnerability disclosures apply to dependencies in the distribution they are relying upon and whether mitigation is called for. (Although this is also of some benefit to adversaries, it must always be assumed that determined adversaries already know.)
-----Original Message-----
From: Sergio Fernández [mailto:sergio.fernandez@salzburgresearch.at]
Sent: Tuesday, April 23, 2013 00:32
To: general@incubator.apache.org
Cc: Marvin Humphrey
Subject: Re: LICENSE/NOTICE revisited (was Release Apache Marmotta 3.0.0-incubating (RC8))
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:
[ ... ]
>> - 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?
[ ... ]
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: LICENSE/NOTICE revisited (was Release Apache Marmotta 3.0.0-incubating
(RC8))
Posted by Sergio Fernández <se...@salzburgresearch.at>.
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-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org