<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
In terms of licenses, I was referring to old discussions I thought
concluded we should err on the side of single license jars. Sacha
pointed me to this internal wiki page, the relevent contents around
licensing are copied below. The main issue is then making
jbossall-client.jar a true aggregation via its class-path manifest
header rather than an actual jar of duplicate content.<br>
<br>
<br>
<a class="moz-txt-link-freetext" href="http://intranet.corp.redhat.com/ic/intranet/wiki.html?wikicat=Engineering:JBoss:Licensing">http://intranet.corp.redhat.com/ic/intranet/wiki.html?wikicat=Engineering:JBoss:Licensing</a><br>
<br>
<!-- BEGIN CONTENT --><!-- BEGIN WIKI -->
<h1 class="western">License Packaging in JAVA</h1>
<p>
</p>
<p>When packaging JAVA code the following license conventions are to be
followed:</p>
<ul>
<li> 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.</li>
<br>
<li> The license for each class should be set forth in the source
code for that class.</li>
<br>
<li> 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.]</li>
<br>
<li> 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: "<i>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.</i>"</li>
<br>
<li> 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: "<i>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></i>"</li>
<br>
<li> 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</li>
</ul>
<br>
Bill Burke wrote:
<blockquote cite="mid:47B0549A.3070600@redhat.com" type="cite">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.
<br>
<br>
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.
<br>
<br>
Scott M Stark wrote:
<br>
<blockquote type="cite">Its beyond that. We said we could not put
non-lgpl content into this, so
<br>
features like logging need other jars. It also complicates patching.
The
<br>
best alternative would be to have Class-Path only jar(s) to replace it.
<br>
<br>
Adrian Brock wrote:
<br>
<blockquote type="cite">On Thu, 2008-02-07 at 13:18 -0800, Scott M
Stark wrote:
<br>
<blockquote type="cite">My vote is that jbossall-client.jar is
just dropped. Its just duplicate
<br>
bloat that is wrong depending on what features your using.
<br>
</blockquote>
It's wrong because we don't test against it.
<br>
<br>
If we fixed the testsuite to only jbossall-client.jar in the classpath
<br>
then we'd quickly spot when it wasn't up-to-date.
<br>
</blockquote>
<br>
_______________________________________________
<br>
jboss-development mailing list
<br>
<a class="moz-txt-link-abbreviated" href="mailto:jboss-development@lists.jboss.org">jboss-development@lists.jboss.org</a>
<br>
<a class="moz-txt-link-freetext" href="https://lists.jboss.org/mailman/listinfo/jboss-development">https://lists.jboss.org/mailman/listinfo/jboss-development</a>
<br>
</blockquote>
<br>
</blockquote>
<br>
</body>
</html>