Subject: Re: Merger//dt and july94 kernels on SE30
To: Ted Lemon <firstname.lastname@example.org>
From: Chris G. Demetriou <email@example.com>
Date: 08/31/1994 13:44:55
[ replies again directed to me; this doesn't belong on this mailing
Ted Lemon said:
> >From the GPL:
> However, as a special exception, the source code distributed need not
> include anything that is normally distributed (in either source or
> binary form) with the major components (compiler, kernel, and so on)
> of the operating system on which the executable runs, unless that
> component itself accompanies the executable.
First of all, if you read that comment carefully, you'll note that
vendors cannot 'safely' ship GPL'd sources with their systems. In
that case, "that component" (the library) _would_ be "accompan[ying]
the executable", and thus they'd have to ship the library sources as
Additionally, this section, has a nice big gray area in it. What is a
"major component" and what constitutes "normal"?
(1) on Solaris, where the compiler (and i assume, .a files)
is sold seperately from the base system, what's the
deal? (it's _NOT_ a major component of the operating
system, in that case, at least by sun's definition.
it's an optional add-on package, though it could be
covered by the specific mention of "compiler.")
(2) is the windowing system a part of the operating system?
How about on systems where it's sold seperately?
Do people that distribute binaries that contain GPL'd
sources and also contain windowing system libs have to
distribute the sources for those libs?
(3) how about other "add-on" products, sold by third parties,
that include libraries or .o files?
(2) and (3) become especially interesting: what if you're selling
motif binaries (with licensed sources), but use 'bison' to do parser
generation? (i forget, doesn't bison cause the output .c file to be
covered by the GPL?)
What if you use the -lwhizzyfastc library sold as an addon, by a third
party, instead of the normal libc?
The point is, it can become a legal nightmare, and one of the points
of _really_ free software is to _AVOID_ just those types of problems.
Ted Lemon also said:
> I would be very upset if I put a lot of work into a subsystem in
> NetBSD and then saw Berkeley withdraw permission to copy and
> commercialize the product. It's only because I have a certain amount
> of trust that Berkeley won't do this that I'm willing to hack on
Actually, berkeley _can't_ do that, for various reasons, not the least
of which is that they've signed a lot of contracts that say that will
not (unless they are provoked, e.g. by not giving proper attribution).
If they do, you can sue them in a court of law for breach of contract,
and, assuming their decision had no provocation, they will lose.
Berkeley _could_ change the terms under which _future_ Berkeley
Software Distributions are distributed. However, in that case, "you
knew the job was dangerous when you took it," if you donated some code
back to berkeley under the standard contribution agreement. (If you
didn't sign the standard contribution agreement: (1) they wouldn't be
distributing it with a berkeley copyright, and (2) they couldn't
change _your_ terms at all.)