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