7 ms·

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 l

by 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.
  - quotemstr 3y ago
    > Have you never used third party code that you didn’t compile yourself? Free software is different. Consider the GPLed libmysql. I can already freely copy libmysql from system to system in either source or binary form. The GPL grants me permission to do that. Fine. Now I copy libmysql.so to /usr/lib and my non-copyleft libproprietary.so to /usr/lib alongside it. Also allowed. But magically, the moment the dynamic linker loads libproprietary.so into the same address space as libmysql.so, I've broken copyright law? Yeah, I know that's the FSF's interpretation. I don't buy it, and here's why: this interpretation followed to its logical conclusion makes huge swaths of the free software ecosystem illegal. See, the FSF theory is that libproprietary.so becomes a derivative work of libmysql.so because it calls APIs provided by libmysql.so. Maybe the FSF is right. Maybe they're wrong. If they're right, though, why should it matter how I use libmysql.so's APIs? Do socket() and connect() make libproprietary.so not a derivative work? Why? I can use an API over a socket too --- and if using an API makes my program a derivative work, then every proprietary program that talks to MySQL is in trouble. This conclusion is absurd: therefore, our premises are wrong. You might say, "well, MySQL's socket API is obviously for general purpose use". So is libreadline's. So what? Either calling a public API propagates copyleft or it doesn't. Differentiating between calling APIs via dlopen() and via socket() makes no sense. I know the industry behaves as if there were a difference, but legally, is there? Show me the case law. The reason I can't just download LabVIEW and run it isn't that it's a library: it's proprietary software! I don't have permission to have it on my machine except by following the rules of the LabVIEW license. I don't need permission to have libmysql.so
    - fluoridation 3y ago
      >Consider the GPLed libmysql. I can already freely copy libmysql from system to system in either source or binary form. The GPL grants me permission to do that. Fine. Now I copy libmysql.so to /usr/lib and my non-copyleft libproprietary.so to /usr/lib alongside it. Also allowed. But magically, the moment the dynamic linker loads libproprietary.so into the same address space as libmysql.so, I've broken copyright law? Mmh... The GPL and copyright are about information distribution. You, as someone who owns their copy of libmysql.so and libproprietary.so, can do whatever you want with them. They're on your hardware and no one can tell you what you can order your hardware to do with the information that's on it. The question is, if you write a program that uses them both and you share that program with the world, how are you supposed to license that program? I.e. What rights are you supposed to give the users of that program? So the question of whether you've broken copyright law depends on how you've licensed the program that links to both libmysql.so and libproprietary.so. If the program is closed source, then yes, you've broken copyright law. If the program is GPL'd then, I don't know. Maybe you have, but I don't know who could sue you for making a GPL'd program that depends on a closed source library that you don't have the source for.
  - poizan42 3y ago
    What is the point you are trying to make here? You can't use a proprietary library without a license because you can't distribute it. Whether you can have code linking to the proprietary library without distributing the proprietary library has been largely irrelevant to the makers of those libraries since you wouldn't be allowed to use that functionality without either the distributor or the user paying for a license anyways.
    - belorn 3y ago
      Distribution is not required for copyright infringement. The creation of a derivative work is a separate right in copyright. Copyright law has however implemented exceptions in the form of interoperability. The distinction between creating a derivative work, or having two works communicating with each other, is a relative fuzzy one.
- LeifCarrotson 3y ago
  This is a question of law, not math - the property doesn't have to be commutative or even consistent. Licenses apply across certain kinds of linking and not others because that's what was in the document you agreed to when you installed the copyleft code. In order to run the code, you have to accept the terms of the contract. Those terms can require almost anything the author wants. In this case, the terms specify propagation over dlopen and not over a socket or pipe. They could just as easily specify the opposite! It would be less sensible, but perfectly possible.
  - quotemstr 3y ago
    > Licenses apply across certain kinds of linking and not others because that's what was in the document you agreed to when you installed the copyleft code. The GPLv2 (for clarity: GPLv3 is more verbose but communicates the same idea) says: > 3. You may copy and distribute the Program (or a work based on it, under Section 2) in object code or executable form under the terms of Sections 1 and 2 above provided that you also do one of the following: > a) Accompany it with the complete corresponding machine-readable source code, which must be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or, > b) Accompany it with a written offer, valid for at least three years, to give any third party, for a charge no more than your cost of physically performing source distribution, a complete machine-readable copy of the corresponding source code, to be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or, > c) Accompany it with the information you received as to the offer to distribute corresponding source code. (This alternative is allowed only for noncommercial distribution and only if you received the program in object code or executable form with such an offer, in accord with Subsection b above.) Where does this license talk about linking? Why should the GPL apply to my program that calls libreadline when I'm distributing the two separately and combining them at runtime? And more importantly, why does a combination involving dlopen() summon the copyright demons but socket() not? The distinction makes no sense. I'd like to see actual case law showing that if I dlopen() libreadline from a proprietary program, dlsym() a function, and call it, then I've violated copyright law. Show me one example of the legal system adopting this interpretation.
- juped 3y ago
  it doesn't, full stop, but the FSF has been pushing its maximalist theories which would not survive a second in court for decades now. what may be more relevant is that the use of the GPL is evidence that the author (possibly) believes in maximalist FSF theories. and therefore might not be someone whose libraries you want anywhere near your work, for avoidance of potential disputes.
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

by gumby 3y ago

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.
- quotemstr 3y ago
  > Have you never used third party code that you didn’t compile yourself? Free software is different. Consider the GPLed libmysql. I can already freely copy libmysql from system to system in either source or binary form. The GPL grants me permission to do that. Fine. Now I copy libmysql.so to /usr/lib and my non-copyleft libproprietary.so to /usr/lib alongside it. Also allowed. But magically, the moment the dynamic linker loads libproprietary.so into the same address space as libmysql.so, I've broken copyright law? Yeah, I know that's the FSF's interpretation. I don't buy it, and here's why: this interpretation followed to its logical conclusion makes huge swaths of the free software ecosystem illegal. See, the FSF theory is that libproprietary.so becomes a derivative work of libmysql.so because it calls APIs provided by libmysql.so. Maybe the FSF is right. Maybe they're wrong. If they're right, though, why should it matter how I use libmysql.so's APIs? Do socket() and connect() make libproprietary.so not a derivative work? Why? I can use an API over a socket too --- and if using an API makes my program a derivative work, then every proprietary program that talks to MySQL is in trouble. This conclusion is absurd: therefore, our premises are wrong. You might say, "well, MySQL's socket API is obviously for general purpose use". So is libreadline's. So what? Either calling a public API propagates copyleft or it doesn't. Differentiating between calling APIs via dlopen() and via socket() makes no sense. I know the industry behaves as if there were a difference, but legally, is there? Show me the case law. The reason I can't just download LabVIEW and run it isn't that it's a library: it's proprietary software! I don't have permission to have it on my machine except by following the rules of the LabVIEW license. I don't need permission to have libmysql.so
  - fluoridation 3y ago
    >Consider the GPLed libmysql. I can already freely copy libmysql from system to system in either source or binary form. The GPL grants me permission to do that. Fine. Now I copy libmysql.so to /usr/lib and my non-copyleft libproprietary.so to /usr/lib alongside it. Also allowed. But magically, the moment the dynamic linker loads libproprietary.so into the same address space as libmysql.so, I've broken copyright law? Mmh... The GPL and copyright are about information distribution. You, as someone who owns their copy of libmysql.so and libproprietary.so, can do whatever you want with them. They're on your hardware and no one can tell you what you can order your hardware to do with the information that's on it. The question is, if you write a program that uses them both and you share that program with the world, how are you supposed to license that program? I.e. What rights are you supposed to give the users of that program? So the question of whether you've broken copyright law depends on how you've licensed the program that links to both libmysql.so and libproprietary.so. If the program is closed source, then yes, you've broken copyright law. If the program is GPL'd then, I don't know. Maybe you have, but I don't know who could sue you for making a GPL'd program that depends on a closed source library that you don't have the source for.
- poizan42 3y ago
  What is the point you are trying to make here? You can't use a proprietary library without a license because you can't distribute it. Whether you can have code linking to the proprietary library without distributing the proprietary library has been largely irrelevant to the makers of those libraries since you wouldn't be allowed to use that functionality without either the distributor or the user paying for a license anyways.
  - belorn 3y ago
    Distribution is not required for copyright infringement. The creation of a derivative work is a separate right in copyright. Copyright law has however implemented exceptions in the form of interoperability. The distinction between creating a derivative work, or having two works communicating with each other, is a relative fuzzy one.
LeifCarrotson 3y ago
This is a question of law, not math - the property doesn't have to be commutative or even consistent. Licenses apply across certain kinds of linking and not others because that's what was in the document you agreed to when you installed the copyleft code. In order to run the code, you have to accept the terms of the contract. Those terms can require almost anything the author wants. In this case, the terms specify propagation over dlopen and not over a socket or pipe. They could just as easily specify the opposite! It would be less sensible, but perfectly possible.
- quotemstr 3y ago
  > Licenses apply across certain kinds of linking and not others because that's what was in the document you agreed to when you installed the copyleft code. The GPLv2 (for clarity: GPLv3 is more verbose but communicates the same idea) says: > 3. You may copy and distribute the Program (or a work based on it, under Section 2) in object code or executable form under the terms of Sections 1 and 2 above provided that you also do one of the following: > a) Accompany it with the complete corresponding machine-readable source code, which must be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or, > b) Accompany it with a written offer, valid for at least three years, to give any third party, for a charge no more than your cost of physically performing source distribution, a complete machine-readable copy of the corresponding source code, to be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or, > c) Accompany it with the information you received as to the offer to distribute corresponding source code. (This alternative is allowed only for noncommercial distribution and only if you received the program in object code or executable form with such an offer, in accord with Subsection b above.) Where does this license talk about linking? Why should the GPL apply to my program that calls libreadline when I'm distributing the two separately and combining them at runtime? And more importantly, why does a combination involving dlopen() summon the copyright demons but socket() not? The distinction makes no sense. I'd like to see actual case law showing that if I dlopen() libreadline from a proprietary program, dlsym() a function, and call it, then I've violated copyright law. Show me one example of the legal system adopting this interpretation.
juped 3y ago
it doesn't, full stop, but the FSF has been pushing its maximalist theories which would not survive a second in court for decades now. what may be more relevant is that the use of the GPL is evidence that the author (possibly) believes in maximalist FSF theories. and therefore might not be someone whose libraries you want anywhere near your work, for avoidance of potential disputes.

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