Actually, scratch that, it's fine to have the NOTICE file with the dependency information in the source as well.
Colm. On Mon, May 8, 2017 at 2:50 PM, Colm O hEigeartaigh <[email protected]> wrote: > 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 <[email protected]> > 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-d >> ocumentation >> > >> >> 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/direct >> ory/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 > -- Colm O hEigeartaigh Talend Community Coder http://coders.talend.com
