I’m glad to see a lively debate about how to handle license and notice content. It’s something that I think we generally want more people to understand and care about because this is a critical part of maintaining an Apache project.
I have a few things to add to the conversation, starting with pointing everyone to LEGAL-234 <https://issues.apache.org/jira/browse/LEGAL-234> where I think this question was asked and already answered by Mark Thomas. The question was whether the boilerplate NOTICE content needs to be copied if you’re including content from other ASF projects and the answer was that you do not need to include it. This makes sense because both projects “include software developed at The Apache Software Foundation” — the ASF doesn’t need to duplicate attributions to itself. In addition, this fits with the general guidance: “Do not add anything to NOTICE which is not legally required.” I think there is also a question about where third-party licenses should go and for that the PMC has already decided to document third-party licenses in LICENSE (including other ASF projects as LICENSE is less restrictive). This is to comply with the third-party bundling policy <https://infra.apache.org/licensing-howto.html#permissive-deps>, which states: In LICENSE, add a pointer to the dependency’s license within the distribution and a short note summarizing its licensing . . . Under normal circumstances, there is no need to modify NOTICE to mention a bundled dependency. Here’s the part of ASF policy <https://infra.apache.org/licensing-howto.html#alv2-dep> that states the modification to LICENSE for an ASF dependency is optional: Assuming that the bundled dependency itself contains no bundled sub-components under other licenses, so the ALv2 applies uniformly to all files, there is no need to modify LICENSE. However, for completeness it is useful to list the products and their versions, as is done for products under other licenses. A strong reason not to modify NOTICE is that it puts additional requirements on downstream projects. Also from the ASF policy <https://infra.apache.org/licensing-howto.html#mod-notice>: It is important to keep NOTICE as brief and simple as possible, as each addition places a burden on downstream consumers. One last thing: I’d appreciate it if everyone participating in discussions about licensing would please take the time to cite sources and examples. This stuff is not easy and I think that being specific helps in a couple ways. First, everyone learns more because some people just aren’t going to go read the docs. And second, the complexity here makes it possible that there is conflicting information out there. So it’s much easier to follow an argument that cites the policy rather than one that makes an assertion about what it says if you go find the right section. Thanks, everyone. Ryan On Fri, Apr 5, 2024 at 1:24 AM Jean-Baptiste Onofré <j...@nanthrax.net> wrote: > Hi Fokko > > Fully agree, it's always "interpretation" and we are often struggling > about NOTICE content (especially during the incubation period). > Let me chat with Justin, Shane and others about this to have a clear > statement and update the "guide/documentation". > > Thanks ! > Regards > JB > > On Fri, Apr 5, 2024 at 9:39 AM Fokko Driesprong <fo...@apache.org> wrote: > > > > Hey everyone, > > > > First of all thanks for all the votes. > > > > Regarding the discussion around the NOTICE. We all agree that when > something is bundled, it needs to be added to the notice. However, Laynes > Law of Debate comes into play: what's the definition of bundling? To expand > on #413: > > > > Hive/Thrift: We don't include anything in the release that comes from > Thrift or Hive directly. We use Thrift to compile the definition Hive > definitions to Python, and those are included. I believe an update to the > NOTICE is not required here. > > Avro: We took the de/encoders as a starting point for our Avro > implementation. This code was modified making it work with an Iceberg > schema, rather than an Avro schema. The LICENSE was updated to attribute > the original authors. I can see that this is considered bundling. > >> > >> This is the problem when people copy what other projects are doing. In > general, it is right, but sometimes, it is not. Also, you may not > understand why it was done in a certain way. I frequently have to point > this out to Incubating projects. I hate to have to say to an Incubating > project not to follow this project's example. > > > > > > It would be great to update the licensing to explicitly mention how to > handle borrowed code. Currently, it is unclear since every project does it > differently. For example, Hive, where the NOTICE is empty. If you search in > the repository for the word borrowed, on the first page you already see > code from HBase and Hadoop. I would love to see the how-to being updated to > explicitly mention how to handle borrowed code. > > > > Kind regards, > > Fokko > > > > Op vr 5 apr 2024 om 09:08 schreef Justin Mclean < > jus...@classsoftware.com>: > >> > >> Hi, > >> > >> > I think you are right, some 3rd parties (including Apache projects) > >> > are missing in the NOTICE file (you and I already mentioned that in a > >> > previous release). We should at least mention this. I pointed Apache > >> > Karaf NOTICE as example. > >> > >> This is the problem when people copy what other projects are doing. In > general, it is right, but sometimes, it is not. Also, you may not > understand why it was done in a certain way. I frequently have to point > this out to Incubating projects. I hate to have to say to an Incubating > project not to follow this project's example. > >> > >> > I propose to not block releases due to that (as it's like this for a > >> > while) and propose to PR to fix that and discuss/document why the > >> > change. > >> > >> I'm not on the PMC, so even if I did vote, it wouldn't count. I would > not treat it as a blocker for this release, but it would be great if it > could be fixed before the next release. > >> > >> Kind Regards, > >> Justin > -- Ryan Blue Tabular
