Is linking a correct proxy for derivative work determination in (copyleft) FOSS licenses?

Question

I tend to use these simple tests to determine if the copyleft terms of a third-party project apply to the calling/reusing code:

• if the calling code is linking (statically or dynamically) with GPL-style licensed code, then the copyleft of the callee applies to the caller because the calling code is then a "derivative work" of the GPL-licensed code.

• if the calling code is (statically and not dynamically) linking with LGPL-style licensed code, then the copyleft of the callee applies to the caller because the calling code is then again a "derivative work" of the LGPL-licensed code.

These are simple tests and they seem to be generally accepted in the community. They are easy to apply and to understand technically. Or are they? And I wonder if these are correct tests. Especially linking is something that is well understood for code compiled to native binaries... but what does it mean for interpreted dynamic languages?

So is linking a proper proxy to determine that calling code is "based on" or a "derived work" of the copyleft code being called and that therefore the copyleft flows to the caller?

Answer 1

No-one knows. It's not the licence, nor the FSF, that determines what constitutes a derivative work - it is copyright law. Since no higher court has (to my knowledge) taken a position on this, we simply don't yet know. There are persuasive arguments that it does; there are persuasive arguments that it doesn't. Until courts start to rule on the issues, are appealed to higher courts, and both local and international legal consensus emerges, I don't think anyone can say for sure.

To address a possible misconception, if dynamic linking with GPL'ed code creates a derivative work, then the same is true of dynamic linking with an LGPL'ed work. The old LGPL was pretty clear about this

A program that contains no derivative of any portion of the Library, but is designed to work with the Library by being compiled or linked with it, is called a "work that uses the Library" ...

[L]inking a "work that uses the Library" with the Library creates an executable that is a derivative of the Library (because it contains portions of the Library), rather than a "work that uses the library"

No distinction is made there between static and dynamic linking.

Answer 2

Linking is a common proxy for whether or not something is a derivative work of a copyleft licensed software project, but in the LGPL case, it doesn't matter whether the linking is static or dynamic - mere linking does not create a derivative work.

Instead, you have to make modifications to the source code of the LGPL project itself for it to be counted as a new derivative work, and hence trigger the copyleft provisions.

Answer 3

The gcc license provides a very broad and irrevocable license for anyone and everyone to produce derivative works of gcc-licensed materials if those derivative works are not distributed. It also provides a very broad and irrevocable license for anyone and everyone to distribute authorized collections of files which contain the gcc-licensed works and all applicable source code therefor via wide variety of means including publicly accessible https:// servers. Further, the license has no authority over works which are not derived from any copyrightable portions of gcc material.

If the recipient of a GPL library and a closed-source library statically links them, the result would be a derived work which could not be distributable under the GPL, but the gcc license grants all the permissions necessary for to link the code if the resulting executable isn't distributed.

If a particular collection of files contains everything necessary to be a standalone authorized distribution of a gcc program or library, the gcc license would grant everyone in the universe, including the creator of a closed-source program that could be usefully linked into an executable that also contained the gcc library, to host those files on a publicly-accessible web server. Further, a program that would automatically download the open-source library from the web server that contains it would not contain any copyrightable aspects from that open-source code, and would thus not fall under the authority of the GPL.

If the closed-source program were to interact directly with the GPL library directly, there could be some questions about whether it contained any copyrightable aspects of the GPL library within it. Such a possibility could be disproved, however, by having the creator of the closed-source software publish an open-source "bridge" which communicated with its own API, and demonstrating that the software would work with a bridge that was modified to use a different library that had nothing in common with the GPL one.

The main difference between static linking and dynamic linking is not the technical aspect of how code is loaded at run-time, but rather whether any derived works containing a mix of GPL and closed-source code are distributed. A program which will dynamically link with a GPL library can be directly executable without containing any copyrightable portion of that library and thus being a derived work thereof requiring a license for distribution. An executable program which is statically linked with the library, however, would be a derived work, and could thus not be distributed in executable form.

Answer 4

Apparently I don't have enough reputation to comment. Mad hatter is not right. A clear distinction was made between dynamic and static linking. That text in the "old" LGPL seems like a big deal.

"[L]inking a "work that uses the Library" with the Library creates an executable that is a derivative of the Library (because it contains portions of the Library), rather than a "work that uses the library""

Yes, that's a distinction. With static linked code you are actually handing out copies of the GPL work in question. It's in there as part of the executable as described right there. You're distributing someone else's program, and you need permission to do that. With dynamic linking you are distributing work that is 100% your own (well, with a possible question regarding header material). The user then combines them, and in dynamic linking I'm not even sure you can say that there ever becomes one "executable" that "contains" the GPL code. That depends what an "executable" means in the context of RAM. But that's a very different question anyway. The argument used in this particular quote is about actually containing the GPL code, and with dynamic linkage that argument at best becomes a question of what the user does with it, and maybe what the provider intends the user to do with it, but certainly not about someone else's work being contained in the distributed to the user. It's a huge difference.

It's like if I sell i-phone covers. Yes, it's useless without an iphone (often not the case with software that needs a library. It loses some functionality but isn't always useless). I guess it's "derived" from the "interface" of an iphone, directly designed literally its physical interface (shape), but the cover was not made by Apple and it exists and is distributed without Apple. Can apple distribute a license with their phone that says I can't make covers for their phone without those covers being distributed under their license? This is what GPL zealots want to think they should be able to do. And they think if I don't like it I shouldn't make the phone covers. Do they get to tell me what kind of phone covers I'm allowed to make?

Ok, but cover doesn't use the phone, the phone uses the cover. I'm adding functionality to apple's product not using their functionality. Well ok, except that argument doesn't fly with GPL. They are unwilling to let that slippery slope be opened either for fear it will slide too far.

My program is my program. It may be useless without something else, just as the phone case is. You may need other programs to make it useful for you. You can re-implement those other programs yourself if you want. But my software is 100% mine and GPL doesn't tell me where I can send it. They've got nothing to do with me. The fact that they say otherwise doesn't make it true.

So Mad hatter was probably right that none of this is well defined by courts. But I think common sense says they clearly have a right to limit static linking, and in my opinion clearly don't have a right to limit dynamic linking. It just needs the right lawyer to make the case for code "accessories" not "derived works". An accessory is useless by itself but is not a derived product.