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