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?


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.

  • Any special consideration for dynamic interpreted languages vs. compiled-to-binary ones? Feb 8 '17 at 12:50
  • I'm not entirely sure what you mean. The question of linking two codes bases into an executable can't arise with interpreted languages, so none of this question seems to me to apply. Also, hi Philippe, glad to see you got back from FOSDEM OK!
    – MadHatter
    Feb 8 '17 at 12:55

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.

  • I am honoured to see you drop by! Feb 8 '17 at 12:30
  • 2
    Indeed, the text of the LGPL calls the linking case a "Combined Work," distinct from a "Modified Work" which actually changes the library itself.
    – apsillers
    Feb 9 '17 at 16:53

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.

  • 2
    Your answer says that I'm wrong, then argues that dynamic linking doesn't create a derivative work. Firstly, we already have a question for that, and this isn't it. Secondly, that is not what I said above. My answer above is agnostic as to whether dynamic linking creates derivatives, and says so. My specific claim about the GPL/LGPL is that the LGPL contains no special text to exempt dynamic linking from creating derivatives in the event that courts hold it does, cf the 2nd bullet point in Philippe's question.
    – MadHatter
    Feb 13 '17 at 7:38

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.