"Software comes from heaven when you have good hardware."
Ken Olsen, founder of DEC
There are many reasons, not all necessarily altruistic, for the popularity of Open Source Software (OSS). This article provides an overview of software and licensing, and suggests usage examples for two well-known open source licenses: the GPL and BSD. This article does not discuss recent GPLv3 developments and reflects my own experiences, not necessarily those of my employer.
Origins of Software Licensing
Long before the term open source was used, software was developed by loose associations of programmers and freely exchanged. Starting in the mid 1950's, volunteer user organizations such as SHARE and DECUS developed much of the software that companies bundled with the hardware they sold. Anything that reduced software cost and made more programs available made these hardware companies more competitive.
Things changed in the 1960's. In 1965, ADR developed the first licensed software product independent of a hardware company. ADR, competing against a free IBM package originally developed by IBM customers, patented their software in 1968. To stop sharing of their program, they provided it under an equipment lease in which payment was spread over the lifetime of the product. ADR thus retained ownership and could control resale and reuse.
In 1969 the US Department of Justice charged IBM with destroying businesses by bundling free software with IBM hardware. As a result of this suit, IBM unbundled its software and software became independent products separate from hardware. In 1968 Informatics introduced the Mark IV, the first software product to have cumulative sales of 10 million USD. This rapidly established the concept of software as a product, the independent software company, and high rates of return for software. Informatics developed the perpetual license which is now standard throughout the computer industry, wherein ownership is never transferred to the customer.
Origins of the BSD and GPL Licenses
Marshall Kirk McKusick describes the evolution of the Berkeley Software Distribution (BSD) license in "Twenty Years of Berkeley Unix". In summary, the license was intended to allow liberal modification and redistribution terms for Berkeley Unix code. The license required that the source identify the University of California Berkeley (UCB) as copyright holder, that derived products advertise that they were based on UCB code, and that the UCB not be held liable for any damages resulting from the code.
The new BSD license was created in 1999 by the University of California, in response to a request by Richard Stallman to remove the advertising clause. The new BSD license is effectively a statement that the user can do anything with the program or its source, but without warranty and none of the authors has any liability; in other words, the user cannot sue anybody. The license must be kept with the source code, assuring accurate attribution.
In the late 1980s, Richard Stallman became upset when he could not legally add minor improvements to the proprietary system that had replaced the home-grown system at MIT. Also, many of Stallman's co-workers had left to form companies based on software developed at and licensed by MIT; there appears to have been disagreement over access to the source code for this software. Stallman devised an alternative to the commercial software license and called it the GPL, or General Public License. He also started a non-profit foundation, the Free Software Foundation (FSF) which intended to develop an entire operating system, including all associated software, that would not be subject to proprietary licensing.
The GPL was designed to be the antithesis of the standard proprietary license; it was intended to keep software from becoming proprietary. As the last paragraph of the GPL states: "This General Public License does not permit incorporating your program into proprietary programs".
Open Source Advantages
Open source enables the creation of competitive software that is widely available at the cost of media. Unlike proprietary software, it is not subject to orphaning. Orphaning occurs when a single business failure or change in product strategy causes a pyramid of dependent systems and companies to fail for reasons beyond their control. Decades of experience shows that the momentary size or success of a software company is no guarantee that their software will remain available, as current market conditions and strategies can change rapidly. Since open source development resembles development by an informal consortium, the development team is not dependent on the survival of a single company or product line. Open source licenses and open source projects are the easiest way to form informal consortiums with minimal cost of entry. Large companies, in which open source code is developed, should be aware that programmers appreciate open source because it leaves the software available to the employee when they change employers. Some companies encourage this behavior as an employment perk, especially when the software involved is not directly strategic. It is, in effect, a front-loaded retirement benefit with potential lost opportunity costs but no direct costs. Encouraging employees to work for peer acclaim outside the company is a cheap portable benefit a company can sometimes provide with near zero downside.
GPL: Advantages and Disadvantages
The GPL is a complex license. Here we present some valuable rules of thumb when using the GPL:
- you can charge as much as you want for distributing, supporting, or documenting the software, but you cannot sell the software itself
- if GPL source is required for a program to compile, the program must be under the GPL; linking statically to a GPL library requires a program to be under the GPL
- the GPL requires that any patents associated with GPLed software be licensed for everyone's free use
- simply aggregating software together, as when multiple programs are put on one disk, does not count as including GPLed programs in non-GPLed programs
- output of a program, such as the gcc compiler, does not count as a derivative work
- since the Linux kernel is under the GPL, any code statically linked with the Linux kernel must be GPLed; this requirement can be circumvented by dynamically linking loadable kernel modules, allowing companies to distribute binary drivers The GPL is a good choice for code that is intended to remain available to a group of researchers with no future plans for a proprietary fork. The GPL assumes that future scenarios to which a code-base is applicable are understood in advance. Where this becomes an issue, the copyright holder can dual-license the software under both the GPL and another license
The GPL is attractive to small companies selling CDs in an environment where "buy-low, sell-high" may still give the end-user an inexpensive product. It is also attractive to companies that expect to survive by providing various forms of technical support, including documentation, for the GPLed intellectual property world.
Those who expect primarily to use a system rather than program it or who do not expect to make a living from their work associated with the system find the GPL attractive as it forces code developed by others to be given to them and keeps their employer from retaining copyright and thus potentially orphaning the software. If you want to force your competitors to help you, the GPL is attractive.
For those who must work with statically-linked implementations of multiple software standards, the GPL minimizes the number of programs that can be built because it precludes using proprietary implementations of the standards. A true technical standard should not mandate exclusion of implementations of other standards for non-technical reasons.
The GPL attempts to make programmers contribute to an evolving suite of programs, then to compete in the distribution and support of this suite. This is unrealistic for many system standards, which may be applied in varying environments requiring commercial customization or integration with legacy standards under non-GPL licenses. A less publicized and unintended use of the GPL is that it is favourable to large companies that want to undercut software companies. In other words, the GPL is well suited for use as a marketing weapon, potentially reducing overall economic benefit and contributing to monopolistic behavior. Small companies that are targeted can readily be put out of business.
As intended, the GPL can present a real problem for those wishing to commercialize and profit from software as the GPL was designed to keep research results from transitioning to proprietary products. This step is often assumed to be the last step in the traditional technology transfer pipeline and it is usually difficult enough under the best of circumstances.
For example, the GPL adds to the difficulty a graduate student will have in directly forming a company to commercialize his research results. An assumption often encountered is that software has become a low-cost commodity; to have significant value it needs to be packaged into a device or a service. A student who has spent years developing a research program might not wish to consider it a commodity.
The GPL is an attempt to keep efforts, regardless of demand, at the research and development stages. This maximizes the benefits to researchers and developers, at an unknown cost to those who would benefit from wider distribution.
Use of a GPL code-base constantly raises commercialization and legal issues. Lawyers working with the GPL have described it as "essentially a full employment guarantee for intellectual property lawyers".
BSD: Advantages and Disadvantages
The BSD license is intended to encourage product commercialization. BSD-licensed code can be sold or included in proprietary products without restriction on future behavior. It is possible to use BSD-licensed code in GPL-licensed code, but the reverse is not the case. However, do not confuse the BSD license with "public domain"; while an item in the public domain is also free for all to use, it has no owner.
A BSD license is a good choice for long duration research projects that permit anyone to retain the option of commercializing with minimal legal issues. BSD licenses may be preferable for long-term government research intended to ultimately transfer research results throughput the economy in the most widely-deployed fashion possible.
In many cases, the long-term results of a BSD license more accurately reflect the goals proclaimed in the research charter of universities then what occurs when results are copyrighted or patented and subject to proprietary university licensing. Anecdotal evidence suggests that universities are financially better rewarded in the long run by releasing research results and then appealing to donations from commercially successful alumni who benefited from the released IP.
The question "why should we help our competitors or let them steal our work?" comes up often in relation to a BSD license. However, if one company came to dominate a product niche that others considered strategic, a mini-consortium aimed at reestablishing parity through a BSD-licensed variant would increase market competition and fairness. Each company believes it will profit from some advantage it can provide, while also contributing to economic flexibility and efficiency. Companies have long recognized the value of de facto standards as a key marketing technique. The BSD license serves this role well, if a company really has a unique advantage in evolving the system. There are times when the GPL may be appropriate for such a standard, especially when attempting to undermine or co-opt others. The GPL, however, penalizes the evolution of that standard, as it promotes a suite. Regardless of the license used, the resulting software will usually devolve to whoever actually makes the majority of the engineering changes and most understands the state of the system.
To minimize software engineering problems, such as mixing code under different licenses, BSD licenses should be encouraged. Being leery of the GPL should particularly be the case with non-profits that interact with the developing world. In locales where application of law becomes a costly exercise, the simplicity of the BSD license is of considerable advantage.
There are distinct advantages and disadvantages inherent in any license; this article outlined some usage scenarios for the GPL and BSD licenses. The GPL, while designed to prevent the proprietary commercialization of open source code, can still provide strategic advantage to a company. The BSD license, by placing minimal restrictions on future behavior, allows code to remain open source or become integrated into commercial solutions, as a project's or company's needs change.