undefined | Better HN

0 pointsfluoridation2y ago0 comments

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

0 comments

3 comments · 1 top-level

quotemstr2y ago· 2 in thread

> If the program is closed source, then yes, you've broken copyright law.

My point is that although many believe that linking proprietary code and GPL code into the same process breaks copyright law, it's not clear that the law actually forbids it. https://tech.popdata.org/the-gpl-license-and-linking-still-u... is one analysis by someone else skeptical of the FSF's position.

fluoridationOP2y ago

I would argue that the act that makes a piece of software "derivative" of another is not loading them both onto the same address space (since that's a symmetric relation anyway), but whether making one depend on the other having a specific behavior. If A.so provides foo(int) with some contract C and B.so depends on an implementation of foo(int) that matches the contract C, then arguably B.so is derivative of A.so, and the more facilities A.so provides and B.so assumes are available, the stronger that argument becomes. Whether the way A.so and B.so communicate is through a calling convention, a pipe, or a network connection, is largely an implementation detail.

quotemstr2y ago

I have two points:

1) it's not clear your interpretation of what makes software "derivative" is correct. One interesting analysis is https://studylib.net/doc/18120956/triggering-infection--dist......

2) if you are correct, then isn't it a violation of copyright law to use a socket or a pipe to talk to a GPL program? For example, if I execute popen("parallel ..."), I'm using a pipe to talk to a GPLed program (assuming "parallel" is GNU parallel). I expect this program to adhere to a specific command line interface. My program won't work with anything else. Is my program violating the GPL by running GNU parallel as a subprocess? Most people would say "no". This position seems incoherent to me.

One of two conditions must then hold: either a) dlopen has legal significance, or b) much of the Linux ecosystem is out of compliance with the GPL because it attempts to use pipe() to circumvent the GPL and this approach doesn't actually work. Which is it?

2 more replies

j / k navigate · click thread line to collapse