> A proprietary app on a GNU/Linux system can use the C library function system() which might invoke /bin/sh that is GNU Bash, and even depend on that functionality.
And that according to FSF is legal because it do not create a derivative work. You said above that "GPL cannot reasonably rule out dynamic linking", but now you are picking and choosing which part of FSF interpretation of derivative is correct and which is wrong. I just wanted to point out that the law could have been easily interpreted in a different way if someone had challenged FSF interpretation 25 years ago.
> But what if that cut-up never leaves my house? Or what if I only distribute instructions
Again, the law is both clear and quite fuzzy at the same time. The author has the exclusive right to transform their work, and as such, you could get charged even if it never leaves your house. In EU its a bit different, since it talks about moral right which protect the integrity of the authors work, through the end result is likely to be the same in many cases.
As for just giving out instructions, the legal nature of those are extremely fuzzy. If I provide instructions that reproduce a copyrighted video (by compressing/encrypting the data that represent it), I will still run foul of copyright infringement. From what I have seen, courts tend to take a "common sense" approach to this problem and if the end result is an infringement, then the indirect steps that will cause an infringement becomes infringement too. Judges collectively seem to rule against people who they perceives as trying to bypass laws by technicalities.
> You should note that the FSF's opinion is that statically or dynamically linking does not alter the status of the result being derivative work or not.
Dynamic linking may or may not create a derivative work on applicable copyright law (on which matter the FSF's opinion is merely the FSF's opinion), but static linking involves directly embedding the libraries code into the final product, which is unmistakably within the exclusive rights of copyright.
In any case, the FSF's opinion on this issue actually makes the GPL more problematic than the alternative would make it.
> then called it through your operating system interface, then you _might_ be fine
Might, exactly. Depending on various courts accepting there is a loophole in GPL, and my layman understanding is that there isn't. Skimming GPLv2 I don't see them differentiating in derivative works between those that use compile time linking and those that use mechanisms like CLI. I'm weary of bringing after the fact constructs to justify something that GPL doesn't talk about. And after all how is CLI that much more different than dynamic linking - CLI is merely an interface that is subjectively a bit more friendly in certain situations but this imo shouldn't a have a bearing in legal discussions.
> 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.
> If you could attempt to ELI5 how I'm potentially getting part of this wrong, or point me to some article, I'd appreciate it!
Suffice to say: a shallow reading of the GPLv2 might lead one to believe that the CDDL and the GPLv2 are incompatible. And I believe SFC and FSF's readings of the GPLv2 and copyright law, which the GPL incorporates by reference, are shallow. There are quite a few reasons to believe a CDDL and ZFS combination would not be incompatible. If you want learned legal opinions expressing my/this contrary view there are a few. [0], [1], [2]. Moreover, I'd warn you that SFC and FSF are not disinterested parties. They have agendas which extend beyond whether ZFS is actually incompatible to what that might mean for the GPL.
If you want my unschooled personal understanding -- most generally, there is no reason to believe that dynamic linking creates a derived work. Without further reasoning, FSF's analysis obliterates this boundary without reference to case law, and without an argument as why this must be the case. Whereas I think there are sound copyright law reasons to think where one creates an API boundary, through the use of dynamic linking or otherwise (a modular kernel interface), fair use allows one to make use of software at that boundary.
This is a difficult pill to swallow for many FOSS advocates because this would mean closed source software modules would be permissible in combination with the Linux kernel. And while I understand their political reasoning for disfavoring this view, I think their legal reasoning is weak. I also think the FSF view makes it much harder to build software which interoperates with other software, which BTW should be a key goal of the FSF and FOSS advocates.
I'm just not sure your copyright license has this kind of power. Imagine you build some software which links to MegaEvil Corp's libc, whose license specifically states, if you link to this libc, your work is a derived work of MegaCorp libc, you forfeit all copyright to MegaEvil Corp. My feeling is any court would say building any such software at an API boundary is fair use and copyright law simply does not grant any court the power to enforce this copyright term.
More specifically re: ZFS module and the GPL, I'd dig into what is a "derived work". The GPLv2 after all incorporates the copyright term by reference at Section 0 when describing a "work based on the Program". I'd consider the ambiguity of what is the "whole" work as described in Section 2 and how that might be construed in light of the long held copyright distinction between derived and collective works. I'd also consider recent copyright jurisprudence when asking whether any court would take the view that distributing the Linux kernel and ZFS module is a copyright violation. [3], [4].
> You said above that "GPL cannot reasonably rule out dynamic linking", but now you are picking and choosing which part of FSF interpretation of derivative is correct and which is wrong.
I don't see how you perceive a position change here. The FSF considers dynamic linking to be derivative; I do not agree.
We both consider the invocation via command line not to be derivative.
> now you are picking and choosing which part of FSF interpretation of derivative is correct and which is wrong.
Have been all along. "Dynamic linking is derivative" is almost complete bullshit in my eyes.
It's pretty much pure use. We map this object into memory and then call it.
My understanding is that it isn't under the theory of what counts as a derivative work requiring a license (and, thus, what is subject to GPLv2 in the first place) espoused by the FSF, however, I believe that view has been hotly disputed as to its accuracy under US copyright law (at least) for about as long as the GPL has existed and never been tested in court.
The FSF, in general -- as is unsurprising for entity that relies on maximally leveraging copyright protections to achieve its ends -- holds to a fairly maximalist view of the legal rights of copyright owners.
What's the FSF's position on this, I wonder. The whole premise of the GPL as opposed to the LGPL is that even dynamic linking creates a derived work.
If someone creates a completely drop-in replacement for readline (I don't know if libedit and kin are drop-in or not) and releases it under a BSD license, there's no way to distinguish my app linking against one vs the other, I'm simply making use of the API in the abstract.
This isn't exactly the same as the Java case, but the copyright status of APIs per-se sure seems to have implication for the GPL's teeth.
>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.
>But usually it’s a misunderstanding of what derivative works are. E.g building an extension to a GPL app. Many don’t believe that simply importing a GPL Python module is enough to make your extension have to comply to GPL.
The GPL doesn't explicitly define the concept of derivative work. The FSF's interpretation is that linking creates a derivative work, but there's no universal consensus among lawyers on this issue.
> The statement you quote is not on point, since there is no "module B" here. What they are trying to describe in that is the situation where someone takes a GPL piece of code, and writes a wrapper module (module B) that adds some kind of interface that their proprietary module (module C) knows how to interface with, and then they distribute this whole mess.
Other than flipping C and A around, what you describe exactly matches the situation from the GPL FAQ.
Apart from that, I'm not going to argue GPL, derived works, and linking here; suffice it to say that the interpretation of the GPL authors is that code calling into GPLed code (directly or indirectly) is a derived work and subject to the GPL, and thus may not be proprietary. That's the interpretation and intention of the FSF in writing the license, and it's the standard interpretation in the broader FOSS community.
> Have you never used third party code that you didn’t compile yourself?
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
> but if the resulting work depends on someone else work.
Yes, so obviously your argument cannot be that "in theory, we could replace this with a workalike".
You better have the workalike, and that's what you should be shipping.
A powerful argument that you aren't infringing is that your shipping media are completely devoid of the work.
> don't care if its use or integration
For the sake of the GPL, they must care in this case, because the GPL specifically abstains from dictating use; it governs redistribution!
The only parts of the license relevant to use are the disclaimers; the only reason a pure user of a GPL-ed program might want to read the license at all is to be informed that if the program causes loss of data (or whatever), the authors are not liable.
GPLed programs get used all the time. A proprietary app on a GNU/Linux system can use the C library function system() which might invoke /bin/sh that is GNU Bash, and even depend on that functionality.
> For example, if I buy a painting and cut it into pieces and rearrange them, I actually need an additional license beyond what I got from purchasing the copy.
But what if that cut-up never leaves my house?
Or what if I only distribute instructions which describe the geometry of some cuts which can be made to a painting, and the relocation of the pieces?
> Its not exactly hard to comply with the AGPL. Just choose either to not modify the software
Unfortunately, the GPL and AGPL suffer from the same flaw: they don't rigorously define what a derivative work is. The way the licences are written they make the definition seem self evident, but it's self evident the way porn is self evident - everyone knows it when they see it.
For example, from the way the GPL is written, dynamic linking to something makes it a derivative work, but invoking services from a http server is not. So how about I circumvent your GPL licence by putting an RPC shim layer than talks over http?
Some projects have solved the problem by drawing their strict demarcation lines. For example, Linus has publicly stated on numerous occasions that using the kernel user user space API does not make a user space program a derivative work of the Linux kernel. Somewhat more dubiously, they seem to tolerate kernel modules that use GPL kernel symbols only. I've convinced myself that strong, clear demarcation is fundamental to Linux being accepted everywhere.
The reason this is important is when you say "choose to not modify the software", the software in question is the original software or any derivative work. The problem is there is no clear definition of when your code becomes a derivative work. If you give a lawyer that much wriggle room and put enough money up as the prize, and you end up spending 10's of millions defending lawsuits from Oracle's lawyers trying to wriggle through an "API is copyrightable" loophole.
A GPLv4 that insisted the licence holder clearly define what they consider to be a derivative work would IMO be a big step forward in copyleft licences. Oh and get rid of the "Installation Information" requirement, or at least make it compatible with code signing. A device defending itself by insisting any binary it runs is signed by a trusted source is not compatible with defining the private keys securing the signature are "Installation Information".
> The userspace ABI is stable and intended not to cause anything targeting it to become a derived work. But once again, this seems to be a way in which the kernel project seems to think it has the power to interpret the GPL. In their minds, targeting the userspace ABI doesn't make a derived work, but writing a module does, unless it only targets GPL_ONLY symbols, in which case for some reason it isn't.
I think this whole part applies as much to the text of the GPL itself as to the common Linux explanation. The GPL draws a distinction between dynamic linking, static linking, and use over a network or through a CLI style interface to decide if a work is a derived work of the GPL program. But, this distinction is just a novel legal theory proposal at best - there is nothing in copyright law that would make the GPL distinctions authoritative.
A license simply doesn't get to decide what constitutes a derived work - that's entirely up to copyright law itself and the court system to decide.
On the other hand, unless and until Congress decides to explicitly legislate how copyright should apply to software, the courts can very well take common industry practice into consideration for judging what is and is not a derived work of a program, and in this sense the Linux kernel developers' opinion is in no way less impactful than the proposals in the GPL itself.
Furthermore, in a matter of contract law (so assuming that the work is indeed judged to be derived according to copyright law, but now judging whether the GPL may offer some relevant exemptions), the stated intentions and interpretations of the parties of the contract are indeed relevant. If there is a long history of kernel developers publicly stating that as long as you are not using GPL_ONLY symbols, your work should not be considered to be under the purview of the GPL, and if this has not been commonly publicly contested, I think that in an actual trial this will matter much more than other interpretations of the GPL.
> I think this whole part applies as much to the text of the GPL itself as to the common Linux explanation. The GPL draws a distinction between dynamic linking, static linking, and use over a network or through a CLI style interface to decide if a work is a derived work of the GPL program.
I just rechecked and it does not seem the GPLv2 does such things. I've not rechecked for v3, but from memory it does not do that either.
I completely agree with you that clear intent is important though.
> Among these, that if we wish to produce any derivative works (under the GPL's definition of "derivative"), we must also release these under the GPL.
This is not quite correct, in my opinion.
Copyright only applies to your work, and works which are derivative works according to copyright.
You can't write a license that requires someone to release 'all' his work under the GPL, for example. (It may be different if it's a contract.)
That's just what the FSF wants you to think. Of course, it usually doesn't pay to go through the legal hassel to defend yourself from unjustified claims by the FSF -- thus it's an effective chilling strategy.
> So no, it's not about a specific situation. It's about the principle of the thing.
That's fair.
> i.e. if the FSF can be founded on the principle of freedom, why can't I claim to believe in the principle of freedom too?
They're founded on a principle of freedom as defined specifically by the four freedoms.
> The logical conclusion of that statement is that copyright doesn't really matter, whether the license is GPL or not. Violators can ignore the copyright, secure in the confidence that the majority of people won't have the resources to sue.
Yes there's a problem with the Copyright system. But the law does act as a deterrent because there is always risk involved in violating it.
> So why don't we assign copyright for all open source projects to the FSF?
The simple answer: they only accept copyright assignments for GNU projects.
They don't have the staff for enforcing others' copyrights, though; there's other organizations for that, like the Conservancy.
> After all, if the software is free, it doesn't really matter who the copyright holder is, right?
Sure it does: only the Copyright holder has standing in court.
> If it's freedom, why does the GPL need copyright law?
I'm sorry, I don't understand what you're trying to say.
The free software definition specifies four specific freedoms:
http://www.gnu.org/philosophy/free-sw.html
It is essential that the user be able to exercise those freedoms no matter what, which means ensuring that certain conditions on the distribution of the program are met, and that all derivative works are also free. This hack on copyright is called Copyleft, and it uses copyright to grant rights _back_ to the user.
https://www.gnu.org/copyleft/
Copyright needs to be used because, in many countries, works are proprietary by default; there is no choice; in the US, if you do not explicitly grant rights to others, then all rights are reserved.
> But then, does this mean anyone can ask for the source of closed-source software that use GPL code, like the ones below? (I just dug two random examples).
If their software is a derivative work of someone else's code then they can't distribute their software without a license from the copyright holder of that code. In the case of the GPL, that licenses them only to distribute their code under the GPL. If they are distributing their software other than under the GPL, then that is copyright infringement (in the same way as if they had made a derived work of some non-GPL code and distributed that), they lose their license, and any holder of a copyright on the code that their software was a derivative work of could sue them for copyright infringement. (In theory they sue for damages; in practice the copyright holder of GPLed code they made a derivative of will usually settle for compliance and an agreement to have their future releases audited).
What constitutes a derivative work is a question for the courts. It's generally accepted that any program that uses a library is a derivative work of that library, and a program that invokes another program at arms length or via a standard interface is probably not a derivative work of that program. The exact boundary is unclear; there's a case to be made that a program that is tightly coupled to another program and invokes it via piped commands might still be a derivative work even though it's not shared objects.
The LGPL is an entirely different license from the GPL.
And that according to FSF is legal because it do not create a derivative work. You said above that "GPL cannot reasonably rule out dynamic linking", but now you are picking and choosing which part of FSF interpretation of derivative is correct and which is wrong. I just wanted to point out that the law could have been easily interpreted in a different way if someone had challenged FSF interpretation 25 years ago.
> But what if that cut-up never leaves my house? Or what if I only distribute instructions
Again, the law is both clear and quite fuzzy at the same time. The author has the exclusive right to transform their work, and as such, you could get charged even if it never leaves your house. In EU its a bit different, since it talks about moral right which protect the integrity of the authors work, through the end result is likely to be the same in many cases.
As for just giving out instructions, the legal nature of those are extremely fuzzy. If I provide instructions that reproduce a copyrighted video (by compressing/encrypting the data that represent it), I will still run foul of copyright infringement. From what I have seen, courts tend to take a "common sense" approach to this problem and if the end result is an infringement, then the indirect steps that will cause an infringement becomes infringement too. Judges collectively seem to rule against people who they perceives as trying to bypass laws by technicalities.
reply