Free software is different.

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?

Yeah, I know that's the FSF's interpretation. I don't buy it, and here's why: this interpretation followed to its logical conclusion makes huge swaths of the free software ecosystem illegal. See, the FSF theory is that libproprietary.so becomes a derivative work of libmysql.so because it calls APIs provided by libmysql.so. Maybe the FSF is right. Maybe they're wrong. If they're right, though, why should it matter how I use libmysql.so's APIs? Do socket() and connect() make libproprietary.so not a derivative work? Why? I can use an API over a socket too --- and if using an API makes my program a derivative work, then every proprietary program that talks to MySQL is in trouble. This conclusion is absurd: therefore, our premises are wrong.

You might say, "well, MySQL's socket API is obviously for general purpose use". So is libreadline's. So what? Either calling a public API propagates copyleft or it doesn't. Differentiating between calling APIs via dlopen() and via socket() makes no sense. I know the industry behaves as if there were a difference, but legally, is there? Show me the case law.

The reason I can't just download LabVIEW and run it isn't that it's a library: it's proprietary software! I don't have permission to have it on my machine except by following the rules of the LabVIEW license. I don't need permission to have libmysql.so

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.

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.

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?

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

What do you have in mind in particular?

Afaik the FSF agrees with your dichotomy and expresses the latter opinion. Take for instance their faq "You cannot incorporate GPL-covered software in a proprietary system. ... However, in many cases you can distribute the GPL-covered software alongside your proprietary system. To do this validly, you must make sure that the free and nonfree programs communicate at arms length, that they are not combined in a way that would make them effectively a single program. The difference between this and “incorporating” the GPL-covered software is partly a matter of substance and partly form. The substantive part is this: if the two programs are combined so that they become effectively two parts of one program, then you can't treat them as two separate programs. So the GPL has to cover the whole thing."

In another question, they address the notion of what might be considered a single combined porogram. "It depends on how the main program invokes its plug-ins. If the main program uses fork and exec to invoke plug-ins, and they establish intimate communication by sharing complex data structures, or shipping complex data structures back and forth, that can make them one single combined program. A main program that uses simple fork and exec to invoke plug-ins and does not establish intimate communication between them results in the plug-ins being a separate program.

"If the main program dynamically links plug-ins, and they make function calls to each other and share data structures, we believe they form a single combined program, which must be treated as an extension of both the main program and the plug-ins. If the main program dynamically links plug-ins, but the communication between them is limited to invoking the ‘main’ function of the plug-in with some options and waiting for it to return, that is a borderline case.

"Using shared memory to communicate with complex data structures is pretty much equivalent to dynamic linking."

So I don't think that the FSF intends that you can use a technical means to escape linking. You cannot take a GPL library and write a pair of libraries which expose its functions via a socket because the result would almost certainly involve "function calls to each other and share[d] data structures".

https://www.gnu.org/licenses/gpl-faq.html

As to whether this puts into jeopardy anyone in particular who uses Linux or libmysql in proprietary systems without additional licences, well, that is a different matter. The FSF's interpretation of the GPL tells you something about when the FSF might sue you and about what revisions might be made to the GPL in the future. But it doesn't tell you about when the copyright holders of Linux or libmysql might sue you, or what they will do if there's a GPL v5.2 released tomorrow.

As far as I know, the FSF takes the view that linking is a logical concept not a technical one, and so communicating via IPC is just as much of a problem as loading a program into your own addressable memory.

> This conclusion is absurd: therefore, our premises are wrong.

I don't think you've demonstrated that it's absurd. For instance, it could be that MySQL does not believe it is a problem, and does not intend for it to be a problem, and will never sue for it - but that MySQL is wrong as a matter of law, and one day the FSF will sue someone in court and win and the Oracle lawyers will realise they have new opportunities for financial gain. Personally, I think that reality is more like this - the FSF and Oracle have different ideas about what it means to release code under the GPL and so the freedoms you get from the FSF are different from the freedoms you get from Oracle, and it's unclear to me what will hold up in a court of law. I certainly don't think there's anything absurd about the notion that different agents have different intents and conflicting understandings. (Note that I take the notion of freedom to include the confidence that I won't be sued by a rational agent for doing something, regardless of whether I could plausibly win the case or not.)

> I know the industry behaves as if there were a difference, but legally, is there? Show me the case law.

I don't think it makes a difference whether the case law is there. The difference is made by whether you're willing to go to court over it. If there is a chance that you will win a case, and there is a chance that you will loose a case, and that if you lose the case you will have to spend the next six months on full time development just to get back where you were before hand, then you might say "even though my lawyers say there is an 80% chance that we will win, I would rather use this BSD alternative, because the risk of that 20% are existential".

So, fundamentally, this is a case of put your money where your mouth is. If you think the GPL does something different than what "industry" thinks it does, then make your business, make your millions, and dare someone to sue you. No one else has an obligation to do that just because you haven't seen the case law.

> I don't have permission to have it on my machine except by following the rules of the LabVIEW license. I don't need permission to have libmysql.so

Btw, here you have a false premises. You don't have permission to copy libmysql.so except by the terms of the licence. I think you've made a mistake. Let's go back. You said "I can already freely copy libmysql from system to system in either source or binary form. The GPL grants me permission to do that." But now you're claiming that the GPL's grant of permission is so absolute that you don't need the permission that it grants. In fact, the terms of the licence are limited, and the question is only to what extent they are limited.

In any case, there is one important consideration. And that is the intent of the FSF. If the terms of the GPL fail to have the legal consequence they intend, and they can modify the GPL to have the legal consequence they intended, then you can be sure they will. And if Oracle has a different intent, and likes the legal consequences that the GPL has, then they might continue to use the unchanged licence. But arguing about whether the GPL does to the FSF's code what the FSF wants the GPL to do is more about arguing about whether it is buggy, then arguing about the feature set. You are well advised to listen to the FSF's interpretation if you want to rely, indefinitely into the future, on an up-to-date version of the FSF's code. But the FSF's interpretation might not really be as important when it comes to Linux or MySQL or any of the other GPLed code bases out there.

Er, dude, you do. A Free license doesn't mean there is no license. If you obtain libmysql.so and use it in any way, you have to respect the license or you're in breach of copyright law.

The fact that free (re)distribution is allowed by the license does not mean that the use of it in any way is not restricted.

> this interpretation followed to its logical conclusion makes huge swaths of the free software ecosystem illegal

That might well be. Free licenses are abused every day, as people don't really know what this or that license requires. They even routinely strip copyright statements on MIT/BSD code, which is literally the only thing one is not supposed to do. But just because people get away with speeding over the limit on most days, it doesn't mean that the speed limit is not legally enforceable.

The GPL is a distribution license, not a use license. Once they've received that source and/or binary, they can do whatever they want with it as long as they aren't distributing it. (Copying it to another machine under their control may or may not be distribution, depending on the circumstances.)

Yes, once they want to distribute their copy to others, they need to comply with the terms of the GPL. But not before then.

We're talking about following the GPL to the letter with respect to libmysql.so. The GPL says nothing about what I can do with a program on my system not covered by the GPL.

Copyright law has however implemented exceptions in the form of interoperability. The distinction between creating a derivative work, or having two works communicating with each other, is a relative fuzzy one.

He's talking about various ways code written by one party may invoke code on the same computer written by someone else but not saying exactly how those two chunks of code came to be on the same computer running at the same time. Without knowing all the people involved in that it is not possible to say what copyright law says about who needs to get permission from whom.

You've talked about "derived dependencies by law" but "derived dependencies" is not a term I've come across in US copyright law.

A lot of free/open source discussion (and sometimes the licenses themselves) tends to use terms that have "derived" in them but mean some sort of vague superset of what copyright law means by "derivative work".

In particular, if work X depends on work Y, even to the point that X is not really useful unless used with Y, that does not necessarily make X a derivative work of Y. That's why game console makers had to use DRM to stop other companies from making cartridges for they game consoles. Even though the software in the cartridges was utterly dependent on the code in the console to do anything the cartridges were not derivative works.

To be a derivative work of Y, X must incorporate some or all of Y. Suppose for example Y is a text to speech library which exports a function "int speak(char * text)". If I write a file, greet.c, that contains this:

  #include "y_speech_lib.h"

  int main()
  {
      speak("Hello, World!");
      return 0;
  }

I can license greet.c under any license I want and distribute it under any terms I want without having to worry about Y's license as far as possible liability to me for direct copyright infringement goes. I'll cover indirect infringement later.

If I want to distribute a.out then I do need to worry about Y's license, because a.out is a derivative work of Y.

If someone else makes an a.out from my greet.c and Y they are making a derivative work, and need permission (maybe [1]) from me and from Y's copyright owner.

It is possible to be an indirect copyright infringer. There are a few different kinds of indirect infringement, such as vicarious infringement and contributory infringement. What they all have in common is for someone to be liable as an indirect infringer there must be a direct infringement for them to be indirectly liable for. If there is no direct infringer there cannot be an indirect infringer.

Since most open source licenses only impose requirements when you distribute code, doing stuff with it on your own computer just for you own use will usually not be a direct infringement, and hence no possibility of indirect infringement for those who supplied you with other code that you used with the open source code code.

Even if you combine my greet.c with someone else's code on your computer and distribute the resulting binary in violation of that other code's license (making you a direct infringer) I'd be OK unless (1) I had the right and ability to control you and received a direct financial benefit from your infringement, (2) I distributed greet.c with the object of promoting its use for such infringement and clearly expressed that or took affirmative steps to encourage it, or (3) greet.c has no other substantial uses that are not infringing.

[1] I say maybe because if they are just compiling and linking copies of greet.c and Y that they legally own in order to use them on their machine they might not need permission. US copyright law contains an exception for things that are an essential step to utilize a program on a machine (17 USC 117) and they don't do anything else with it like distribute it.

I think this is very much debatable, and I believe the FSF at least takes the position that greet.c is a derived work of Y since it is designed to depend on Y. Even more, their position is that a program like this:

  #include <stdlib.h>
  
  int main() {
    create_complex_c_code_using_gcc_specific_extensions("./intermediate.c");
    system("gcc -o intermediate ./intermediate.c");
    system("./intermediate");
  }

Now, this type of thing has never been tested in a court of law as far as I know, so it's difficult to say whose interpretation of copyright and its implications is actually correct. But this is similar to the idea that if you were to write an original novel that uses characters or very recognizable aspects of, say, The Lord of the Rings, you'd be creating a derived work (and thus permission from the Tolkien estate), even if you didn't include any part of the original longer than "Galadriel".

  #!/bin/sh
  say Alexa what time is it

Link it how, though? If you statically link it with Y, then I can see the argument that a.out is a derived work, because it literally contains all of Y in it.

But if you dynamically link it, a.out contains no more of Y than greet.c does. Are you asserting that a.out is still a derived work of Y in this case as well?

That one.

> But if you dynamically link it, a.out contains no more of Y than greet.c does. Are you asserting that a.out is still a derived work of Y in this case as well?

No, I'm not asserting that that a.out would be a derivative work of Y.