6 ms·

anyone who believes that GPLd dynamically linked libraries impact code written to use them effectively believes that APIs can be copyrighted. (ex: the FSF beli

anyone who believes that GPLd dynamically linked libraries impact code written to use them effectively believes that APIs can be copyrighted. (ex: the FSF believes this).

coldpie 6y ago
You may be right, but can you supply a citation for this? I believe many open-core software vendors work around this idea by doing exactly what you suggest: creating an API barrier where the proprietary software lives on one side and the GPL'd software on the other. It requires some care so you don't cross GPL'd software into the proprietary side, but it's fairly common. I think the Linux Nvidia GPU driver works this way.
- compsciphd 6y ago
  citation that the FSF believes that GPLd libraries when dynamically linked require the all the code to be GPLd? https://gitlab.com/gnu-clisp/clisp/blob/dd313099db351c90431c1c90332192edce2bb5c9/doc/Why-CLISP-is-under-GPL https://gitlab.com/gnu-clisp/clisp/blob/dd313099db351c90431c... or something else? I agree that many create that API barrier (ex: ZFS on Linux). Those that argue that ZFS on Linux is legally problematic agree with the FSF's definition (which I would argue leads to the belief that APIs are copyrightable). Those that think ZFS on Linux is on a fine footing believe that APIs aren't copyrightable and one can create a shim to decouple your non GPLd code from GPL "libraries", especially if the coupling that ends up happening is never distributed as done by the end user.
  - coldpie 6y ago
    Yes, that's exactly what I was looking for. Thanks for the read, it was very interesting. I thought this was a settled matter, but it looks like I was wrong.
- salawat 6y ago
  It's called a GPL condom, and that's a bit different in the end in that the GPL mandates GPL'ing code that links against GPL symbols. It's more of a contract than copyright. If you want to use these in your code, you must GPL, or reimplement at your leisure! That's less Copyright in the sense that it's mandating the relinquishing of monopolistic control of the work product in question to the public. Oracle wants the opposite. They want Java used everywhere, and the right to sue anyone who does anything too similar to it too. This is absolutely an act of monopolistic market shaping. No smaller firm would ever have utilized this nuclear option of a lawsuit given the widespread damage this could potentially cause to the entire software ecosystem. This would honestly be enough to get me moving completely out of Software if the Court screws the pooch on this badly enough. I'm not spending the rest of my life debugging code that as a matter of fact must be run through obfuscate steps to avoid copyright liability.
marcosdumay 6y ago
It is different. In the GPL case, you are distributing the software, not just using the API. I don't know if it's different enough, but it's not the exact same issue.
- compsciphd 6y ago
  if I distribute the GPL library (say libreadline) with my app, I'd probably agree with you. If I expect the end user to have libreadline installed on their machine (from debian / redhat repos, and for argument sake Debian/Red Hat/et al aren't distributing my app), I think I'd disagree. I'm not distributing any GPLd code. I think its a bit more complicated if Debian/Red Hat are distributing my non GPLd app that links against a GPLd library that they also distribute, but aren't really distributing them together. The reason I say this, is because even though they are "distributing" both "together", we wouldn't say that GPLd code and BSD code that they "distribute" "together" infects the BSD code. I might also agree that its not exactly the same issue, but I do think it should make one think about it.
  - belorn 6y ago
    If you explain to a judge the difference between distributing a library and app code to the user, and expecting the user to download the library themselves and then you combine the app-code and the library afterward, will they care or will they see the two methods as being practically identical in terms of forming a single derivative program out of the library and app-code. In the past people argued that streaming could not be copyright infringement since the recipient never received a copy of the movie. Courts however did not see much of an meaningful distinction between streaming a movie and downloading a movie since the experience from the user were close to identical and the perceived impact on the publisher were also identical. During a conference I recall a lawyer explaining that a judge does not like arguments that try to use tricks to walk around laws. It makes the judge look like a fool and that annoys them.
    - compsciphd 6y ago
      except in the case of libreadline, its highly likely that any Linux user (i.e. bash depends on it) already has the library on the system. I'm not distributing it. But lets get into the weeds a little. Lets say I am distributing it according to all definitions. I'm allowed to distribute GPLd material. I'm allowed to distribute non GPLd material. I'm allowed to distribute them together even (say a linux CD without the GPL impacting the rest). The question the judge would have to answer, is the non GPLd portion a "derivative work" of the GPLd portion and is that derivative work being distributed. I'm not so clear that this the case unless one really believes that APIs can be copyrighted (then it is clearly the case). As a simple example: lets say we accept that it is a derivative work, but then lets say I made a replacement version of libreadline that was ABI compatible (but not feature complete) with the original one, so hence my program can be dynamically linked against both but it will be a better end user experience if they use the GPL version. To provide a somewhat more concrete thought experiment (concrete as an ABI copatible reimplemntation under a different license, thought as its making up a fact): imagine microsoft dual licensed windows with GPL and not and they believed that if one wanted to ship a non GPL program one had to pay them a license fee to keep the program not GPLd. Now, as wine has implemented the required APIs to run my program, can I ship a non GPLd program where I refuse to license the right to be non GPLd from Microsoft that will still run on Windows? Does it change because wine exists (i.e. the answer would be different if wine didn't exist) and if so why? This case isn't to nitpick how windows is different than libreadline or the like, but just as an example of ABI compatible non feature complete implementations can exist.
belorn 6y ago
Those two are complete different concepts within copyright. Oracle claim is that google copies of header files requires copy right permission, with google saying that header files are either not protected by copyright or that using them is fair use. FSF claim in regard to dynamically linked libraries is that using them in a work creates a derivative work. For C code, software without its dynamically linked libraries won't even load past the linker, and in their view, a judge/jury will see the program as a single work rather than two independent works. This court case will not define what is a derivative work or when two combined works should be seen as independent of each other. It may explore the limits of what is copyrightable and what is fair use, which is interesting in terms of API's and compatibility but less so for defining the limits of the GPL as an copyright license.
- mantap 6y ago
  You don't just dynamically link a library. You link it and then use its API, it's precisely the using of the API that creates the derivative work (if you accept FSF's position). I don't see how e.g. calling dlopen() on its own but not using the API could create a derivative work any more than calling fopen() does.
  - belorn 6y ago
    The original case for RMS when he created the position for dynamically linked libraries where when apple created an GCC version that had a Objective-C frontend. RMS initially did not think this would be covered by copyright but after talking with the lawyer Eben Moglen he got the following explanation: A judge would unlikely see it as an objective-C fronted as an independent work that is talking with GCC, but rather just a compiler. That compiler would be the work, and thus a derivative work since it combines the GCC code and the objective-C fronted. Nothing in there is about API's. There is also nothing about linking. It just about what a judge would perceive as being "the work". FSF however do seem to have a policy about enforcing the license at the technical distinction of linking, but that is just a policy decision based on where they think a judge would likely side with them. Apple were free to go to court arguing that it is not a compiler but rather different independent works simply communicating with each other, but they chose not to do so.

anyone who believes that GPLd dynamically linked libraries impact code written to use them effectively believes that APIs can be copyrighted. (ex: the FSF believes this).

coldpie 6y ago

You may be right, but can you supply a citation for this? I believe many open-core software vendors work around this idea by doing exactly what you suggest: creating an API barrier where the proprietary software lives on one side and the GPL'd software on the other. It requires some care so you don't cross GPL'd software into the proprietary side, but it's fairly common. I think the Linux Nvidia GPU driver works this way.

compsciphd 6y ago
citation that the FSF believes that GPLd libraries when dynamically linked require the all the code to be GPLd? https://gitlab.com/gnu-clisp/clisp/blob/dd313099db351c90431c1c90332192edce2bb5c9/doc/Why-CLISP-is-under-GPL https://gitlab.com/gnu-clisp/clisp/blob/dd313099db351c90431c... or something else? I agree that many create that API barrier (ex: ZFS on Linux). Those that argue that ZFS on Linux is legally problematic agree with the FSF's definition (which I would argue leads to the belief that APIs are copyrightable). Those that think ZFS on Linux is on a fine footing believe that APIs aren't copyrightable and one can create a shim to decouple your non GPLd code from GPL "libraries", especially if the coupling that ends up happening is never distributed as done by the end user.
- coldpie 6y ago
  Yes, that's exactly what I was looking for. Thanks for the read, it was very interesting. I thought this was a settled matter, but it looks like I was wrong.
salawat 6y ago
It's called a GPL condom, and that's a bit different in the end in that the GPL mandates GPL'ing code that links against GPL symbols. It's more of a contract than copyright. If you want to use these in your code, you must GPL, or reimplement at your leisure! That's less Copyright in the sense that it's mandating the relinquishing of monopolistic control of the work product in question to the public. Oracle wants the opposite. They want Java used everywhere, and the right to sue anyone who does anything too similar to it too. This is absolutely an act of monopolistic market shaping. No smaller firm would ever have utilized this nuclear option of a lawsuit given the widespread damage this could potentially cause to the entire software ecosystem. This would honestly be enough to get me moving completely out of Software if the Court screws the pooch on this badly enough. I'm not spending the rest of my life debugging code that as a matter of fact must be run through obfuscate steps to avoid copyright liability.

marcosdumay 6y ago

It is different. In the GPL case, you are distributing the software, not just using the API. I don't know if it's different enough, but it's not the exact same issue.

compsciphd 6y ago
if I distribute the GPL library (say libreadline) with my app, I'd probably agree with you. If I expect the end user to have libreadline installed on their machine (from debian / redhat repos, and for argument sake Debian/Red Hat/et al aren't distributing my app), I think I'd disagree. I'm not distributing any GPLd code. I think its a bit more complicated if Debian/Red Hat are distributing my non GPLd app that links against a GPLd library that they also distribute, but aren't really distributing them together. The reason I say this, is because even though they are "distributing" both "together", we wouldn't say that GPLd code and BSD code that they "distribute" "together" infects the BSD code. I might also agree that its not exactly the same issue, but I do think it should make one think about it.
- belorn 6y ago
  If you explain to a judge the difference between distributing a library and app code to the user, and expecting the user to download the library themselves and then you combine the app-code and the library afterward, will they care or will they see the two methods as being practically identical in terms of forming a single derivative program out of the library and app-code. In the past people argued that streaming could not be copyright infringement since the recipient never received a copy of the movie. Courts however did not see much of an meaningful distinction between streaming a movie and downloading a movie since the experience from the user were close to identical and the perceived impact on the publisher were also identical. During a conference I recall a lawyer explaining that a judge does not like arguments that try to use tricks to walk around laws. It makes the judge look like a fool and that annoys them.
  - compsciphd 6y ago
    except in the case of libreadline, its highly likely that any Linux user (i.e. bash depends on it) already has the library on the system. I'm not distributing it. But lets get into the weeds a little. Lets say I am distributing it according to all definitions. I'm allowed to distribute GPLd material. I'm allowed to distribute non GPLd material. I'm allowed to distribute them together even (say a linux CD without the GPL impacting the rest). The question the judge would have to answer, is the non GPLd portion a "derivative work" of the GPLd portion and is that derivative work being distributed. I'm not so clear that this the case unless one really believes that APIs can be copyrighted (then it is clearly the case). As a simple example: lets say we accept that it is a derivative work, but then lets say I made a replacement version of libreadline that was ABI compatible (but not feature complete) with the original one, so hence my program can be dynamically linked against both but it will be a better end user experience if they use the GPL version. To provide a somewhat more concrete thought experiment (concrete as an ABI copatible reimplemntation under a different license, thought as its making up a fact): imagine microsoft dual licensed windows with GPL and not and they believed that if one wanted to ship a non GPL program one had to pay them a license fee to keep the program not GPLd. Now, as wine has implemented the required APIs to run my program, can I ship a non GPLd program where I refuse to license the right to be non GPLd from Microsoft that will still run on Windows? Does it change because wine exists (i.e. the answer would be different if wine didn't exist) and if so why? This case isn't to nitpick how windows is different than libreadline or the like, but just as an example of ABI compatible non feature complete implementations can exist.

belorn 6y ago

Those two are complete different concepts within copyright. Oracle claim is that google copies of header files requires copy right permission, with google saying that header files are either not protected by copyright or that using them is fair use. FSF claim in regard to dynamically linked libraries is that using them in a work creates a derivative work. For C code, software without its dynamically linked libraries won't even load past the linker, and in their view, a judge/jury will see the program as a single work rather than two independent works. This court case will not define what is a derivative work or when two combined works should be seen as independent of each other. It may explore the limits of what is copyrightable and what is fair use, which is interesting in terms of API's and compatibility but less so for defining the limits of the GPL as an copyright license.

mantap 6y ago
You don't just dynamically link a library. You link it and then use its API, it's precisely the using of the API that creates the derivative work (if you accept FSF's position). I don't see how e.g. calling dlopen() on its own but not using the API could create a derivative work any more than calling fopen() does.
- belorn 6y ago
  The original case for RMS when he created the position for dynamically linked libraries where when apple created an GCC version that had a Objective-C frontend. RMS initially did not think this would be covered by copyright but after talking with the lawyer Eben Moglen he got the following explanation: A judge would unlikely see it as an objective-C fronted as an independent work that is talking with GCC, but rather just a compiler. That compiler would be the work, and thus a derivative work since it combines the GCC code and the objective-C fronted. Nothing in there is about API's. There is also nothing about linking. It just about what a judge would perceive as being "the work". FSF however do seem to have a policy about enforcing the license at the technical distinction of linking, but that is just a policy decision based on where they think a judge would likely side with them. Apple were free to go to court arguing that it is not a compiler but rather different independent works simply communicating with each other, but they chose not to do so.