[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: GPLed software and OpenSSL

On Fri, 2002-05-31 at 16:43, Henning Makholm wrote:
> Scripsit Jeff Licquia <licquia@debian.org>
> > > 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.
> Hm, I haven't followed the concrete circumstances closely. I thought
> this was about new licensing terms for an upstream release that
> wouldn't make Woody in any case. I may be confused here.

I'm addressing Simon's particular point that lots of stuff in non-us is
GPL and links against OpenSSL.  The situation with Nessus, it would
seem, is as you describe.

> However, what the GPL allows and doesn't allow is not influenced by
> how much in a hurry Debian is at any given time.

True.  My point was that we would adhere to the letter of the law now,
and resolve the problems with the spirit of the law later.  My
"good-faith effort" wording may have been unclear; I meant by this that
we should resolve all "letter-of-the-law" violations now that we know

> > > 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.
> I think it is crucial that these are distributed *separately* as
> add-ons. If they were part of the core OS distribution (to which we
> can equal main but possibly not non-free) I'm sure the FSF would have
> gone to battle. Otherwise the entire purpose of the "unless that
> component accompanies" clause eludes me.

Yes.  That is why I'm proposing that non-us be considered divorced from
regular Debian main, and that we not do things like make CD images with
non-us on them.  At least, not until we take care of all the GPLed
OpenSSL-linked stuff in there.

To UNSUBSCRIBE, email to debian-legal-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Reply to: