6

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?

Improve this question

4 Answers 4

Reset to default
7

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.

Improve this answer
3
  • Any special consideration for dynamic interpreted languages vs. compiled-to-binary ones?
    – Philippe Ombredanne
    Feb 8, 2017 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, 2017 at 12:55
  • It's a copyright law indeed. See here (under the "DERIVATIVE WORK" section). We do know the rough definition of a derivative work. BTW I'm not a legal expert. I would say that dynamic linking is building alongside or using the GPL'd code. And static linking is building on-top-of the GPL'd code which in my opinion makes a derived work.
    – Nasir Hossain
    Jun 25 at 8:24
1

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.

Improve this answer
2
  • I am honoured to see you drop by!
    – Philippe Ombredanne
    Feb 8, 2017 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, 2017 at 16:53
0

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.

Improve this answer
-1

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.

Improve this answer
8
  • 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, 2017 at 7:38
  • @MadHatter: Whether or not dynamic linking creates a derivative work would only be relevant if the in-memory code image that resulted were distributed. If a closed-source program comes with instructions for statically linking it with open-source components, and that linking step is done by the recipient, I see no basis for regarding that as any different from the situation where a system dynamically links code as it's loaded.
    – supercat
    Sep 1, 2022 at 20:45
  • @supercat I disagree. The right to create derivative works is one of the rights controlled by copyright, just as the right to control distribution is another. Ongoing distribution of the derivative work will further violate the rightsholder's copyright, certainly, but a copyright violation has occurred the moment an (unlicensed) derivative work is made.
    – MadHatter ♦
    Sep 2, 2022 at 6:15
  • @MadHatter: The gnu license explicitly authorizes the production of derivative works provided they are not distributed.
    – supercat
    Sep 2, 2022 at 11:35
  • @supercat I'm sorry, I thought you were claiming that "whether or not dynamic linking creates a derivative work would only be relevant if the in-memory code image that resulted were distributed" was generally true. If you're saying that your analysis only holds for GPL-licensed works, then I agree with you, but I also think it's irrelevant - because in most cases I don't think one can lawfully distribute a closed-source program designed to be linked to GPL software by the end-user at run-time.
    – MadHatter ♦
    Sep 2, 2022 at 11:41

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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