NET 1 2

History of FreeBSD – Net/1 and Net/2 – A Path to Freedom

History of FreeBSD

Part 5: Net/1 and Net/2 – A Path to Freedom

Author’s note: So far this history has been jumping around a little bit. That’s my fault. I’m learning about the history of BSD as we go along. I’m sure that a few of the more eagle-eyed BSD scholars have noticed the discrepancies, and I’d like to apologize for the jumping around.


With that in mind, this article is going to cover the time period from the release of 4.3BSD with TCP/IP to the BSD lawsuits. This period set the stage for BSD as we know it today. That being said, let’s get started.

A New Architecture?

4.3BSD was released in June of 1986 with Berkeley’s TCP/IP code installed. An InformationWeek article declared that this release of BSD was the “single Greatest Piece of Software Ever, with the broadest impact on the world”. At the time, the VAX architecture, which was used by a majority of DARPA projects, was getting long in the tooth.

Initially, it looked like VAX would be replaced by a new product from Computer Consoles, Incorporated, named Power 6/32. Plans to replace VAX with Power 6/32 were short-lived because CGI decided to go in a different direction. However, it did leave a big impact in the future of BSD.

An engineer named Mike Sullivan was performing routine maintenance on Jurassic when he made a typo. With that keystroke, the server went down and a thousand engineers were left with nothing to do until the data was restored from backups. 

Computer Consoles, Incorporated provided Berkeley with several of their Power 6/32 machines to help with the porting process. As part of that process, Bill Joy split the “BSD kernel into machine-dependent and machine-independent parts”. This work would make it much easier to port BSD to other architectures in the future. The results were released in June of 1988 as 4.3BSD-Tahoe. “Tahoe was the code name for the Power 6/32.”

(Interesting side note: While the platform was short-lived, Pixar’s Computer Animation Group used a Power 6/32 machine to render part of 1985’s Young Sherlock Holmes.)

Networking for All

DARPA had invested quite a bit of money into BSD to get networking and other features added. But that investment only really benefited DARPA research partners. Anyone else who wanted access to BSD, and its networking capabilities had to pay for an AT&T software license. After all, BSD contain proprietary AT&T code. “That was becausethe 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.”

According to Kirk McKusick, such a license would cost $250,000. (It still amazes me how expensive the software that download without a second thought used to cost.)

As a result of the exorbitant cost of the AT&T license, people started asking about the possibility of getting access only to Berkeley’s TCP/IP networking code. “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.”

In response, the networking code written by Berkeley, and the supporting utilities were released as a standalone product. This took place in June of 1989. It was called Networking Release 1 (or Net/1) and it was “the first freely-redistributable code from Berkeley”.

Compared to AT&T’s products, the license on Net/1 was downright liberal. Someone who bought a license could release the code without having to pay any royalties to Berkeley. The released code could be modified. The only stipulation was that the original copyright notices had to be left in place and products based on Berkeley code had to note in their documentation that it contained code from Berkeley.

Also, unlike AT&T, Berkeley charged a relatively small licensing fee of $1,000. The developers didn’t think that they would sell very many copies, but they were wrong. It was very popular. In the end, over a thousand people sent in their money to get a licensed copy. Since licensees could redistribute it, Net/1 was hosted on many FTP sites and spread from there.

This was the first real BSD because it didn’t contain any proprietary code.

Work Continues

With the release of the networking code, work continued to progress on the base system. One of the things the developers worked on was adding a virtual memory system. There were two that they were interested in: Sun Microsystem’s SunOS implementation and Carnegie-Mellon University’s MACH.

After performing some analysis, the Berkeley team decided to go with Sun Microsystem’s virtual memory system. They worked their way through Sun’s chain of command all the way to Scott McNealy, who was the CEO. They received green lights all the way, until the lawyers got involved. The lawyers suggested that Sun could be “sued by your stockholders for giving away company assets.” The team ended up using the MACH virtual memory system instead.

You might also be interested in

Improve the way you make use of ZFS in your company

ZFS is crucial to many companies. We guide companies and teams towards safe, whitepaper implementations of ZFS that enhance and improve the way the infrastructure is enabling your business.

The developers also worked on making BSD more POSIX compliant. POSIX is a set of standards from the IEEE Computer Society for “maintaining compatibility between operating systems”. This made the BSD code based larger than it had been previously.

Several other additions were made, including a network file system, and support for “the HP 9000 range of computers”.

This update was released as 4.3BSD-Reno in July of 1990. This was an interim release designed to test the changes that had been made this far. “Our goal in making this release available is to get feedback on any problems in the design or implementation of the new facilities, as well as to allow adventurous sites to gain experience with these portions of 4.4BSD.”

The announcement noted that “this distribution is NOT intended to be used on production systems”. (The name Reno was a reference to the gambling center in Reno, Nevada. Thus, installing it was considered a gamble.) It also states: “The reason that this distribution is not labeled 4.4BSD-alpha is because it does not contain several major interfaces that we plan to have available for that distribution.”

Freedom Nears

The popularity of Net/1 led to many people asking if they could release more code. After all, since Net/1 “consisted primarily of networking code, it was hardly a replacement for Unix”.

Keith Bostic, one of the three BSD devs, pushed the idea of rewriting and replacing the propriety AT&T code, so they could release it to the public. The others told him that it would be a lot of work, and challenged him to find a way to get the utilities and libraries rewritten.

Bostic started one of the first crowdsourcing efforts to do just that. “He solicited folks to rewrite the Unix utilities from scratch based solely on their published descriptions.” Anyone who did this would not get paid. Instead, they would have their name “listed among the Berkeley contributors next to the name of the utility that they rewrote”. “For example, vi, which had been based on the original Unix version of ed, was rewritten as nvi (new vi). “

The project started slowly and was limited to simple utilities. Eventually, more contributions came in. In the end, “nearly all the important utilities and libraries had been rewritten” in 18 months.

Faced with this amount of community effort, McKusick and Mike Karels started the arduous job of removing AT&T code from the kernel. They accomplished this by comparing the BSD kernel to the UNIX/32V code. (UNIX/32V was the original source for BSD.) They removed code that originated in UNIX/32V. In many cases, these removals made the BSD kernel perform better.

In the end, there were only six files left that contained AT&T code. The BSD developers decided to release what they had. They went to the Berkeley administration to get permission to do so. Unfortunately, they had to work their way up the chain of command to get that permission. Finally, the chancellor signed off on it after an independent audit of the code.

In order to expedite the release, the developers decided not to come up with a new name because that would mean getting the lawyers to write a new license. So, they decided to name the release Networking Release 2 (Net/2) “since we could just do a revision of the approved Networking Release 1 license agreement”.

Net/2 shipped in June 1991 with several hundred people paying the $1,000 license fee.

Lawsuits and Beyond

It didn’t take long for someone to replace the remaining six AT&T files. Bill Jolitz replaced them and created 386BSD for personal computers. Shortly thereafter, a company named Berkeley Software Design, Incorporated started selling a commercial version of BSD.

BSDi caught AT&T’s attention by advertising their product as a Unix replacement and selling it for 1% the cost of System V. This led to the BSD lawsuits. The lawsuits ended in an agreement between the two parties that allowed BSD to be freely available after some slight changes. 

To learn more about the BSD lawsuits, check out part 2 of this series.

Like this article? Share it!

You might also be interested in

Improve the way you make use of ZFS in your company

ZFS is crucial to many companies. We guide companies and teams towards safe, whitepaper implementations of ZFS that enhance and improve the way the infrastructure is enabling your business.

More on this topic

Managing Boot Environments

A ZFS boot environment is a bootable clone of the datasets needed to boot the operating system. Creating a BE before performing an upgrade provides a low-cost safeguard: if there is a problem with the update, the system can be rebooted back to the point in time before the upgrade.
This article demonstrates how to use the bectl utility to manage BEs and provides examples on how to update packages, apply security patches, and upgrade the operating system using BEs.

Performance observability

FreeBSD Performance Observability

Performance observability is a powerful feature that highly supports FreeBSD. In this article, we’re showing you how to take advantage of tools that are specifically built for and with an operating system: tools which understand and are built into the operating system’s kernel structures. Learn about how to gather the information you need in order to get the most out of your system, determine your operational baselines, and find and resolve performance bottlenecks.

Devsummit

FreeBSD Developer Summit 2021

Join us through the 2 day walk through of our (Hopefully last) online conference walkthrough of the year. Learn more about FreeBSD and what the open source community is working on in this write-up.

Tell us what you think!