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