[ 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.
>> Can
>> 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.
>
> Matt
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
>> copy".
>
> 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
> packages.
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
> suffice.
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!
Best regards,
Andrew
[email protected]
--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]
