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
