On Tue, May 03, 2005 at 07:06:36PM -0700, Steve Langasek wrote:
>
> The license of the GNUTLS OpenSSL shim is GPL, causing possible license
> problems in the other direction with GPL-incompatible apps. It's also not a
> very complete compatibility layer.
>
So dynamically link against _an_ SSL library, using dlopen(), and this
completely trumps the issue. The fact that there are multiple
libraries, implementing the OpenSSL interface, means that as long as
the application calls the *interface* it can't be derived from
*either* library, and it escapes the license incompatibility issues.
(Remember, license compatibility can only be an issue if the program
can be shown to be a derived work of a particular library. If it is
calling an interface which is implemented by more than one library,
then clearly it can't be a derived work, and once it is not a derived
work, copyright law by definition can't apply.)
Example: The libss library searches for the readline, editline, and
libedit libraries via a search path, and dlopen()'s the first one it
can find. It the calls those interfaces to get readline
functionality. The Solaris SEAM (Solaris Enterprise Authentication
Mechanism), which is a propietary program which is derived from the
MIT Kerberos V5 sources, also happens to call the libss library, with
which it is dynamically linked.
Yet now when you run the Kerberos administration CLI program from
SEAM, and install the newer version of libss library so that it
dynamically links with it, and then the libss library could possibly
dlopen the GNU readline library ---- you can a process containing
propietary Solaris code, BSD licensed libss code, and GPL'ed readline
library, all in the same address space. But has there been a GPL
violation? No, since, the only time a derivitive work can
conclusively shown to be created is when the user ran the kadmin
program, and the GPL does not restrict use, only distribution.
Could the kadmin program be considered a derived work of the readline
library? No, because it was written to call libss *years* ago, long
before libss was modified to potentially call the readline library.
The kadmin program called the libss *interface*, and at the time the
author of the kadmin program had no idea that it might subsequently
end up calling a GPL'ed library indirectly via libss. And
furthermore, the BSD-licensed libss program does not even directly
link against the readline library, but rather uses dlopen() and
dlsym() to call a particular *interface* which could be satisified
either by a GPL or BSD licensed library. So how can you say that the
libss program is a derivitive work of either library?
I believe you can use a similar solution to solve the openssl library
problem. If there is a shim layer, and the application uses a search
path to find a library which it then dlopen()'s, this should
completely trump the license compatibility issue, since in this case
it is clear that it is not a derived work of any one particular
library, but rather it is calling an interface which can be satisified
by multiple libraries, and which library will get used can only be
determined at run-time.
- Ted
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
