Ansgar Burchardt <ans...@debian.org> writes: > Russ Allbery <r...@debian.org> writes:
>> Most upstream authors that I've spoken with don't believe that >> licensing crosses the shared library ABI boundary, that the shared >> OpenSSL library and the GPLv2 program that calls it remain separate >> works, and therefore there is no need for OpenSSL to meet the GPLv2 >> requirements since the binary as distributed is not a derivative work >> of both projects. Instead, the projects are combined at runtime by the >> end user, who doesn't have to meet any redistributability requirements >> of either license. >> The FSF is a notable exception to this. > One can create a shim library implementing the interface that does > nothing and also provide headers stripped of comments (including > parameter names). Then one can use that shim headers and library to > create a program that uses the given interface. > However none of the copyrightable parts of the library in question were > used during this process, unless the interface was copyrightable. Does > the FSF believe this? This is one of the places where you have to be careful about the difference between software and law. Introducing a shim layer solely to obscure the linkage between the binary and the shared library is unlikely to change the matter from a legal perspective; in fact, you could possibly end up in a worse legal position if the judge decided you were doing this in an intentional effort to deceive. What does matter is if there are multiple, unrelated functional implementations of the same interface. In that case (such as with readline, whose interface has been independently reimplemented in BSD-licensed code), even the FSF has conceded the point that the license will not cross that sort of API boundary. But you have to actually have another functional, independent, clean-room implementation to make use of that legal argument. Otherwise, you still have to argue the hotly disputed point of whether writing a program to an API that's unique to one software project makes your program a derivative work of that project. > This is basically the other direction of what Wine or Samba do (they > reimplement the library given the interface). Except they do a full clean-room reimplementation of the interface, so this is more akin to the readline situation. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87r48urob9....@windlord.stanford.edu
