Scripsit Jeff Licquia <[EMAIL PROTECTED]>
> > 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.
However, what the GPL allows and doesn't allow is not influenced by
how much in a hurry Debian is at any given time.
> > 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.
--
Henning Makholm "They want to be natural, the anti-social
little beasts. They just don't realize that
everyone's good depends on everyone's cooperation."
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
