4 ms·

> Why does perl being linked have anything to do with that? The perl script itself is GPL... First of all: IANAL. Yes, and the perl script will remain GPL, bu

by lawl 4y ago

> Why does perl being linked have anything to do with that? The perl script itself is GPL... First of all: IANAL. Yes, and the perl script will remain GPL, but that doesn't make the rest of the program a derived work. That even seems to be the position of the FSF: > The Free Software Foundation [...] asserts that an executable that uses a dynamically linked library is indeed a derived work. This does not, however, apply to separate programs communicating with one another. Perl (and the script) is a separate program, the entirety of CheatEngine is not automatically a derived work of the perl script. Thus the script can remain GPL and CE could be licensed any way it wants without a problem. Wikipedia has a section dedicated to this: https://en.wikipedia.org/wiki/GNU_General_Public_License#Linking_and_derived_works https://en.wikipedia.org/wiki/GNU_General_Public_License#Lin...

nybble41 4y ago
>> The Free Software Foundation [...] asserts that an executable that uses a dynamically linked library is indeed a derived work. Which if you think about it is really a very problematic assertion, for a couple of reasons. First, it doesn't seem to be related at all the the definition of "derived work" in the Copyright Act (in the US) or the examples given for other kinds of derived works, which all involve incorporating creative elements from the original work into the derived work. These elements might be translated or rearranged or otherwise transformed, but they're still necessary for the work to count as derivative. Linking against a dynamic library has more in common with referencing another work in your bibliography—which so far as I am aware has never been considered enough on its own to consider the referencing document a derivative work. But more importantly: The FSF also maintains that a clean-room, from-scratch open-source reimplementation of a proprietary library with a compatible ABI is not a derived work of the proprietary library. (For example Lesstif vs. Motif, or Wine vs. Windows.) A program which is dynamically linked against some library is only dependent on the library's ABI, not the specific implementation of the library, and can be used at runtime with either version. So is it a "derivative work" of the original proprietary library, or the open-source reimplementation? And of course the same logic could be applied the other way around for a program which can be (but need not be) dynamically linked against a GPL library—it could just as easily be linked against a proprietary reimplementation of the same library with a compatible ABI. And why should it make any difference for the purpose of declaring something a "derivative work" whether the reimplementation under a compatible license already exists, or merely could exist? The part which is asserted to be "derivative" hasn't changed at all. I am not (a / your) lawyer, yada yada, but the "dynamic linking implies derivative work" argument has always struck me as being at odds with both the plain meaning of "derivative work" and actual practice when the situation is reversed.

by lawl 4y ago

nybble41 4y ago

>> The Free Software Foundation [...] asserts that an executable that uses a dynamically linked library is indeed a derived work. Which if you think about it is really a very problematic assertion, for a couple of reasons. First, it doesn't seem to be related at all the the definition of "derived work" in the Copyright Act (in the US) or the examples given for other kinds of derived works, which all involve incorporating creative elements from the original work into the derived work. These elements might be translated or rearranged or otherwise transformed, but they're still necessary for the work to count as derivative. Linking against a dynamic library has more in common with referencing another work in your bibliography—which so far as I am aware has never been considered enough on its own to consider the referencing document a derivative work. But more importantly: The FSF also maintains that a clean-room, from-scratch open-source reimplementation of a proprietary library with a compatible ABI is not a derived work of the proprietary library. (For example Lesstif vs. Motif, or Wine vs. Windows.) A program which is dynamically linked against some library is only dependent on the library's ABI, not the specific implementation of the library, and can be used at runtime with either version. So is it a "derivative work" of the original proprietary library, or the open-source reimplementation? And of course the same logic could be applied the other way around for a program which can be (but need not be) dynamically linked against a GPL library—it could just as easily be linked against a proprietary reimplementation of the same library with a compatible ABI. And why should it make any difference for the purpose of declaring something a "derivative work" whether the reimplementation under a compatible license already exists, or merely could exist? The part which is asserted to be "derivative" hasn't changed at all. I am not (a / your) lawyer, yada yada, but the "dynamic linking implies derivative work" argument has always struck me as being at odds with both the plain meaning of "derivative work" and actual practice when the situation is reversed.