Is the Artistic License 2.0 compatible with the GNU LGPL?

| | August 5, 2015

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.

5 Responses to “Is the Artistic License 2.0 compatible with the GNU LGPL?”

  1. I hate to answer this so late, but yes, the Artistic License 2.0 is compatible with the GNU LGPL. To start off, the Perl Foundation in their FAQ states “Several other open source and free software licenses also qualify under 4(c)(ii), including the LGPL, MPL, and the Apache license.” But just to confirm compatibility, let’s go through all the possible cases of distribution. Are you not distributing it? You can do that “without restriction”.

    Are you distributing your standard version in source form? If so, then you’re fine, because you can also do that “without restriction”.

    Is it a standard version in executable form? Then you should be telling your users how to get the AL package’s source code.

    Is it a standard or modified version that is merely linked to your LGPL code? Then you’re fine as long as “the result does not expose a direct interface to the package”, but what does that mean? In the Perl Foundation’s FAQ, they state “On the other hand, if you embed it and users can nevertheless do things like running Perl scripts, then you really are distributing Perl and need make sure that your distribution fits one of the use cases in (1)-(7).” So comply with one of the other sections if the users can do such parallel things to the AL package.

    Finally, is the AL package a modified version in executable form, as I assume you were asking? If so, then you have to comply with section 4 for its source, which would mean you would either have to give your modifications to the copyright holder, rename the package and make sure that you can still install the standard AL package beside it, or relicense it.

    That’s the thing. You can relicense AL material under any license you choose. You could even make it entirely proprietary, as long as you did one of those things. I’d recommend option (i), which seems the easiest.

    The Artistic License is compatible with the LGPL, even if it’s not through the relicensing option in 4(c)(ii).

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

  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 :).

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

  5. Egon Willighagen on November 30, -0001 @ 12:00 AM

    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?

Leave a Reply