When is my project a derivative work in an interpreted language?

Question

With compiled languages, I understand when a work is considered derivative of another and thus, a license such as the GNU GPL covers the whole work.

However, with interpreted languages such as PHP or Python, I am not so sure. If I find a library online that is covered under the GNU GPL v2 or later and I use this library in my PHP/Python/Ruby/... project, does the GNU GPL cover the whole work?

What about if I subclass classes from that library? Are those subclasses covered by the GNU GPL? Is the code that then uses those subclasses also covered by the GPL?

Answer 1

A derivative work is a work based on or derived from one or more already existing works.

In the arts, common derivative works include translations, musical arrangements, motion picture versions of literary material or plays, art reproductions, abridgments, and condensations of preexisting works.

In programming, as well as in the arts, a derivative work is a “new edition” of a preexisting work in which the editorial revisions, improvements, elaborations, or other modifications that is present in the whole work (i.e. the end result of combining all the different parts together to create a public facing work).

Given the above definition, it should not make any difference if the programming is compiled or interpreted. If you find a library online that is covered under the GNU GPL and you use that library in your PHP/Python/Ruby/... project in such a way that a (non trivial) part of the functionality your project depends on said library, then the project is a derived work of that library, and the whole work must be licensed under the GNU GPL.

The idea that the software architecture (dynamic vs. static linking, late binding ("plugin") vs. compiled, subclassing, etc.) are analytically unhelpful and misleading in answering the derivative work question.

The following quote from Eben Moglen and Mishi Choudhary: Software Freedom Law Center Guide to GPL Compliance 2nd Edition addresses this concern:

The GPL licenses, then, are explicit about limiting the scope of copyleft to the scope of copyright. They do not, however, as is sometimes suggested, do so in a way that distinguishes “dynamic” from “static” linking of program code in “early-binding” programming languages. It is occasionally suggested that a subroutine “dynamically” linked to GPL’d code is, by virtue of the linking alone, inherently outside the scope of copyleft on the main work. This is a misunderstanding. When two software components are joined together to make one work (whether a main and some library subroutines, two objects with their respective methods, or a program and a “plugin”) the combination infringes the copyright on the components if the combination required copyright permission from the component copyright holders, and such permission was either not available or was available on terms that were not observed.

So to answer the derivative work question, we need to examine whether combining two works together would infringe copyright (unless permission to create the combined work was granted by the GPL).

The answer to this question cannot be found by examining the software architecture of the composite work. Instead, we need to look at the actual components, and to what degree one components depends on the other to create a functional, whole work.

The question asks specifically about class hierarchies: If a subclass builds on a very generic class (e.g. Java's top level "Object class) and that subclass adds substantial functionality to the work that is not present in the generic class, it is unlikely that the subclass will infringe the copyright of the generic class, because such a generic class is not copyrightable.

In other cases, a class may be considered copyrightable, but the courts may decide that linking should be considered fair use.

And yet in other cases, if one were to subclass a very rich and functional class, for instance a class that provides checkout and payment in e-commerce context, it is very likely that such use would require permission from the copyright holder, and as a result, a subclass of this as part of an e-commerce application or website would in this particular situation, be considered a derivative work.

Answer 2

This answer is offered as a supplement to FreeRadical's fine exposition, and is focussed on subclasses.

I am not sure that it is helpful to focus on individual classes. Copyright law looks at a 'work'. If a class is intrinsically part of a work, and you build code that depends on that class, I think that there's a fair chance that you're making a derived work, regardless of the triviality of the class. I believe that The GNU classpath license was created for this reason, to 'disconnect' all Java classes that use or derive from the JRE's boot classpath from the JRE.

So, by this logic, if some interpreter is object-oriented, and the license does not specifically exempt works that use the standard library, you might be deriving from the standard library and be subject to its license. Since PHP and Python are 'permissively' licensed, they don't cause this problem; but other things (oh, here I go mentioning Drupal after suggesting that FreeRadical should not) like Drupal explicitly go here. (So maybe I was wrong to suggest that he edit that reference out.) Drupal isn't an interpreter, it's a library. Imagine that there was some GPL-licensed class library that had a trivial 'Object' class at the bottom of the class hierarchy, I am suspecting here that deriving from the class counts as 'using' the library.

Answer 3

In the case of interpreters, you get quite broad permissions through freedom 0. Freedom 0 is the freedom to run the program; this freedom is particularly unconstrained by the GPL. You can run and do whatever you want with the program, unless the output consists of parts of the program itself; copyleft only takes place when you convey/distribute something. Copyright law might see that differently, and might consider the act of running to require a license, but if it does so, you get one very liberal from the GPL.

Interpreter question in GPL FAQ

That means that you don't have to put your scripts under GPL when they run on an interpreter, e.g. bash; even when you make use of the many bash-specific constructs that make your script “depend” on in the sense that it won't run on any other shell.

This is particularly important, if you think of shar-style installers, i.e. shell-scripts that install some proprietary software that is data embedded inside a shell script and extracted by running it. If bash would “taint” that installer, all that software would have to be GPL'd. That's not established.

The whole thing is difficult, because copyright does not talk about technical things such as linking, subclassing, function calling or just running an interpreter which interprets builtins just like a C compiler calls functions — these are technical details that don't matter. Invoking a bash-specific builtin in a script from a copyright point of view is IMHO exactly the same dependency of two works as calling a function in a C library, or, for what's it's worth, using a C language element in a C program (or a GCC extension, which ties your program to GCC; and it does not help if later a clang developer clones it — the creative process of using a GCC feature is what creates the derivative work, not the existence of a clone, which, by ruling that APIs are copyrightable, is on its own a copyright violation). It might also be possible that the interpretation of the GPL that merely calling a function in a library is creating a derivative work actually depends on that interpretation of the Google vs. Oracle case (because a short reference to other works is fair use as minor citation).

That thing of interpreting a script is covered by freedom 0, the right to run a program. Running GCC translates your C source into some assembler or binary representation, and by giving you freedom 0, it can't be a copyright violation, regardless if copyright would say that using GCC extensions makes your program a derivative work of GCC: For that part, you have a license. Interpreting a script with an interpreter is just the same; that is the purpose of the interpreter.

What you do likely need is a permission to load other software into that interpreter together with your program, i.e. if you use some Python/PHP/Ruby framework stuff together with your code that makes use of the framework (and therefore by copyright is a derivative work), then you better hope that this framework is under LPGL — or your code is GPL compatible. The same applies to libraries that you interface to in your interpreter, e.g. using SWIG to bind to C libraries. You cannot use the right to run an interpreter to loophole that part.

One difficult part here might be if that C library is already a core part of the interpreter; e.g. if the interpreter offers regexps, and uses a library like PCRE to implement those (supposed that library is under GPL). The combination of interpreter and a hypothetical GPL'd libPCRE is ok, when the interpreter is GPL'd, too. The act of running the interpreter is freedom 0, i.e. unconstrained. Running an interpreter is the act of letting it interpret some script; which, in typical interpreters, is matching a lot of strings with regular expressions. That is accessing the libPCRE functionality just like linking to it, but through the core functionality of an interpreter, and therefore covered by the act of running.

That might not be legal, because the author of this GPL'd libPCRE did not give that permission of loopholing the GPL. The author of an interpreter, by defining the core parts of his interpreter, does give you a conscious permission to run it as such. On the other hand, the act of running the libPCRE is unconstrained, anyways, and the author of an interpreter like AWK should be free to use libraries for low-level stuff like regexps.

What is a core function of an interpreter? I would say something that does not require some syntactic element that reads like “include source file” or “import class”, and as such clearly refers to the imported element as not inherent part of the interpreter. If the interpreter has a scoping mechanism, accessing an already existing scope is not an import, adding a new scope by loading in the respective program is (same as dynamic linking). I.e. even if a core functionality of the interpreter gives you the ability to do C bindings on the fly, doing that does not loophole the GPL of that C libraries you can access; at some point in your bindings, you need to load that library, in which case you see that you now add another program to your program, and that's creating a derivative work.

TL;DR: Interpreter core functions are covered by freedom 0, so scripts under incompatible licenses as such are ok, regardless if they are legally a derivative work or not (they probably are). Libraries in an interpretative language are just the same as compiled libraries, if you include them, you add them to your program, just as if you link to them.