How does the GPL static vs. dynamic linking rule apply to interpreted languages?

Question

In my understanding, the GPL prohibits static linking from non-GPL code to GPL code, but permits dynamic linking from non-GPL code to GPL code. So which is it when the code in question is not linked at all because the code is written in an interpreted language (e.g. Perl)?

It would seem to be too easy to exploit the rule if it was considered dynamic linking, but on the other hand, it would also seem to be impossible to legally reference GPL code from non-GPL code if it was considered static! Compiled languages at least have a distinction between static and dynamic linking, but when all "linking" is just running scripts, it's impossible to tell what the intent is without an explicit license!

Or is my understanding of this issue incorrect, rendering the question moot? I've also heard of a "classpath exception" which involves dynamic linking; is that not part of the GPL but instead something that can be added on to it, so dynamic linking is only allowed when the license includes this exception?

Answer 1

As for specific question regarding interpreted languages, GPL FAQ is very clear:

The interpreted program, to the interpreter, is just data; a free software license like the GPL, based on copyright law, cannot limit what data you use the interpreter on. You can run it on any data (interpreted program), any way you like, and there are no requirements about licensing that data to anyone.

As for generic question about dynamic vs static linking. First of all, FSF's and Stallman's view is that it doesn't matter if linking is static or dynamic, GPL infects either way. From FSF GPL FAQ:

If the program dynamically links plug-ins, and they make function calls to each other and share data structures, we believe they form a single program, which must be treated as an extension of both the main program and the plug-ins. This means that combination of the GPL-covered plug-in with the non-free main program would violate the GPL.

and

Linking [name of your program] statically or dynamically with other modules is making a combined work based on [name of your program]. Thus, the terms and conditions of the GNU General Public License cover the whole combination

However, this is questionable from legal point of view. In the only case that actually went to court regarding dynamic linking — Galoob v. Nintendo — Court of Appeals ruled that derivative work "must incorporate a portion of the copyrighted work in some form". Which is not the case with dynamic linking.

Anyway regardless if dynamic linking does indeed infect or not, there is work around. It's used for example by Nvidia to provide binary drivers for Linux. You create (L)GPL wrapper, but as author you are allowed to add special exception to link with specific closed-source. Vide FSF GPL FAQ.

Answer 2

Note: this is a legal question. Programmers.SE is not a legal forum, it's a programming forum. While the people here know quite a bit about programming, they don't know anything about the law. If you want to ask a legal question, you should ask that in a legal forum, where there are people who actually know something about the subject matter.

---

The GPL doesn't say anything about static or dynamic linking. It doesn't even say anything about linking at all. Every lawyer or judge I talked to says that the issue of static and dynamic linking is completely irrelevant.

Copyright is about creativity. Static vs. dynamic linking is a technical implementation detail. Whether or not something is statically or dynamically linked is not a creative act, it cannot possibly change the copyright status of a work.

In your question, you talk about "interpreted languages". But that term doesn't make sense: there is no such thing as an interpreted language. A language is an abstract set of mathematical rules and restrictions. A language isn't interpreted or compiled. A language just is. The term "interpreted language" is not just wrong, it is non-sensical. If English were a typed language, it would be a type error.

Interpretation and compilation are traits of the interpreter or compiler (duh!), not the language. Every language can be implemented with an interpreter, and every language can be implemented with a compiler. Most languages have both. Most modern language implementation even combine both in a single execution engine.

The Rubinius Ruby Implementation, for example, contains a static ahead-of-time compiler which compiles Ruby code to Rubinius byte code, an interpreter which interprets Rubinius byte code, and a dynamic just-in-time compiler which compiles Rubinius byte code to LLVM IR, which the LLVM infrastructure in turn compiles to native machine code. The MacRuby Ruby Implementation doesn't contain an interpreter at all, it compiles Ruby code straight to LLVM IR, then further to native machine code.

On the other hand, there are interpreters for C or C++.

All of this is just technical details. It is completely irrelevant to copyright.

It just doesn't make sense that whether or not someone violates someone else's copyright depends on whether or some third person chooses to run the program with an interpreter or compile it first.

The question is whether or not a work is derived from another work. It can be dynamically linked and still be derived, and it can statically linked and not derived at all.

Answer 3

No idea how much truth there is in this, and IANAL, etc.; but in my interpretation, what is important is whether the library you link against is is in some form included in the "binary" (where "binary", in the case of dynamic programming languages, is just the source code as distributed; this is what I make of the FSF's definition of "binary" in this context).

So if you reference libraries from your code without including them in your distribution, I would consider this the equivalent of "dynamic linking", whereas if you bundle the libraries with your product, or copy-paste parts of the library into your own code, the "static linking" scenario would apply. This, at least, is in the spirit of the GPL: you can freely use (run, inspect, reference) the GPL'd software without restrictions, but as soon as you derive from it (by linking or copying parts of it into your own distributable product), it goes viral, and your software must also be GPL'd.