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