Hi stevieb,

Update - TL;DR: In this case, Perl's license (GNU GPL + Artistic License) appears to be compatible with the GPL, so you should be able to release your code under Perl's license and link to GPLv3 code. However, in general, the GPLv3 is quite strict about its requirements and one should always research this topic.

I studied* this topic back when the GPLv2 was current, and IIRC the definition of "linking" was open to some interpretation. I think the GPLv3 is more explicit, and although I haven't studied the license itself in detail, the FAQ appears to be quite explicit:

If a library is released under the GPL (not the LGPL), does that mean that any software which uses it has to be under the GPL or a GPL-compatible license?

Yes, because the software as it is actually run includes the library.

Does the GPL have different requirements for statically vs dynamically linked modules with a covered work?

No. Linking a GPL covered work statically or dynamically with other modules is making a combined work based on the GPL covered work. Thus, the terms and conditions of the GNU General Public License cover the whole combination. See also What legal issues come up if I use GPL-incompatible libraries with GPL software?

Note that Perl is dual-licensed under the Artistic License 1.0 and the GPLv1 (or any later version), and the GNU website has this to say about it:

License of Perl 5 and below

This license is the disjunction of the Artistic License 1.0 and the GNU GPL—in other words, you can choose either of those two licenses. It qualifies as a free software license, but it may not be a real copyleft. It is compatible with the GNU GPL because the GNU GPL is one of the alternatives.

We recommend you use this license for any Perl 4 or Perl 5 package you write, to promote coherence and uniformity in Perl programming. Outside of Perl, we urge you not to use this license; it is better to use just the GNU GPL.

So it sounds like the "Perl license" (dual license) is GPL-compatible, the Artistic License 1.0 alone is probably not. BTW, are you sure the library you're linking to is GPL and not LGPL? Also, of course you always have the option of contacting the library's author to get special permission, or even try to convince him/her to change the license to LGPL :-)

* Update 2016-08-12: I realized that the word "studied" may be misunderstood here. I did not have this taught to me at a university or similar, I am using the definition of "studied" meaning I researched the topic in depth on my own time. As I said in my other post, I'm not a GNU/GPL advocate, expert, or lawyer. When in doubt, don't get legal advice from strangers on the Internet ;-)

Hope this helps,
-- Hauke D

Minor updates to text.

This depends on what your jurisdiction considers a "derivative work" and "linking". Consider talking to a lawyer.

Personally, I understand the two schools of thought as follows:

The one school believes that what the (version of the) GPL says is literally so, so any kind of linking infects the other side of linking with the GPL as well.

The other school believes that "linking" has no meaning in the license and that only the "derivative work" as governed by the copyright law has relevancy, maybe even tempered by laws about providing compatibility. If you subscribe to the latter school of thinking, then you need to convince at least yourself that your code is not derivative of the (header) files of the other library.

Workarounds could be to implement a stub library which happens to use a similar interface to your library, or to provide a (GPL-licensed) shim of the library to another interface, and to have multiple backend implementations for the other interface. Then, one could argue, the other interface is not derivative and thus blocks the GPL restrictions.

See also Term::ReadLine and Term::ReadLine::Gnu + Term::ReadLine::Perl.

I've always chosen the easy way

No ad hoc expertise here, but your description of your plan seems to me to suggest that you can still go with your "normal Perl license" -- so long as the "quasi wrapper" is distributed with a prominent warning to the user that your code is linked to a C lib and #includes headers therefrom -- both of which are covered by a GPL3+ license.

Update: Restored dropped "go"

Thanks for all the great feedback all!

Because I opt to put all of my CPAN modules under the standard Perl license (and always have), I'm going to try to keep it that way.

If a library is released under the GPL (not the LGPL), does that mean that any software which uses it has to be under the GPL or a GPL-compatible license?

Yes, because the software as it is actually run includes the library.

Because my code is not compiled before it is actually installed, my distribution will not contain any code of the included library. It's only during the make process that the libs are sucked in. This leads me to believe that this is a copyright issue (like anonymonk said in Re: When linking to a C library, do I need to use its license?), as I am directly using API calls into the library, but only after a user links the two.

I think what I'll do here is contact the author, state what I'm doing, and see if I can get a blanket exemption (license and copyright) in writing, so long as I never include any code.

If that fails, I'll give my lawyer a couple hours worth of work, and if it can't be sorted within that time, I'll just GPL the code and remove the Artistic license.

Hi stevieb,

Disclaimer: I'm not a GNU/GPL advocate, expert, or lawyer, I've just spent some time researching and thinking about the issue, from both sides - I've released GPLed code, and I've been in the situation of wanting to link open source code into proprietary code often enough.

... my distribution will not contain any code of the included library ...

Your argument is one of the common counterarguments to the "any code that touches GPLed code must be GPL as well" stance. If I don't modify the GPLed code, only link to it dynamically, and even distribute the GPLed code, why should that force my code to become GPLed as well? There was - and still is, albeit smaller - a gray area as to what this "linking" thing is. However, I think the GPL has become more clear on this topic, and it sounds to me like your use of the GPLed code falls under the definition of "linking".

I'll just GPL the code and remove the Artistic license

The way I understand the GNU website is that if you place your code under the Perl license (dual license), that's GPL-compatible. But if you want to play it safe of course you can just remove the Artistic License, since under the Perl license your code is GPLed already anyway.

I get the feeling that, unfortunately, many people simply slap the GPL on their code without thinking about whether the LGPL might be more appropriate to their code, and I often think it would help them reach a wider audience. If you do contact the author, perhaps you can get him/her to consider licensing the library under the LGPL instead.

Hope this helps,
-- Hauke D

Disclaimer: I am not a lawyer. This is not legal advise.

Another option would be RPC - remote procedure call.

Similar to Corion's stub/shim library suggestion, but adds an "ether gap" between your program and the library.

As best I know, a GPL'd webserver doesn't "infect" webbrowsers with the GPL. Similarly, wrapping the GPL'd library in a RPC server should not infect the RPC clients using it (though the server itself would be infected).

Of course, always best to consult an actual IP lawyer. In this case, preferably one with open source experience.

But you are not linking to the library, are you? Do you distribute compiled objects i.e. .dll's or .so's that have been linked against the library?

Your question appears to be about copyrightability of APIs. You don't need to worry about this in connection with the GPL. It's your source, your license.