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