Jolitz: The Road Not Taken
David Harris
I changed a few cases of 3-character underlining into capitals and removed
excess blank lines to make it more readable online. I think this story
deserves coverage by computer journalists. Personal interest and
technical importance are intermingled in this situation. -Dave Harris
--------------------------- Start --------------------------------------
386BSD Release 0.0
The Road Not Taken
William F. Jolitz
I shall be telling this with a sigh
Somewhere ages and ages hence:
Two roads diverged in a wood,
and I ---
I took the one less traveled by,
And that has made all the difference.
"The Road Not Taken" [1916] -- Robert Frost
386BSD Release 0.0 has been greatly motivated by the
frustrations of many who have written and phoned me about
their inability to obtain access to 386BSD, whether licensed
or not. I had hoped that through the groups I was working
with, interested parties could have access to SUPPORTED ver-
sions of 386BSD, but this was not to be.
So, in making a break with the past, I paused in my
series of 386BSD porting articles, took the unencumbered but
incomplete NET/2 kernel available from UC Berkeley, and fin-
ished the missing pieces necessary to make a bootable run-
ning kernel that provides a self-supporting development
environment. In describing this process (see DDJ May-June
1992), as well as providing the actual source code, I hope
this will finally break the logjam that has frustrated and
perplexed our many readers.
In 1989, when Lynne and I began this project, 386BSD
was simply intended to be a port of BSD to the 386. While we
did not wish to add to anyone's proprietary license revenues
by folding in new encumbered code (especially pertaining to
the 386), removing or redesigning new code to replace old
encumbered code was out of the scope of this project. Since
I was willing to work gratis on 386BSD (preparing the
specification, supplying the initial equipment, obtaining
equipment and support from companies such as Compaq and
Cyrix, and doing the actual port), making an unencumbered
version was simply impossible.
After Lynne and I contributed 386BSD to UCB in December
of 1990, the UCB CSRG staff seriously began to set their
sights on releasing only unencumbered code. It was quite a
chore for us to continually revise and improve 386BSD while
updating it to match the new work done by CSRG and other UCB
staff. The result was the UCB NET/2 release.
What we've since learned from this experience, to our
sorrow, is that once anyone starts down the track to
providing a broadly accessible system, aberrations, such as
delusions of profit and glory, cannot be allowed to blur the
goal. This rule holds no matter how well-meaning the motiva-
tions of other people appear.
After NET/2 came out, I was willing to go to great
lengths to help my "friends" at CSRG -- Mike Karels, the
Best Man at my wedding and to whom I introduced the UNIX
kernel some 12 years ago, Keith Bostic, and Kirk McKusick --
pull some success and profit out of the years of work they
had put into BSD. In Mike's case, he had earlier invested in
a company I founded many years ago, and he said I "owed him"
the opportunity to help him build his own company. I am not
trying to say that I was unusually naive or altruistic. I
simply believe that you should help your friends to the best
of your abilities, and that they in turn should help you
when you need it.
However, friendship has obligations and responsibili-
ties as well. You do not lie to your friends. You do not
demand that your friends act unethically or immorally to
accomplish a goal. You do not abdicate your responsibilities
to other people, such as the students and professors who
require this system to teach, even though it might be to
your immediate advantage. In the process of taking the easy
road, the friendship will inevitably be destroyed. Is any-
thing worth this price? I don't think so.
I began to notice that the original point in doing this
work had become lost, and that things were getting wildly
out of control. An insatiable desire for power and wealth
had begun to distort the entire BSD research project, and I
felt I had to put the value of 386BSD back into perspective.
I spent many months trying to resolve my growing differences
with CSRG in an appropriate and quiet fashion. After all,
they were my friends.
Unfortunately, after a 15-year work association, three
years of work on this project, and a long friendship, the
culmination of my efforts was a slew of cancelled accounts
and a letter from CSRG unilaterally cancelling Berkeley
involvement in 386BSD, and claiming all the work that I had
contributed to Berkeley since NET/2 as "University
proprietary".
I had anticipated even before receiving this letter
that I might be forced to take a different road -- the one
less traveled -- and had planned accordingly. I had known
that this would not be easy -- it required me at the end of
November 1991 to erase all of my work on 4.4BSD, take a copy
of the original unencumbered NET/2 release, and start from
scratch to make 386BSD Release 0.0. I had to, in essence,
abandon all my previous work with CSRG.
I realized that my family would suffer personally by
this stance. It was not easy to hear my little daughter say
"Daddy, I liked Mike and Keith and Kirk. Why don't they like
us anymore?" It was not easy to see long-time friends at
USENIX catch a glimpse of me, turn, and run in the opposite
direction for fear of being seen talking to me. It was not
easy to find my University associates putting my new pro-
jects "on hold", even though they told me that they really
didn't believe any of those nasty rumors circulating about
my character or work on 386BSD. It has been quite a strain
these last months enduring these indignities in silence and
focussing on completing my goals.
But I cannot distort my values and ethics and ignore
the needs of others simply to suit the whims of a few. One
must always strive to "do the right thing", no matter what
the personal consequences. As the proverb goes: "What pro-
fits a man if he gains the world and loses his soul?"
And now, since CSRG has stated in writing that the
386BSD project will not be continued at Berkeley (not
surprising, given I was the only one who maintained the
machines and the 386BSD code), I have no choice but to GO
IT-ALONE and get this system out-the-door to the tens-of-
thousands of people who need an experimental research and
educational system. Otherwise, they would continue to be
denied access by CSRG to either a licensed or unencumbered
version of 386BSD from UCB, and instead be forced to pay for
a version of my work from a firm in which they have a
private interest. I have been fortunate in finding many
others who believe in the goals of 386BSD, and who are now
spending a great deal of time and effort getting it out to
everyone who desires a copy.
The purpose of the 386BSD project remains the same: so
students, faculty, staff, and researchers can use BSD on a
simple and inexpensive platform. And now, since few have
been able to obtain a licensed version from UCB (and none an
unencumbered version), I have made 386BSD Release 0.0 avail-
able with public access sources. I intend to maintain both
source and binary versions of 386BSD for some time to come.
And, since the Berkeley CSRG has abandoned 386BSD, I am wil-
ling to contribute my 386BSD work to other University groups
in order to facilitate the establishment of "new" 386BSD
projects elsewhere. 386BSD Release 0.0 is only a beginning
-- not an end.
Despite my unpleasant experience with CSRG, I have con-
tinued my efforts to "do the right thing" by offering the
CSRG Faculty Advisor, Professor Susan Graham, the 386BSD
Release 0.0 changes for immediate release from Berkeley, so
that the conflict-of-interest charges and other issues would
become moot, and so that the Berkeley EECS Department would
not suffer further embarrassment in this matter. I think
many in the academic community would find it fitting that
386BSD be available from the University where the BSD pro-
ject began. I myself believe that the BSD tradition has
been a venerable one, and I would like to see it honorably
continue.
In any event, Lynne and I intend to hold to the
"spirit" of what the 386BSD project is really all about. It
is not about writing a few lines of source code, or obtain-
ing a cheap operating system to diddle, or even building a
mini-AT&T to entangle you in proprietary license agreements.
386BSD is an attempt to allow new possibilities and alterna-
tive approaches in an industry that has become moribund. You
can use it, or not. But remember, someone worked hard to
give you the CHOICE. Use it wisely.
--------------------------- End ------------------------------------
--
David C. Harris: ...!sun!ys2!medint!dharris , in Palo Alto, California.
Rob Kolstad
I believe, in the interest of fairness to all concerned, that the net should
have some additional information about Bill Jolitz's recent posting.
I joined BSDI on December 1, 1991. Here's what I know:
Bill Jolitz was one of the founders of Berkeley Software Design, Inc.
(BSDI). As with any profit-making venture, he had to have known from the
beginning that BSDI systems would be made available in source form, but
would not be freely redistributable -- those were tenets of the company.
Bill was a full time employee of BSDI for 11 months of 1991 -- from
January 1, 1991 through November 30, 1991, actively contributing to both
the "encumbered" product and the modules which were donated to Berkeley.
All code that Bill developed through June 30, 1991 was contributed to the
BSD project, as was all work performed by the two other BSDI employees
during that period. That work was included as part of the Berkeley NET2
distribution, the most recent distribution made by Berkeley. This
donation forms a significant portion of "386BSD Release 0.0". The code
written by Jolitz and other BSDI employees was not developed without
compensation, nor was it developed solely by Jolitz.
BSDI is not attempting to impede creation of free BSD systems. Moreover,
BSDI has made significant contributions to make them possible.
My comments on the requirements for sustaining the viability of an
operating system are on record.
Rob Kolstad
Program Manager
--
/\ Rob Kolstad Berkeley Software Design, Inc.
/\/ \ kol...@bsdi.com 7759 Delmonico Drive
/ / \ 719-593-9445 Colorado Springs, CO 80919
Keith Bostic
Group (CSRG) to reply to William Jolitz's allegations since they have
been made public in this newsgroup. Some of his statements, and more
importantly, his implications, concerning the CSRG are not true. We
do not intend to debate each individual allegation which he has made.
There are, however, significant issues that must be clarified.
For those unfamiliar with the 4BSD distributions, the University policy
is as follows. The 4BSD system is distributed for reproduction costs.
Each recipient is granted a non-exclusive license to use, modify and
redistribute the system as long as obligations to USL (previously AT&T)
regarding proprietary source code are met. As the NET/1 and NET/2
distributions contained no source code proprietary to USL, they may be
used, modified, and redistributed freely.
Every line of code that Jolitz had contributed to the University at the
time of the NET/2 release was part of that release. Every line of code
that Jolitz contributed to the University since the NET/2 release will
be part of the next 4BSD distribution. Furthermore, no vendor has had
early or different distribution rights to University software or any
software contributed to the University by Jolitz or any other party.
The University has never stated that the work contributed by Jolitz is
proprietary to the University. The contribution agreement which Jolitz
signed explicitly gave the University nonexclusive access to the code,
and explicitly noted that copyright was retained by Jolitz.
Finally, the CSRG has never stated that it will discontinue development
of a version of BSD for the 386 architecture. As with many other
portions of the system, most of the development will be done by outside
contributors, or derived from systems like Jolitz's 386 release. We have
always intended that 4.4BSD run on the 386 machines and see no reason
that this will not happen.
Kirk McKusick
Keith Bostic
Mike Karels
on behalf of Bill Jolitz ("The Road Not Taken"), but given the nature
of the comments about me, my past relationship with Bill, and my work,
I am compelled to respond.
I do not understand Bill's complaint with CSRG, with me or with BSDI,
nor do I understand why he is now saying the things that he is. The
recent posting is not at all an accurate reflection of past events.
I do not want to correct it point by point, as I will not continue this
argument in a public forum. However, there is nothing for which I should
apologize. I have not lied to Bill or other friends, and I have not
asked anyone to act unethically or immorally.
Bill was a founder of BSDI as well as its first full-time paid employee;
he can hardly be surprised that BSDI is selling a supported system
based on the freely available Berkeley code, of which he contributed
the 386 port. I did not exert pressure on Bill to work for BSDI,
although I did introduce him to the other founders. When he became
unhappy working for BSDI, I had a number of long conversations with him
about the problems. Although I never fully understood the problems,
his complaints centered on business and personal relationships within
the company rather than the fact that the company planned to charge
for its product.
Bill's complaints about CSRG are unjustified, and only originated in January
after I decided to leave Berkeley to work for BSDI. CSRG released all
of the code contributed by Bill in source form. His complaint is the
lack of a supported binary release from the University. However, Berkeley
releases have never been supported in the normal commercial sense, and
have never been packaged and documented for easy installation on machines
as diverse as 386 AT systems. While I was in CSRG, we never considered
doing another binary release after NET2 until the alpha release of 4.4BSD.
Although the NET2 release contained most of the BSD kernel, several
critical modules were missing because they were derived from licensed code.
CSRG could have taken the shortest path to filling in those modules,
but those modules were among the oldest in the kernel. Rather than
reimplementing those pieces as they had been, CSRG chose to redesign
them properly, which is in progress.
I regret that this disagreement was made public at USENIX and in
this news group. I will not continue this discussion in public.
Mike Karels
Berkeley Software Design, Inc.
kar...@BSDI.COM