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.
yes
> 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.
If they distribute it together though then it becomes an aggregate work
unless you make sure that gumby is speaking for the FSF, then that comment does not provide evidence that the FSF believe that. It's merely evidence that gumby does.
I don't understand why people are so quick to take somebody's personal opinion and ascribe it to whatever organization(s) they happen to belong to. This sort of fallacy is why we constantly have to suffer through the "I speak only for myself, not my organization" disclaimers
And indeed I do not speak for the FSF and never have.
You should try arguing in court for FSF legal theories on linking!
Some things shouldn't change just because entitled people are inconvenienced by them.
The only pertinent question is whether a program B designed to require library A is a derived work of library A or not - and this is a question for the copyright courts, the license of library A has nothing to say about this.
Now, I think even if it were established that program B is not a derived work of library A, it could be possible for library A to have a license that says "you're not allowed to distribute this library to others unless both you and they agree to never link program B or works derived from it with library A". The GPL could be modified to say something like this, and it may still match its original goals - though it may be more difficult to litigate this type of license term (in many countries, license or contract terms can be declared too onerous and be ignored).
