The most recent version of this essay can be found athttp://linuxmafia.com/faq/Licensing_and_Law/forking.html.
[1] (Footnote on overall context of this essay. Please read.)
From rick Sun Nov 14 16:13:06 1999Date: Sun, 14 Nov 1999 16:13:06 -0800From: Rick Moen rickTo: [several individuals at my former firm]Subject: Essay for the Brown-Baggers: code forkingMessage-ID: 19991114161305.C32325@uncle-enzo.imat.comMime-Version: 1.0Content-Type: text/plain; charset=us-asciiX-Mailer: Mutt 1.0iX-CABAL: There is no CABAL.X-CABAL-URL: There is no http://linuxmafia.com/cabal/X-Eric-Conspiracy: There is no conspiracy.X-Eric-regex-matching: There are no stealth members of the conspiracy.Status: ROContent-Length: 20135Lines: 381
Ed, I hope you would not mind forwarding this essay to the Brown Baggersmailing list. I was trying to finish this for the sales force's benefitbefore my departure, but ran out of time, in my rush to get my departmentin order.
WHY LINUX WON'T FORK
And why being able to fork is still A Good Thing.[2]
I noticed some puzzled faces when Nick[3] did hispresentation on licences at a Brown Bag session, and talked about theright to fork source code. He pointed out that the right to start yourown mutant version of any open source project (which is what we mean by"forking") is an important safeguard. He and I both stressed that theabsence of that right in Sun's "SCSL" (Sun Community Source Licence),used for Java, Jini, and (potentially) Solaris[4]and Star Office is what prevents SCSL from being genuinely open source.(Borrowing a term from Eric S. Raymond, I called SCSL projects "viewablesource".)
But this creates a puzzle for you guys[5]: I'llbet you have to work hard to fight customer fears that GNU/Linux[6] will fragment into a hundred incompatibleversions because there's no single big corporation in charge. Right?And here Nick and I come, saying thank God open source licencesguarantee everyone the right to do just that.
Sounds contradictory, right? OK, here's the quick and dirty answer.The detailed one comes later:
Linux won't fork because the fork-er has to do too much work for no payoff: Any worthwhile improvements he makes will be absorbed into the main branch, and his fork will be discarded/ignored as pointless.
The above happens with Linux, even though it hasn't with earlier projects, because of the effect of Linux's source-code licence.
NOTABLE PAST INSTANCES OF FORKING
1. Unix --> dozens of proprietary mutant corporate Unixes
If you've read up on Unix history, you know that Unix was a freak productof AT&T's Bell Labs division, around 1969. I'll omit most of the longstory, but the most important fact to know is that AT&T was then operatingunder a January 24, 1956 Department of Justice anti-trust judgement[7] (which expired around1980) prohibiting it from entering the computer/software business, andrequired it to reveal what patents it held and license them when asked. So,it could not legally sell Unix, but instead sold source-code licences(and occasionally also the right to use the trademarked name "Unix") to(1) universities, such as U.C. Berkeley, and (2) companies such as IBM,Apple, DEC, Data General, SGI, SCO, HP, etc.
Those companies bought the right to make their own Unixes: IBM releasedAIX. Apple did A/UX. DEC did Ultrix[8], OSF/1,and Digital Unix (later renamed "Compaq Unix" and now "Compaq Tru64Unix"). Data General did DG/UX, SGI did IRIX, HP did HP/UX, and SCO didXenix[9] which eventually mutated into SCO OpenServer. And we could cite others, but I'll spare you.
The point is that these were the jokers who ruined Unix. Every one ofthem marketed his mutant Unix as "Unix plus" -- everything the otherguys have and more. Needing to create differentiators, theydeliberately made their Unixes incompatible while giving lip service to"standards".
For customers, this was simply a mess, and Microsoft drove right throughthese guys' disunity like a Sherman tank. It isthe classicinstance of forking that sticks in people's minds. Which is why youfolks are expected to assure customers that the same won't happen toGNU/Linux. We'll return to this point later.
2. BSD --> FreeBSD, NetBSD, OpenBSD, BSD OS, MachTen, NeXTStep(which has recently mutated into Apple Macintosh OS X), and SunOS (nowcalled Solaris)[10]
As I mentioned above, antitrust-limited AT&T, not being able to sellUnix itself, gave out very cheap Unix source-code licences [11] to universities including U.C. Berkeley. UCB's Computing Systems Research Group (CSRG) took the lead in the academic world: Having access to the source code,they quickly realised that they could rewrite it to make it much better,and slowly did so. Their rewrite was dubbed "BSD" (Berkeley SoftwareDistribution), and they were glad to share it with anyone similarlyhaving an AT&T Unix source licence.
And their work was generally a great deal better than Bell Labs's,partly because it benefited from worldwide peer review in a veryopen-source-like fashion.[12] Over quite a fewyears, they gradually replaced almost all of the AT&T work, without(at first) really intending to.
One fine day in 1991, grad student Keith Bostic came to the BSD lead developers,inspired by Richard M. Stallman's (remember him?)[13] GNU Project, and suggested replacing BSD'sremaining AT&T work to create a truly free BSD. Dreading theconfrontation likely to result with AT&T, they tried to stall byassigning Bostic the difficult part of this task, rewriting some key BSDutilities. This backfired when he promptly did exactly that. So, theygrumbled but then completed the job[14], and triedto prevent AT&T from noticing what they had done.
AT&T did notice[15], panicked, and sued.That, too, is a long story best omitted. Under the stress of thelawsuit, freeware BSD split into three camps (FreeBSD, NetBSD, andOpenBSD).[16] But there were also severalproprietary branches[17], made possible becauseU.C. Berkeley's "BSD Licence" allowed creation of those: SunMicrosystems's SunOS, Tenon Intersystems's MachTen, BSDI's BSD OS[18], and NeXT Computer's NeXTStep OS all came outfor salewithout public access to source, and were all based onthe Berkeley BSD source code.
Note the distinction: If you write a program and release the sourcecode under the GNU General Public Licence (GPL), other people who sellor otherwise release derived works that incorporate your work mustrelease their source code under GPL conditions. The same is not true ifyou release your work under the BSD Licence: Anyone else can create avariant form of your work and refuse to release his source-codemodifications. (In other words, he is allowed to create proprietaryvariants.)
A word about the three free BSD variants: All three were splinters froma now-dead project called 386BSD. All have talked about re-merging inorder to save duplication of effort,but they now persist asseparate projects because they've specialised: FreeBSD aims for thehighest possible stability[19] on Intel x86 (IA32)CPUs, NetBSD tries to run on as many different CPU types as possible,and OpenBSD aims to have the tightest security possible. In otherwords, the 386BSD project remains forked because there are compellingreasons that make this a win for everyone.
Also, where possible, these three sister projects collaborate on toughtasks -- and they also collaborate with GNU/Linux programmers. Some ofthe best hardware drivers in the Linux kernel are actually BSD drivers.There's a high level of compatibility among the three BSDs and betweenthem and GNU/Linux: Unlike the proprietary Unix vendors, BSD andGNU/Linux programmers have an incentive to eliminate incompatibility andsupport standards.
3. emacs --> GNU emacs --> Lucid emacs --> xemacs --> other proprietary emacsen, now mostly forgotten
The Emacs editor / programming environment (short for "editing macros")was originally written by Richard M. Stallman (with Guy Steele and DaveMoon) in 1976, in TECO macrosand PDP 10 assembly, to run on ITS and TOPS-20 -- at that time, under noexplicit licence terms. (Stallman has clarified that it did carry astatement that "People should send changes back to me so I could addthem to the distribution.") It proved wildly popular, and by 1981 hadstarted to give rise to explicitly proprietary variants, notably JamesGosling's C-coded "Gosling Emacs". [The original version of thisessay's section on Emacs forks was sadly confused, as I had confusedthis "Gosmacs" fork with others, in attempting to recall Emacs historysolely from unaided memory, and my explanation went wrong from thatpoint on. For this revision, I've replaced that entire section.]
In 1985, Richard Stallman resumed leadership, creating his flagship GNUEmacs version in C, based initially on Gosling's work, but replacing allGosling code by mid-year, enabling Stallman to place the work under hisnewly written GNU General Public Licence, which he then did. At thispoint, mid-1985, Emacs's open-source history begins.
By 1991, Stallman's GNU Emacs had gone from major versions 15 through18, with a number of point releases. NCSA originated a set of popularpatches ("Epoch") to improve GUI support: GNU Emacs 19 was expected tomerge Epoch's features cleanly.
So things stood as developers at Lucid, Inc. (who used Emacs with theirproprietary C / C++ development tools) began participating in the GNU Emacsdevelopment effort, attempting to bring about version 19. For reasons that remain disputed (http://www.jwz.org/doc/lemacs.html), the Lucid developersand Stallman had difficulty cooperating, and the Lucid developersreleased their version as Lucid Emacs 19.0, in April 1992. (As a forkof GNU Emacs, it is likewise under the GNU GPL.)
The anomalous aspect of this rare fork of a GPLed work is not so muchthat it occurred as that it persists to this day: Lucid Emacs wasrenamed XEmacs in September 1994 (after Lucid, Inc. closed) and remainsequally popular with Stallman's version. This appears to be a rarecase of differences about working styles, design issues, and managementpolicies outweighing the advantages of re-merging. However, even here,convergence occurs: Since much of an Emacs implementation'sfunctionality exists as elisp macros, essentially all of that code iscommon to the two rival Emacs projects. And each benefits from studyingthe other's new features and code.
4. NCSA httpd --> Apache Web server
These days, the world's standard Web server package is the Apachepackage, maintained by the all-volunteer Apache Group. (That is not tosay that they don't make money: Members of the Apache Group such asBrian Behlendorf have practically a licence to print cash, when it comesto Web consulting, because of their well-earned fame.)
But, before there was an Apache, you ran either the University of Illinoisat Urbana-Champaign National Center for Supercomputing Applications's"NCSA httpd" (HyperText Transport Protocol daemon) or Geneva-basedCERN's (Centre Européen pour la Recherche Nucléaire's)"CERN httpd". The NCSA daemon was smaller and faster, while theCERN one was famous mostly for association with the creator of the Web,Tim Berners-Lee, who worked as a researcher at CERN.[20]
CERN's httpd (later called "W3C httpd") was always under an early sortof free-software licence. It's no longer maintained -- a dead project.It's unclear what NCSA httpd's licence was originally, but when thatproject died (1996) its licence was a "free for non-commercial usageonly" one.[21]
In any event, the story is that an on-line group of programmers who hadbeen producing patches (modifications) for the NCSA httpd eventuallydecided that they'd produced their own variant in 1995, forking thecode. "Apache" was originally just Brian Behlendorf's temporary codename for the project, but fellow developers then pointed out the name'sappropriateness ("a-patchy" server = "apache"; get it?), and it stuck.
In any event, this is an instance of why and how open-source projectsfork benignly, for good reason: Development at NCSA had stalled afterthe package's original creator, Rob McCool, left the Center. If thathappened to a proprietary product, it would just die, leaving all itsusers in the lurch. However, because the product was so useful, theApache Group forked the source code and kept driving it forward. It nowdominates all Web servers, regardless of their marketing and developmentbudgets.
5. gcc --> pgcc --> egcs --> gcc
Here's an odd one: Richard M. Stallman (remember him?) founded in 1984the GNU Project, which produced[22] the immenselyimportant GNU C Compiler ("gcc"). gcc is designed to work on just aboutany remotely feasible computer, not just the Intel x86 (IA32) series.So, it might just have been other priorities that delayed improved Intelsupport. Specifically, well into 1997, the best the then-current gcc 2.7 series could do for code optimisation on Intel was to set the compiler for 486 chips. People pleaded with FSF for Pentium optimisation, but were stubbornly ignored.
So, two separate groups, in succession, developed Pentium-optimised compilers as forks from gcc 2.7. The first was "pgcc", from the PentiumCompiler Group, a consortium consisting mainly of Intel Corporation staffers. pgcc produced very fast code via a two-pass process, butwas completely non-functional on gcc's non-Intel platforms, and for thatreason could not be accepted into the main gcc code. Further, it departedso radically from the base gcc code that it proved difficult for pgccto track gcc improvements.
However, the Pentium Compiler Group distributed its work widely, and its Web site remained available as a major resource on Pentium optimisationissues for interested parties -- so much so that my initial version of this section, based on memories of that site, inadvertently confusedthe Intel/PCG work with the later egcs work (discussed below). My thanksto Ian Lance Taylor of CYGNUS for helping me straighten out the account.
Perhaps inspired in small part by receiving a copy of pgcc, but moreso by a desire to make their jobs easier, improve the compiler theyworked extensively with, and broaden the development model to includemore developers (than just Richard Kenner, who was in charge of gcc), programmers at the CYGNUS company of Sunnyvale, California (the onethat was recently bought by Red Hat Software, Inc.) independently followed up pgcc with the more-successful egcs compiler. Unlike pgcc,egcs was only a modest departure from gcc 2.7, was equally portable, and was like gcc single-pass. And it was a very clear improvement over Kenner's 2.7 and 2.8 gcc series, not just in adding Pentium support.
For whatever reason, Stallman's Free Software Foundation (developers ofthe GNU Project) continued to act as if egcs didn't exist. So,GNU/Linux distributions began to emerge based on egcs, and thefree-software world began to mostly ignore gcc.
This can be seen as a variant on the Apache experience. The ability tofork means that progress will not be impeded by a developer not wantingto move forward: Somebody else can, as gracefully as possible, assumethe leadership role and (if necessary) fork the project.
However, this necessity was averted in the egcs case. In April 1999,the FSF re-merged egcs into the (would-be) main gcc branch, and handedover all future development to the egcs team (such that egcs 1.2became gcc 2.95), thereby resolving the conflict.
6. glibc --> Linux libc --> glibc
This is a nearly mirror-image case. Any Unix relies extremely heavilyon a library of essential functions called the "C library". For the GNUProject, Richard M. Stallman's (remember him?) GNU Project wrote[23] the GNU C Library, or glibc, starting in the1980s. When Linus and his fellow programmers started work on theGNU/Linux system (using Linus's "Linux" kernel), they looked around forfree-software C libraries, and chose Stallman's[24]. However, they decided that FSF's library (thenat version 1-point-something) could/should best be adapted for the Linuxkernel as a separately-maintained project, and so decided to fork offtheir own version, dubbed "Linux libc". Their effort continued throughversions 2.x, 3.x, 4.x, and 5.x, but in 1997-98 they noticed somethingdisconcerting: FSF's glibc, although it was still in 1-point-somethingversion numbers, had developed some amazing advantages.[25] Its internal functions were version-labeledso that new versions could be added without breaking support for olderapplications, it did multiple language support better, and it properlysupported multiple execution threads.
The GNU/Linux programmers decided that, even though their fork seemed agood idea at the time, it had been a strategic mistake. Adding all ofFSF's improvements to their mutant version would be possible, but it waseasier just to re-standardise onto glibc. So, glibc 2.0 and above havebeen slowly adapted as the standard C Library by GNU/Linuxdistributions.
The versionnumbers were a minor problem: The GNU/Linux guyshad already reached 5.4.47, while FSF was just hitting 2.0. Theyprobably pondered for about a millisecond asking Stallman to make hisnext version 6.0 for their benefit. Then they laughed, said "This isStallman we're talking about, right?", and decidedout-stubborning Richard was not a wise idea. So, the convention is thatLinux libc version 6.0 is the same as glibc 2.0.
7. Sybase --> Microsoft SQL Server
Woody Allen has a saying that "The lion may lie down with the lamb, butthe lamb won't get much sleep". Much the same can be said of companiesthat enter "industry alliances" with Microsoft Corporation. One of theseveral slow-learner corporations to make this mistake was SybaseCorporation, publisher of the Sybase Structured Query Language (SQL)database package for numerous Unixes and NetWare. As part of thealliance, Microsoft sold Sybase to its customers, relabeled asMicrosoft SQL Server, and got access to Sybase's source code undernon-disclosure agreement.
Then, predictably, Microsoft broke the alliance when it had learned allit could from Sybase, and reintroduced Microsoft SQL Server as its ownproduct in competition with Sybase. I do not know if current MS SQLServer versions are rewritten from scratch or retain Sybase code underlicence terms[26], so this may not be a legitimatecase of forking (let alone open source), but it's similar enough Ithought I should mention it.
ANALYSIS: WHY OPEN-SOURCE FORKING IS BOTH RARE AND BENIGN
You, the reader, can fork any open source project at any time. This isabsolutely not cause for alarm. Let's prove it: Get a copy of thecurrent Linux kernel fromftp://ftp.kernel.org/. Rename it.Call it Fooware OS. Send out messages to everywhere you can think of,announcing that Fooware OS has splintered off from Linux, and greatthings are expected of it.
Wait for reactions. Wait some more. Listen to the clock ticking. Sortyour lint collection. Open up the source code tree, think about whatyou might do with it, and wonder where you're going to find the time.
Well, that's a little unfair: You're probably not a programmer. Let'simagine that you are. You're a ninja programmer with mighty code-fu, adrive to succeed, and a disciplined team of programmer henchmen. So,you don't just listen to the clock tick, but get some really good workdone. You improve the heck out of the kernel, in fact. And then theLinux people smile broadly, and quite sincerely tell you "Thank you verymuch." Like effective programmers the world over, they know programmingis difficult work and are constructively lazy. That is, they're notproud, and are glad to use other people's work -- when that's allowed.
Oh, you forgot that your work was under the GPL, didn't you? By forkingoff, working on, and distributing your variant of a GPLed work (theLinux kernel), you consented to issuing your improvements under the GPLalso, for other people to freely use. So, you only thought you werecreating Fooware OS; in fact, you were creating a better Linux.
That's why forking is uncommon in open-source code, and even more so in(specifically) GPLed code: The improvements one group makes in itswould-be "fork" are freely available to the main community.
But, as we have seen from the mostly non-GPL examples above, forking isnonetheless not only always an option, but is a vital safety valve incase the existing developers (1) stop working on the project, or (2)decide to stand in the way of progress. The fact that this can occur isA Good Thing.
A third reason for forking also exists, and may hit the GNU/Linuxcommunity eventually: specialisation. You may recall that this is whatultimately happened with the three free BSD variants -- although stressfrom the clash-of-the-titans AT&T v. U.C. Berkeley lawsuit arguablymade that situation unique.
That is, somebody may eventually propose to the Linux kernel team someextension that's simply outside the scope of the project, and yet buildsenough support behind it (and has enough reason for existing) that itproceeds anyway. In that case, Linuxwill fork -- and it willbe a good thing, because then there will be two strong projects insteadof one, each concentrating on an important niche that the other cannotfill.[27]
If that happens, the forks would undoubtedly share code and informationexactly as the BSD variants do, to prevent duplication of effort, andbecause it makes sense to do so. And the world will be richer for boththe fork and the sharing.
I hope this explanation proves useful to you. It's been a pleasureworking with you all, and please do stay in touch.
-- Rick M.
[1]On the afternoon of Saturday, November 13, 1999, I was badly in need ofa little diversion: I was sitting next to the hospital bed of mygirlfriend, who had been abruptly dismissed from my firm (a major-nameLinux firm that shall go nameless), three daysearlier. On account of my own separate issues with management, I hadjust resigned my job as chief of the system administration department.I also had just gone through a week of sixteen-hour days to put mydepartment in top condition (preparatory to leaving), plus I wassuffering exhaustion and a week-old case of influenza. And now we werewaiting the first of many hours for my girlfriend's blood-test results,and so I needed something to keep my mind occupied.
Fortunately, I had my laptop computer with me, and so I wrote out anessay I'd been working on in my head for the past week or so: I wroteit, beginning to end, in one long, continuous typing spree, over thecourse of several hours. Please note that I had no access to theInternet or any reference works; all contents were from myfatigue-addled memory. I was still exhausted the next day, and e-mailedout the completed text without meaningful checking.
That essay was intendednot for the world at large, but ratherfor an internal mailing list at my former firm, as a parting gift to myfriends in the sales department: A couple of months earlier, I hadhelped found a series of internal seminars, the Brown Bag series, with apresenter every Tuesday and Thursday briefing the sales department (andother interested employees) on different aspects of free / open-sourcesoftware, to help them understand the GNU/Linux community, its historyand customs, and many related, sales-relevant issues.
As an adjunct, we also set up a Brown Bag mailing list, where the salesforce were encouraged to ask us techies anything they needed to know.To help matters, whenever a salesman asked me a good, fundamentalquestion (which happened frequently, since all of them were impressivelybright, quick learners), I would spend an evening writing it up in essayform, for the entire list.
So, my "Fear of Forking" essay (a title later suggested for it by EricS. Raymond) was my final contribution, to close out that series ofessays. I sent it to the Brown Bag list-owner, and cc'd two otherformer colleagues for their enjoyment. One of the latter asked if thefirm could use it as a featured article, which they then did. Thatversion was then picked up by Slashdot.org.
Please bear in mind that design goal, as you read the piece: It was notintended to be a history of Unix, nor a technical treatise on codeforking, but rather a conceptual overview of the code forking issue,with brief historical examples, to explain to a sales team how and whyfree / open-source software differs from proprietary software in nothaving that problem -- to help them better do their jobs.
It might be worth mentioning that "Unix" was written as "UNIX" early inthat OS's history -- for no good reason. (It's not an acronym.)Likewise for some similar non-acronym names such as XENIX and ULTRIX. Ihave rendered all in the more modern and grammatically-justifiablefashion.
[2]Staff at my former firm changed the subtitle for their version to "Howthe GPL Keeps Linux Unified and Strong" and wrote three different,replacement introductory paragraphs, for the version published at theirWeb site.
I generally like what they wrote, but -- in those three new paragraphsand the new subtitle -- they did inadvertently make the piece seem a bitof an advertisement and ideological argument for (specifically) the GNUGPL, which wasnot my intention. The BSD crowd would arguethat although BSD licensing does allow proprietary code forks, thosetend to be temporary and/or lose momentum because they cease to fullybenefit from the exchange of code and information in the larger BSDcommunity. I would strongly agree. History seems to support theirclaim.
[3]Nick Moffitt, Brown Bag lecturer and member of my staff at my formerfirm.
[4]An edit error on my part: In the essay as posted to the Brown Bag list,I included Solaris among those works whose source code had already beenissued under the SCSL family of licences. As of that date, SunMicrosystems was clearly contemplating such a move but had not taken it:Solaris remained binary-only. So, I have fixed my essay text to list itcorrectly in the "potential" category. (Sun later promised it wouldgenuinely open-source Solaris, and did exactly that in 2007, albeitwith some third-party inclusions available only as proprietary,binary-only code, including many important device drivers.)
There is no one definitive SCSL licence text: Each instance is slightlydifferent, such that Sun refers to SCSL as afamily oflicences.
In May 2007, finally, Sun also re-released almost all of the Sun Javatoolkit under the GNU General Public License, leaving out only a few component libraries whose third-party owners refused to go open source.Those will remain proprietary and binary-only.
[5]Referring, in case it isn't obvious, to the firm's sales force.
[6]I use this term to refer to complete operating system packages based onthe Linux kernel, and "Linux" to mean just the kernel. At variouspoints, I also used the terms "free software" and "open-source software"interchangeably, considering them two terms for the same concept withdifferent marketing emphases -- differences in emphasis that are oftensignificant, but not here.
[7]Technical speaking, a consent decreeas opposed to a judgement.Consent decrees are legal settlements under which a firm agrees to bebound by certain restrictions, in exchange for a regulatory agencyagreeing to drop a legal action against it. The firm gets toavoid proceeding to judgement, and a milder penalty than itmight suffer at a judge's hands. The agency gets a quicker settlement,and avoids the always-present possibility of eventually losing, not tomention the certainty of greater legal costs.
[8]Long-vanished DEC Ultrix was actually based on Berkeley Unix (BSD), andtherefore only indirectly on AT&T Unix. (Does anyone really care?)
[9]Xenix was a very limited and much-derided Unix variant for 80286(AT-class) machines, written by a team at Microsoft, whose divisionimmediately split off as Santa Cruz Operation (SCO), taking the product(such as it was) with them in exchange for giving Microsoft (if memoryserves) 40% of their stock -- a kind of reverse acquisition. I hadn'tforgotten this history in writing my essay; it's just one of many finedetails that I saw no need to get into.
(That "SCO" company, based in Santa Cruz, California, whicheventually renamed itself to Tarantella, sold off its unwanted OS businessdivision, and was merged into Sun Microsystems, should not be confusedwith the more recent SCO Group of Lindon, Utah. The latter company,which had started life as Linux firm Caldera Systems, Inc., in 2001purchased the "SCO" name and related unwanted OS division, exited theLinux business, and since then has attempted rather poorly to be aproprietary Unix company, but has become better known for its even moredoubtful lawsuit efforts.)
[10]There's a tedious and well-worn flamewar over SunOS vs. Solaris that Iwas hoping to skirt entirely. Naturally, it became a prime topic on theSlashdot thread, nonetheless:
Originally, SunOS (through version 4.1.0) was a variant form of BerkeleyUnix (BSD). Then, Sun Microsystems developed Solaris as (approximately)an outgrowth/extension of SunOS, but in so doing discarded the existingBSD-based codebase, rewriting it on an AT&T System V Unixfoundation. Nonetheless, Sun maintains to this day that Solarisincorporates SunOS, and the output of Solaris's "uname" commandasserts this, too. For their part, hordes of BSD-loving Sun userscontinue to despise Solaris, and use the term "SunOS" to meanpre-SystemV versions.
Given that my essay wasnot intended to be a history of Unix,itcertainly wasn't intended to delve into this morass ofdefinitional warfare.
[11] For a decade or more, the academic licence fee amounts were at tokenlevels, but then were raised astronomically when AT&T emerged fromthe antitrust consent decree, and was able to sell Unix directly.
[12]Arguably, Sun Microsystems was trying to establish a similar sort ofcommunity, collectively bound by a uniform proprietary licence but ableto work with shared code openly, with its SCSL. Free / open-source softwareadvocates, during Sun's SCSL years of the late 1990s and early 2000s,often accused Sun of attempting to subvert their community using SCSL,but I believed the charge was erroneous -- and my view was vindicated in 2006-7 when Sun went substantively all-open-source with its mainofferings.
[13]This phrase is a private running gag I had with some of the firm's salesforce, after Richard Stallman addressed them in June 1999: RMS's namekept surfacing in my explanations of software history and primary issuesto the sales representatives, and I kept having to confirm that thiswas indeed the same young but ubiquitous Richard M. Stallman they hadheard speak.
I should stress, also, that in referring to Richard (in this essay tomy former company's sales staff) as "stubborn", I meant that termstrictly in an admiring and laudatory spirit. This, too, was a runninggag we had kept going: When, in mid-1999, I had first explainedRichard's history and long-term programme to the sales staff, a weekbefore he was scheduled to visit our firm and give a guest lecture, Ihad started by quoting from George Bernard Shaw's introduction toMan and Superman: "The reasonable man adapts himself to theworld; the unreasonable man persists in trying to adapt the world tohimself. Therefore all progress depends on the unreasonable man."
[14]Which entailed identifying and replacing all code that either wasdefinitely or might be AT&T's, in the BSD system.
[15]There were several things that tipped off and provoked AT&T, such asthe use of something resembling an AT&T "Death Star" corporate logoon the cover of a then-recent BSD release, but apparently the finalprovocation was tiny proprietary BSD-offshoot BDSI's January 1992 newspaperadvertisement that advised readers to call "1-800-ITS-UNIX". There ismuch more to this story, but it is told betterelsewhere.
[16]This statement is vague -- intentionally so, and in several ways at thesame time. (Again, this was never intended to be a history of Unix.)At the time, the lawsuit's allegation of infringement of AT&Tsource-code copyright cast a shadow over not just Berkeley's BSD andBSDI's BSD OS, but also William and Lynne Jolitz's free-software 386BSDproject, which was a patchkit of about 180 patches based on Berkeley's "NET/2" BSD release. (In retrospect, there is grave doubt about whetherAT&T's complaint ever had merit, on several grounds, but this wasnot clear at the time. Kirk McKusick told me that defendants ultimatelyagreed in the settlement that seven BSD files were encumbered by AT&T copyrights only to let AT&T save face on what would otherwise havebeen a dead loss, allowing that concession because the seven files were dreadful spaghetti code and overdue for replacement anyway.) Apparentlyin part because of the legal threat, the Jolitzes withdrew from theproject, leaving copyright questions and a leadership vacuum on top ofthe project's other problems.
Two separate groups separated (setting up real source repositories andversion control) from the stagnating 386BSD patchkit project: firstNetBSD and then FreeBSD, both in 1993. In May, 1996 (after the January1994 legal settlement), OpenBSD emerged as an offshoot from NetBSD.
Nov. 2004 addendum: I do not in general update this essay beyond attempting to fix errors as of its original publication date, but forcompleteness's sake will mention that, in July 2003, longtime FreeBSDcore committer Matthew Dillon and others forked offDragonFly BSD based on theFreeBSD 4.x architecture, because of serious dissatisfaction withFreeBSD 5.x.
A complete roster of open-source BSD forks must also include AppleDarwin, for a total of five surviving forks. Darwin is the core ofApple Macintosh OS X, and comprises NeXT, Inc.'s old NeXTStep / Openstepcode built around NeXT's xnu kernel, updated and retrofitted with an emulator for legacy MacOS code.
The "stress of the lawsuit" (my phrase) was clearly a leading forcebehind this overall chain of events. Those (on Slashdot) whointerpreted that phrase as meaning that the lawsuit directly andunambiguously caused each step in it drastically over-interpreted mywording, to an extent I would have scarce thought possible previously.
[17]As footnoted elsewhere, DEC Ultrix was also among these.
Some commentators interpreted this passage as claiming that the AT&Tlawsuit likewise caused all of the proprietary forks, all at the sametime and simultaneously with the free-software forks. Unfortunately forthis odd interpretation, I nowhere said, and certainly did not mean, anypart of that.
Moreover, there seems to be a persistent misapprehension that I hadimplied some time-line for the history of the Unix operating system,hidden in that paragraph, since a number of commentators remarked on thetime-line's (supposed) inaccuracy. I checked; there's no time-line. AndI can state from personal knowledge that it'snotmissing on account of my forgetting it.
If you thinkthat comment (just preceding) sounds ludicrous,you should have seen the Slashdot posts and e-mails that made itnecessary. Maybe they're crazy, maybe I'm crazy: You decide.
[18]Which was at first named BSD/386, not to be confused with the Jolitzes'free-software / open-source 386BSD.
[19]I originally wrote "performance", here, but then was admonished by earlyreaders that the performance advantages of FreeBSD are an incidentaleffect of it being designed for stability. So, I changed the wording --and was then criticised for not mentioning FreeBSD's performance. Somedays, you just can't win.
Suffice it to say that theworld's record for maximum 24-hour performance for an ftp server is held by a FreeBSD box(wcarchive.cdrom.com, at now-defunct Walnut Creek CD-ROM, Inc.): 1.39terabytes of data served to the public in a single day by asingle Pentium II box, on Sunday, May 23, 1999. Each time this recordhas been broken, for years, it's beenby FreeBSD, and alwaysbreaking a record previouslyset by a FreeBSD box.
It should also be mentioned that FreeBSD is increasingly portable tonon-Intel CPU architectures, notably DEC Alpha and (more recently) PowerPC.
[20]In fairness, it's also relevant that the CERN HTTP daemon was for quitea while theonly such software extant.
Its licensing history is more than a little fuzzy, since source archives are available athttp://www.w3.org/Daemon/only of the final v. 3.0A version (July 23, 1996). That versionincludes an MIT copyright/licence notice resembling the MIT/X Consortiumlicence, plus a requirement that any products based on the codebasecredit CERN. Those interested in researching thefull licence historywill probably find sufficient records within the CERN W3 Project's historical archives athttp://www.w3.org/History/.
[21]Some correspondents have disputed this assertion, on the basis of theirown fading recollection. I was speaking on the basis of licence terms for the final version (1.5.2a, released 1995) I found athttp://hoohoo.ncsa.uiuc.edu/docs/COPYRIGHT.html; they're valid for "academic, research and internal business purposesonly". Brian Behlendorf of the Apache Group corresponded with me ine-mail about the above-cited terms, and clarified: "That is not thelicense that was on NCSA [httpd] 1.3. That license said, 'This code isin the public domain, and give us credit'."
Upon examination of the source archives atftp://ftp.ncsa.uiuc.edu/Web/httpd/Unix/ncsa_httpd/, it appears that NCSA's switch to proprietary licensing occurred between June 22, 1995's v. 1.4.2 andMarch 21, 1996's v. 1.5c, without any mention in the documentation.Version 1.4.2 included the following statement in its README file,matching Behlendorf's recollection: "This code is in the public domain.Specifically, we give to the public domain all rights for futurelicensing of the source code, all resale rights, and all publishingrights. We ask, but do not require, that the following message beincluded in all derived works: Portions developed at the National Centerfor Supercomputing Applications at the University of Illinois atUrbana-Champaign. THE UNIVERSITY OF ILLINOIS GIVES NO WARRANTY,EXPRESSED OR IMPLIED, FOR THE SOFTWARE AND/OR DOCUMENTATION PROVIDED,INCLUDING, WITHOUT LIMITATION, WARRANTY OF MERCHANTABILITY AND WARRANTYOF FITNESS FOR A PARTICULAR PURPOSE."
[22]No offence whatsoever is intended by this phrasing to various actualproject leads including Richard Kenner (for v. 2.5.x through 2.8.x) andthe GCC (née EGCS) Steering Committee (for later versions). As with(almost) all FSF projects, it is produced by volunteers under FSFimprimatur.
My initial account of the Pentium Compiler Group's history was based onwhat had been posted on their now-vanished development Web site, andinadvertently annoyed some PCG participants from Intel by not citing their role concerning pgcc.
Some time in the year 2001, the GCC acronym was retroactivelyre-construed to mean GNU Compiler Collection, recognising the additionof compilers for numerous other languages (beyond C), including Java.
[23]No offence whatsoever is intended by this term to project leadprogrammer Ulrich Drepper and other volunteers, who do all the work,with FSF giving their imprimatur to it.
[24]Again, I mean this solely in the figurative sense of it being"Stallman's" in the sense of him being the founder, head, and motivespirit of FSF, which is the sponsoring organisational umbrella for theGNU libc effort. Ulrich Drepper and other volunteers should be creditedfor the actual coding and debugging work.
[25]Richard Stallman sent me a much better and more-lucid explanation: "Wewanted to merge in their changes, but the person who maintained thatversion didn't want to explain the changes, write change logs, or evensort out which changes had come from which authors so we could get legalpapers. But we considered support for GNU/Linux important, so the FSFhired a person to redo that work. Then we came out with GNU libc 2.0,which worked in GNU/Linux 'out of the box'." For his part, UlrichDrepper, the project lead, asserts that FSF paid someone only to work onglibc for the HURD kernel, and explicitly forbade that person to work onLinux support. Drepper adds that FSF never to his knowledge supportedthe work on libc for Linux in the first place, and in fact activelypressured him to work on HURD support instead of Linux support.
[26]An experienced Sybase programmer subsequently wrote to me with thefollowing: "In case no one has yet clarified the case about the forkbetween Sybase and Microsoft's SQL Server, SQL [Server] 7 is indeed acomplete rewrite from the ground up. Microsoft finally outgrew theSybase code (which considering its age held up pretty well IMO). Allversions before that (including 6.5 - probably still installed at moreplaces than it should be) are merely the forked versions of Sybase."
[27]In fact, an example of just that has already existed for quite sometime, in the Embedded Linux Kernel Subset (ELKS) project(http://www.elks.ecs.soton.ac.uk/), a highly modified Linux variantthat runs on the original IBM Personal Computer PC, XT, and compatibles,e.g., on antique 8086- and 8088-class machines that, lackingmemory-protection, cannot run real, full-fledged Unix-like operatingsystems. Also, in the medium term, Linux ports to some of the moredifficult CPU architectures, including even the Power PC, areresynchronised rarely to Torvalds's kernels, and might be seen as atleast temporary forks. Ditto Alan Cox's series of patches, which can beseen as a parallel development path to the main kernel series.
Last, Nick Moffitt has pointed out another ongoing cause of temporary forks,brought to his attention by his own GAR software-build/packaging system:the very act of packaging software for a particular OS or distribution.Inevitably, non-portable changes must be made to some packages to makethem install and function on various distributions and OS platforms.
Last modified: June 19, 2007
(Note: Please don't request additions/correctionsbeyond making the piece correct a/o my original 14 Nov 1999 publication date. This essay is not a newspaper.)
