5 ms·

The tech industry runs on myth and superstition more than most people will admit. One persistent myth is the special role of "linking" in propagating "derived w

The tech industry runs on myth and superstition more than most people will admit. One persistent myth is the special role of "linking" in propagating "derived work" copyright status. Are we really supposed to believe that if non-copyleft code A is tightly coupled with copyleft code B, then the copyleft does propagate to A if we summon the ld-linux.so.2 demon for dynamic linking and doesn't propagate if A uses B via system(2) and a pipe? Ridiculous. Whether A is a derivative work of B has to do with the extent to which A is coupled to B in particular, not the mechanism of this coupling. Personally, I've always found it hard to believe that merely using, e.g. libreadline (or Linux EXPORT_SYMBOL_GPL) really makes one program a derivative work of another. Is there any actual legal precedent for mere dynamic linking propagating copyleft? Common sense suggests that, no, linking to libreadline or libmysql or whatever doesn't make a program that does something totally different a derivative work. Has the linking-propagates-copyleft theory ever actually been tested? Might we have been making life hard for ourselves for decades for no actual reason?

gumby 3y ago
The issue ‘One persistent myth is the special role of "linking" in propagating "derived work" copyright status’ has nothing to do with GPL. If you use any 3P library it’s a derived dependency by law. Is that what you are arguing? It’s settled law at this point. MS lets you link against their DLLs but only on their platform. You might pay for a special library, but you have to pay them money for programs that link against it (actually does anybody do that any more?). GPL code is no different in any way except instead of paying the FSF cash or buying a Windows OS you agree to provide the user the freedom to change the code.
- quotemstr 3y ago
  > If you use any 3P library it’s a derived dependency by law. Is that what you are arguing? It’s settled law at this point. Is it? So if I, the author of non-copyleft A, want to use copyleft library B, it's illegal if I use `dlopen` but legal if I use a socket or a pipe? That's absurd. Either both are illegal or both are legal, and I've yet to see evidence that it's the former. IOW, I've yet to see evidence that licenses apply across dlopen bounds. It's a meme in our industry that it does, but does it really? Where's the data?
  - gumby 3y ago
    “Where is the data?” Have you never used third party code that you didn’t compile yourself? Hell, Unity itself (the topic of this article) is an example. Labview. Some code for talking to a spectrometer we bought for our lab last month. It’s extremely common. People used to sell libraries to do various computations and charge royalties for their use. Probably they still do but I don’t work in that kind of world any more. You may call it absurd if you like but that’s how the system works. The GPL and LGPL deliberately do not break new ground in that regard. What was/is novel about them is not using an exchange of money, but rather other value instead. No more, no less.
    - tzs 3y ago
      I'm having a hard time figuring out what either of you are actually talking about. He's talking about various ways code written by one party may invoke code on the same computer written by someone else but not saying exactly how those two chunks of code came to be on the same computer running at the same time. Without knowing all the people involved in that it is not possible to say what copyright law says about who needs to get permission from whom. You've talked about "derived dependencies by law" but "derived dependencies" is not a term I've come across in US copyright law. A lot of free/open source discussion (and sometimes the licenses themselves) tends to use terms that have "derived" in them but mean some sort of vague superset of what copyright law means by "derivative work". In particular, if work X depends on work Y, even to the point that X is not really useful unless used with Y, that does not necessarily make X a derivative work of Y. That's why game console makers had to use DRM to stop other companies from making cartridges for they game consoles. Even though the software in the cartridges was utterly dependent on the code in the console to do anything the cartridges were not derivative works. To be a derivative work of Y, X must incorporate some or all of Y. Suppose for example Y is a text to speech library which exports a function "int speak(char * text)". If I write a file, greet.c, that contains this: #include "y_speech_lib.h" int main() { speak("Hello, World!"); return 0; } greet.c is not a derivative work of Y because I have not included any copyrightable elements of Y in greet.c. If I compile greet.c and link it with Y the resulting a.out is a derivative work of Y. I can license greet.c under any license I want and distribute it under any terms I want without having to worry about Y's license as far as possible liability to me for direct copyright infringement goes. I'll cover indirect infringement later. If I want to distribute a.out then I do need to worry about Y's license, because a.out is a derivative work of Y. If someone else makes an a.out from my greet.c and Y they are making a derivative work, and need permission (maybe [1]) from me and from Y's copyright owner. It is possible to be an indirect copyright infringer. There are a few different kinds of indirect infringement, such as vicarious infringement and contributory infringement. What they all have in common is for someone to be liable as an indirect infringer there must be a direct infringement for them to be indirectly liable for. If there is no direct infringer there cannot be an indirect infringer. Since most open source licenses only impose requirements when you distribute code, doing stuff with it on your own computer just for you own use will usually not be a direct infringement, and hence no possibility of indirect infringement for those who supplied you with other code that you used with the open source code code. Even if you combine my greet.c with someone else's code on your computer and distribute the resulting binary in violation of that other code's license (making you a direct infringer) I'd be OK unless (1) I had the right and ability to control you and received a direct financial benefit from your infringement, (2) I distributed greet.c with the object of promoting its use for such infringement and clearly expressed that or took affirmative steps to encourage it, or (3) greet.c has no other substantial uses that are not infringing. [1] I say maybe because if they are just compiling and linking copies of greet.c and Y that they legally own in order to use them on their machine they might not need permission. US copyright law contains an exception for things that are an essential step to utilize a program on a machine (17 USC 117) and they don't do anything else with it like distribute it.
- poizan42 3y ago
  > If you use any 3P library it’s a derived dependency by law. Is that what you are arguing? It’s settled law at this point. Not it's definitely not. For B to be a derivative work of A it needs to include copyrightable elements of A. But if B merely dynamically links to A then it only contains knowledge of the API surface of A. And SCOTUS refused to rule on the copyrightability of APIs in Google LLC v. Oracle America, Inc. In the EU APIs seems to be explicitly called out as non-copyrightable by Directive 2009/24/EC Article 1(2): > 2. Protection in accordance with this Directive shall apply to the expression in any form of a computer program. Ideas and principles which underlie any element of a computer program, including those which underlie its interfaces, are not protected by copyright under this Directive.
  - gumby 3y ago
    An utterly irrelevant side point since the whole question is the use of the implementation not the API. If you call write() in Microsoft’s libc you must follow Microsoft’s license terms or you don’t have the right to use it. If you call glibc’s write() the same applies. And if you don’t like glibc’s terms you are free to, say, install bsd’s libc or write your own write() implementation (which probably just does a system call anyway).
    - juped 3y ago
      I don't agree with you but I appreciate you providing me with comments like this to cite when I try to convince people "yes, FSF are really that maximalist; no, that's not a 90s relic they moved on from".
      - freedomben 3y ago
        > I don't agree with you but I appreciate you providing me with comments like this to cite when I try to convince people "yes, FSF are really that maximalist; no, that's not a 90s relic they moved on from". unless you make sure that gumby is speaking for the FSF, then that comment does not provide evidence that the FSF believe that. It's merely evidence that gumby does. I don't understand why people are so quick to take somebody's personal opinion and ascribe it to whatever organization(s) they happen to belong to. This sort of fallacy is why we constantly have to suffer through the "I speak only for myself, not my organization" disclaimers
jopsen 3y ago
I thought that the license for B says you can't distribute it along side A. Not that copyright propagates. Obviously, a zip archive containing A and B is a derived work of B. Hence, license of B can say you can't distribute such works. Does distributing A without B make any sense?
- im3w1l 3y ago
  I have seen stuff like this. Audio programs asking you to specify the location of lame_enc.dll. Emulators asking you to specify location of some bios.
  - anthk 3y ago
    The BIOS it's a different case. That's left to the user. Also, the usage of the BIOS happens under emulation, not the main machine. For instance, FUSE with the Sinclair ZX ROM's instead of OpenSE. or Vice with the Commodore BIOSes instead of shipping C64 OpenBIOSes.
- quotemstr 3y ago
  > I thought that the license for B says you can't distribute it along side A. Nope. The GPL explicitly says > In addition, mere aggregation of another work not based on the Program with the Program (or with a work based on the Program) on a volume of a storage or distribution medium does not bring the other work under the scope of this License.
- jameshart 3y ago
  > Obviously, a zip archive containing A and B is a derived work of B. It’s not obvious that any copyright attaches to a zip archive at all, any more than hanging two paintings on a wall makes a derived work copyrightable wall. To be a derived work something still has to be a ‘work’. A distribution license can restrict how you are allowed to distribute a work because it can directly restrict your behavior not because it propagates and applies to the container you distribute it in. That is it can just say ‘you can’t distribute this bundled up with other things’, in much the same way as it can say ‘you can’t distribute this without the copyright notice’, or ‘you can’t distribute this on Wednesdays’.
deleted 3y ago
[deleted]
singpolyma3 3y ago
Dynamic linking will result in a program in memory at runtime that is under the copyleft terms. The separate pieces on disk are of course as you say.

gumby 3y ago

The issue ‘One persistent myth is the special role of "linking" in propagating "derived work" copyright status’ has nothing to do with GPL. If you use any 3P library it’s a derived dependency by law. Is that what you are arguing? It’s settled law at this point. MS lets you link against their DLLs but only on their platform. You might pay for a special library, but you have to pay them money for programs that link against it (actually does anybody do that any more?). GPL code is no different in any way except instead of paying the FSF cash or buying a Windows OS you agree to provide the user the freedom to change the code.

quotemstr 3y ago
> If you use any 3P library it’s a derived dependency by law. Is that what you are arguing? It’s settled law at this point. Is it? So if I, the author of non-copyleft A, want to use copyleft library B, it's illegal if I use `dlopen` but legal if I use a socket or a pipe? That's absurd. Either both are illegal or both are legal, and I've yet to see evidence that it's the former. IOW, I've yet to see evidence that licenses apply across dlopen bounds. It's a meme in our industry that it does, but does it really? Where's the data?
- gumby 3y ago
  “Where is the data?” Have you never used third party code that you didn’t compile yourself? Hell, Unity itself (the topic of this article) is an example. Labview. Some code for talking to a spectrometer we bought for our lab last month. It’s extremely common. People used to sell libraries to do various computations and charge royalties for their use. Probably they still do but I don’t work in that kind of world any more. You may call it absurd if you like but that’s how the system works. The GPL and LGPL deliberately do not break new ground in that regard. What was/is novel about them is not using an exchange of money, but rather other value instead. No more, no less.
  - tzs 3y ago
    I'm having a hard time figuring out what either of you are actually talking about. He's talking about various ways code written by one party may invoke code on the same computer written by someone else but not saying exactly how those two chunks of code came to be on the same computer running at the same time. Without knowing all the people involved in that it is not possible to say what copyright law says about who needs to get permission from whom. You've talked about "derived dependencies by law" but "derived dependencies" is not a term I've come across in US copyright law. A lot of free/open source discussion (and sometimes the licenses themselves) tends to use terms that have "derived" in them but mean some sort of vague superset of what copyright law means by "derivative work". In particular, if work X depends on work Y, even to the point that X is not really useful unless used with Y, that does not necessarily make X a derivative work of Y. That's why game console makers had to use DRM to stop other companies from making cartridges for they game consoles. Even though the software in the cartridges was utterly dependent on the code in the console to do anything the cartridges were not derivative works. To be a derivative work of Y, X must incorporate some or all of Y. Suppose for example Y is a text to speech library which exports a function "int speak(char * text)". If I write a file, greet.c, that contains this: #include "y_speech_lib.h" int main() { speak("Hello, World!"); return 0; } greet.c is not a derivative work of Y because I have not included any copyrightable elements of Y in greet.c. If I compile greet.c and link it with Y the resulting a.out is a derivative work of Y. I can license greet.c under any license I want and distribute it under any terms I want without having to worry about Y's license as far as possible liability to me for direct copyright infringement goes. I'll cover indirect infringement later. If I want to distribute a.out then I do need to worry about Y's license, because a.out is a derivative work of Y. If someone else makes an a.out from my greet.c and Y they are making a derivative work, and need permission (maybe [1]) from me and from Y's copyright owner. It is possible to be an indirect copyright infringer. There are a few different kinds of indirect infringement, such as vicarious infringement and contributory infringement. What they all have in common is for someone to be liable as an indirect infringer there must be a direct infringement for them to be indirectly liable for. If there is no direct infringer there cannot be an indirect infringer. Since most open source licenses only impose requirements when you distribute code, doing stuff with it on your own computer just for you own use will usually not be a direct infringement, and hence no possibility of indirect infringement for those who supplied you with other code that you used with the open source code code. Even if you combine my greet.c with someone else's code on your computer and distribute the resulting binary in violation of that other code's license (making you a direct infringer) I'd be OK unless (1) I had the right and ability to control you and received a direct financial benefit from your infringement, (2) I distributed greet.c with the object of promoting its use for such infringement and clearly expressed that or took affirmative steps to encourage it, or (3) greet.c has no other substantial uses that are not infringing. [1] I say maybe because if they are just compiling and linking copies of greet.c and Y that they legally own in order to use them on their machine they might not need permission. US copyright law contains an exception for things that are an essential step to utilize a program on a machine (17 USC 117) and they don't do anything else with it like distribute it.
poizan42 3y ago
> If you use any 3P library it’s a derived dependency by law. Is that what you are arguing? It’s settled law at this point. Not it's definitely not. For B to be a derivative work of A it needs to include copyrightable elements of A. But if B merely dynamically links to A then it only contains knowledge of the API surface of A. And SCOTUS refused to rule on the copyrightability of APIs in Google LLC v. Oracle America, Inc. In the EU APIs seems to be explicitly called out as non-copyrightable by Directive 2009/24/EC Article 1(2): > 2. Protection in accordance with this Directive shall apply to the expression in any form of a computer program. Ideas and principles which underlie any element of a computer program, including those which underlie its interfaces, are not protected by copyright under this Directive.
- gumby 3y ago
  An utterly irrelevant side point since the whole question is the use of the implementation not the API. If you call write() in Microsoft’s libc you must follow Microsoft’s license terms or you don’t have the right to use it. If you call glibc’s write() the same applies. And if you don’t like glibc’s terms you are free to, say, install bsd’s libc or write your own write() implementation (which probably just does a system call anyway).
  - juped 3y ago
    I don't agree with you but I appreciate you providing me with comments like this to cite when I try to convince people "yes, FSF are really that maximalist; no, that's not a 90s relic they moved on from".
    - freedomben 3y ago
      > I don't agree with you but I appreciate you providing me with comments like this to cite when I try to convince people "yes, FSF are really that maximalist; no, that's not a 90s relic they moved on from". unless you make sure that gumby is speaking for the FSF, then that comment does not provide evidence that the FSF believe that. It's merely evidence that gumby does. I don't understand why people are so quick to take somebody's personal opinion and ascribe it to whatever organization(s) they happen to belong to. This sort of fallacy is why we constantly have to suffer through the "I speak only for myself, not my organization" disclaimers

jopsen 3y ago

I thought that the license for B says you can't distribute it along side A. Not that copyright propagates. Obviously, a zip archive containing A and B is a derived work of B. Hence, license of B can say you can't distribute such works. Does distributing A without B make any sense?

im3w1l 3y ago
I have seen stuff like this. Audio programs asking you to specify the location of lame_enc.dll. Emulators asking you to specify location of some bios.
- anthk 3y ago
  The BIOS it's a different case. That's left to the user. Also, the usage of the BIOS happens under emulation, not the main machine. For instance, FUSE with the Sinclair ZX ROM's instead of OpenSE. or Vice with the Commodore BIOSes instead of shipping C64 OpenBIOSes.
quotemstr 3y ago
> I thought that the license for B says you can't distribute it along side A. Nope. The GPL explicitly says > In addition, mere aggregation of another work not based on the Program with the Program (or with a work based on the Program) on a volume of a storage or distribution medium does not bring the other work under the scope of this License.
jameshart 3y ago
> Obviously, a zip archive containing A and B is a derived work of B. It’s not obvious that any copyright attaches to a zip archive at all, any more than hanging two paintings on a wall makes a derived work copyrightable wall. To be a derived work something still has to be a ‘work’. A distribution license can restrict how you are allowed to distribute a work because it can directly restrict your behavior not because it propagates and applies to the container you distribute it in. That is it can just say ‘you can’t distribute this bundled up with other things’, in much the same way as it can say ‘you can’t distribute this without the copyright notice’, or ‘you can’t distribute this on Wednesdays’.

deleted 3y ago

[deleted]

singpolyma3 3y ago

Dynamic linking will result in a program in memory at runtime that is under the copyleft terms. The separate pieces on disk are of course as you say.