This is most likely very unpopular opinion but the GPL also relies on this overly broad interpretation which leaves a bad taste in my mouth.
In short, the GPL considers linking your program with it a derivative work, even if the GPL program is not distributed alongside yours. There's some limitations on it which I'm not really qualified to define, but those roughly boil down to that if you use it over a "generic interface" (network, or calling it as a process) then it doesn't count as a derivative work.
The massive problem with this is that it's a huge overreach. You are not distributing anything from their program (only the symbol names in the binary, which shouldn't be considered a meaningful amount of original work) but you are obliged to follow the terms of the licence to interoperate with a GPL-licenced program.
Granted, this is not a huge problem in practice because the GPL specifically is not used by abusive corporations much, but a similar issue happens with the enforcement of "terms of service"-s based on clickwrap "contracts" you never actually agreed to when you visit a website. Those also argue that not following their ToS also counts as either redistribution of their copyrighted work, or unauthorized access to their systems, both are huge overreaches.
This is why RMS describes the GPL as a "judo throw" - the stronger you interpret copyright to be, the stronger the GPL is. The more conservatively you interpret copyright to be, well, that's what RMS ultimately wants - the reduction and elimination of copyright law and for information to be free.
Well, eliminating copyright would also remove the copyleft portions of the GPL, which are also aimed at user freedom. I would say just removing copyright would not achieve the professed goals of the FSF: without the requirement to provide source code to users, user freedom is still constrained through that imbalance in power, even if they are free to modify and distribute the binaries they have however they wish.
That's what FSF says. Did it actually get tested in the court? I think the concept that loading program into shared address space makes it derivative work is silly.
There's very weird language at the end of the GPL:
"The GNU General Public License does not permit incorporating your program into proprietary programs."
This is bizarre because "you" is defined as "each licensee," not "each licensor." It's also contradictory with the definition of "work based on the program," which only applies to works that use the program "in a fashion requiring copyright permission" -- which dynamic linking does not.
It's also hopelessly vague. What does proprietary mean here? There's no definition, and the common definition is simply that it describes something owned by someone... which includes every GPL'd program ever.
> You are not distributing anything from their program (only the symbol names in the binary..)
This is where I would expect to see the issue being contested. The pirate bay argued that they just provided symbols in the sense of torrent files, basically sign posts giving people direction to where the work is located. They were not distributing anything from the copyrights works.
The other side did not engage that kind of argument at all. Their focus is what users saw, which is that they went to the website and through technical means got access to the copyrighted work. The steps in between was primarily deemed as irrelevant technical details.
What "the work" is, and what "distributing the work" is are two very important step in any copyright case. It is why technical workaround for copyright usually never works, even if they are waterproof in theory. A personal favorite is freenet that split files into blocks rather than bytes, in the theory that a recipe that combines blocks that are shared among multiple files could not be claimed as distributing any individual file.
Does it in fact "rely" on it, or does that merely expand its scope? Even if its claims of what is "derivative" were diminished to exclude linking/API calls, the GPL would survive, albeit as slightly less viral.
The GPL is quite conscious of the fact that several of its terms would be useless in a sensible copyright regime.
That said, although both are "broad" they are quite different concepts. The linked "interoperability" cases involve 3 works/parties A, B, and C, and the EFF's claim is that A should have no rights regarding B+C just because B+A existed first. OTOH, the GPL's relevants to linking is that A has rights regarding A+B.
The US definition of "derivative work" is quite broad, and seems to cover linking just fine.
The Berne Convention, however, doesn't mention "derivative works", only specific traditional examples thereof, so it's possible that countries other than the US may have implemented it in such a way that linking doesn't count as a derived work. TODO look up "compilation" (in the copyright sense) and "collective work", which might actually be more relevant for linking?
Edit: "GPL is MAD in the copyright cold war" is a good phrase to describe things.
> The US definition of "derivative work" is quite broad, and seems to cover linking just fine.
the problem is the GPL view seems doubtful and has not only bad implications for software copyright but copyright of... well literally anything else. I mean, remember what linking actually is (especially dynamic linking), you're basically just making references to certain things.
the analogy that I can best describe is this: if you're writing a paper on something whatever, and you link to a page number of a book, that doesn't make your paper a derivative work of that thing per se.
if I say in the middle of my novel new text on foobars and fozzinators, hey "book A page 32" has instructions for how to confabulate your fozzinator or "book B page 42" has the values needed to valienate your foobaz, referring to those things in general makes no sense to consider this originally authored book a derivative of A, B, or A and B.
or for a more concrete example, saying Microsoft should be the final authority on who can interoperate with their products or saying that the people who publish research are automatically derivative works of other peoples research[1] papers or people who write articles can't even REFER to other articles in such a way.
[1]: research itself may come from derivative ideas of course, but I'm talking about the copyrightable elements here; i.e. not the facts necessarily presented within, but rather how such facts are presented and laid out. copyright does not cover facts (true or false[2]), but your presentation of such facts are.
I would dispute that pretty heavily. They're not, and obviously have never, claimed copyright over the DLL you made or whatever, nor the entire concept of linking to Windows APIs (as an example).
Mostly because that's, like the GPL, currently a way to get laughed out of court.
Well no, it doesn't rely on it (as in, if they didn't use this argument, the licence would still hold up quite well) but it definitely has an impact. For example, see GNU Readline which was explicitly licenced as GPL to encourage virality with the linking clause.
GPL defines interface requirement in order to provide simple packaging exception. By default GPL would extend to package, but if the interface requirement isn't met, it leaves package as a collection of disconnected files.
> This is most likely very unpopular opinion but the GPL also relies on this overly broad interpretation which leaves a bad taste in my mouth.
Well, then, you're missing the point of the GPL. The point is to use copyright law against itself, with the goal of advancing user freedoms.
Not programmer freedoms, note ... but freedom for the user.
This thing that leaves a bad taste in your mouth is not the GPL, but the overly broad and restrictive copyright laws. The GPL is simply using those overly broad laws in a way to highlight just how bad they are.
If copyright was sane (or saner, anyway), the GPL itself wouldn't exist.
it's also worth bringing up some arguments made by Theodore Tso over this very issue in 1998[1]:
> Consider the following --- what defines "link"? Does an RPC call mean linking? What about shared libraries? What about making calls via the system call interface? What about running GPL'ed programs via the system() command from a commercial program? If you take things to extremes, a commercial program which uses the system() program will be interfacing with the GPL'ed /bin/bash on most systems --- is that considered "linking"?
> And if not, what is the legal distinction between what /etc/ld.so does when it maps a GPL'ed library into memory and the thread of control is temporarily tranfered from propietary code to GPL'ed library code when a library function is called, and what happens when a propietary program calls system() and the kernel maps /bin/bash into system memory, and the thread of control transfers temporarily from the propietary program to /bin/bash? You can see how things can get quite ridiculous quite quickly.
> [...]
> The FSF assertion also a very dangerous legal argument to make. If this is true, does this mean that if you write code which happens to make use of interfaces developed by Microsoft and implemented by Microsoft DLL's, that Microsoft somehow has a claim over your code which it could enforce via copyright law? What about any i386 assembly code which makes use of the Intel machine language? Does Intel now have a copyright claim on all i386 object code, and can try to prevent people from executing i386 object code on non-Intel processors? (After all, when a Pentium interprets your object code, one could argue that it is "linking" your object code with the Pentium microcode, which is copyrighted by Intel....)
> What the FSF is trying to advocate is one step down the slippery slope of interface copyrights, and we really, really don't want to go there.
i've seen arguments especially after the Google v. Oracle[2] decision and I think one in particular mentioned the sort of "reality distortion field"[3], which I found to be interesting, especially because a lot of open source projects that are GPL tend to rely on the good-naturedness of other users using their code in a way that's positively in spirit with the GPL. (which, to be fair, has probably helped open source immensely.)
but as Tso points out, therein lies a contradiction with GPL that at if its maximal interpretation to be correct, it's much much more dangerous, than if the GPL effectively is equivalent to the LGPL. but I don't think that (barring a world pre-this-case) this world is the one that is so. (no idea how the AGPL fits into this though, that sounds like a PITA.)
if I were ruler of the world, I'd say that symbol names are a matter of fact and thus should probably not be copyrightable by themselves. but then again I don't rule the world, and I'd probably have other things to change as well, even about copyright.
In short, the GPL considers linking your program with it a derivative work, even if the GPL program is not distributed alongside yours. There's some limitations on it which I'm not really qualified to define, but those roughly boil down to that if you use it over a "generic interface" (network, or calling it as a process) then it doesn't count as a derivative work.
The massive problem with this is that it's a huge overreach. You are not distributing anything from their program (only the symbol names in the binary, which shouldn't be considered a meaningful amount of original work) but you are obliged to follow the terms of the licence to interoperate with a GPL-licenced program.
Granted, this is not a huge problem in practice because the GPL specifically is not used by abusive corporations much, but a similar issue happens with the enforcement of "terms of service"-s based on clickwrap "contracts" you never actually agreed to when you visit a website. Those also argue that not following their ToS also counts as either redistribution of their copyrighted work, or unauthorized access to their systems, both are huge overreaches.