If you use any 3P library it’s a derived dependency by law. Is that what you are arguing? It’s settled law at this point.
MS lets you link against their DLLs but only on their platform. You might pay for a special library, but you have to pay them money for programs that link against it (actually does anybody do that any more?). GPL code is no different in any way except instead of paying the FSF cash or buying a Windows OS you agree to provide the user the freedom to change the code.
Not it's definitely not. For B to be a derivative work of A it needs to include copyrightable elements of A. But if B merely dynamically links to A then it only contains knowledge of the API surface of A. And SCOTUS refused to rule on the copyrightability of APIs in Google LLC v. Oracle America, Inc. In the EU APIs seems to be explicitly called out as non-copyrightable by Directive 2009/24/EC Article 1(2):
> 2. Protection in accordance with this Directive shall apply to the expression in any form of a computer program. Ideas and principles which underlie any element of a computer program, including those which underlie its interfaces, are not protected by copyright under this Directive.
If you call write() in Microsoft’s libc you must follow Microsoft’s license terms or you don’t have the right to use it. If you call glibc’s write() the same applies. And if you don’t like glibc’s terms you are free to, say, install bsd’s libc or write your own write() implementation (which probably just does a system call anyway).
I find this interesting, and maybe I am just a bit confused. But here is what I am wondering now.
If it is not about the use of an API but about the use of the implementation, then that would mean that the end-user that is running the application which dynamically links to a proprietary library on the end-users pc the one violating the license terms, not the developer that distributed their code without distributing the proprietary library itself.
And if the developer has the rights to distribute the library, because it is under GPL, then they could do so, and would not violate the license terms, because they are not doing the dynamic linking and using of the implementation, that would happen only when the end-user starts the application.
I never heard about any case against end-users, that for instance used the proprietary Nvidia kernel module, compiled and linked on each end-user's PC.
I don't think that works that way, there has to be more to that than just the usage of the implementation that triggers the license violation.
Is it? So if I, the author of non-copyleft A, want to use copyleft library B, it's illegal if I use `dlopen` but legal if I use a socket or a pipe? That's absurd. Either both are illegal or both are legal, and I've yet to see evidence that it's the former.
IOW, I've yet to see evidence that licenses apply across dlopen bounds. It's a meme in our industry that it does, but does it really? Where's the data?
Hell, Unity itself (the topic of this article) is an example. Labview. Some code for talking to a spectrometer we bought for our lab last month. It’s extremely common. People used to sell libraries to do various computations and charge royalties for their use. Probably they still do but I don’t work in that kind of world any more.
You may call it absurd if you like but that’s how the system works. The GPL and LGPL deliberately do not break new ground in that regard. What was/is novel about them is not using an exchange of money, but rather other value instead. No more, no less.
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
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.
Licenses apply across certain kinds of linking and not others because that's what was in the document you agreed to when you installed the copyleft code. In order to run the code, you have to accept the terms of the contract. Those terms can require almost anything the author wants. In this case, the terms specify propagation over dlopen and not over a socket or pipe. They could just as easily specify the opposite! It would be less sensible, but perfectly possible.
The GPLv2 (for clarity: GPLv3 is more verbose but communicates the same idea) says:
> 3. You may copy and distribute the Program (or a work based on it, under Section 2) in object code or executable form under the terms of Sections 1 and 2 above provided that you also do one of the following: > a) Accompany it with the complete corresponding machine-readable source code, which must be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or, > b) Accompany it with a written offer, valid for at least three years, to give any third party, for a charge no more than your cost of physically performing source distribution, a complete machine-readable copy of the corresponding source code, to be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or, > c) Accompany it with the information you received as to the offer to distribute corresponding source code. (This alternative is allowed only for noncommercial distribution and only if you received the program in object code or executable form with such an offer, in accord with Subsection b above.)
Where does this license talk about linking? Why should the GPL apply to my program that calls libreadline when I'm distributing the two separately and combining them at runtime? And more importantly, why does a combination involving dlopen() summon the copyright demons but socket() not? The distinction makes no sense.
I'd like to see actual case law showing that if I dlopen() libreadline from a proprietary program, dlsym() a function, and call it, then I've violated copyright law. Show me one example of the legal system adopting this interpretation.
what may be more relevant is that the use of the GPL is evidence that the author (possibly) believes in maximalist FSF theories. and therefore might not be someone whose libraries you want anywhere near your work, for avoidance of potential disputes.