Mailing-List: contact kerby-help@directory.apache.org; run by ezmlm
Precedence: bulk
Reply-To: kerby@directory.apache.org
MIME-Version: 1.0
Reply-To: coheigea@apache.org
In-Reply-To: <CAB8XdGARDFa0R8CzuSTrgpGiZyYv_M6+OnL28AH=zO+ZqVH1_A@mail.gmail.com>
References: <6bdac7ec-15ea-bd9e-6694-48385808d3a9@gmail.com>
 <9037BCED616A964EB486B12FCA9DCFCF3BC8E2F0@SHSMSX103.ccr.corp.intel.com>
 <CAG8=FRhOUF7mmjb3twbaByyePN=MyeYWi9suGw0fvKGSyU1Xnw@mail.gmail.com>
 <CAB8XdGDVP897fxq+Yphm7Uacx=T61P+dwcqRtGPA+FoaCAdrEg@mail.gmail.com>
 <fd5d5d3a-91a0-8ac9-4ed7-0ecdbf74d7f8@gmail.com> <09878766-2827-aa2f-ee91-e6515cd83243@stefan-seelmann.de>
 <b026f400-8575-f17e-2679-401205a8bb64@gmail.com> <CAB8XdGARDFa0R8CzuSTrgpGiZyYv_M6+OnL28AH=zO+ZqVH1_A@mail.gmail.com>
From: Colm O hEigeartaigh <coheigea@apache.org>
Date: Mon, 8 May 2017 15:02:16 +0100
Message-ID: <CAB8XdGBOWNgB3FmrjefP61N5izTavhLaS7+gsC7EynPHq9Zaqg@mail.gmail.com>
Subject: Re: Questions about the release
To: kerby@directory.apache.org
Content-Type: multipart/alternative; boundary=94eb2c13dfa6cfe595054f03afa8
archived-at: Mon, 08 May 2017 14:02:19 -0000

--94eb2c13dfa6cfe595054f03afa8
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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=C3=A9charny <elecharny@gmail.c=
om>
> wrote:
>
>>
>>
>> Le 08/05/2017 =C3=A0 14:44, Stefan Seelmann a =C3=A9crit :
>> > On 05/08/2017 01:23 PM, Emmanuel L=C3=A9charny wrote:
>> >>
>> >> Le 08/05/2017 =C3=A0 11:26, Colm O hEigeartaigh a =C3=A9crit :
>> >>> Hi Emmanuel,
>> >>>
>> >>> Is there a wiki page or something that you are aware of at Apache th=
at
>> >>> 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-bundle=
d
>> >>
>> >> The thing is that it's not really clear to me too, because there is n=
o
>> >> example on this page.
>> > Here is another one, that makes it IMHO clear that the source N&L shou=
ld
>> > 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 tha=
t.
>> >>
>> >> 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 wou=
ld
>> > 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 o=
f
>> > 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 no=
t
>> > 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 user=
s
>> > 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 z=
ip
>> > 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 mayb=
e
>> > we can tune the Maven release build to include all dependencies for th=
e
>> > 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 muc=
h,
>> >> 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 t=
o
>> >> make sure that those binaries contain all the required N&L for all th=
e
>> >> 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 hav=
e
>> >> 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 f=
or
>> >> 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 th=
is
>> >> is what we do for MINA, is to tell users : "ok, if you want to use th=
is
>> >> specific LGPL library which is required fr that specific functionalit=
y,
>> >> 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 -Pseria=
l"
>> >> 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
>


--=20
Colm O hEigeartaigh

Talend Community Coder
http://coders.talend.com

--94eb2c13dfa6cfe595054f03afa8--