Hi everyone, Thanks for all the votes and all the discussions around LICENSE and NOTICE. We really appreciate all the effort. I would like to cancel this RC due to another issue:
- Hive Catalog cannot create table with TimestamptzType field · Issue #583 <https://github.com/apache/iceberg-python/issues/583> We will run RC2 when the issue is resolved. Based on the discussion above about the NOTICE content, let's continue the discussion to reach a clear statement/guide. Hopefully, we can resolve all related concerns before the next major release. Thanks again! Best regards, Honah On Fri, Apr 5, 2024 at 11:24 AM 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 <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 >
