Re: Plugins, libraries, licenses and Debian

[mru@kth.se (Måns Rullgård)]

bts@alum.mit.edu (Brian T. Sniffen) writes:

>>> The only problem is when you start loading both GPL plugins and
>>> GPL-incompatible plugins.  Here, your license is irrelevant; it's the
>>> plugin licenses that are in conflict.  A permissive license shouldn't
>>> add any new problems, at least.
>>
>> There is a plugin that uses OpenSSL...
>
> You want to distribute a package which makes takes advantage of code
> others have written and distributed under the GPL.  Part of the deal
> they offered you was that you could use their code, but in exchange
> there would be no restrictions on what you distribute but the GPL's.

I'm not placing any restrictions on the distribution of their code,
nor on any of my code that uses GPL'd libraries.

> You *also* want to have functionality in your package from Eric
> Young's SSLeay.  Part of the deal under which he lets you use his code
> is the requirement that you advertise for him.

The OpenSSL license has these requirements (typos copied verbatim):

 * Redistribution and use in source and binary forms, with or without
 * modification, are permitted provided that the following conditions
 * are met:
 * 1. Redistributions of source code must retain the copyright
 *    notice, this list of conditions and the following disclaimer.

I'm not distributing the OpenSSL source code.  I'm distributing code
that, when compiled, will be linked dynamically with OpenSSL libraries
at runtime.

 * 2. Redistributions in binary form must reproduce the above copyright
 *    notice, this list of conditions and the following disclaimer in the
 *    documentation and/or other materials provided with the distribution.

Again, I'm not distributing any OpenSSL code as binaries.

 * 3. All advertising materials mentioning features or use of this software
 *    must display the following acknowledgement:
 *    "This product includes cryptographic software written by
 *     Eric Young (eay@cryptsoft.com)"
 *    The word 'cryptographic' can be left out if the rouines from the library
 *    being used are not cryptographic related :-).

Strictly speaking, my program doesn't include anything written by Eric
Young.  It makes calls to software written by him, but that is not the
same as including it.  I'd venture to guess that this was written
thinking of programs copying (parts of) the SSL library as source code
into a bigger program or library.

 * 4. If you include any Windows specific code (or a derivative thereof) from 
 *    the apps directory (application code) you must include an acknowledgement:
 *    "This product includes software written by Tim Hudson (tjh@cryptsoft.com)"

Not applicable.

This is followed by two identical sections with these requirements,
more or less equivalent with the above, with the addition of 4 and 5:

 * Redistribution and use in source and binary forms, with or without
 * modification, are permitted provided that the following conditions
 * are met:
 *
 * 1. Redistributions of source code must retain the above copyright
 *    notice, this list of conditions and the following disclaimer. 
 *
 * 2. Redistributions in binary form must reproduce the above copyright
 *    notice, this list of conditions and the following disclaimer in
 *    the documentation and/or other materials provided with the
 *    distribution.
 *
 * 3. All advertising materials mentioning features or use of this
 *    software must display the following acknowledgment:
 *    "This product includes software developed by the OpenSSL Project
 *    for use in the OpenSSL Toolkit. (http://www.openssl.org/)"
 *
 * 4. The names "OpenSSL Toolkit" and "OpenSSL Project" must not be used to
 *    endorse or promote products derived from this software without
 *    prior written permission. For written permission, please contact
 *    openssl-core@openssl.org.
 *
 * 5. Products derived from this software may not be called "OpenSSL"
 *    nor may "OpenSSL" appear in their names without prior written
 *    permission of the OpenSSL Project.
 *
 * 6. Redistributions of any form whatsoever must retain the following
 *    acknowledgment:
 *    "This product includes software developed by the OpenSSL Project
 *    for use in the OpenSSL Toolkit (http://www.openssl.org/)"

> You can't distribute a package which combines all of this and
> satisfies all of these requirements.  You have to either forgo the
> functionality offered by one of these otherwise generous authors and
> write it yourself, or find a way to do it that doesn't involve the
> copyrights of these authors.

The question is about when something is to be considered a derived
work.  Keep in mind that the GPLv2 is dated 1991, and is based on the
even older GPLv1 (I can't find an exact date).  The OpenSSL license
originated in the early 1990's.  Back in those days, dynamic linking
wasn't nearly as common as it is today, if it was used at all, and may
not have been thoroughly considered by the authors of licenses.
Today, dynamic linking is commonplace, and thus the question of
whether dynamic linking creates a derived work, *before* the linking
takes place, has arisen.

The OpenSSL license frequently uses the term "use".  In my view, code
calling OpenSSL functions uses the OpenSSL *API*, not the OpenSSL
*code*.  I have seen many claims that an API can not be copyrighted.
Is this true?

Adding to my arguments, plugins to my program must implement one or
more interfaces defined by me, and licensed under the MIT license.
The plugins can not communicate except through these interfaces.
Well, they _could_ of course get around this, but mine don't do that.

> Distributing it as separate packages -- *really* separate packages,
> clearly not a single work which happens to be in multiple volumes --
> is OK.  Getting an OpenSSL license exception from all the authors of
> the GPL'd libraries could work.  Or you could use the GNUtls package,
> which is LGPL'd (though the OpenSSL compatability layer itself is
> GPL'd).

It's a shame that so much time gets wasted on reimplementing things,
only because of some questionable legalities.

-- 
Måns Rullgård
mru@kth.se