Is the Artistic License 2.0 compatible with the GNU LGPL?

Question

Perl's Artistic License 2.0 says that the source code distribution may be relicensed so long as the new license is:

(ii) a license that permits the licensee to freely copy, modify and redistribute the Modified Version using the same licensing terms that apply to the copy that the licensee received, and requires that the Source form of the Modified Version, and of any works derived from it, be made freely available in that license fees are prohibited but Distributor Fees are allowed.

The FSF says:

This license is a free software license, compatible with the GPL thanks to the relicensing option in section 4(c)(ii).

What I can't tell is if the Artistic License 2.0 is compatible with the LGPL.

It seems from the text that "any works derived from it" would also mean any binary package which links to or otherwise uses the original code, which would preclude the LGPL.

Here's an anonymized version of the specific example I'm working with.

Package L is a library distributed under the LGPL. ("L" here is for "LGPL".) It includes functionality which comes from package A, distributed under the Artistic License 2.0 (hence the "A"). The Artistic License 2.0 clause 8 clearly says:

(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.

Because package L distributes pre-compiled binaries as well as source, and it exposes a direct interface to package A, it is impossible to keep package A under the Artistic License 2.0. It seems that the solution is to use section 4(c)(ii) and relicense package A to something which is compatible with the LGPL and within the constraints of section 4(c)(ii).

However, since package L distributes precompiled binaries, which are clearly derived from package A, then it seems the source to package L must be distributed under a license which has the so-called "viral" nature of the GPL. The LGPL is not sufficient.

(It's clear that the existing LGPL'ed code inside of package L does not need to be changed. I'm concerned about the license for the code in package L which is based on the Artistic License 2.0 code from package A. If it makes a difference, this code contains some bug fixes and is not identical to what the package A vendor provides.)

I have looked for a clear statement on the compatibility between the Artistic License 2.0 and the LGPL (2.1 or newer) and found nothing. Because the Artistic License is so seldom used (Google finds only 106 pages which use the text "result does not expose a direct interface to the Package" - the initial estimate is 6,220 but go to the end and you'll see that was an overestimate), I'm not surprised there's little discussion on this topic.

Can anyone provide something more definite? That is, can a package which is based in the Artistic License 2.0 be relicensed to the LGPL?

I have been talking to the maintainers of packages A and L and we are all confused about this issue. No lawsuits will be involved, but it would be nice if this was cleared up for the future, since other packages which uses these two packages may be affected, and may be surprised that they are affected. That makes for bad community relations.

Answer 1

Interesting question! I would like to extend the question and ask if this relicensing is actually explicitly required? Given that the answer to the above question is 'yes', must package L relicense A as LGPL2.1, or can L distribute A just under the AL2.0?

Answer 2

The copyright holders can relicence any code they hold the copyright to in any way they like. What they can't do is revoke an existing licence, so the code will end up being dual licenced. This is not normally a problem.

Answer 3

If you've been talking to the maintainers of package A and they are happy with what you're trying to achieve, just not sure whether it's possible with their licensing, it may be possible for them to explicitly release their package under the LGPL too, for the avoidance of confusion. This seems like the cleanest way to resolve your issues.

You may also be able to re-license based on sections 4a or 4b; 4b could presumably be satisfied by L quite easily, as could 4a if you're the one doing the modifying. The key thing here is that the person doing the modifying is restricted, but they don't have to constrain their recipient.

It might also be wise to talk to the FSF directly, as they have actual lawyers and real experience :).

Answer 4

The LGPL is less restrictive than the GPL (thus the Lesser name) if the artistic license is compatible with the GPL then it is compatible with the LGPL since the LGPL explicitly allows you to apply the terms of the GPL instead of the LGPL (clause 3 of the LGPL)

Remember the LGPL does not allow you to distribute binaries without source, it only allows you to link your non-GPL code to the LGPL code. You are still required to distribute the source of LGPL code.

If someone is distributing LGPL code and not providing source they are in violation of the license.