I don't think we need the Mockito notice as it's a test dependency, right? Colm.
On Mon, May 8, 2017 at 3:02 PM, Colm O hEigeartaigh <[email protected]> wrote: > 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-n >>> on-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 > -- Colm O hEigeartaigh Talend Community Coder http://coders.talend.com
