Re: GnuTLS in Debian
Ansgar Burchardt <ansgar@debian.org> writes:
> Russ Allbery <rra@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 (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: