Subject: Re: Merger//dt and july94 kernels on SE30
To: Greg Ames <>
From: Chris G. Demetriou <>
List: macbsd-general
Date: 08/31/1994 00:46:48
[ Yes, i really, really, really have better things to do than this,
  but i'm trying to whittle away some time...  Also note that when i
  say 'we' i'm speaking for myself, but have received input from many
  of those who've worked on NetBSD for the last year and a half.  I'm
  sure this isn't as clear as it can be; i'm tired and wanted to get
  this off my plate today.  I've redirected replies to myself, because
  this isn't really appropriate for the list.  i'm definitely
  willing to explain myself further to those who inquire privately,
  however.  (If i can debate it with John Gilmore over coffee, i can
  surely do so with others in e-mail. 8-) -- cgd ]

> What's the incompatiblity between NetBSD and the GPL?  Am I correct
> that it is because NetBSD is still under the UCB copyright (I don't
> have any code to refer to; it's at home)?

First, let me say the following things:
	(1) i am not a lawyer, and
	(2) i do not even play one on the net.

I have recently, however, had the need to investigate intellectual
property (and in particular, copyright) law, and a friend of mine
who's a lawyer basically filled me in on the important details.

Also, note that i'm not talking about the LGPL in the following
discussion, only the GPL.

By the license terms outlined in the GPL, any binary that includes
code based on GPL'd sources must have the complete sources used to
build the binary made available.  (The ways in which the source code
can be made available are enumerated in the the GPL, however one thing
is made clear about the form of the source code: it must be in its
original, "primary" form.  In other words, if it's C source, you can't
run cpp over it before giving it away.)  "Simple aggregation" of
binaries (such as putting binaries from GPL'd sources and other
sources on to a CD-ROM) doesn't impose this requirement of
distribution on the other sources whose binaries are aggregated with
the GPL'd binary.  The "upper bound" on "simple aggregation" isn't
well defined -- it's more than putting two things together on a CD-ROM
or in a tar archive, but it's less than linking them together.

If GPL'd sources are combined with sources with other license terms,
in the same binary, then the license constraints on _all_ of the
software must be followed.  For instance, if you're using 'crunch' (a
package which helps link multiple binaries into one, larger binary,
saving space by avoiding duplication of library routines) to glue
together, say, the NetBSD init(8), gzip(1), and a few other utilities,
you'd have to satisfy the Berkeley License _AND_ the GPL.

For the Berkeley license and the GPL, that's not difficult.  You just
distribute sources and give adequate credit in advertising material
and "supporting documentation."

However, consider the case where you're combining GPL'd sources into a
binary with "random" objects -- say, those found in the system library
on a SunOS system.  You CANNOT legally give away the sources to those
library routines, and you may not even have them!  However, by a
strict interpretation of the GPL, you'd have to, and thus it would
be _ILLEGAL_ for you to create and distribute a gzip binary for SunOS.

Well, then comes the question: what is distribution?  obviously,
putting something up for FTP and announcing it to the 'net is
distribution.  But, say you're an internet service provider, and
provide people with shell accounts for a fee.  Can the copy of 'bash'
you've compiled for customer use be world-readable?  (if so, users
can copy it, and since you made it available to them, it could be said
that you distributed it...)

That's a strange set of questions, eh?  It's not meant to indicate
"this will happen," it's meant to show that under a strict
interpretation of all the terms, it _could_.  There are a lot of gray
areas in the GPL.  Those gray areas mean that, since precident
hasn't really been comprehensively established yet for intellectual
property law as it relates to software, if you go into court and your
claims lie in a 'gray area,' you're rolling the dice.

If you compare this to the Berkeley copyright, you'll see a vast
difference; the Berkeley copyright succinctly spells out exactly what
compliance with the license terms implies.  All that's required is
proper attribution.  There are few, if any, gray areas in the license
terms of the berkeley copyright.

That, however, is not the only (or even primary) reason why _i_
dislike the GPL.  The GPL claims that it exist to make software "Free"
-- not in the "cost" sense, but in the "you can copy it" sense.

However, true freedom implies much more than the ability to copy
some software!  It implies the ability to do _whatever_you_want_ with
that software.  TRUE free software is that which is placed in the
public domain by its authors.  However, in many cases, especially
where people have put a lot of work into a piece of software, that is
not feasible.  Berkeley-style copyrights are a very close second to
complete freedom -- you can do anything you want, as long the people
who've worked on the software are properly credited.

It's quite plain that in the commercial world, it's not feasible to
give away your software.  In many cases, the software is what makes
your business profitable.  Should you have to release the sources to
it all because you included one header file that somebody else wrote?
No, you shouldn't.  But if that header file were GPL'd, you'd have to!

You'll note that because of this problem, you'll find very little
GPL'd software used or distributed by vendors, in their systems.
For vendors, the GPL has the potential to be legal suicide.  On the
other hand, you'll notice that almost all UN*X-like systems
distributed by vendors contain at least some Berkeley-derived code.

Now, what does that have to do with NetBSD?  I, and the other people
in NetBSD's core team believe that software should be as free as
possible.  People should be able to do whatever they like with it, as
long as those of us who have worked on it are given credit for the
work we've done (because some of us make our incomes off of
consulting, so name recognition is important).

We don't believe that it is our place to tell people what they can do
with their money and time, and think it is unconscionable put
restrictions like the GPL on software and call it 'free'.  We _are_ in
the business of supporting _free_ software, software which is
distributed with minimally encumbering licenses.

Because of that, we have to be careful about what we can include in
the NetBSD source tree.  We refuse to have any GPL'd or LGPL'd system
libraries or programs, if reasonable alternatives are available.  We
completely refuse to put any GPL'd code in the kernel, because we want
people who might develop and distribute NetBSD-based products (and
there are several) to be able to do so with minimal hassle.

This has caused painful decisions in the past.  For instance, there's
a good math emulator for the i386 written by Bill Methenzen, for
Linux, that's under the GPL.  We can't use it in our kernel, because
it's GPL'd and because we couldn't talk the author into letting us use
it under a different license.  Life goes on.  eventually, we'll have
as good an emulator, and ours will be _free_.

In summary, the NetBSD Project is about creating and distributing
high quality software that is truly free of encumbering licenses.
Using software with the GPL would make more of our software have
_more_ encumbering licenses, even though the GPL, hypocritically,
claims to encourage just the opposite.  Additionally, because of a
lack of clarity in the GPL's license terms, its legal status has not
yet been completely determined, making it hazardous for any form of