Re: Artistic and LGPL compatibility in jar files
[ on combining LGPL and Artistic Licenses in a single JAR file
as part of a Java library distribution.]
On Dec 12, 2009, at 3:26 PM, Matthew Johnson wrote:
> I believe that neither of these licences specify the licence of the code
> they are linked with, so this will be alright. The resulting licence of
> the package will be _both_, applying to different parts, AIUI.
Both licenses mention linking, although in the Artistic License it's an irrelevant reference. In 2.0 there's a direct statement about linking - section (8).
I wasn't sure if the jar file counts as a derived work in its totality, or if it counts as an aggregate. If I read the Artistic License correctly then it does seem to limit itself to "textual changes", which I didn't catch the first few times I read the license.
There is a clause about object code. If a distribution includes object code then it must do at least one of four possibilities. Option (c) is
c) accompany any non-standard executables with their corresponding Standard Version executables, giving the non-standard executables non-standard names, and clearly documenting the differences in manual pages (or equivalent), together with instructions on where to get the Standard Version.
and is the easiest to do, since the JAR distributes no executable. So with the Artistic License it's clear (now) that there's no imposition on the license terms for the other packages in the jar.
Interestingly, the license does mention linking in a strange way, given that this is a Java package (but obvious given the Perl source):
7. C or perl subroutines supplied by you and linked into this Package shall not be considered part of this Package.
It's a moot point since CDK links to the Package and not vice versa.
The above was for the Artistic License. For Artistic License 2.0 there is a section on linking.
Aggregating or Linking the Package
(7) You may aggregate the Package (either the Standard Version or Modified Version) with other packages and Distribute the resulting aggregation provided that you do not charge a licensing fee for the Package. Distributor Fees are permitted, and licensing fees for other components in the aggregation are permitted. The terms of this license apply to the use and Distribution of the Standard or Modified Versions as included in the aggregation.
(8) You are permitted to link Modified and Standard Versions with other works, to embed the Package in a larger work of your own, or to build stand-alone binary or bytecode versions of applications that include the Package, and Distribute the result without restriction, provided the result does not expose a direct interface to the Package.
If the JAR is an aggregate then (7) applies, but as CDK uses and exposes the API, I strongly suspect (8) is the one which applies. That is why the CDK will have to take the relicense clause, which is why I want to know if the Artistic License 2.0 relicense requirements are compatible with LGPL 2.1.
>> the LGPL 2.1 library include functionality which requires
>> this unalterable schema definition?
> Well, the biggest problem is that the CC-ND licence is not DFSG free, so
> inclusion of this at all would require putting the package in non-free.
I've forwarded this to the CDK maintainer. He's going to look into pulling out that one file so it's not needed in the core. Thanks for the clarification!
>> This software library and program are available under the "Artistic
>> License", which you can read in the Sourceforge details and in the
>> distributed pom.xml file. The distribution also includes the file
>> LICENSE.txt, saying:
> This doesn't sound like the two things being included in the same
> package? I'd expect it to depend on them at build and runtime.
I'm sorry, I didn't understand your comment. The source and jar distributions are named "JUMBO" and CML is a library distributed as part of JUMBO.
>> I tried to read and understand the Artistic License but I got
>> confused. The simplest conflict seems to be that the Artistic License
>> says "You may not charge a fee for this Package itself." where
>> ""Package" refers to the collection of files distributed by the
>> Copyright Holder, and derivatives of that collection of files created
>> through textual modification." This is in conflict with the LGPL 2.1
>> clause "You may charge a fee for the physical act of transferring a
> This may well be a problem for combining things into a single package,
> but I would not have thought it was an issue for things in different
Currently the CDK distributes everything in a single jar. One solution might be to distribute two jars. This does have some downstream difficulties. The JChemPaint Java applet uses CDK and it distributes a single applet jar. It would have to rearchitect a bit so there are two jar files, one with the JUMBO/CML code. This is possible, and I think would be an acceptable interpretation.
>> I read that the FSF considers the 2.0 license
>> compatible with the GPL because of the relicensing clause 4(c)(ii),
>> which allows the GPL.
> In this case the whole work would be distributed under the full GPL, not
> the LGPL
I read this and the rest as you confirming that my understanding is correct. Thank you for that.
> A simple statement from the copyright holder(s) (all of them) should
Right now we're trying to get something definite out of them. They raised the issue that no one has complained about it in the 10 years the package has been available and they would rather work on code and science than worry about detailed legal issues.
> regardless of this (and I think the schema can be data for these
> purposes, so yes), it can't go in Debian main.
The main CDK developer is worried about the legality of things, and making sure the package fits into Debian and the downstream users of the CDK know about the issues. This should be resolved within the next month, either by clarifying the license and/or by removing that one file from the main distribution and doing a new cut of CDK in January, and possibly also doing some refactoring of the jar files.
Thank you for your time!