3 ms·
I have always been skeptical of the FSF dogma that dynamic linking of a module or shared library into a GPL program's address space propagates the GPL into that
by quotemstr 6y ago
I have always been skeptical of the FSF dogma that dynamic linking of a module or shared library into a GPL program's address space propagates the GPL into that module. The choice of inter-module communication technique (dynamic linking, sockets, etc.) shouldn't have any bearing on licensing. Either components are independent or they're not. There's nothing magic that happens when you take an API that's intra-process and run it over a socket instead. If FUSE filesystems don't carry the GPL tag, neither should in-kernel modules logically decoupled from the kernel core.
- belorn 6y agoYou are right that the choice of inter-module communication technique does not have a bearing on the licensing unless the license explicit say so. To be fair to FSF however, they have to my knowledge never actually said anything else. What they do say is that they will enforce the license at that distinction, a conclusion RMS arrived at many years ago when apple tried to make proprietary addons to GCC. The reasoning, as provided by a consulted lawyer Eben Moglen at the time, was that a judge would likely see it as creating a single derivative work out of the linked parts, and as such you need a copyright license. This story has been mention in a few talks because so far no one has yet to challenge FSF in court and prove it wrong, which is a fight that at least Eben Moglen have been all this years willing (and possible wanted) to take up if given the opportunity. As a bright line in the sand the concept has served FSF well, but it is not a supreme court decision that defines what a derivative work is under software. It could be that the line should be drawn much more narrower, but personally my bet is the opposite. Courts are rarely on the side that want to abolish copyright control or limit its scope.