Re: GPLed software and OpenSSL
On Wed, 2002-05-29 at 15:24, Henning Makholm wrote:
> Scripsit Simon Law <sfllaw@engmail.uwaterloo.ca>
>
> > libssl0.9.6 is a standard library in main, so I guess it could
> > very well be construed as a standard Debian Operating System library.
> > Could we get the FSF to clarify if this would allow us to link GPLed
> > software to this library under the OS linking provision?
>
> I'm not the FSF, but I don't think it fits. The intended meaning of
> the "unless that component accompanies the executable" exception seems
> to be something along the lines of
>
> RMS says: You may distribute binaries of GPLed programs for a
> proprietary operating system, even if the binaries
> of necessity contain pieces of the proprietary operating
> system's proprietary system libraries.
>
> RMS says: However, this will not be the case if you're the *vendor*
> of that proprietary operating system. We will not allow you
> to enhance the utility of your steenking proprietary code by
> bundling it with our free software. Set your operating
> system free instead.
>
> Because of the GPL's inability to distinguish between "proprietary"
> and "not GPL" (which has good legal-technical reasons) this means
> that Debian's role w.r.t. the exception MUST be that of the
> proprietary OS vendor, to the extent that Debian includes non-GPL
> libraries.
I would agree with you to the extent that we should generally adhere to
the intent, which is no doubt what you have described. In this case,
however, we are looking for a way to avoid delaying the woody release
any more than it already has been. In such a case, filing a "statement
of intent" to follow the spirit of the law and a good-faith effort to
follow the letter of the law may be the best route.
> Any other interpretation would seem to open a loophole that would
> allow Microsoft to ship, e.g., GNU Emacs as a standard component of
> Windows, linked against MS's proprietary user interface libraries.
Actually, this is already done in the proprietary UNIX world, and the
FSF hasn't seen fit to complain. At least Sun and SCO/Caldera ship a
GNU add-on CD as a separate product that contains prebuilt gcc, emacs,
etc. for their proprietary UNIX, and have done so openly for years.
See, for example, http://www.caldera.com/skunkware/ and
http://www.sun.com/software/solaris/freeware.html.
I see no reason why Microsoft could not do the same with one or more of
the various ports of GNU software to Windows. Of course, they couldn't
bundle it.
> > If the FSF approves this, then we can take corrective action
> > with the software authors;
>
> That would be the sane and right way of solving the problem. Clearly,
> if the authors have written all the code themselves, what they want is
> obviously to allow linking with this particular non-GPL library. But
> if they have borrowed code from other purely GPL projects, we're in
> deep trouble.
In most cases, I think that rebuilding the package with "--no-ssl" or
some such should do the trick. For others, simply removing the
offending package may also suffice.
--
To UNSUBSCRIBE, email to debian-legal-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: