4 ms·

“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. Labv

by 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.
- simiones 3y ago
  > greet.c is not a derivative work of Y because I have not included any copyrightable elements of Y in greet.c. I think this is very much debatable, and I believe the FSF at least takes the position that greet.c is a derived work of Y since it is designed to depend on Y. Even more, their position is that a program like this: #include <stdlib.h> int main() { create_complex_c_code_using_gcc_specific_extensions("./intermediate.c"); system("gcc -o intermediate ./intermediate.c"); system("./intermediate"); } Is quite possibly a derived work of GCC, since it depends critically on communicating with GCC using a very complex and specific data interchange format (the GCC-specific C source code). Note that this is not including any portion of GCC itself, even after compilation. Now, this type of thing has never been tested in a court of law as far as I know, so it's difficult to say whose interpretation of copyright and its implications is actually correct. But this is similar to the idea that if you were to write an original novel that uses characters or very recognizable aspects of, say, The Lord of the Rings, you'd be creating a derived work (and thus permission from the Tolkien estate), even if you didn't include any part of the original longer than "Galadriel".
  - tzs 3y ago
    I just ran this shell script on my Mac: #!/bin/sh say Alexa what time is it and my Amazon Echo told me the time. Is that shell script a derivative work of Amazon's Alexa code? It is very clearly designed to depend on Alexa.
    - simiones 3y ago
      I don't know, no one really does as this has never been tested in courts as far as I know. I believe the FSF would say that it's not a derivative work, as it doesn't interact with the Alexa code through complex data types. However, this is their own legal theory, not directly a part of any law or jurisprudence (as far as I know - if there is some case law on this topic, I would be very curious to read it).
- kelnos 3y ago
  > If I compile greet.c and link it with Y the resulting a.out is a derivative work of Y. Link it how, though? If you statically link it with Y, then I can see the argument that a.out is a derived work, because it literally contains all of Y in it. But if you dynamically link it, a.out contains no more of Y than greet.c does. Are you asserting that a.out is still a derived work of Y in this case as well?
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.

by gumby 3y ago

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.

simiones 3y ago
> greet.c is not a derivative work of Y because I have not included any copyrightable elements of Y in greet.c. I think this is very much debatable, and I believe the FSF at least takes the position that greet.c is a derived work of Y since it is designed to depend on Y. Even more, their position is that a program like this: #include <stdlib.h> int main() { create_complex_c_code_using_gcc_specific_extensions("./intermediate.c"); system("gcc -o intermediate ./intermediate.c"); system("./intermediate"); } Is quite possibly a derived work of GCC, since it depends critically on communicating with GCC using a very complex and specific data interchange format (the GCC-specific C source code). Note that this is not including any portion of GCC itself, even after compilation. Now, this type of thing has never been tested in a court of law as far as I know, so it's difficult to say whose interpretation of copyright and its implications is actually correct. But this is similar to the idea that if you were to write an original novel that uses characters or very recognizable aspects of, say, The Lord of the Rings, you'd be creating a derived work (and thus permission from the Tolkien estate), even if you didn't include any part of the original longer than "Galadriel".
- tzs 3y ago
  I just ran this shell script on my Mac: #!/bin/sh say Alexa what time is it and my Amazon Echo told me the time. Is that shell script a derivative work of Amazon's Alexa code? It is very clearly designed to depend on Alexa.
  - simiones 3y ago
    I don't know, no one really does as this has never been tested in courts as far as I know. I believe the FSF would say that it's not a derivative work, as it doesn't interact with the Alexa code through complex data types. However, this is their own legal theory, not directly a part of any law or jurisprudence (as far as I know - if there is some case law on this topic, I would be very curious to read it).
kelnos 3y ago
> If I compile greet.c and link it with Y the resulting a.out is a derivative work of Y. Link it how, though? If you statically link it with Y, then I can see the argument that a.out is a derived work, because it literally contains all of Y in it. But if you dynamically link it, a.out contains no more of Y than greet.c does. Are you asserting that a.out is still a derived work of Y in this case as well?

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.