Hi, Here is another example which has been graduated just a couple of months ago: https://github.com/apache/druid/blob/master/LICENSE
Kind Regards, Furkan KAMACI On Tue, Apr 7, 2020 at 2:49 PM Paul King <[email protected]> wrote: > The LICENSE and NOTICE from NIFI look good to me for the source artifact: > https://github.com/apache/nifi > > The LICENSE and NOTICE for the NIFI bundle also look good to me: > https://github.com/apache/nifi/tree/master/nifi-assembly > > HTH, Paul. > > > On Tue, Apr 7, 2020 at 9:43 PM Paul King <[email protected]> wrote: > > > Most projects should be the same. I am most familiar with Groovy and > > believe it is done correctly there. Gradle is used for building which > might > > make it harder to mimic given NLPCraft is using maven. I'll take a quick > > look at some others ... > > > > On Tue, Apr 7, 2020 at 6:53 PM Aaron Radzinski < > [email protected]> > > wrote: > > > >> Paul, > >> Can you point to some ASF project(s) that has done it right? I've looked > >> at several and they all seem to be doing differently... > >> > >> Thank you, > >> -- > >> Aaron Radzinski > >> > >> > >> > >> On Mon, Apr 6, 2020 at 9:21 PM Paul King <[email protected]> wrote: > >> > >>> Another important concept is that for any artifact, the included > >>> NOTICE/LICENSE should be the minimum required for that artifact (or > >>> instead > >>> of thinking it as the minimum, think just accurately specified for that > >>> artifact). > >>> > >>> So, the list you provide would possibly be appropriate for a zip > >>> distribution, assuming that is desirable. If that is needed, I'd change > >>> the > >>> wording from: > >>> "NLPCraft project uses or integrates with the following 3rd party > >>> software > >>> (binary dependencies) that is licensed under non-Apache License 2.0" > >>> to something like: > >>> "This NLPCraft distribution bundles 3rd party binary dependencies that > >>> are > >>> licensed as outlined below." > >>> > >>> In general, the source distribution LICENSE would not need (and > therefore > >>> should not have) those entries listed. > >>> > >>> A binary jar artifact suitable for publishing in a repo, assuming one > is > >>> needed, would also not need most (if not all) of those entries. The > >>> LICENSE > >>> and NOTICE pertain to the artifact itself not listed dependencies > (which > >>> will already contain their own LICENSE/NOTICE info). > >>> > >>> I'd also expect in general modifications to the NOTICE file. It would > >>> include any copyright notice sections from even ASF2 licensed > >>> dependencies > >>> which aren't specifically "copyright ASF", e.g. might be individuals. > In > >>> addition, if any of the third party licenses request some kind of > >>> acknowledgement, that would go in the NOTICE file(s). > >>> > >>> Cheers, Paul. > >>> > >>> > >>> On Tue, Apr 7, 2020 at 10:58 AM Aaron Radzinski < > >>> [email protected]> > >>> wrote: > >>> > >>> > Paul, Roman, et. al., > >>> > I've listed non-ASF2.0 licenses for our dependencies here: > >>> > https://github.com/apache/incubator-nlpcraft/blob/master/LICENSE > >>> > > >>> > Please review and let me know if this passes the muster. > >>> > > >>> > Thank you, > >>> > -- > >>> > Aaron Radzinski > >>> > > >>> > > >>> > > >>> > On Mon, Apr 6, 2020 at 2:58 PM Roman Shaposhnik < > [email protected]> > >>> > wrote: > >>> > > >>> > > On Mon, Apr 6, 2020 at 12:48 PM Aaron Radzinski > >>> > > <[email protected]> wrote: > >>> > > > > >>> > > > Mentors, > >>> > > > I'm confused on how to (and why) list licenses for all project's > >>> > > > dependencies. To do it explicitly is a major time sink and it's > >>> very > >>> > hard > >>> > > > to maintain it this way going forward. How do projects approach > >>> this in > >>> > > an > >>> > > > automated way? Will this be enough to provide an Apache RAT > report? > >>> > > > >>> > > It depends on what you want to distribute. There are two artifacts > >>> that > >>> > > you can > >>> > > distribute: > >>> > > #1 source code tarball > >>> > > #2 binary convenience archives (of any kind) > >>> > > > >>> > > For both your downstream consumers have know *exactly* what > licenses > >>> > > are covering: > >>> > > #1 every single line of code in every file > >>> > > #2 every single bit > >>> > > > >>> > > Now, #1 is somewhat easier since all the new code is going to be > >>> licensed > >>> > > under ALv2. Still, there will be cases when you (or your build > >>> system) > >>> > > statically pulls source code in that ends up in your release source > >>> > tarball > >>> > > that wasn't developed by you and is available under a different > >>> license. > >>> > > That has to be tracked very, very carefully. > >>> > > > >>> > > In fact, that is exactly why a lot of downstream consumers trust > ASF > >>> > > (that we won't subject them to anything by ALv2 compatible > licenses) > >>> > > and don't trust a random GH project where somebody simply slapped > >>> > > an ALv2 license on their repo. > >>> > > > >>> > > As for #2 -- this is where the hell typically breaks lose and > that's > >>> > where > >>> > > you either do the same good job you do with #1 (there are not > >>> > > shortcuts -- sorry) > >>> > > > >>> > > OR > >>> > > > >>> > > You simply decide NOT to release binary artifacts and make them > >>> > > responsibility of somebody else. A typical example of somebody > >>> > > else would be a Linux Distribution company. > >>> > > > >>> > > Or it can even be yourself with your individual's hat on -- it just > >>> can > >>> > NOT > >>> > > be ASF unless we can do the same due diligence we do for #1. > >>> > > > >>> > > Thanks, > >>> > > Roman. > >>> > > > >>> > > >>> > >> >
