Thanks Emmanuel! So if I understand correctly, the changes that were made to the NOTICE file in Kerby are incorrect:
https://github.com/apache/directory-kerby/blob/trunk/NOTICE Instead, the NOTICE file should just have the standard Apache bit. However, we need to update the distribution source code to include the NOTICE file with the added dependencies etc. Is this correct? Colm. On Mon, May 8, 2017 at 2:21 PM, Emmanuel Lécharny <elecha...@gmail.com> wrote: > > > Le 08/05/2017 à 14:44, Stefan Seelmann a écrit : > > On 05/08/2017 01:23 PM, Emmanuel Lécharny wrote: > >> > >> 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. > > Here is another one, that makes it IMHO clear that the source N&L should > > not include any information about dependencies: > > > > "LICENSE and NOTICE MUST NOT provide unnecessary information about > > materials which are not bundled in the package, such as separately > > downloaded dependencies." > > > > https://www.apache.org/legal/release-policy.html#licensing-documentation > > > >> 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. > > I agree with you. But I think it's two differenct cases: > > > > 1) The content of a distributed package. > > 1a) If the package only contains source code witten by ASF committers or > > the compiled class files then the minimal N&L applies. (Note: this would > > probably not apply if we would code against an API of an GPL library, > > that's why it's not allowed in ASF projects). > > 1b) If some source code was borrowed e.g. from some 3rd party licensed > > under MIT then we need to include that license and copyright notice. > > 1d) And only if we bundle (redistribute) 3rd party content (e.g. in an > > uber jars or binary distribution or installer) then all required N&L of > > the bundled artifacts have to be added. > > On the same page, as soon as we are talking about source package. > > > > > 2) The dependencies. As long as they are not bundled then they must not > > be added to N&L. > correct. > > > But of course it's our duty to make sure that all used > > dependencies are compatible to ALv2. And we should be nice to our users > > and list the dependencies. And in fact we do that :). All the Maven > > generated jars contain a META-INF/DEPENDENCIES file with all > > dependencies and its licenses listed. And the Maven generated source zip > > also containse a DEPENDENCIES file The only issue I see is that the > > Kerby source package (kerby-all-1.0.0-source-release.zip) contains an > > empty DEPENDENCIES (similar for ApacheDS, whereas for Fortress-core > > looks fine). It's probably because of the multi-module build, but maybe > > we can tune the Maven release build to include all dependencies for the > > whole project. > > > >> 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...) > > Here I disagree. If the users builds it then it's not our duty to > > provide prober N&L because we don't redistribute what th user builds. > > Let me clarify : when we distribute only source package (aka tar.gz of > source files) then this package dos not have to have any N&L file if we > don't embed binary components (like lib, images, whatever) in the jar, > or when we haven't copy/pasted any snippet of external code. > > Now, the trick is that users will take this package and will build > binary packages out of it, and these binary packages must have the > required N&L files. That mean the build configuration must contain the > necessary instructions to get those required N&L files to be present in > the generated binary. This is what we do for ApacheDS, with the N&L file > present in the > installers-maven-plugin/src/main/resources/org/apache/ > directory/server/installers > directory. That what I meant when I said the source package must include > the required N&L. > > To be spot on, those N&L files must not be in the META-INF subdirectory > of the source package, but be present in teh module that will generate > binary packages. > > Hop this clarify my stance. > > > >> 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. > > If and only if 3rd party dependencies are bundled within the jar (like > > an uber jar). > > On teh same page. > > > >> 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. > > Right, and it's lot of work to get it right ;) > > Absolutely. > > > >> 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 > > -- Colm O hEigeartaigh Talend Community Coder http://coders.talend.com
