>>>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:[email protected]] Sent: Sunday, May 7, 2017 11:12 PM To: [email protected] 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
