1 Aug
2012
1 Aug
'12
4:39 a.m.
On 07/30/2012 06:35 PM, Caleb James DeLisle wrote:
My understanding is this does not affect the licensing
of XWiki any more than the GPL packages in Debian affect the LGPL packages because they
are on the same installer disk.
The LGPL originated from the C compiling and linking mechanism where a header file was
prepended to the .c file in the compiling cycle, making what was arguably a derived work.
While the GPL is fuzzy about it, the LGPL explicitly says this is ok.
I am not aware of any claims arising from using GPL licensed .jar files being included in
a .zip distribution.
The LGPL license file only applies to the XWiki codebase itself, we use libraries which
are licensed under a range of different licenses including Apache and BSD like licenses.
That said, we do not use GPL'd libraries so this is something which will have to be
fixed, thanks for letting us know.
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/