Re: GPL-licensed packages with depend-chain to OpenSSL
Glenn Maynard <glenn@zewt.org> schrieb/wrote:
> On Sun, Sep 05, 2004 at 09:07:00PM +0200, Claus Färber wrote:
>> Brian Thomas Sniffen <bts@alum.mit.edu> schrieb/wrote:
>>>> If we follow this interpretation, this means that you can't distribute
>>>> an closed source OS with GPL tools. IMO, this was not the intention of
>>>> the GPL authors. If you have to distribute the component with the GPL
>>>> software, this is a sign that it's not universally available on the
>>>> operating system. However, if you are distributing an OS...
>>
>>> That was *exactly* the intent of the GPL authors: to prevent Sun from
>>> distributing the GNU tools with Solaris. They do distribute them
>>> separately.
>>
>> They did. Solaris 9 reportedly comes with GNU tools (I can't check it
>> myself because I don't have a machine running Solaris).
>>
>> I can't find anything on the FSF's homepage that says you can't distri-
>> bute GNU tools with non-GPL operating systems. Further, I can't find an
> This is all irrelevant. The issue is that you can't distribute GPL
> binaries *linked against* GPL-incompatible libraries.
It's more complicated than that when dynamic linking is involved.
It ultimatly does not make sense if you can choose one of several
libraries (with different licenses) that can be dynamically linked
against a program without recompiling it.
For example, you distribute a program linked against "libcurl". It works
with "libcurl-nossl", "libcurl-gnutls" -- but also "libcurl-ssl". Is it
linked against a GPL-incompatible library?
> A vendor can't distribute a GPL binary for its operating system if its
> libc, or any other library used by the GPL binary, is GPL-
> incompatible.
Again, it is more complicated. What if you have both a free and binary-
compatible proprietory version of the os? E.g., is a Windows program
linked against the Windows DLLs if users can run it with wine? What
about Linux binaries that can run on Solaris' emulation layer?
I think you can make a good case that in all of these examples, the
library and and actual programs should be considered separate works,
even though they use dynamic linking.
> The operating system clause makes an exception for this, but it's not
> available when the program is packaged along with the libraries.
The GPL does not say "packaged along with", it says "accompanied with".
The later suggests a closer relationship than mere aggregation on the
same distriution medium.
> It is *not* intended to allow OS vendors (Microsoft, Debian) to link
> GPL applications against whatever proprietary code (such as Word or
> OpenSSL, which are both "proprietary" as far as the GPL is concerned)
> they wish.
There is one big difference here: Word can not be considered a "major
component ... of the operating system". OpenSSL can.
There is no loophole to link against *any* proprietary code.
> The "accompanies the executable" restriction exists to close this
> loophole.
You could only claim that something is "normally" part of the os when it
is not. IOW: Having to distribute a component with your software is a
sign that that component is not part of the os.
Well, as you say, the clause is supposed to close such loopholes.
There is no indication that it is also supposed to prevent os vendors
from distributing GPL'd tools along with their operating system.
Actually, the results of such an interpretation are quite ridiculous:
. You could not distribute updates for an os and GPL'd software for that
OS on a magazine CD. You could put them on the CDs of two subsequent
issues - or is it enough if you have two CDs in one issue?
. You could not distribute Debian (including OpenSSL) along with
OpenSSL-dependent programs but you could set up a different, apt-
get'able repository with these tools. It was even suggested that
putting them in "whatever-but-not-main" is enough.
. You could not sell an proprietary os including GPL tools on the
distribution media, but you could sell the GPL tools as a separate
product or have the user download GPL tools from your website to make
your os useable.
> This is all very well known to be fundamental to the intent of the GPL.
> If you want to convince us that the intent is actually different, you
> should start by asking licensing@fsf.org.
I think you'd better explain the intent of the GPL to them and ask why
they don't sue Sun or Apple.
Claus
--
http://www.faerber.muc.de
Reply to: