As far as I understand it, the GPL only governs distribution. As the GPL is implemented via copyright and the concept of a "derived work", and use of an API is not a "derived work", the interpreter gap that Perl creates insulates your code while using a GPLed library. Any XS wrapper (statically) linking to a GPLed library gets infected by the GPL, but that's where the infection ends. If you want to play it really safe, you can write a second implementation to the same API, like Term::ReadLine::Perl is for Term::ReadLine.

Any XS wrapper (statically) linking to a GPLed library

As far as I understand dynamic linking of GPL libraries with proprietary programs are not allowed either. There was a famous email conversation between RMS and Bruno Haible where they discussed this question.

There is no fact, mere "discussions with a lawyer" regarding dynamic linking, and I don't see the linking that Perl does (dynamically loading object code) as "creating a derivative work" in the same sense that linking to a C header creates a "derivative work", because to use the API from Perl does not involve the C headers.

Building the XS component involves the C headers and thus makes the XS component a derivative work, but that cannot infect the Perl program, no matter how much RMS wants this to.

... is one triggering GPL obligations simply by "use"ing it?

The GPL only covers redistribution of verbatim or modified versions. If you do not distribute the code, the GPL does not apply.

Now, as far as I understand, this aspect of the GPL has never been really tested in court in any language, nevermind perl.

German courts have upheld the GPL. It doesn't matter though, because if the GPL is invalid, then you're down to standard copyright infringement, and you have no right to redistribute modified or verbatim versions.

The real question is whether the code you write constitutes a "derivative work" of GPLd code. This is where you need good legal advice.

The author of this module listed a copyright date as of 2002 and nothing about the GPL and he uploaded it to CPAN. Given that everyone understands to place it CPAN means that it will be distributed to CPAN source nodes, he was OK with that method of distribution.

As for whether you can distribute it yourself on a CD, well, that is something else. The reason is that the author could never change his mind and stop distributing it. At least with CPAN, if he wishes, he can turn around and say that this is no longer accessible(whether this is practical is an exercise for the reader...).

As Corion pointed out, perhaps you would be better off reimplementing the module on your own since it is fairly small and would be easier to do than argue with a bunch of lawyers.

As for dual licensing, it allows a customer who wants code changed and does not want those changes distributed (for whatever reason). The dual license gives the author a private version for clients and a public version(GPL) for everyone else.

It's a bit hard for me to see what your main question is, but I'll try to shed light on some things anyway, hope it helps (disclaimer: I am not a lawyer and have no insight into licensing laws beyond what anybody has through the Internet).

If a Perl module on CPAN does not include a license, you cannot use or redistribute it without risking copyright infringement. No matter what CPAN is for in spirit, without a license the author has sole copyright over the code he posted and they could take you to court if they found you were using it (whether they'd win and what the repercussions would be is another matter, but for me personally the risks would be too high). So I believe your lawyers are right in regard to Sort::Topological.

If a program links to a GPL'ed library, and you distribute said program, you need to put it under a GPL-compatible license. Opinions apparently differ on whether "use"ing a Perl module constitutes "linking to a library" or not. Corion seems to think it does not (and from my reading, neither does the README file distributed with Perl), I believe it does, and so does the FSF. So IMO, any Perl script that uses a GPL-only (i.e. not dual-licensed) module needs to be distributed under a GPL-compatible license.

If your GPL'ed application wants to link to a library with a license not compatible with the GPL, you, and all other copyright holders of your program need to specifically allow linking your program to this library by modifying the license to your program. I put part of the last sentence in bold because this means that the copyright holders of any GPL-only libraries you use are also copyright holders to your program, so you need them to modify their license as well (see here for further explanation and an example of such a license modification).

So, for example, we have program frobnicate.pl (written by you), which also uses the module Frob.pm(copyright A.Frob, license GPL) and Nic.pm (copyright N.Nac, license Artistic 2.0/GPL). You also want to use module Evil.pm (copyright Evilcorp, license proprietary). To do so, you need to license frobnicate.pl under the GPL and write a specific permission into the license allowing use of Evil.pm. You also need to get A.Frob to do the same for Frob.pm. You don't need to bother N.Nac, since you can use his module according to the Artistic License 2.0, which includes a relicensing clause. If you also want to use Nary.pm (licensed under the Artistic License 1.0) I believe things are rather hairy and it is unclear to me whether you can legally include Nary.pm into a GPL'ed program without getting the author to relicense it under the GPL with an exemption clause.

Accordingly, a GPL app would not be able to use both DBD::DB2 and DBI, if DBI were a GPL-only module. Luckily it is dual-licensed, so that you can use the Artistic License for DBI and don't need to do anything. Unfortunately, DBI uses "the same license as Perl itself", which for Perl 5 is the Artistic License 1.0, which means that you are on previously mentioned murky ground if your application does indeed need to be licensed under the GPL (for example because it uses a third, GPL-only module). This probably comes as a bit of a surprise to you (it does to me), I'd be interested to hear any clarification on this that anyone can offer.

Just as an addendum, the linking of non-free libraries also has a special exemption for "system libraries" (i.e. ones distributed with the major components of your operating system), but that shouldn't matter to you, because I believe no Perl module falls under that exemption.

And I believe you are correct that the "dynamic linking" aspect of the GPL has never been tested in court, and I've never heard of a GPL court case that involves Perl modules either.

Suppose the license on some module "A" requires that all other programs, modules, libraries, ... must be under a similar license if they make use of module "A".

What would be the sanction if some module "B", explicitly or implicitly, does not obey this rule?

It would mean --IMHO-- that module "B" makes illegal use of module "A", but not that module "B" would get automatically tainted by the license of module "A". The effects of not obeying the rules of the license of module "A" would most probably mean that you are not allowed to use module "A" (but the licensing rules might provide otherwise: they could e.g. provide that you now have to pay a fee to the author of module "A").

The GPLv3 says:

8. Termination.

You may not propagate or modify a covered work except as expressly provided under this License. Any attempt otherwise to propagate or modify it is void, and will automatically terminate your rights under this License (including any patent licenses granted under the third paragraph of section 11). It doesn't say: your work is now virally infected by GPL, whether or not you include the GPL in your work.

So to summarize: the "failure" of the author of Sort::Topological to add a GPL sort of license, does not allow you to assume that it somehow, somewhere attracted a GPL form of license, even if the author was under an obligation to GPL his code. If he erroneously didn't, that is his mistake, but you cannot remedy that by adding or assuming the existence of a GPL license yourself. I'm afraid your lawyers were right in saying "no".

Something in my lawyer's mind says me that a module not explicitly under GPL, cannot become GPLed because it uses or otherwise links (statically or dynamically) to another GPLed module.

True. The collective program may have the GPL apply because it is a derivative work of a GPLd component. That does not mean that all of the other components must have the GPL apply to them.

Suppose the license on some module "A" requires that all other programs, modules, libraries, ... must be under a similar license if they make use of module "A".

Use is irrelevant. The GPL only applies to distribution.

To be more precise it's http://www.gnu.org/licenses/gpl-faq.html#IfInterpreterIsGPL

Another similar and very common case is to provide libraries with the interpreter which are themselves interpreted. For instance, Perl comes with many Perl modules, and a Java implementation comes with many Java classes. These libraries and the programs that call them are always dynamically linked together.

A consequence is that if you choose to use GPL'd Perl modules or Java classes in your program, you must release the program in a GPL-compatible way, regardless of the license used in the Perl or Java interpreter that the combined Perl or Java program will run on.

• commercial
• WTFPL
• GPL

And, thankfully, most code on CPAN is dual-licensed (though not always obviously so - sometimes it's in the POD, which makes it very difficult to abide by the lawyer's rules that I can't download the code without corporate approval, and I need to tell them what license it's under...).

I say, if it's on cpan it's fair game no matter how you cut it. After all, for software to be useful it most typically needs to be distributable. I'm just saying there is a significant implied license (although I know that lawyers don't like that).

From cpan contributors part of the faq:

http://www.cpan.org/misc/cpan-faq.html#How_contribute_modules

However, I was surprised not to be able to find a place where you must agree to a license to upload.

Just for the sake of argument, let's say that your lawyers conclude that you can NOT use Sort::Topological. Would it be that hard to "roll your own"? I mean, the source for the module is pretty short (especially after you strip out all the comments, POD, etc.), and it implements a fairly straight-forward algorithm easily found in any textbook on graph theory. You might even clean it up a little, find a spot to optimize here or there, etc. You can call the end result My::Topological::Sort, and slap your own GPL verbiage on it (and post it to CPAN). Problem solved?

Nothing in its Makefile.PL, or its README or anywhere that I can see would allow me to re-use Sort::Topological.

FYI: Graph is another module which also implements topological sort. And that module is licensed under the same terms as Perl itself — which I interpret as "if you can use Perl, then you can use this module".

I agree that this kind of legal questions are a rather silly waste of time... I'm pretty sure no CPAN author intended his module to pose this kind of legal problem. It's just that they probablby slapped any convenient type of license on the module when they first released it.