Thanks Ryan I talked with Justin about guidance. As he's VP Legal assistant, he can point to the resources and clarify. I don't consider myself as an expert in LICENSE and NOTICE. My gut feeling is that it's not so clear even if we have pages about that. So maybe worth to clarify/simplify the pages about LICENSE/NOTICE.
We are at the service of the PMC members, so we have to help you all :) Regards JB On Fri, Apr 5, 2024 at 8:24 PM Ryan Blue <b...@tabular.io> wrote: > > 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 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, 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 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: > > 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
