When you unzip, e.g., xwiki-enterprise-jetty-hsqldb-4.1.2.zip, it is in the webapps\xwiki\WEB-INF\lib folder ________________________________________ From: devs-bounces(a)xwiki.org [devs-bounces(a)xwiki.org] on behalf of Vincent Massol [vincent(a)massol.net] Sent: Friday, July 27, 2012 5:13 PM To: XWiki Developers Subject: Re: [xwiki-devs] XWiki Enterprise 4.1.x GPL vs. LGPL question Hi Mark, I've just checked and I don't see this jar in our distribution. Could you point me to where you've seen it? Thanks -Vincent On Jul 27, 2012, at 11:07 PM, Mark Wallace wrote: _______________________________________________ devs mailing list devs(a)xwiki.org http://lists.xwiki.org/mailman/listinfo/devs

On 07/27/2012 10:59 PM, Vincent Massol wrote: It is in a 4.2-SNAPSHOT that I have locally. I agree that this is wrong and this jar should be removed. I traced to see where it comes from, and it's a dependency used by Infinispan, which means that Infinispan is in the wrong here. I created https://issues.jboss.org/browse/ISPN-2179 and I hope that it will be addressed soon. -- Sergiu Dumitriu http://purl.org/net/sergiu/

Apparently this jar is not needed at run time https://issues.jboss.org/browse/AS7-2343 But it's still pulled if you end up with it. You can wait for infinispan to get rid of it or we could exclude it ourselves Since our code is not really linking to it in the end we are ok but we should still make sure it does not end in our distro Ludovic Envoyé de mon iPhone Le 31 juil. 2012 à 01:35, Caleb James DeLisle <calebdelisle(a)lavabit.com> a écrit :

On 07/31/2012 09:54 PM, Mark Wallace wrote: You're wrong, the AGPL is actually more viral/restrictive than GPL. I traced back to JFreeChart, another LGPL library that we're using for generating charts. I don't think that we need iText, since we're not generating PDF versions of the charts, so I guess that if you want to stay clear of the AGPL, you could try to remove it from your lib directory. I raised https://sourceforge.net/tracker/?func=detail&aid=3552914&group_id=1… hoping to get this problem addressed (still no answer from Infinispan). -- Sergiu Dumitriu http://purl.org/net/sergiu/

On 07/30/2012 06:35 PM, Caleb James DeLisle wrote: I don't agree here, but when it comes to licenses nobody can be sure; even judges contradict each other. My understanding is that GPL does disperse through jars used in the same application. They're not just individual programs that happen to sit in the same zip, they are used together in the same application, with direct calls from one class to another. "Derivative work" doesn't refer to [intermediary] source code alone (the .h being copied into the .c that uses it), it refers to end programs as a whole, since the *functionality* of a library is present in the end program. The fact that we use non-xGPL libraries doesn't mean that we can use any library because the licenses don't interfere with each other. It means that Apache and BSD licenses can be used within a LGPL project, because they permit relicensing. This means that we're not using the Apache-licensed Lucene library, we're using the LGPL-licensed Lucene library derived from the Apache-licensed Lucene library. This works because: - ASL/BSD/MIT allow relicensing (they are compatible with the xGPL) - LGPL is stronger than ASL/BSD, so by relicensing we're only adding restrictions, not removing any - Since we don't actually make any changes to these libraries, we don't have to provide any source code other than what's already offered by the official code repositories of those libraries, so the fact that we're relicensing doesn't have any real implications This makes me wonder what happens with the libraries that we do modify/repackage, like Pygments and Jython. -- Sergiu Dumitriu http://purl.org/net/sergiu/