directory-kerby mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Li, Jiajia" <jiajia...@intel.com>
Subject RE: [VOTE] - Release Apache Kerby 1.0.0
Date Mon, 08 May 2017 03:29:44 GMT
>>>At this point, I don't know what we package : there is a kerby-dist sub-project,
which supposely generates the packages, but it's hard to 
>>>tell what is inside, without looking to the maven pom files and assembly files.
I'd like that to be explicit somewhere for people to check 
>>>easily the validity of the packages...

As Stefan said, we only distribute the source for Kerby. If people wants to run the shell(start-kdc.sh,
kadmin.sh, kinit.sh ,klist.sh...), he should download the distributed source code, and run
"mvn clean package -Pdist", after that, the kerby-dist module will copy the dependencies to
the kerby-dist/kdc-dist/target/lib and kerby-dist/tool-dist/target/lib.

Thanks
Jiajia

-----Original Message-----
From: Emmanuel Lécharny [mailto:elecharny@gmail.com] 
Sent: Sunday, May 7, 2017 11:12 PM
To: kerby@directory.apache.org
Subject: Re: [VOTE] - Release Apache Kerby 1.0.0



Le 07/05/2017 à 13:08, Stefan Seelmann a écrit :
> On 05/06/2017 09:53 PM, Emmanuel Lécharny wrote:
>> but I can't cas a +1 : the N&L are lacking some required external 
>> licenses (MIT for mockito, qos.ch for slf4j, BSD for harmcrest, ASM 
>> is BSD, and bytebuddy depends on it, Junit is ECL, Netty has a NOTICE 
>> file just must be included - see
>> https://github.com/netty/netty/blob/4.1/NOTICE.txt- , and has *many* 
>> dependencies on other products, that must be listed if used -see
>> https://github.com/netty/netty/tree/4.1/license-)
> I don't think we have to list all those licenses. As far as I see for 
> Kerby we only distribute the source (which is ASLv2 only) and the JARs.
> We don't distribute any artifact that bundles any third-party 
> dependency. [1] clearly states: "Dependencies which are not included 
> in the distribution MUST NOT be added to LICENSE and NOTICE. As far as 
> LICENSE and NOTICE are concerned, only bundled bits matter."
>
> But maybe I'm wrong and Maven dependencies count as "bundled"?
It depends.

First of all, we *must* have different N&L files if we distribute sources on one side
and a bnary package on another side. This is typically what we do with apacheDS : we have
the source targ.gz and a binary (the installers). As they embed different components, they
have differnet N&L files. For instance, the installers-maven-plugin/src/main/resources/org/apache/directory/server/installers/LICENSE
file contains the antlr license while the root LICENSE file does not :
it makes totally sense because we don't have any generated antlr file in the source, while
we have many in the installers.

All in all, this is the logic to follow :

* if a library is present in the package, and if its LICENSE is not AL 2.0, then add the LICENSE
file in the package
* if a library is present in the package, and if there is a NOTICE file for this lib then
it must be added in the package
* of course, we don't support any non-AL 2.0 compatible bundle (GPL/LGPL aren't accepted license)

There are specific cases : everything that is required to build the sources, and that will
not generate files (à la antlr) don't need to get their N&L added. Same thing for the
tests.

One more thing : we *may* distribute source only, but at some point, people will build it
and embed the result in their product. It's fine if our source package does not include any
N&L from bundles that are referenced by maven dependencies, as we don't bundle those dependencies
in the resulting source tar gz. But at some point, people *will* consume a library, generated
*from* the sources, and this library may content external dependencies : at this point, this
library *MUST* contain all the required N&L.

At this point, I don't know what we package : there is a kerby-dist sub-project, which supposely
generates the packages, but it's hard to tell what is inside, without looking to the maven
pom files and assembly files. I'd like that to be explicit somewhere for people to check easily
the validity of the packages...


--
Emmanuel Lecharny

Symas.com
directory.apache.org

Mime
View raw message