It's a very good reading and I learned a lot. Thanks!!! Sent from iPhone
> 在 2017年5月8日，下午7:23，Emmanuel Lécharny <[email protected]> 写道： > > > >> Le 08/05/2017 à 11:26, Colm O hEigeartaigh a écrit : >> Hi Emmanuel, >> >> Is there a wiki page or something that you are aware of at Apache that >> clearly lays out what the obligations of projects are for licenses + notice >> files for third party dependencies? It's something I've yet to clearly wrap >> my head around. > > I think the page is the one pointed out by Stefan : > > https://www.apache.org/dev/licensing-howto.html#bundled-vs-non-bundled > > The thing is that it's not really clear to me too, because there is no > example on this page. > > The logic is the following : we are distributing packages (either > sources or bianeis - for convenience, as The ASF is only required to > deliver source packages for the users to build them -), and we *must* > not give an opportinuty for our users to make a mistake and embed an > incompatible component, or forget to add a required notice or license in > their own packages, putting them at risk of being sued because of that. > > We can think that if a company is going to use our packages should do > their due diligence, but that is putting too much of a burden on them. > More important, it would be very bad PR for The ASF if we were to forgot > some of teh required N&L. > > > So what does it mean for Kerby, specifically ? Let's check teh different > use cases... > > 1) We are distributing sources only > > Ok, so we basically don't distribute any binary (libs or exe). Our users > *must* build Kerby if they want to use one of the packages, or > copy/paste kerby's code in their one code. Are we safe ? Not that much, > as building the packages may pull some external dependencies and add > them in the produced jars (typically, slf4j). In this case, the produced > packages *must* include the embedded jars' N&L, if they are not fully AL > 2.0, or if they required us to do so for any kind of reason (an AL 2.0 > bundle may have a NOTICE file that requires us to embed it. It could be > attribution, a tribute for the cat's author, or anything...) > > 2) We are distributing binaries > > And, yes, the jars pulled from Maven *are* binaries. Again, we have to > make sure that those binaries contain all the required N&L for all the > embedded components in our jars. > > 3) We are distributing installers > > This is not Kerby's choice, it's ApacheDS and Studio choice, so I'll > explain what is required for teh sake of clarity, but it wo'nt apply to > Kerby. Installers are usually binaries that generate binaries. We have > to verify that the installer's binaries are fully AL 2.0 compatible, and > that the generated installers contain all the required N&L too. > > > Last, not least, it's unecessary to embed N&L for component that aren't > bundled, like tests, or tools we use to build the packages. One notable > exception, for instance, would be antlr : it's a tool, so we don't have > to add the antlr N&L in a source package, because we don't embed antlr > in the source package. But when we run the build and generate a binary > package after havig processed some antlr files, then we have to embed > teh antlr N&L, because buidling the source will generate some file > produced by antlr (typically myFile.g --(antlr)--> myFile.java) that > contain some antlr dependency, and the binary package will require a > antlr library to process the java file. > > Why should we not add extraneous N&L files ? Because that would make our > user's task too complex, and we don't want that. > > > One last note about GPL/LGPL dependencies : GPL are clearly a no-no for > us. As GPL is a contaminating license, taht would make all our code GPL. > That one of our user decide to embed a GPL component is not our > business, but in any case, they expect our packahes to be AL 2.0, not GPL. > > LGPL is slightly different, but for teh exact same reason, we can't > embed such a component in our packages. What we can do though, and this > is what we do for MINA, is to tell users : "ok, if you want to use this > specific LGPL library which is required fr that specific functionality, > then you have to build the package yoruself, using a specific flag". For > MINA, we have a flag for the rxtx package, which is LGPL : building MINA > with this package requires the user to run 'mvn clean install -Pserial" > where the 'serial' flag will embed the rxtx library. But when we release > MINA, we don't use this flag, so our packages never embed rxtx. > > > I hope this is clear enough, but to be frank, this is not a simple > thing, and this is my understanding on how it works... > > > -- > Emmanuel Lecharny > > Symas.com > directory.apache.org >
