3 ms·

I don't think that's actually the argument being made. It's the standard "color of your bits"[1] distinction: intent matters. If you use GPL licensed code in yo

I don't think that's actually the argument being made. It's the standard "color of your bits"[1] distinction: intent matters. If you use GPL licensed code in your program (that does not fall into an explicit exception, eg. syscalls on linux) you must follow the GPL. No amount of technical trickery allows you to circumvent this. If however, you reimplement an API, that may or may not be copyrighted (watch for the final result on that google vs oracle case). 1: https://ansuz.sooke.bc.ca/entry/23 https://ansuz.sooke.bc.ca/entry/23

p_l 6y ago
The language of the license doesn't talk anything about technical methods used, only whether the program is derived from GPLed code or not. This has some !FUN! possibilities, in Dwarf Fortress meaning. On one side, currently more common line of thought (promoted among other things by Linus, when non-GPLed code ended up in Linux through AFS) is related to actual functionality of the program being specifically dependant on GPLed code, vs. being a case where a common interface that existed in non-GPLed code might be used in between. This also makes moot any concern about syscalls that aren't linux-specific, as the programs using them have obvious defense of "I was following UNIX standards". On the maximalist interpretation... well, it doesn't matter if the code runs on separate machine and you talk to it over IPC. The trouble seems to stem from FSF itself misinterpreting derived to have direct application to technical specifics of linking. Whether by mistake or on purpose.
- cmeacham98 6y ago
  Here's Linus's actual words: > anything that was written with Linux in mind (whether it then also works on other operating systems or not) is clearly partially a derived work > Historically, there's been things like the original Andrew filesystem module: a standard filesystem that really wasn't written for Linux in the first place, and just implements a UNIX filesystem. Is that derived just because it got ported to Linux that had a reasonably similar VFS interface to what other UNIXes did? > Personally, I think that case wasn't a derived work, and I was willing to tell the AFS guys so. If we take this logic and apply it to this situation, we can see that the GPL always applies if you are intentionally designing for and using GPLed code in your program, even if you "run on separate machine and you talk to it over IPC". Now, if there happened to be some common readline API, with readline_gpl.so and readline_mit.so, then you could use it. But making up a hypothetical about readline_doesnotexist.so, when the only implementation you actually are using is readline_gpl.so is not going to convince a judge that the GPL does not apply. You could maybe get away with it if you originally designed for inputline.so, some non-GPL library that had similar functionality to readline but with a different API, and then ported to readline.so - it would be situation dependent and I'd probably talk to a lawyer here. However, that wasn't what happened here either.

p_l 6y ago

The language of the license doesn't talk anything about technical methods used, only whether the program is derived from GPLed code or not. This has some !FUN! possibilities, in Dwarf Fortress meaning. On one side, currently more common line of thought (promoted among other things by Linus, when non-GPLed code ended up in Linux through AFS) is related to actual functionality of the program being specifically dependant on GPLed code, vs. being a case where a common interface that existed in non-GPLed code might be used in between. This also makes moot any concern about syscalls that aren't linux-specific, as the programs using them have obvious defense of "I was following UNIX standards". On the maximalist interpretation... well, it doesn't matter if the code runs on separate machine and you talk to it over IPC. The trouble seems to stem from FSF itself misinterpreting derived to have direct application to technical specifics of linking. Whether by mistake or on purpose.

cmeacham98 6y ago
Here's Linus's actual words: > anything that was written with Linux in mind (whether it then also works on other operating systems or not) is clearly partially a derived work > Historically, there's been things like the original Andrew filesystem module: a standard filesystem that really wasn't written for Linux in the first place, and just implements a UNIX filesystem. Is that derived just because it got ported to Linux that had a reasonably similar VFS interface to what other UNIXes did? > Personally, I think that case wasn't a derived work, and I was willing to tell the AFS guys so. If we take this logic and apply it to this situation, we can see that the GPL always applies if you are intentionally designing for and using GPLed code in your program, even if you "run on separate machine and you talk to it over IPC". Now, if there happened to be some common readline API, with readline_gpl.so and readline_mit.so, then you could use it. But making up a hypothetical about readline_doesnotexist.so, when the only implementation you actually are using is readline_gpl.so is not going to convince a judge that the GPL does not apply. You could maybe get away with it if you originally designed for inputline.so, some non-GPL library that had similar functionality to readline but with a different API, and then ported to readline.so - it would be situation dependent and I'd probably talk to a lawyer here. However, that wasn't what happened here either.