|
|
|
|
|
by prutschman
3682 days ago
|
|
> Which I believe is OK with everyone 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. |
|
Okey, in this fantasy world, do we still have the concept of derivative work? I would say Yes. Would thus GPL still apply? Yes. Is there an API? No.
GPL is not based on the technology of linking. As a software license, it used the concept of derivative work, distribution and other concept in copyright law to define the scope. LGPL in contrast do specify linking technology, but that is only an additional permission which would need to be modify if it were to function with new linking technologies.
If you created a drop-in replacement for readline, the argument that the complete work is readline + some code get weaker. However, if the police finds some emails on your drive that states your intention to combine readline + some code, and then go to copy readline by reimplemented the software in a identical (copy'ish) way, then you might very well be infringing on the right of the readline authors. It depend what a judge/jury think your intentions was.