License Packaging in JAVA

When packaging JAVA code the following license conventions are to be followed:

• All source code included in a single class must be licensed under (and be available for license under) a single open source license. That is, a class cannot contain code licensed under multiple open source licenses.


• The license for each class should be set forth in the source code for that class.


• JARs, which may contain other JARs, classes, and other file types, are, using the terms of the GNU General Public License, "mere aggregations." As a consequence, it is not necessary that every class or file within a JAR be licensed under the same open source license nor is it necessary that all such licenses within a JAR be compatible with one another. [N.B. - This fundamental assessment of JARs was asserted in the LGPL Whitepapre prepared by Jim Harvey on behalf of JBoss in 2005. The FSF concurs with Jim's conclusion that JARs are mere aggregations.]


• Where all classes/files included in a single JAR are under a single open source license, that license should be included in a file denoted license.txt within the JAR even though the various identically-licensed classes/files within that JAR contain the same license text. For example, such a license text file could say: "All components contained in this JAR are licensed under the GNU General Public License version 2, a copy of which may be found at XXXX."


• Where a JAR contains components (JARs, classes, files) that are licensed under a variety of licenses, include (at a minimum) a license.txt file in the master JAR with the following statement: "The various components in this JAR (JARs, classes, files, etc.) are each licensed under an open source license that permits you to copy, modify, and distribute the code in both binary and source code form. In some cases those licenses impose obligations on you when you redistribute the code. Please refer to the license information contained in the source code of each of the components for the specific license applicable to that component>"


• Although not a mandatory requirement, in the case where the JAR contains multi-licensed components it would be best practice to include with the above referenced statement a table showing each component and identifying its relevant license

This makes building with maven hard.  Right now, a test client all it has to do is archive jbossall-client.jar.  Now a user has to figure out the entire dependency graph or archinve 20 different jars.

BTW, I don't see how including non-lgpl jars breaks any license agreement.  This approach of separating individually licensed jars also has an effect on the embedded project.  We want only one monster jar in that case as it makes testing and configuration much easier.

Scott M Stark wrote:

Its beyond that. We said we could not put non-lgpl content into this, so
features like logging need other jars. It also complicates patching. The
best alternative would be to have Class-Path only jar(s) to replace it.

Adrian Brock wrote:

On Thu, 2008-02-07 at 13:18 -0800, Scott M Stark wrote:

My vote is that jbossall-client.jar is just dropped. Its just duplicate
bloat that is wrong depending on what features your using.

It's wrong because we don't test against it.

If we fixed the testsuite to only jbossall-client.jar in the classpath
then we'd quickly spot when it wasn't up-to-date.

_______________________________________________
jboss-development mailing list
jboss-development@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-development