Copyright 2003-2005 Bruce R. Montague. All rights reserved.

This document makes a case for using a BSD-style license for software and data resulting from open research; specifically it recommends using a BSD-style license in place of the GPL. It can also be read as a BSD versus GPL Open Source License introduction and summary. I am not an expert in this area, but about the fifth time I found myself writing to explaining ramifications of current open source I decided to attempt to consolidate my efforts. My experience in ongoing arguments in the Federal civil service in the 1970's over the merits of in-house, contract, off-the-shelf, public domain, and government-developed ``open source'' software may contribute to a dreary aversion to this subject.

"To the question "What was IBM's official stand on SHARE?"... Thomas J. Watson, Sr., did not favor any kind of customer group. His attitude changed once he was shown that the cost of programming could be kept down. ... one of the first concepts to come out of SHARE was that of an integrated software system. ... SHARE became a club of systems programmers." [MB98]

IBM was soon distributing a million cards a month of SHARE software (this was in the mid-50's). Much software today has roots in user group software developed in the 1960s and 1970s:

"In the DEC world software was largely free. The best source was DECUS, the DEC User Society. It was from DECUS that Bill Gates got hold of paper tapes containing the source code to a version of BASIC and an assembler for the PDP-8. He used them to begin work on a project he considered fun: his very own edition of a BASIC interpreter." [MA99]

There was no software industry at this time. Most software development was ``in house'' or came from ``user group tapes'' that programmers exchanged at regular meetings. Aficionados of this style of program development often speak wistfully of the American Radio Relay League, which has loosely coordinated technically sophisticated ham activities for nearly 80 years, a longevity record that many companies can only envy.

 §  Software products. Although consultants had served the computer industry since the late 1940's (Cristopher Strachey apparently was the first), discussion in the Annals of the History of Computing seems to have converged in agreeing that in 1965 ADR developed the first licensed software product independent of a hardware company, that is, ADR's product was a turning point in the formation of the software industry [Goe98]. ADR was competing against a free IBM package originally developed by IBM customers. ADR patented their software in 1968 and to stop ``sharing'' of their program they provided it under an ``equipment lease'' in which payment was spread over the lifetime of the product. Thus, ADR retained ownership and could control resale and reuse. Many other companies were exploring this area; it was natural for consulting companies to attempt to commercialize their software. A rapid result of these events was the anti-trust suite against IBM in 1969 by the US Department of Justice. The charge against IBM was, in effect, that it was destroying businesses by bundling free software with IBM hardware. As a result of this suite IBM unbundled its software, that is, software became independent products separate from hardware.

 §  The commercial ``perpetual license''. In 1968 Informatics introduced the first commercial ``killer-app'' and rapidly established the concept of the ``software product'', the software company, and very high rates of return. Informatics developed the perpetual license which is now standard throughout the computer industry. While somewhat similar to an equipment lease, this license allowed Informatics to be paid a large lump-sum up-front, independent of the lifetime of the product. Ownership never transfered to the customer. The development of the modern software industry, largely independent of hardware vendors, followed rapidly.

 §  Modern open source. The term open source has recently been deliberately introduced to describe the original non-commercial model of software development, the communities that form to develop software in this manner, and the software itself. Open source software development communities often resemble international clubs that maintain intellectual traditions in areas as diverse as chess and amateur astronomy. Open source never really disappeared, although those engaged in it may not have consciously thought of it in those terms. Programmers in government labs, universities, system administrators, and hobbyists all often find it convenient to share the programs they write in a non-commercial fashion.

 §  Development of Unix. Unix was developed principally by ATT Bell Labs employees Ken Thompson and Dennis Ritchie. They had worked at MIT on a large joint research project between ATT, MIT, and GE (later Honeywell). The project used CTSS, a system developed at MIT and among the earliest interactive time-sharing systems. Ritchie was later to write that Unix was largely a ``modern'' re-implementation of CTSS:

"In fact, a good case can be made that it is in essence a modern implementation of M.I.T.'s CTSS system. This claim is intended as a compliment to both UNIX and CTSS. Today, more than 15 years after CTSS was born, few of the interactive systems we know of are superior to it in ease of use; many are inferior in basic design." [Rit78]

ATT, who owned the original Unix implementation, was a publicly-regulated monopoly tied up in anti-trust court; it was legally unable to sell a product into the software market. It was, however, able to provide it to academic institutions for the price of media (it apparently was required to make technology it developed available via a license, although it didn't have to make that easy). Bell Labs, the research arm of ATT, had started making digital computers in the late 1930s. Because these computers could only be sold legally to ATT or the US government, Bell developed a close relationship with military computing in World War II, specializing in weapons control computers. This relationship lasted into the late 1950s.

Universities rapidly adopted Unix after an OS conference publicized it and its availability. It was extremely helpful that Unix ran on the PDP-11, a very affordable 16-bit computer, and was coded in a high-level language that was demonstrably good for systems programming. The DEC PDP-11 had, in effect, an open hardware interface designed to make it easy for customers to write their own OS, which was common. DEC eventually sold at least 6 OSes for the PDP-11, many with roots in customer systems. As DEC founder Ken Olsen famously proclaimed, ``software falls from the sky'', and ``software comes from heaven when you have good hardware''.

 §  Development of BSD. Ken Thompson returned to his alma mater, UC Berkeley, for a year (1975) and taught the kernel line-by-line. This resulted in an evolving system ``distribution'' known as BSD (Berkeley Standard Distribution). BSD attracted funding by D/ARPA, a military research agency which, to foster technology for military command-and-control, funded over half the major commercial time-sharing OS implementations of the day (6 out of 12).

UCB converted Unix to 32-bits and added virtual memory. UCB also implemented, with considerable DARPA involvement, the TCP/IP stack upon which the Internet was essentially built. UCB made BSD available for the cost of media under what became known as the BSD license. A customer purchased Unix from ATT, and then ordered a BSD tape from UCB. Chief features of the original BSD license were that it (1) put no restrictions on the use or commercialization of the code, (2) stipulated UC was to have no legal liability resulting from the code, and (3) UC was required to be publicly credited in any use of the code or related documentation. In a sense UC was giving the code away for advertising and ``goodwill''. DARPA was desirous of as widespread an adoption of BSD as possible to permit DARPA-funded research projects to build on one another instead of disappearing into a swamp of incompatible systems. Another factor that greatly assisted the spread of BSD was publication in 1977 of John Lions ``Commentary'' by the University of New South Wales. This was a complete listing of Unix accompanied by a detailed line-by-line description of the code. This document was widely pirated and achieved widespread dissemination, despite its restricted-release proclamation that the reader was required to have an ATT Unix license.

 §  Government standardization policies. The US government, via the GSA (the agency ultimately in charge of purchasing contracts) encouraged the growth of the Unix industry by mandating Unix as the required OS for all federal government purchases. The government was legally required to attempt to foster competition in the computer industry (the Brooks Act); their standard "foil" to IBM were the mainframe companies informally called the BUNCH. These mainframe companies were failing and could no longer maintain competitive OS groups. Government adoption of Unix also pleased many small government suppliers (and their political representatives) because these small companies often were simply resellers and system integrators without any technical ability to compete at the OS level - reselling a ``standard'' system was in their interest. The GSA standardization was probably premature, as Unix was not yet competitive in many areas, so waivers for other OSes became routine. Indeed, in many areas, such as transaction processing, SMP, asynchronous I/O, or soft--real-time, Unix had never been particularly good (these features are starting to be addressed now, many years later, in Linux and the BSDs; various Unix systems have addressed them in the past to one degree or another).

SUN benefited greatly from the GSA's policy and the success of Unix in government and academic markets. SUN became the leading Unix vendor. SUN's OS was a derivative of BSD. In the mid-80s, the government anti-trust case against ATT ended with the break-up of ATT (Bell Labs eventually became Lucent). ATT still owned Unix and was now able to sell it. ATT embarked on an aggressive licensing effort, and most commercial Unixes of the day became ATT-derived. ATT made a large investment in SUN. In reaction, DEC, IBM, and HP formed an alliance known as OSF, the ``Open Software Foundation''. By the early 1990s over 350 companies had joined OSF. ATT, SUN, NCR, and Unisys formed a competing alliance, ``Unix International''. The ``open'' in OSF was not the same as in open source - the companies wanted an independent Unix distribution legally available to them without ATT involvement.

About the time the GSA adopted Unix, the Europeans and the Japanese also adopted and heavily pushed similar government Unix-centric policies. Large Japanese companies such as Hitachi and Fujitsui realized they could compete on hardware but faced an almost insurmountable problem competing with software at the user-interface level. They saw Unix as the great equalizer. These two companies had been badly burned by building mainframe hardware that ran IBM OSes - they had been sued for theft of intellectual property by IBM and ended up paying IBM almost a billion dollars in settlement. Hitachi had also been caught outright in industrial espionage in the US ``obtaining'' proprietary IBM OS code. Large European companies were often nationalized and subject to political considerations. These companies, such as France's Bull, Germany's Siemens, and Britain's ICL, had largely failed in OS competition with IBM. They likewise wanted a ``standard'' that took the OS off the table.

 §  Confusion and splintering due to competing commercial consortiums. By the early 1990's the Unix market had reached a state of great confusion due to competing consortiums and standards. Contributing to this, ATT sued UC over license violations related to BSD. UC discovered that ATT had incorporated, without acknowledgment or payment, many improvements due to BSD into ATT's products, and lengthy court cases between ATT and UC ensued. During this period some UCB programmers embarked on a project to get as many people as possible throughout the BSD community to rewrite any ATT code associated with BSD. This project, largely conducted via e-mail, was mostly successful, and resulted in a system called BSD 4.4-lite (lite because it was not a complete system; it lacked 6 key ATT files).

 §  PC BSD. A lengthy series of articles published slightly later in Dr. Dobbs magazine described a BSD-derived 386 PC version of Unix, with BSD-licensed replacement files for the 6 missing 4.4 lite files. This system, named 386BSD, was due to ex-UCB programmer William Jolitz, and became the basis of all the PC BSDs in use today.

 §  The ``new'' BSD license. In the mid-90s Novell purchased ATT's Unix rights and a (then secret) agreement was reached to terminate the lawsuit. UC soon terminated its support for BSD. BSD was now nearly in the ``public domain''. The so-called new-BSD license that soon became common for BSD code placed no restrictions on the use of the code or advertising credits. It simply required a notification in the code that developers of the software were not liable and could not be sued.

 §  Gnu C:   Richard Stallman (the developer of Emacs, perhaps the most popular and feature-rich Unix editor) was a member of the research staff at MIT when his lab switched from home-grown to proprietary systems. Stallman became upset (enraged might not be too strong a word) when he found that he could not legally add minor improvements to the system. He devised an alternative to the commercial software license and called it the GPL, or ``GNU Public License''. He also started a non-profit foundation, the ``Free Software Foundation'' (FSF), which was intended to develop an entire system, repleat with an OS and all needed software, that would not be subject to proprietary licensing. This system was called GNU, for ``GNU is Not Unix''.

The GPL was designed to be the antithesis of the standard proprietary license. To this end, any modifications that were made to a GPL program were required to be ``given back'' to the GPL community (by making the source of the program available to the user) and any program that used or linked to GPL code was required to be under the GPL.

Although the goal of creating a complete system failed, a portable C compiler was developed that had great importance. It was widely used throughout the Unix industry and was modified for numerous special commercial projects. This was largely possible because the output of the compiler was not considered a derivative work requiring the GPL. The FSF attracted a vocal following of programmers that sometimes become sidetracked by social and anti-capitalist issues to the detriment of engineering efforts.

The GPL somewhat resembles an elaborate form of the licenses which the US government has occasionally used from the earliest days of the industry to release government-developed software with the provision that the software cannot be used for gain, on the justification that the taxpayer has already paid for the code.

 §  X-windows:   By the early 1980s, MIT's home-grown computing environment had fallen behind the times. MIT managed to convince the VPs in charge of university research at IBM and DEC to ``match-fund'' a project to develop a vendor-neutral portable networked windowing system (GUI) for Unix. Although this project lasted nearly a decade and spent perhaps $100 million dollars, the initial version of X-windows was developed at MIT by two staff programmers (one an on-site DEC employee). X was ``forked from'' (based on) the W system that had been developed at Stanford. In 1985 MIT made X version 9 available at the cost of media under a license that resembled the BSD license. X version 10 became a widespread success. MIT was reluctant to enter the software business, but in the confusion of competing consortiums many companies where happy politically to leave MIT in charge. MIT thus acted as chief architect and project manager but handed off implementation responsibility to DECWSL, DEC's west coast research lab, which employed many ex-employees of Xerox Parc who had GUI development experience. Many companies contributed to the ``public'' DECWSL ``X re-engineering'' effort under this arrangement, including SUN. The Internet was widely used as part of X development, and many engineers in large companies that they perceived to be mis-managed learned to cooperate with each other over the Internet on product development. In 1988 MIT founded the ``MIT X Consortium'' and effected its escape.

 §  Linux:   While the commercial Unix wars raged, the Linux kernel was developed as a PC Unix clone based considerably on the then prevalent ATT Unix APIs (the SystemV APIs, which by then had been a major influence on an IEEE standards effort known as POSIX) and MINIX, a small academic Unix clone developed for the PC by Andrew Tannenbaum. MINIX had attempted to rewrite Unix using a microkernel and had serious performance problems. Linus Torvalds, an experienced assembly programmer, disliked MINIX performance and used a classical monolithic kernel for Linux. Linus credits the existence of the GNU C compiler and the associated GNU tools for the existence of Linux, and put the Linux kernel under the GPL. Indeed, Richard Stallman is causing some controversy currently by insisting that Linux should properly be called GNU/Linux; that is, Linux is the GPLed OS that he always wanted. I believe Linus wrote, or I heard him say, that the existence of ATT's ``SystemV Interface Definition'' in the University library had a large influence on the API's he initially adopted.

In the days of the mainframe, Unix had been the low-cost cost-of-media solution. By the days of competing consortiums and microcomputers, Unix had become a high-cost, high-end solution. Unix solutions were competing on performance in ``cost is no object'' government and academic environments. Many experienced OS engineers by this time were extremely demoralized as to the state of affairs in the commercial OS world (and not just with respect to Unix). Many of them leapt to contribute to a system to which they could, once again, have low-cost, uninfringed access.

 §  Why Linux? Factors contributing to the success of Linux include (1) BSD was at the time in a legal morass, (2) the gcc compiler was available, (3) Linux concentrated on supporting small, low-end PC configurations, (4) many frustrated engineers were able, and more than willing, to participate in system development over the Internet and Linus managed this type of project well, (5) the X-Windows system was released under a BSD-style license, (7) the large code-base of BSD utilities was available and was used, (6) the GPL was intrinsically attractive to many, and (7) although Linux was just the kernel, many small companies were able to assemble ``distributions'' of common Unix applications and install tools that they sold. Some of these companies, such as Red Hat and VA Linux, executed good marketing campaigns and had flamboyant IPOs in a speculative market that was running out of rational stories.

Linus Torvalds, a recognized celebrity, good politician, manager, and marketer, personally controls the Linux kernel and has done a masterful job (he did not sign its copyright over to the FSF). However, because a complete system contains much more than just the kernel, Linux has provided a relatively easy way for small companies to enter the business of packaging and selling Linux CDs and Linux support. Companies such as Red Hat, Mandrake, SUSE, and TurboLinux compete on the applications they pack on their CDs, the quality of their installation program and documentation, their distribution channels, and brand name. These commercial distributions tend to include at least 400 programs. Caldera, who obtained the original Unix license when they bought SCO, appears to be the company with the Linux distribution that everybody ``loves to hate'', probably instigated by the insistence of its CEO, Ransom Love, that there is no viable long-term business model simply making Linux distributions. Another major force behind the Linux market, not to be underestimated, has been technical publishing houses such as O'Reilly, who have in a sense inverted the financial relationship between documentation and software. Their approach has caused open source to be called ``a difficult way to write books''.

 §  Linux and the GPL In theory, the GPL requires anything that statically links to any code under the GPL to be released back to the GPL community. Although this ``viral'' license was designed specifically to thwart making modifications to a program proprietary, in practice dynamic linking is not considered a violation of the GPL, and thus binary-only drivers that can be dynamically loaded into the Linux kernel are provided by a number of commercial device vendors. This often leads to a situation in which closed proprietary Linux drivers exist that can only run under a particular release from a particular company.

Pressure to put proprietary applications (such as the Oracle database) on Linux became overwhelming, resulting in a modified version of the GPL called the LGPL (``Library'', since renamed to ``Lesser'' GPL). The LGPL allows proprietary code to be linked to the GNU C library, glibc. You do not have to release the source to code dynamically linked to an LGPLed library. If you statically link an application with glibc, such as is often required in embedded systems, you cannot keep your application proprietary, that is, the source must be released. Both the GPL and LGPL require any modifications to the code directly under the license to be released.

Linux popularity has, of course, exploded in mindshare in the last few years, with a flurry of hot IPOs (which now, however, have almost all crashed). The GPL is very favorable to large hardware companies that want to compete on hardware and undercut software companies. IBM, for instance, is apparently investing around a billion dollars a year in Linux. Linux is very popular with students because of its low-cost, good marketing of its GPL ``ideology'', and a reasonable distrust of Microsoft. Linux has also been rapidly adopted outside the US, to some extent due to its near-zero cost and to some extent in reaction to the dominance of US software companies, which has always been a concern in many places.

In many parts of the world today the GPL, and associated legal niceties, may simply be being ignored in regard to Linux and related software. The long-term ramifications of this are unclear.

A common, and valid, reason to use the GPL is because one is modifying or extending the gcc compiler. This is particularly apt when working with ``one-off'' specialty CPUs in environments where all software costs are likely to be considered overhead, with minimal expectations that others will use the resulting compiler. In such an environment the use of gcc and the GPL is often unrelated to Linux.

 §  The FSF and the GPL. Code that is GPLed does not have to be given to the FSF to include in the GNU collection, although this is encouraged. To provide your GPLed software to the FSF you must sign your copyright over to the FSF:

``On the advice of counsel, the Foundation requires that the copyrights to improvements in GNU code be signed over to it before they are incorporated in releases of Foundation software. The concentration of ownership maximizes the standing of the Foundation as the aggrieved party in a lawsuit, as opposed to the collective complaints of hundreds of developers.'' [Ros00]

 §  Is GPLed code protected from market forces? It is not the case that a GPled project cannot be ``taken over'' by a commercial company. For instance, Red Hat, the leading US Linux distributor, purchased an engineering company (Cygnus) that had taken over development of the FSF compiler tools, such as the gcc compiler. Cygnus was able to do this because Cygnus had developed a business model in which they sold support for GNU software, enabling them to employ some 50 engineers and drive the direction of the programs by contributing the preponderance of modifications. The president of Cygnus wrote:

``Unlike proprietary software, in which companies fight in a two-sided win/lose contest, with Open Source it's more like fighting on a Moebius strip and everything flows to the side of the primary maintainer." [Tie99]

A recognized open source licensing expert describes this as follows:

``Projects using licenses like the GPL, ... live under constant threat of having someone take over the project by producing a better version of the code and doing it faster that the original owners.'' [Ros00]

Perhaps an open source community has a minimal size, depending on the complexity of the software, that can preclude such dominance (in the case of Cygnus, it was considered beneficial to all concerned).

 §  The Installfest. Greatly contributing to the popularity of Linux has been the ``installfest'', which has become a marketing technique used to great effect by Linux evangelists. These events, popular among students, somewhat resemble a social event in which everyone who wants to get Linux brings their entire PC, and a handful of Linux ``pros'' then walk the area, installing the appropriate or desired Linux distribution. These are social events that have greatly contributed to Linux popularity and the social networking of Linux resources.

 §  The GPL as a monopolistic marketing weapon. The GPL is well suited for use as a marketing weapon, potentially reducing overall economic benefit and contributing to monopolistic behavior. A developer of the Apache server writes:

``...the GPL could be an extraordinary effective means to establish a platform that discourages competitive platforms from being created...'' [Beh99]

 §  The GPL does not mean ``free''. The GPL is sometime erroneously considered to mean ``free software'', as in ``free beer''. This is not at all the case. The GPL is a requirement that the user of a program always have access to the source and the right to make derivatives and redistribute the product. The media containing such software can be sold at any cost desired, that is you can charge as much as you want for the cost of making a copy of the free software. Why would a user pay for such software, when they could potentially get it from some other source at trivial cost? If the user realistically is not the developer who is most rapidly able to engineer and distribute the product, the user's potential abilities may have little actual value. Conversely, if the product is static, the original developer may benefit little from widespread product distribution.

 §  Users of the GPL. Notable systems using the GPL include Linux, the gcc compiler, and Emacs.

 §  The new BSD license. The so-called ``new BSD license'' applied to BSD within the last few years has become even more ``open'', and now is effectively simply a statement that you can do anything with the program or its source, but you don't have any warranty and none of the authors has any liability (basically, you can't sue anybody). This new BSD license, which to some extent likely results from the success of Linux, is intended to encourage product commercialization. Any BSD code can be sold or included in proprietary products without any restrictions on the availability of your code or your future behavior. Some claim that the nature of the BSD-style license largely results from it being applied to projects originally funded by the government or by consortiums of commercial members who were always intending to take variations of the results private.

Although the new BSD license can be considered, in practice, close to ``public domain'', it is not at all the same as public domain. An item in the public domain has no owner. It is free for all to use.

 §  Use for Internet infrastructure. Because of its relationship to the original TCP/IP stack, BSD was adopted by small Internet companies, many formed by ex-UCB or other long-term BSD programmers. Small ISPs, and the hardware integrators that support such companies, are probably still the largest users of the BSDs.

 §  PC BSD distributions. There are only three open source BSD distributions, none of which is commercial (in this respect they all most closely resemble the Linux Debian distribution). The three open source BSDs serve different markets; FreeBSD targets x86 PC platforms, NetBSD targets cross-architecture portability, and OpenBSD concentrates on providing a small system that has been closely audited for security. Most of the reminder of this section is specific to FreeBSD, but the material could apply equally well to any of the open source BSDs.

In the Linux market the companies making commercial distributions take the kernel and add their own utilities, drivers, and install procedures to make a ``distribution'' (there is one non-commercial distribution, Debian). Thus, there are numerous such companies with feature-sets that differ. The open FreeBSD distribution includes the utilities, install tools, and applications that are found in a commercial Linux distribution, not just the kernel as with Linux. Because each BSD project provides a complete distribution, and there are only three distributions, which are all non-commercial, fragmentation is reduced. In addition, if any one distribution develops a successful feature, the others can, and do, adopt it (under the BSD license there is, of course, no reason why this can't always be done with publicly released software). In this sense the three distributions both compete and cooperate, evolving their systems. You can almost consider the three BSD distributions as traditional members of a software product family, with different members optimized for different markets. In the Linux world, the GPL achieves this for the kernel, but this is not achieved for the entire system, as competition between distributions has emphasized differentiation.

All three of the non-commercial BSD distributions maintain their source-code in globally accessible web sites, and maintain large collections of runnable applications called ports, available for download (FreeBSD currently has some >5000 ports). Because of this, the process of developing the entire distribution is in a sense more ``open'' then Linux (with exception of Debian) and less sensitive to the possibility that important parts of the code-base can become unavailable due to market conditions (that is, have their ``oxygen cut off''). The Linux code, of course is open, and the Linux kernel is not vulnerable, but individual Linux distributions are - indeed many such distributions have already come and gone and their particular incantations and peculiarities orphaned. Again, Debian is the exception to this, and things might be quite different if Debian was the dominant Linux distribution.

 §  FreeBSD project organization. FreeBSD development is managed by a ``core team'' of around a dozen members that are elected by over 200 ``committers''. Many of the developers that support FreeBSD are from the small companies that are dependent on FreeBSD; they are involved precisely to maintain ``assured platform existence and access''. In this sense, the FreeBSD community resembles a loose industrial consortium with a very low cost-of-entry usually expressed in the currency of direct engineering talent and man-hours. Individuals can easily, voluntarily, and informally enter this consortium. The FreeBSD community, which has existed roughly ten years, has had no legal organization. A non-profit foundation has recently been organized to assist in assuring the long-term survival of FreeBSD independent of any vicissitudes of the market, but this foundation has no direct relation to the FreeBSD project.

 §  FreeBSD strengths. FreeBSD has one of the longest and most illustrious pedigrees in the operating system world (this should not be taken as translating into always having the best features). The TCP/IP Internet stack that became the dominant Internet stack was developed on the BSD system from which FreeBSD is directly derived and FreeBSD uses the current version of this ``reference stack''. (Earlier network stacks had been developed, for instance, BBN developed the first TCP/IP stack on BSD; UCB forked BBN's original stack.) Additionally, FreeBSD is still heavily used for ongoing Internet research, both in universities and in many of the largest communications companies in the world. Yahoo is based on FreeBSD. Microsoft's Hotmail originally used FreeBSD. Much of Apple's new Mac OS X (the TCP/IP stack and API functionality) is based on FreeBSD 3.2 (the most current development version of FreeBSD is 5.0). OS X is rapidly becoming the Unix distribution with the largest numbers ever shipped.

I have also become aware in the course of writing this document that, although exact details remain murky, FreeBSD is apparently the OS of choice in the Internet pornography business (this may explain why we keep hearing that FreeBSD is good in the ``server-side'' space). Years ago I would have dismissed this; however, after seeing what similar business did for commercialization of the CD, and considering that this business may be among the largest profit-making Internet endeavors (and multimedia technology drivers), this is not a factor to simply be dismissed with a laugh. Perhaps this also explains why some areas of the FreeBSD community seem oddly remote.

 §  BSD-license strengths. A BSD-style license is a good choice for long-duration research or other projects that need a development environment that (1) has near zero cost, (2) will evolve with the latest Internet technology, (3) will never disappear, and (4) permits anyone to retain the option of commercializing final results with minimal legal issues. This final consideration may often be a dominant consideration, and I argue below that, in relation to research policy targeting technology transfer, it should be.

 §  BSD-license open source projects as ``standards''. BSD-style open-source has historically been phenomenally successful. The Internet infrastructure itself, and companies like SUN (based on a BSD-derived OS originally bundled with the hardware at no cost) are examples. One of the Apache web server's developers describes the situation this way:

``This type of license is ideal for promoting the use of a reference body of code that implements a protocol for common service. This is another reason why we choose it for the Apache group - many of us wanted to see HTTP survive and become a true multiparty standard, and would not have minded in the slightest if Microsoft or Netscape choose to incorporate our HTTP engine or any other component of our code into their products, if it helped further the goal of keeping HTTP common.

...

All this means that, strategically speaking, the project needs to maintain sufficient momentum, and that participants realize greater value by contributing their code to the project, even code that would have had value if kept proprietary.'' [Beh99]

 §  Use of BSD-style licenses. BSD-style licenses are used by the Apache web server, the X-windows system, Zope application server, and of course FreeBSD, NetBSD, and OpenBSD.

 §  Software Patents - a new danger and a big mess? Patents are property that protect openly described ideas, not the expression of an idea, as occurs in computer programs. A US patent grants the holder the right to keep others from using the idea for 20 years. In theory, the patent benefits society because it protects innovators from having their ideas stolen, thus encouraging open exchange of information. Software patents were rarely granted before 1981. That has changed. Some 20,000 US software patents were granted in the year 2000, and apparently around 100,000 US software patents exist in all. Software patents are growing exponentially and now constitute over 10% of all grants. [Bra01]

Many segments of the software industry largely believe that many (if not most) of these patents would not withstand scrutiny with respect to prior art or the required test of ``obviousness''. Prior art means the idea was published in the past. Many software patents are considered something of a joke. It is widely believed that almost all programs today, in practice, are likely violating numerous patents that have recently been granted without consideration of the common practices of the field. Patents are expensive (often in the tens of thousands of dollars) and may take years to process. Patent searches are likewise expensive and, given the state of the patent system, error-prone. Many small software businesses cannot play this game and simply ignore software patents.

In some software areas, such as telecommunications, the situation is very different, with software patents playing a predominant role. Such companies in the past two decade have invested considerably engineering time ``patenting everything in sight'', and maintain research arms that act as ``patent mills''. This is happening globally, as well as in the US (Hitachi is not going to underestimate the value of software intellectual property again). Companies use their patent suites to negotiate cross-licensing agreements with other companies that have similar patent pools. Patent pools become alternate currency unavailable to the small player, who is forced to pay royalties (it is probably not hard to find some patents that the programmer without a patent pool is violating, even if it's in the ``obvious'' category, and paying license fees is cheaper than going to court).

Thus, the patent system (worldwide) in many ways has become inverted with respect to its original purpose and strongly favors large companies that maintain full-time legal departments that trade in patents as currency. An unhealth situation exists in which some market segments effectively ignore the law, while other segments are dominated by legal considerations and the collection and trading of patents.

Software patents pose a significant danger not just to open source but to the entire concept of the small software business. An important strategy for those in open source is to document and disseminate techniques of prior art. It is reasonable to ask why some academic software engineering departments have not embarked on such an effort years ago. There are also a number of government efforts throughout the world to review and revise the current software patent system. An interesting question is to what degree the age of Unix and the existence of documents such as Lions's Commentary contributes to open source Unix popularity in this age of software patent uncertainty.

 §  The big danger. Finally, the largest danger faced today by all open source software is clearly closed hardware. As margins in hardware markets become very small, it becomes ever more attractive for hardware companies to consider themselves software companies that just happen to require certain proprietary hardware. Many hardware companies, in areas such as communications cards, video cards, and digital cameras, appear to intend to make the bulk of their money by selling drivers or licensing software, rather then profiting directly from the sale of hardware. This means that the interface to their hardware is undocumented and protected as their intellectual property. This often makes it impossible for open source software to use such hardware.

 §  Similar past technology transfer mechanisms. ``Communities'' similar to those supporting BSD-style open source are not new. Other than making use of the Internet, the FreeBSD project does not appear markedly different from the similar loose associations of small companies surrounding ``open'' cores that defined and evolved systems such as Forth, Mumps, or non-IBM APL. The comparison to Forth is especially relevant, as Forth was often used as a stand-alone OS, and voluntary interactions between numerous very small cooperating companies drove its overall evolution. The histories of these projects may have little to say about the applicability of the overall adhoc-consortium-of-individuals model (it may even indicate that it is appropriate in areas of very high risk). As is, Forth was heavily used when appropriate (and still is, Forth controlled the instruments on the spacecraft that recently landed on an asteroid and is running on the Cassini probe at Saturn). I believe Mumps (M) became (and may still be) a billion dollar-a-year industry.

Another reason that Forth is of particular interest in regard to open source is that Forth has long been perhaps the leading example of an open source community in which software is simply released directly into the public domain. Forth itself was placed in the public domain in 1972. The success of open source Forth demonstrates that it is viable to simply place software in the public domain, without any formally-crafted open source license.

 §  Current transfer of research into deployed technology is weak, often because research in not really relevant. Rob Pike has lamented that perhaps DARPA's emphasize on a single platform caused experimental OS research to stagnate; many agree with him (and have for a long time). Linux Torvalds is of the opinion that OS research funding made OS researchers direct their attention in ineffective directions:

"I don't necessarily think these researchers were knowingly dishonest. Perhaps they were simply stupid. Or deluded. I mean this in a very real sense. The dishonesty comes from the intense pressure in the research community at that time to pursue the microkernel topic." [To99]

Some research has clearly been very relevant. For instance, a number of the more difficult system-level components of FreeBSD (such as the basic filesystem and VM architectures) derive from PhD dissertations. However, the gap between research and practice is large enough to have generated a number of articles in venues such as CACM and IEEE Software; by-and-large it is simply expected that much OS research today is largely an exercise in grad-student training with little ``forefront'' component.

 §  Research and technology transfer costs have plummeted with hardware costs. What does this have to do with licensing issues and funding systems research? Consider the possibility that open source is not primarily an alternative software engineering model, business model, intellectual property model, or even a manifestation of particular development communities. Rather, modern open source simply results from the cost of conducting a complete traditional software technology transfer pipeline, from research through deployment, having dropped to the point where it can be conducted and funded by individuals, certainly by small groups of individuals or companies organized under almost any basis.

 §  Ad-hoc implementable standards consortiums. Very small, focused ``lightweight'' adhoc-consortiums can rapidly be created at low cost that can conduct operations, to a lesser or greater degree, along the entire technology transfer pipeline. Such consortiums tend to make markets accessible and provide a mechanism by which members of a market can react to unfair or monopolistic advantage. When possible, such consortiums are typically more efficient at end-to-end technology transfer than governments or large company bureaucracies largely because the efforts of a single individual can typically span a larger range of the pipeline. Such consortiums are not inherently superior. In particular areas, for instance, requiring specialty hardware, current costs may not be low enough for self-funded research and development. Likewise, open source groups can have political problems that destroy the organization. However, these problems exist for all manner of organizations.

Although low-cost Internet infrastructure is an essential part of this picture, it is necessary but not sufficient. Other factors include decades of accumulated and accessible software, decades of documented experience and results in the area, and a very large number of people qualified to work at the required level. Open source simply reflects what happens as we approach an economic situation where individuals can self-fund research efforts not markedly different in goals, scope, or available talent from those of the typical government-funded research project. But, even better, not only has research activity become low-cost, but the cost of the entire technology transfer pipeline has fallen to a level approachable by individuals.

 §  The need for economic (information and resources) feedback. The idea is often put forth in the open source community that open source is a variant of the scientific method, with code distribution being the equivalent of unfettered and open publication. The idea that science developed by itself, without commercial activity, and based solely on the free exchange of information, is vastly flawed. Free exchange of information is a necessary condition, but it did not in itself develop the vast infrastructure of technology and instrumentation that in many ways led, rather than followed, the development of science. If Darwin had been reduced to freely exchanging ideas with his peers, rather than spending 5 years on H.M.S Beagle (financially supported by the British Navy), it is likely that his writing would more resemble the theorizing that had dominated his area of interest for millennia. H.M.S Beagle and its mission reflected an entire culture which had numerous public and government components resting on a vast commercial enterprise. Science, and the evolution of science via experimental results, does not occur in a non-commercial vacuum. Historically it has occurred in the context of an immense web of activities that permit science to benefit from new instrumentation made practical by advances in technology, while supporting the costs by which some scientific advances, via various means of ``technology transfer'', result in better technology available throughout society.

 §  The technology transfer pipeline. The traditional technology transfer pipeline that research-funding agencies assume looks something more-or-less like this:

Research->Applied->Development->Advanced->Deployment
          Research              Development

A very rough summary of these steps might be:

Research    - You're futzing around, perhaps looking
              for an interesting state-space or a
              way to attack a well-know problem area.
              You are ``looking for an itch''.
              You want to find out what others have done.

Applied R.  - You found something interesting and
              are exploring the state space; nothing
              you do is expected to be usable by others.
              You want others to know what you have found
              and to know of your interest.

Development - You're making something that you can
              use reliably to take advantage of
              what you found; you're alpha testing.
              It's not likely usable by others.
              You want others to know what you are doing.

Advanced D. - You're packaging your solution to be part 
              of a widely-used distribution; others 
              may be beta testing. You want a few 
              knowledgeable others to be using what
              you did.

Deployment  - Anyone can use your result with 
              minimal difficulty.

The above does not adhere to to any particular definition, but is roughly assumed by any research program concerned with technology development and transfer (under any economic system and scale). Typically, governments and very large companies (which are often entangled in government industrial policy) fund the initial research side of this pipeline to benefit the entire society, as most of these efforts can be expected to fail. In practice, for many technologies the advanced development and deployment stages of this process resemble a tree rather than a pipeline, that is, multiple groups may attempt advanced development.

 §  Technology transfer problems. Many programs assuming this chain ``break down'' somewhere in the development stage, where classically a result might move out of the lab into some sort of commercial development vehicle. This is the famous ``and then it's tossed over the wall''. Other research efforts break down due to a disconnect between what is happening at the two ends of the pipeline, that is, the research is simply ``not relevant'' or is unnecessary because there is no possibility that it can transition along the pipeline. Such research is commonly defended on the grounds that you can't ever know what research will be useful in the future; this is true, but sometimes irrelevant. If there is no feedback between the two ends of the pipeline, results for which one has application hopes can become irrelevant because they lead to known development cul-de-sacs. In all cases, the easier one can move specific technology and associated artifacts up-and-down the technology transfer pipeline, the better.

 §  Minimizing technology transfer problems. The role of research as ``seed'' in the above chain implies that software research results produced by the early phases of the pipeline should be open sourced. This gives the follow-on or validating researcher all source required to build the system and the tools to perform such a build. This is important for the researcher needing to gain an in-depth understanding of the system, or in the event that an old result becomes newly applicable. This is also important because research results and project life-times are such that you may need to modify code at any level over a long period of time out of step with all others (this is similar to many embedded system products).

In the past, research projects transitioning this pipeline often have had large physical costs that received constant scrutiny. For a successful research effort, this often results in a visible transition, typically somewhere in the advanced development stage, to a self-sustaining commercial environment. In the case of engineering research, this often provides overall advantage as the funding agency can invest in other research projects while the ``feedback loop'' inherent in commercial operations leads to resources available commensurate with the need for the result. Since software no longer requires large physical costs, this transition has become obscured, especially when volunteers are able to absorb the most common cost, that is, man hours. However, lack of economic feedback can keep the deployment stage from being a success. Instead of research results becoming readily available to all throughout the economy, the benefits of the research are deployed at a rate limited by time available to volunteers and by their degree of interest in non-research phases of the pipeline. The overall result is more limited deployment of the result, and less overall benefit.

 §  BSD license advantages. The BSD-license allows all elements of the technology transfer chain to occur with no organizational transitions, funding ``gateways'', ``sales hurdles'', or (in many cases) legal dependencies or licensing transfers. The transition from phase-to-phase is essentially nearly frictionless. As such, BSD-style licenses can easily be used by the largest and smallest organizations that operate both in research and commercial spheres.

 §  GPL license disadvantages. The GPL can present a real problem for companies or researchers wishing to commercialize and profit from software at the system level in the deployment stage. The GPL adds to the difficulty a graduate student will have in directly forming a company to commercialize his or her research results, or the difficulty a student will have in joining a company on the assumption that a promising research project will be commercialized. It is likely that such commercialization processes, with the developer physically transitioning along the pipeline, is the method by which much technology transfer actually occurs in the United States and other countries based on legally mediated property. The GPL should be discouraged because it discourages the developer from moving himself along the stages of the technology transfer pipeline.

For those interested in core software standards that do not, as with Linux, use a trap-based API, the GPL is a poor license because it precludes commercial products based on the standard and thus minimizes the number of programs that can be built using the standard. The LGPL does not necessarily preclude such products but can make them more difficult (or impossible) if the nature of the standard is such that wide coupling exists between code in the standard and a program using the standard. The GPL (ignoring the Linux trap-based case) does not provide a mechanism to develop a standard on which one engineers products. Rather it attempts to force everyone to contribute to an evolving suite of programs, and then to compete in the distribution and support of this suite. The LGPL likewise forces contribution to a suite of libraries. This situation is unrealistic for many required core system standards, which may be deployed in widely varying environments that may require commercial customization or legacy integration.

The GPL targets the concept of the technology transfer pipeline itself. It is an attempt to keep all efforts, regardless of demand, at the research and development stages. This maximizes the benefits to researchers and developers at an unknown cost to those that would benefit from wider distribution.

 §  The orphaning problem with proprietary commercial software. The GPL correctly identified a serious problem and endemic vulnerability of proprietary software that often caused it to fail in some areas. Those outside the software engineering field (and those in some software areas) may not appreciate the problems this flaw in the proprietary model has caused in actual practice. The problem, known by names such as ``orphaning'', is that a single business failure or change in a product strategy can cause a huge pyramid of dependent systems (and companies) to fail for reasons beyond their control. Even the threat of such an event can have great consequence. These events may be completely unplanned; upper management in large companies may be so far removed from lowest-level engineering specifics that they may not even realize they are triggering such events. The short average lifetime of startups exacerbates this problem.

Orphaning can and does destroy entire engineering careers. Decades of experience have shown that the momentary size or success of a software supplier is no guarantee that their software will remain available or stable; current market conditions can change rapidly. Legal ``software-escrow'' schemes are of little avail because it is the process of engineering the software that is important, not a snapshot of the code. Thus, engineers often find themselves building their products and careers on foundations that can vanish at any time. Some software markets, such as embedded systems, experience an aggravated form of this problem because their product life-cycles (which they may have to guarantee) may be longer than the average expected corporate lifetime of their would-be suppliers. Engineers often react to this problem by attempting to bring ``in-house'' as much of their system software as possible. The GPL attempts to prevent orphaning by severing the link to proprietary intellectual property.

 §  Solving the problem with implementable standards organized as BSD-licensed open source projects. One realistic solution to the orphaning problem is for ``failsafe'' implementation standards to exist as realistic ongoing engineering processes rather than as the traditional specifications, interfaces, reports, and committees that the word ``standard'' conventionally brings to mind. This is, in fact, what has naturally, albeit sometimes tortuously, occurred as exemplified by some of the larger BSD-licensed ``projects'' (such as Apache, X, and FreeBSD). These projects provide viable standards in practice, as opposed to the often forlorn efforts that the industry has come to expect from a ``standards process''.

 §  Valid goals of the GPL can be achieved via BSD-style licenses. A key effect of the GPL - to make a complete and competitive open source system widely available at cost of media - is not at all unreasonable, especially considering that lack of such system software can be a significant obstacle to research progress in many important areas. BSD-style licenses, in conjunction with ad-hoc-consortiums of individuals, can achieve this goal of the GPL without destroying the economic assumptions at the deployment end of the technology transfer pipeline that limit the benefits to society at large.

 §  Forming a foundation for a more practiced-based discipline of software engineering around open and implementable reference standards. Software engineering is still a very young field. BSD-style projects are often low-level and are more concerned with implementation then are traditional standards. However, BSD-style projects may more accurately portray the nature of standards which can provide a long-term basis for the software engineering field than do more traditional notions of standards.

 §  Government studies. Susan Graham is a distinguished senior researcher at UC Berkeley, a faculty member of the original UCB BSD development team, and was at one-time leader of the UCB BSD project. Susan was a member of a government technology advisory committee charged with defining government policy towards open source in high-end computing. Susan's resulting paper, ``From Research Software to Open Source'', summarizes the recommendations of a Presidential advisory committee on open source (PITAC) as: (1) encourage development of open source software, (2) encourage competition between open source and proprietary software, and (3) undertake a government analysis of open source licensing issues [Gra01]. This recommendation is intended to remove the de facto prohibition on government procurement of open source software, and has no specific conclusions regarding licenses other than the recommendation for a follow-on analysis. Graham also notes a similar set of recommendations from the European Union, embodied in the Libre report, which likewise recommends governments promote open source reference implementations for all protocols, promote open source in general, and address associated legal issues so as to promote long-term competitive advantages.

For the PITAC open source report, see:

 §  Academic software engineering. A pair of papers by Bezroukov provide an interesting academic critique of some open source issues.

www.opensource.org/licenses/bsd-license.html
www.ibiblio.org/pub/Linux/LICENSES/bsd.license

Examples of BSD licenses (in rough order of increasing restrictions):

   FreeBSD:   www.freebsd.org/copyright/freebsd-license.html
   XFree86:   www.xfree86.org/current/LICENSE1.html#1
              www.xfree86.org/legal/licence.html

   Apache:    http://httpd.apache.org/docs/LICENSE
   X-windows: www.x.org/xlicense.html
   Zope:      www.zope.org/Resources/ZPL

Zope is an example of a corporation using a BSD-style license. Zope requires that modifications be distributed as patches to a standard Zope release.

The X license was originally knows as the ``MIT X License''. The XFree86 project (the PC X-windows consortium) explicitly considers the GPL ``too restrictive for XFree86 use.''

 www.xfree86.org/legal/licence.html

  "When U.S. Government drawings, specifications
  or data are used for any purpose other than a
  definitely related Government procurement
  operation, the Government thereby incurs no
  responsibility nor any obligation whatsoever;
  and the fact that the Government may have
  formulated, furnished, or in any way supplied
  the said drawings, specifications, or other
  data is not to be regarded by implication or
  otherwise, as in any manner licensing the holder
  or any other person or corporation, or conveying
  any rights or permission to manufacture, use,
  or sell any patented invention that may be in
  any way related thereto.

  The information in this document is subject to
  change without notice and should not be construed
  as a commitment by the Government. The Government
  assumes no responsibility for the use of or
  reliability of the information contained in
  this document. This document can be freely
  copied by any means whatsoever provided that
  this disclaimer is included. The contents of
  this document cannot be copied/used for private
  gain."

www.ibiblio.org/pub/academic/computer-science/history/pdp-11/rsx/decus/rsx80a/372004/disclam.doc

www.share.org
SHARE, an IBM user's group.

www.decus.org
DECUS, the DEC user's society.

www.softwarehistory.org/Goetz1.htm
The paper, ``How ADR Got Into the Software Products Business and Found Itself Competing Against IBM'', by Martin A. Goetz.

www-personal.umich.edu/~vnrusso/histcomp/informatics.html
MARK-IV and Informatics.

www.cbi.umn.edu/collections/inv/cbi130.htm
Some Mark IV User Group material, by Evan Linick

www.fsf.org
The Free Software Foundation.

www.fsf.org/licenses/licenses.html
The FSF's license page.

www.fsf.org/licenses/gpl.html
The GPL.

www.fsf.org/licenses/gpl.txt
The text version of the GPL.

www.gnu.org/software/gcc
The gcc C compiler.

http://www.daemon.org/bsd-releases/misc/USL-lawsuit
The great BSD lawsuit.

www.opensource.org
The Open Source Initiative (OSI).
See also http://opensource.org/licenses
for a list of open source licenses and their descriptions.

www.opensource.org/licenses/bsd-license.html
www.ibiblio.org/pub/Linux/LICENSES/bsd.license
Templates for the new BSD license.

http://stlr.stanford.edu/STLR/Articles/01_STLR_4/index.htm
The article A New Paradigm in Intellectual Property Law? The Case against Open Sources, Mathias Strasser.

www.x.org
The X Consortium.

www.xfree86.org
XFree86 is the version of X for the PC.

www.faqs.org/faqs/x-faq/part1/preamble.html
The X FAQ.

http://ecco.bsee.swin.edu.au/unix/uh/x-windows.html
The paper, The X-Windows Disaster, by Don Hopkins. Although this is slightly tongue-in-cheek, it contains some interesting insights.

http://larch-www.lcs.mit.edu:8001/~corbato/sjcc62
http://www.multicians.org/thvv/7094.html
The CTSS operating system.

Note that the first reference in Corbato's paper is to a paper by Christopher Strachey. Strachey had patented the concept of the time-sharing OS (I believe in 1959), deliberately to keep others from trying to profit by it. Some apparently consider the C language to be indirectly named for Strachey (via the C in CPL, via BCPL).

www.opengroup.org
The current incantation of, OSF, the Open Software Foundation.

www.oreilly.com/reference/dictionary/terms/U/UNIX_International.htm
Brief descritpion of UI, Unix International.

www.cs.bell-labs.com/cm/cs/who/rob/utah2000.pdf
The paper, ``Systems Software Research is Irrelevant'', by Rob Pike.

www.firstmonday.org/issues/issue3_3/raymond/index.html
``The Cathedral and the Bazaar'', Eric S. Raymond.

http://www.firstmonday.dk/issues/issue4_12/bezroukov
``A Second Look at the Cathedral and the Bazaar'', Nikolai Bezroukov

http://firstmonday.org/issues/issue4_10/bezroukov/index.html
``Open Source Software Development as a Special Type of Academic Research (Critique of Vulgar Raymondism)'', Nikolai Bezroukov.

www.gsa.gov
The GSA, the Government agency responsible for purchasing.

www.itpolicy.gsa.gov/roadmap.htm
The GSA's computer folks, with some history of the Brooks act, and Federal industrial policy.

www4.law.cornell.edu/uscode/17/index.html
US Copyright Law.

http://link.springer-ny.com/link/service/series/0558/bibs/2000/20000195.htm
Abstaract of Susan Graham's paper, ``From Research to Open Software''.

www.itrd.gov/pubs/index.html
www.itrd.gov/pubs/pitac/pres-oss-11sep00.pdf
``Developing Open Source Software to Advance High End Computing'', PITAC committee.

http://eu.conecta.it
The European Working Group on Libre Software.

www.amazon.com/exec/obidos/ISBN%3D1573980137/102-0796348-3343332
``Lions Commentary on Unix 6th Edition, with Source Code'', John Lions.

www.geocities.com/SiliconValley/7041/ref.html
A MUMPS portal page.

www.faqs.org/faqs/m-technology-faq/part1
www.faqs.org/faqs/m-technology-faq/part2

www.vmth.ucdavis.edu/m/m_faq1.htm
www.mcenter.com/mtrc/mfaqhtm1.html
MUMPS FAQ pages.

http://forth.gsfc.nasa.gov
``Space-Related Applications of Forth'', a NASA summary page.

File Archive

My Contact Info