directory-kerby mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Colm O hEigeartaigh <cohei...@apache.org>
Subject Re: Questions about the release
Date Mon, 08 May 2017 19:40:06 GMT
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 <coheigea@apache.org>
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 <coheigea@apache.org>
> 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 <elecharny@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-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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message