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.
