True in terms of the GPL as such, but the FSFs interpretation that the GPL applies to works that link, even dynamically, to a GPL covered work, which it holds to be derivative works, depends absolutely on the API presented by a library being a copyright-protected element (it also probably can't stand even then without an extremely narrow interpretation of "fair use".)
This is not a much a question of the API as it is of the effect during execution. If the API would be considered to be what was protected then copyleft code can never be cloned in an interoperable manner under permissive licenses.
Instead the idea is that the code linking to GPL'ed code generates a new work during execution that's a derative of it AND the GPL'ed work, inheriting the copyleft license, requiring a compatible license on the linking code.
Where the GPL is concerned the distinction between linking when code has been compiled and the API itself is very clear. Code is copyrightable, but headers and interfaces do not make something else a derivative work. Stallman agrees on this one:
That is a very surface based interpretation of FSF stance on the subject. What I have heard from members of FSF board members is that the dynamic linking aspect of GPL is a simplified rule that a non-lawyer can use to identify when a derivative work is created.
The primary argument is the simple question: is there two disconnected works or a single work with separate parts, parts that exist either for technical reason or for plain arbitrary reasons. Software that is dynamically linked can't be run without the dynamic library, is dependent on the library, and generally has no purpose if you try to use it without the library. If a judge/jury member will view the complete work as the software+library, then the method of linking the two together is irrelevant.
The "first" case of this was a patch to GCC. The patch would not have much purpose without GCC. A common sense approach would be that the working Objective-C compile had two parts, the patch provided by apple and the compile provided by the GNU project. RMS initial thought like most programmers that since patches seems like separate parts than it was separate and disconnected works. However, it was unclear so he asked a lawyer and thought that a judge would not view it like that. From there the dynamic linking guideline came to be and that is where current thinking has stayed. Nothing about API is needed for this, and GPL would still work tomorrow if someone created a third method to link software together as a single work.
A interesting future case would be a program that is dynamically linked to a library that exist under several different licenses. Such software would have a strong argument to be disconnected from their library, but they would still be incomplete and a judge would likely put a lot of weight on the developers intention rather than any technical aspects.
Why? A license is just a contract, no? Can't the clauses be arbitrary?
I mean, could you have a clause in a license that said "to distribute this work, you need to wear purple shoes on Mondays"? If so, why wouldn't you just be able to say "to distribute this work, you need to distribute works that link to it under the same license", as as arbitrary condition?
> Why? A license is just a contract, no? Can't the clauses be arbitrary?
You don't need to abide by a copyright license if you aren't doing anything for which permission of the copyright holder is required in the law -- a copyright license is only needed to do things which would otherwise be prohibitd as within the exclusive purview of the copyright owner.
As the GPL isn't a sale contract that you must agree to as a precondition for receiving a copy of the software, when you receive a copy of GPL-covered software you can do anything you want with it as long as that isn't legally within the exclusive prerogative of the copyright owner (or contrary to the law for some other reason), and the GPL itself is irrelevant. The assertion by the FSF that particular uses of GPL-licensed software are constrained by the license is, therefore, necessarily an assertion that those uses are within the scope of the exclusive rights provided by copyright law.
The assertion by the FSF that particular uses of GPL-licensed software are constrained by the license
Ah, that's what I was missing. When did they assert that the use by itself (with no redistribution) is constrained by the GPL? That seems to go directly against their FAQ:
If I only make copies of a GPL-covered program and run them, without distributing or
conveying them to others, what does the license require of me?
Nothing. The GPL does not place any conditions on this activity.
Sure, you can make arbitrary restrictions for how to distribute a work in a license.
The question at hand is whether you can impose these restrictions in the viral fashion of the GPL, e.g., on code I write that merely makes use of your APIs.
The way that the GPL attempts to enforce this is with copyright law, by not granting you the right to redistribute GPLed software unless you comply with it. By design, it doesn't restrict anything else about how you use the software.
True in terms of the GPL as such, but the FSFs interpretation that the GPL applies to works that link, even dynamically, to a GPL covered work, which it holds to be derivative works, depends absolutely on the API presented by a library being a copyright-protected element (it also probably can't stand even then without an extremely narrow interpretation of "fair use".)