Differences between revisions 6 and 7
Revision 6 as of 2009-11-28 12:27:06
Size: 43326
Editor: Elias
Comment: 删除对PageComment2组件的引用
Revision 7 as of 2009-12-25 07:16:05
Size: 43329
Editor: localhost
Comment: converted to 1.6 markup
Deletions are marked like this. Additions are marked like this.
Line 4: Line 4:
[[TableOfContents]] <<TableOfContents>>
Line 6: Line 6:
[[Include(CPUGnav)]] <<Include(CPUGnav)>>
Line 10: Line 10:
[http://linuxmafia.com/faq/Licensing_and_Law/forking.html Fear of Forking essay] ~ 中译 [[http://linuxmafia.com/faq/Licensing_and_Law/forking.html|Fear of Forking essay]] ~ 中译
Line 284: Line 284:
::-- ZoomQuiet [[[DateTime(2008-01-30T10:07:14Z)]]]
'''>>>[:/PageCommentData:PageCommentData]'''
::-- ZoomQuiet [<<DateTime(2008-01-30T10:07:14Z)>>]
'''>>>[[/PageCommentData|PageCommentData]]'''

CPUG联盟::

CPUG::门户plone

BPUG

SPUG

ZPUG

SpreadPython Python宣传

1. 分支恐慌咏叹调

Fear of Forking essay ~ 中译

From rick Sun Nov 14 16:13:06 1999
Date: Sun, 14 Nov 1999 16:13:06 -0800
From: Rick Moen rick
To: [several individuals at my former firm]
Subject: Essay for the Brown-Baggers: code forking
Message-ID: 19991114161305.C32325@uncle-enzo.imat.com
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0i
X-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: RO
Content-Length: 20135
Lines: 381
}}

Ed, I hope you would not mind forwarding this essay to the Brown Baggers mailing list. I was trying to finish this for the sales force's benefit before my departure, but ran out of time, in my rush to get my department in 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 his presentation on licences at a Brown Bag session, and talked about the right to fork source code. He pointed out that the right to start your own mutant version of any open source project (which is what we mean by "forking") is an important safeguard. He and I both stressed that the absence 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 "viewable source".)

But this creates a puzzle for you guys[5]: I'll bet you have to work hard to fight customer fears that GNU/Linux [6] will fragment into a hundred incompatible versions because there's no single big corporation in charge. Right? And here Nick and I come, saying thank God open source licences guarantee 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 product of AT&T's Bell Labs division, around 1969. I'll omit most of the long story, but the most important fact to know is that AT&T was then operating under a January 24, 1956 Department of Justice anti-trust judgement [7] (which expired around 1980) prohibiting it from entering the computer/software business, and required 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 released AIX. Apple did A/UX. DEC did Ultrix[8], OSF/1, and Digital Unix (later renamed "Compaq Unix" and now "Compaq Tru64 Unix"). Data General did DG/UX, SGI did IRIX, HP did HP/UX, and SCO did Xenix[9] which eventually mutated into SCO Open Server. And we could cite others, but I'll spare you.

The point is that these were the jokers who ruined Unix. Every one of them marketed his mutant Unix as "Unix plus" -- everything the other guys have and more. Needing to create differentiators, they deliberately made their Unixes incompatible while giving lip service to "standards".

For customers, this was simply a mess, and Microsoft drove right through these guys' disunity like a Sherman tank. It is the classic instance of forking that sticks in people's minds. Which is why you folks are expected to assure customers that the same won't happen to GNU/Linux. We'll return to this point later.

1.0.1. 2. BSD

--> FreeBSD, NetBSD, OpenBSD, BSD OS, MachTen, NeXTStep (which has recently mutated into Apple Macintosh OS X), and SunOS (now called Solaris)[10]

As I mentioned above, antitrust-limited AT&T, not being able to sell Unix 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 Software Distribution), and they were glad to share it with anyone similarly having 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 very open-source-like fashion.[12] Over quite a few years, 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's remaining AT&T work to create a truly free BSD. Dreading the confrontation likely to result with AT&T, they tried to stall by assigning Bostic the difficult part of this task, rewriting some key BSD utilities. This backfired when he promptly did exactly that. So, they grumbled but then completed the job[14], and tried to 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 the lawsuit, freeware BSD split into three camps (FreeBSD, NetBSD, and OpenBSD).[16] But there were also several proprietary branches[17], made possible because U.C. Berkeley's "BSD Licence" allowed creation of those: Sun Microsystems's SunOS, Tenon Intersystems's MachTen, BSDI's BSD OS [18], and NeXT Computer's NeXTStep OS all came out for sale without public access to source, and were all based on the Berkeley BSD source code.

Note the distinction: If you write a program and release the source code under the GNU General Public Licence (GPL), other people who sell or otherwise release derived works that incorporate your work must release their source code under GPL conditions. The same is not true if you release your work under the BSD Licence: Anyone else can create a variant form of your work and refuse to release his source-code modifications. (In other words, he is allowed to create proprietary variants.)

A word about the three free BSD variants: All three were splinters from a now-dead project called 386BSD. All have talked about re-merging in order to save duplication of effort, but they now persist as separate projects because they've specialised: FreeBSD aims for the highest 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 other words, the 386BSD project remains forked because there are compelling reasons that make this a win for everyone.

Also, where possible, these three sister projects collaborate on tough tasks -- and they also collaborate with GNU/Linux programmers. Some of the best hardware drivers in the Linux kernel are actually BSD drivers. There's a high level of compatibility among the three BSDs and between them and GNU/Linux: Unlike the proprietary Unix vendors, BSD and GNU/Linux programmers have an incentive to eliminate incompatibility and support standards.

1.0.2. 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 Dave Moon) in 1976, in TECO macros and PDP 10 assembly, to run on ITS and TOPS-20 -- at that time, under no explicit licence terms. (Stallman has clarified that it did carry a statement that "People should send changes back to me so I could add them to the distribution.") It proved wildly popular, and by 1981 had started to give rise to explicitly proprietary variants, notably James Gosling's C-coded "Gosling Emacs". [The original version of this essay's section on Emacs forks was sadly confused, as I had confused this "Gosmacs" fork with others, in attempting to recall Emacs history solely from unaided memory, and my explanation went wrong from that point on. For this revision, I've replaced that entire section.]

In 1985, Richard Stallman resumed leadership, creating his flagship GNU Emacs version in C, based initially on Gosling's work, but replacing all Gosling code by mid-year, enabling Stallman to place the work under his newly written GNU General Public Licence, which he then did. At this point, mid-1985, Emacs's open-source history begins.

By 1991, Stallman's GNU Emacs had gone from major versions 15 through 18, with a number of point releases. NCSA originated a set of popular patches ("Epoch") to improve GUI support: GNU Emacs 19 was expected to merge Epoch's features cleanly.

So things stood as developers at Lucid, Inc. (who used Emacs with their proprietary C / C++ development tools) began participating in the GNU Emacs development effort, attempting to bring about version 19. For reasons that remain disputed (http://www.jwz.org/doc/lemacs.html), the Lucid developers and Stallman had difficulty cooperating, and the Lucid developers released their version as Lucid Emacs 19.0, in April 1992. (As a fork of GNU Emacs, it is likewise under the GNU GPL.)

The anomalous aspect of this rare fork of a GPLed work is not so much tha