incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marvin Humphrey <>
Subject LICENSE/NOTICE revisited (was Release Apache Marmotta 3.0.0-incubating (RC8))
Date Thu, 18 Apr 2013 00:30:16 GMT
On Wed, Apr 17, 2013 at 11:00 AM, Sebastian Schaffert
<> 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.
> 2.
> 3.
> 4.

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:

    Pointers are sufficient.

Roy elaborates here:

    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:

    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

    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:

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

> 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:

    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.

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

> 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:
For additional commands, e-mail:

View raw message