Scripsit Simon Law <[EMAIL PROTECTED]>
> 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.
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.
> 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.
--
Henning Makholm "We're trying to get it into the
parts per billion range, but no luck still."
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
