4.3BSD

As with the 4.1BSD release, criticism was quick in coming. Most
of the complaints were that the system ran too slowly. The problem, not
surprisingly, was that the new facilities had not been tuned and that many of
the kernel data structures were not well-suited to their new uses. Karels' and
my first year on the project was spent tuning and polishing the system.

After two years of work spent tuning the system and refining the
networking code, we made an announcement at the June 1985 Usenix conference
that we anticipated releasing 4.3BSD later that summer. However, our release
plans were brought to an abrupt halt by the folks at BBN. They correctly
pointed out that we had never updated 4.2BSD with the final version of their
networking code. Rather, we were still using the much-hacked initial prototype
that they had given us many years earlier. They complained to DARPA that
Berkeley was to implement the interface while BBN was supposed to implement
the protocol, so Berkeley should replace the TCP/IP code in 4.3BSD with the
BBN implementation.

Mike Karels got the BBN code and did an evaluation of the work
that had been done since the prototype that was handed off to Berkeley. He
decided that the best plan was to incorporate the good ideas from the BBN code
into the Berkeley code base, but not to replace the Berkeley code base. The
reason to retain the Berkeley code base was that it had gotten considerable
testing and improvements from the widespread distribution in 4.2BSD. However,
as a compromise, he offered to include both implementations on the 4.3BSD
distribution and let users select which one to use in their kernel.

After reviewing Mike Karels' decision, DARPA decided that
releasing two code bases would lead to unnecessary interoperability problems,
and that just one implementation should be released. To decide which code base
to use, they gave both to Mike Muuse of the Ballistics Research Laboratory,
who was viewed by both Berkeley and BBN as an independent third party. After a
month of evaluation, the report came back that the Berkeley code was more
efficient but that the BBN code handled congestion better. The tie breaker was
that the Berkeley code flawlessly ran all the tests while the BBN code
panicked under some stress conditions. The final decision by DARPA was that
4.3BSD would stick with the Berkeley code base.

The polished 4.3BSD system was finally released in June 1986. As
expected, it quelled many of the performance complaints, much as the 4.1BSD
release quelled many of the complaints about 4BSD. Although most of the
vendors had started the switch back to System V, large parts of 4.3BSD were
carried over into their systems, particularly the networking subsystem.

In October 1986, Keith Bostic joined the CSRG. One condition of
his employment was that he be allowed to finish up a project that he had been
working on at his previous job, which was to port 4.3BSD to the PDP-11. While
both Karels and I believed that it would be impossible to get a system that
compiled to 250 Kbytes on the VAX to fit in the 64-Kbyte address space of the
PDP-11, we agreed that Bostic could finish up his attempts to do so. Much to
our amazement, the port was done successfully, using an intricate set of
overlays and auxiliary processor states found on the PDP-11. The result was
the 2.11BSD release, done by Casey Leedom and Bostic, which is still in use on
some of the last remaining PDP-11's still in production in 1998.

Meanwhile, it was becoming increasingly obvious that the VAX
architecture was reaching the end of its life and that it was time to begin
considering other machines for running BSD. A promising new architecture of
the time was made by Computer Consoles, Incorporated, and was called the Power
6/32. Unfortunately, the architecture died when the company decided to change
its strategic direction. However, they did provide the CSRG with several
machines that enabled us to finish the work, started by Bill Joy, of splitting
the BSD kernel into machine-dependent and machine-independent parts. The
result of this work was released as 4.3BSD-Tahoe in June 1988. The name Tahoe
came from the development name used by Computer Consoles, Incorporated, for
the machine that they eventually released as the Power 6/32. Although the
useful lifetime of the Power 6/32 machine support was short, the work done to
split the kernel into machine-independent and machine-dependent parts proved
to be extremely valuable as BSD was ported to numerous other architectures.

Networking, Release 1

Up through the release of 4.3BSD-Tahoe, all recipients of BSD
had to first get an AT&T source license. That was because the BSD systems
were never released by Berkeley in a binary-only format; the distributions
always contained the complete source to every part of the system. The history
of the Unix system and the BSD system in particular had shown the power of
making the source available to the users. Instead of passively using the
system, they actively worked to fix bugs, improve performance and
functionality, and even add completely new features.

With the increasing cost of the AT&T source licenses,
vendors that wanted to build standalone TCP/IP-based networking products for
the PC market using the BSD code found the per-binary costs prohibitive. So,
they requested that Berkeley break out the networking code and utilities and
provide them under licensing terms that did not require an AT&T source
license. The TCP/IP networking code clearly did not exist in 32/V and thus had
been developed entirely by Berkeley and its contributors. The BSD originated
networking code and supporting utilities were released in June 1989 as
Networking Release 1, the first freely-redistributable code from Berkeley.

The licensing terms were liberal. A licensee could release the
code modified or unmodified in source or binary form with no accounting or
royalties to Berkeley. The only requirements were that the copyright notices
in the source file be left intact and that products that incorporated the code
indicate in their documentation that the product contained code from the
University of California and its contributors. Although Berkeley charged a
$1,000 fee to get a tape, anyone was free to get a copy from anyone who
already had received it. Indeed, several large sites put it up for anonymous
ftp shortly after it was released. Given that it was so easily available, the
CSRG was pleased that several hundred organizations purchased copies, since
their fees helped fund further development.

4.3BSD-Reno

Meanwhile, development continued on the base system. The virtual
memory system whose interface was first described in the 4.2BSD architecture
document finally came to fruition. As was often the case with the CSRG, we
always tried to find existing code to integrate rather than write something
from scratch. So, rather than design a new virtual memory system, we looked
around for existing alternatives. Our first choice was the virtual memory
system that appeared in Sun Microsystem's SunOS. Although there was some
discussion about Sun contributing the code to Berkeley, nothing came of those
talks. So we went with our second choice, which was to incorporate the virtual
memory system from the MACH operating system done at Carnegie-Mellon
University. Mike Hibler at the University of Utah merged the core technology
from MACH with the user interface described by the 4.2BSD architecture manual
(which was also the interface used by SunOS).

The other major addition to the system at the time was a
Sun-compatible version of the Network Filesystem (NFS). Again the CSRG was
able to avoid writing the actual NFS code, instead getting an implementation
done by Rick Macklem at the University of Geulph in Canada.

Although we did not yet have the complete feature set of 4.4BSD
ready to ship, the CSRG decided to do an interim release to get additional
feedback and experiences on the two major new additions to the system. This
licensed interim release was called 4.3BSD-Reno and occurred in early 1990.
The release was named after a big gambling city in Nevada as an oblique
reminder to its recipients that running the interim release was a bit of a
gamble.

Networking, Release 2

During one of our weekly group meetings at the CSRG, Keith
Bostic brought up the subject of the popularity of the freely-redistributable
networking release and inquired about the possibility of doing an expanded
release that included more of the BSD code. Mike Karels and I pointed out to
Bostic that releasing large parts of the system was a huge task, but we agreed
that if he could sort out how to deal with reimplementing the hundreds of
utilities and the massive C library then we would tackle the kernel.
Privately, Karels and I felt that would be the end of the discussion.

Undeterred, Bostic pioneered the technique of doing a mass
net-based development effort. He solicited folks to rewrite the Unix utilities
from scratch based solely on their published descriptions. Their only
compensation would be to have their name listed among the Berkeley
contributors next to the name of the utility that they rewrote. The
contributions started slowly and were mostly for the trivial utilities. But as
the list of completed utilities grew and Bostic continued to hold forth for
contributions at public events such as Usenix, the rate of contributions
continued to grow. Soon the list crossed one hundred utilities and within 18
months nearly all the important utilities and libraries had been rewritten.

Proudly, Bostic marched into Mike Karels' and my office, list in
hand, wanting to know how we were doing on the kernel. Resigned to our task,
Karels, Bostic, and I spent the next several months going over the entire
distribution, file by file, removing code that had originated in the 32/V
release. When the dust settled, we discovered that there were only six
remaining kernel files that were still contaminated and which could not be
trivially rewritten. While we considered rewriting those six files so that we
could release a complete system, we decided instead to release just what we
had. We did, however, seek permission for our expanded release from folks
higher up in the University administration. After much internal debate and
verification of our method for determining proprietary code, we were given the
go-ahead to do the release.

Our initial thought was to come up with a whole new name for our
second freely-redistributable release. However, we viewed getting a whole new
license written and approved by the University lawyers as an unnecessary waste
of resources and time delay. So, we decided to call the new release Networking
Release 2 since we could just do a revision of the approved Networking Release
1 license agreement. Thus, our second greatly expanded freely-redistributable
release began shipping in June 1991. The redistribution terms and cost were
the same as the terms and cost of the first networking release. As before,
several hundred individuals and organizations paid the $1,000 fee to get the
distribution from Berkeley.

Closing the gap from the Networking Release 2 distribution to a
fully functioning system did not take long. Within six months of the release,
Bill Jolitz had written replacements for the six missing files. He promptly
released a fully compiled and bootable system for the 386-based PC
architecture which he called 386/BSD. Jolitz's 386/BSD distribution was done
almost entirely on the Net. He simply put it up for anonymous FTP and let
anyone who wanted it download it for free. Within weeks he had a huge
following.

Unfortunately, the demands of keeping a full-time job meant that
Jolitz could not devote the time needed to keep up with the flood of incoming
bug fixes and enhancements to 386/BSD. So, within a few months of the release
of 386/BSD, a group of avid 386/BSD users formed the NetBSD group to pool
their collective resources to help maintain and later enhance the system.
Their releases became known as the NetBSD distribution. The NetBSD group chose
to emphasize the support of as many platforms as possible and continued the
research style development done by the CSRG. Until 1998, their distribution
was done solely over the Net; no distribution media was available. Their group
continues to target primarily the hardcore technical users. More information
about the NetBSD project can be found at http://www.netbsd.org.

The FreeBSD group was formed a few months after the NetBSD group
with a charter to support just the PC architecture and to go after a larger
and less technically advanced group of users, much as Linux had done. They
built elaborate installation scripts and began shipping their system on a low
cost CD-ROM. The combination of ease of installation and heavy promotion on
the Net and at major trade shows such as Comdex led to a fast, large growth
curve. Certainly FreeBSD currently has the largest installed base of all the
Release 2-derived systems.

FreeBSD has also ridden the wave of Linux popularity by adding a
Linux emulation mode that allows Linux binaries to run on the FreeBSD
platform. This feature allows FreeBSD users to use the ever-growing set of
applications available for Linux while getting the robustness, reliability,
and performance of the FreeBSD system. The group recently opened a
FreeBSD Mall, which brings
together many parts of the FreeBSD community, including consulting services,
derived products, books, and a newsletter.

In the mid-1990s, OpenBSD spun off from the NetBSD group. Their
technical focus was aimed at improving the security of the system. Their
marketing focus was to make the system easier to use and more widely
available. Thus, they began producing and selling CD-ROMs with many of the
ease-of-installation ideas from the FreeBSD distribution. More information
about the OpenBSD project can be found at http://www.openbsd.org.

The Lawsuit

In addition to the groups organized to freely redistribute
systems built around the Networking Release 2 tape, a company, Berkeley
Software Design, Incorporated (BSDI), was formed to develop and distribute a
commercially supported version of the code. (More information about BSDI can
be found at http://www.bsdi.com.) Like the other
groups, they started by adding the six missing files that Bill Jolitz had
written for his 386/BSD release. BSDI began selling their system including
both source and binaries in January 1992 for $995. They began running
advertisements touting their 99% discount over the price charged for System V
source plus binary systems. Interested readers were told to call
1-800-ITS-Unix.

Shortly after BSDI began their sales campaign, they received a
letter from Unix System Laboratories (USL) (a mostly-owned subsidiary of
AT&T spun off to develop and sell Unix). The letter demanded that they
stop promoting their product as Unix and in particular that they stop using
the deceptive phone number. Although the phone number was promptly dropped and
the advertisements changed to explain that the product was not Unix, USL was
still unhappy and filed suit to enjoin BSDI from selling their product. The
suit alleged that the BSDI product contained proprietary USL code and trade
secrets. USL sought to get an injunction to halt BSDI's sales until the
lawsuit was resolved, claiming that they would suffer irreparable harm from
the loss of their trade secrets if the BSDI distributions continued.

At the preliminary hearing for the injunction, BSDI contended
that they were simply using the sources being freely distributed by the
University of California plus six additional files. They were willing to
discuss the content of any of the six added files, but did not believe that
they should be held responsible for the files being distributed by the
University of California. The judge agreed with BSDI's argument and told USL
that they would have to restate their complaint based solely on the six files
or he would dismiss it. Recognizing that they would have a hard time making a
case from just the six files, USL decided to refile the suit against both BSDI
and the University of California. As before, USL requested an injunction on
the shipping of Networking Release 2 from the University and on the BSDI
products.

With the impending injunction hearing just a few short weeks
away, preparation began in earnest. All the members of the CSRG were deposed
as were nearly everyone employed at BSDI. Briefs, counter-briefs, and
counter-counter-briefs flew back and forth between the lawyers. Keith Bostic
and I personally had to write several hundred pages of material that found its
way into various briefs.

In December 1992, Dickinson R. Debevoise, a United States
District Judge in New Jersey, heard the arguments for the injunction. Although
judges usually rule on injunction requests immediately, he decided to take it
under advisement. On a Friday about six weeks later, he issued a forty-page
opinion in which he denied the injunction and threw out all but two of the
complaints. The remaining two complaints were narrowed to recent copyrights
and the possibility of the loss of trade secrets. He also suggested that the
matter should be heard in a state court system before being heard in the
federal court system.

The University of California took the hint and rushed into
California state court the following Monday morning with a counter-suit
against USL. By filing first in California, the University had established the
locale of any further state court action. Constitutional law requires all
state filing to be done in a single state to prevent a litigant with deep
pockets from bleeding an opponent dry by filing fifty cases against them in
every state. The result was that if USL wanted to take any action against the
University in state courts, they would be forced to do so in California rather
than in their home state of New Jersey.

The University's suit claimed that USL had failed in their
obligation to provide due credit to the University for the use of BSD code in
System V as required by the license that they had signed with the University.
If the claim were found to be valid, the University asked that USL be forced
to reprint all their documentation with the appropriate due credit added, to
notify all their licensees of their oversight, and to run full-page
advertisements in major publications such as The Wall
Street Journal and Fortune magazine notifying the
business world of their inadvertent oversight.

Soon after the filing in state court, USL was bought from
AT&T by Novell. The CEO of Novell, Ray Noorda, stated publicly that he
would rather compete in the marketplace than in court. By the summer of 1993,
settlement talks had started. Unfortunately, the two sides had dug in so deep
that the talks proceed slowly. With some further prodding by Ray Noorda on the
USL side, many of the sticking points were removed and a settlement was
finally reached in January 1994. The result was that three files were removed
from the 18,000 that made up Networking Release 2, and a number of minor
changes were made to other files. In addition, the University agreed to add
USL copyrights to about 70 files, although those files continued to be freely
redistributed.

4.4BSD

The newly blessed release was called 4.4BSD-Lite and was
released in June 1994 under terms identical to those used for the Networking
releases. Specifically, the terms allow free redistribution in source and
binary form subject only to the constraint that the University copyrights
remain intact and that the University receive credit when others use the code.
Simultaneously, the complete system was released as 4.4BSD-Encumbered, which
still required recipients to have a USL source license.

The lawsuit settlement also stipulated that USL would not sue
any organization using 4.4BSD-Lite as the base for their system. So, all the
BSD groups that were doing releases at that time, BSDI, NetBSD, and FreeBSD,
had to restart their code base with the 4.4BSD-Lite sources into which they
then merged their enhancements and improvements. While this reintegration
caused a short-term delay in the development of the various BSD systems, it
was a blessing in disguise since it forced all the divergent groups to
resynchronize with the three years of development that had occurred at the
CSRG since the release of Networking Release 2.

4.4BSD-Lite, Release 2

The money received from the 4.4BSD-Encumbered and 4.4BSD-Lite
releases was used to fund a part-time effort to integrate bug fixes and
enhancements. These changes continued for two years until the rate of bug
reports and feature enhancements had died down to a trickle. The final set of
changes was released as 4.4BSD-Lite, Release 2 in June 1995. Most of these
changes eventually made it into the other systems source bases.

Following the release of 4.4BSD-Lite Release 2, the CSRG was
disbanded. After nearly twenty years of piloting the BSD ship, we felt that it
was time to let others with fresh ideas and boundless enthusiasm take over.
While it might seem best to have a single centralized authority overseeing the
system development, the idea of having several groups with different charters
ensures that many different approaches will be tried. Because the system is
released in source form, the best ideas can easily be picked up by other
groups. If one group becomes particularly effective, they may eventually
become the dominant system.

Today, the open source software movement is gaining increased
attention and respect. Although the Linux system is perhaps the most
well-known, about half of the utilities that it comes packaged with are drawn
from the BSD distribution. The Linux distributions are also heavily dependent
on the complier, debuggers, and other development tools written by the Free
Software Foundation. Collectively, the CSRG, the Free Software Foundation, and
the Linux kernel developers have created the platform from which the Open
Source software movement has been launched. I am proud to have had the
opportunity to help pioneer the Open Source software movement. I look forward
to the day when it becomes the preferred way to develop and buy software for
users and companies everywhere.