The open source software movement traces its history to the formation of the Free Software Foundation ("FSF") in 1983. The FSF was formed with the goal of creating a free version of the UNIX operating system. The FSF released a series of programs in source code form under "GNU" name ("GNU" is an irreverent acronym that stands for Gnu’s Not Unix). The GNU project did not actually result in a free version of UNIX, but did result in the creation of some popular tools for UNIX programmers, including the GNU C compiler and text editor. It also set the stage for even more ambitious free software development projects in the 1990s.

The license agreement that accompanied the GNU software -- known as the General Public License ("GPL") or "copyleft" license -- was revolutionary for its time. It is written in a non-legalistic style with a breezy preamble and statement of purpose. The GPL gives licensees broad rights to sell, copy and modify licensed programs, so long as licensees grant to downstream licensees the same rights to sell, copy and modify the modifications to the original program. Licensees are also required to make their changes available in source code form.

For many years, the FSF filled a relatively small niche in a large and growing market for proprietary products from large companies. Many UNIX programmers used -- and continue to use -- the GNU C compiler and debugger from the FSF to create new programs targeting variants of the UNIX operating system offered by companies like IBM, Hewlett-Packard and Sun.

With the Internet’s rise in the 1990s, there has been renewed interest in free software and a shift in development resources from esoteric development tools to products and technologies having a broader commercial appeal. In 1998, a group associated with free software introduced the term "open source" to emphasize a break with the pro-hacker, anti-business past associated with GNU and other free software projects and to place a new emphasis in the community on the possibilities of extending the free software model to the commercial world. These new "open source" projects would exist in the mainstream of the commercial software market and include operating systems, such as Linux, the Apache web server, and the Mozilla browser.

The meaning of "open source" is very much in flux. According to opensource.org, an oversight organization for the open source movement, theterm "open source" doesn't just mean that licensees have access to the source code. The distribution terms of open-source software must comply with the following criteria:

1. Free Redistribution. The license may not restrict any party from selling or giving away the software as a component or an aggregate software distribution containing several programs from several sources. The license may not require a royalty or other fee for such sale.

2. Source Code. The program must include source code, and must allow distribution in source code as well as compiled form. Where some form of a product is not distributed with source code, there must be a well-publicized means of obtaining the source code for no more than a reasonable reproduction cost -- preferably, downloading via the Internet without charge. The source code must be the preferred form in which a programmer would modify the program. Deliberately obfuscated source code is not allowed. Intermediate forms such as the output of a preprocessor or translator are not allowed.

3. Derived Works. The license must allow modifications and derived works, and must allow them to be distributed under the same terms as the license of the original software

4. Integrity of The Author's Source Code. The license may restrict source-code from being distributed in modified form only if the license allows the distribution of "patch files" with the source code for the purpose of modifying the program at build time. The license must explicitly permit distribution of software built from modified source code. The license may require derived works to carry a different name or version number from the original software.

5. No Discrimination Against Persons or Groups. The license must not discriminate against any person or group of persons.

6. No Discrimination Against Fields of Endeavor. The license must not restrict anyone from making use of the program in a specific field of endeavor. For example, it may not restrict the program from being used in a business, or from being used for genetic research.

7. Distribution of License. The rights attached to the program must apply to all to whom the program is redistributed without the need for execution of an additional license by those parties.

8. License Must Not Be Specific to a Product. The rights attached to the program must not depend on the program's being part of a particular software distribution. If the program is extracted from that distribution and used or distributed within the terms of the program's license, all parties to whom the program is redistributed should have the same rights as those that are granted in conjunction with the original software distribution.

9. License Must Not Contaminate Other Software. The license must not place restrictions on other software that is distributed along with the licensed software. For example, the license must not insist that all other programs distributed on the same medium must be open-source software.

Source: www.opensource.org

As the open source movement has gained credibility in the marketplace, however, the term has been applied to many projects that do not fit within the foregoing parameters. For instance, Sun Microsystems has introduced a "Community Source License Agreement" that is an attempt to capture some of the spirit and momentum behind open source initiatives, but contains significant restrictions that make it substantially different from the "classic" open source licenses such as the GPL and BSD-style licenses. The Sun license in some instances requires the licensee to pay Sun a fee; it also contains restrictions on modifications that do not pass a large set of conformance tests, and purports to treat the source code as "confidential information," even though it is available for download from the Internet.

The application of the term "open source" to projects licensed under proprietary models, such as the Sun Community Source License, could help lead to reducing the term "open source" to a marketing gimmick and to confusing developers about the rights associated with various programs available under the "open source" banner. Software developers must ensure their lawyers have an opportunity to review the license agreements associated with "open source" programs before they download and use these programs in their own projects, and that their lawyers carefully review the licenses that accompany programs billed as "open source" software to ensure the licensing and other contractual restrictions are consistent with the expectations, goals and risk tolerances of individual clients.

There are many reasons why the "open source" model has been successful and popular with developers, including the following:

• Access to Source Code. Documentation for commercial software products is notoriously skimpy on detail and often out-of-date. This is frustrating for developers who try to write software programs that are designed to interoperate with or target other programs. The best documentation for a program is the source code itself. Having access to source code enables the developer to understand the program at a deep level and to debug and optimize his or her own program at a level of efficiency and skill that is often not possible with programs available only in binary form.

• Community. Having a common source code pool and the tools provided by the Internet creates an opportunity for extensive and speedy collaboration on development projects.

• Cost. Most programs distributed as "open source" are free. Obviously, this is a compelling alternative to programs that cost money if the free program is equally feature rich and meets requisite performance parameters.

• Broad Rights. The broad license grant, which allows licensees to use, modify and redistribute open source programs, is a major advantage of the typical open source license. Typical commercial software products are distributed only in binary form and may not be modified. Often the documentation associated with commercial programs is not detailed enough to permit some kinds of "value added" programming that is possible for developers who have direct access to source code.

Along with the many benefits of open source, however, come a number of risks. Perhaps the most obvious risk is potential liability for intellectual property infringement. The typical open source project is a grass-roots effort that contains contributions from many people. This method of development can be worrisome from an intellectual property standpoint because it creates multiple opportunities for contributors to introduce infringing code and makes it almost impossible to audit the entire code base. The risks of this development process are largely borne by the licensees. Contributors do not vouch for the cleanliness of the code they contribute to the project; in fact, the opposite is true -- the standard open source license is designed to be very protective of the contributor. The typical license form does not include any intellectual property representations, warranties or indemnities in favor of the licensee; it contains a broad disclaimer of all warranties that benefits the licensor/contributors.

Even if such representations and warranties or indemnity obligations existed in open source license agreements, it would be difficult if not impossible to recover against the licensor for having licensed infringing code. Many of the most prominent open source projects appear to be owned by thinly-capitalized non-profit entities that do not have the financial wherewithal in most cases to answer for a massive intellectual property infringement suit.

The shifting of all risk for intellectual property infringement to the licensee is somewhat atypical for the commercial software world. Most for-profit software companies would require some level of contractual assurances from a licensor of software technology that such technology does not infringe intellectual property rights. By receiving such contractual assurances, the licensee shifts some or all of the risk of an intellectual property lawsuit onto the licensor, assuming of course the licensor’s capability to honor its obligations.

Open source licenses also do not contain the kinds of representations and warranties of quality or fitness for a particular purpose that commercial software vendors sometimes negotiate into agreements among themselves. Again, the process of developing open source software can contribute to problems in this area. Some open source software projects, such as the Linux initiative, have one or more stewards who monitor code quality and track bugs. Other initiatives, however, are really more the product of weekend and after-hours hobbyists and do not enjoy the same code quality and rigorous testing protocol. Without contractual commitments of quality or fitness, the licensee must accept the risk that the software contains fatal errors, viruses or other problems that may have downstream financial consequences.

Companies looking to build a business on open source software also need to consider the problems associated with creating derivative works. Some open source license forms, such as the GPL, require licensees to provide free copies of their derivative works in source code form for others to use, modify and redistribute in accordance with the terms of the license agreement for the unmodified program. This licensing term is advantageous for the free software community because it ensures that no for-profit company can "hijack" the code base from the community. On the other hand, this licensing term makes it very difficult for companies in the commercial software business to use such open source software as a foundation for a business. These companies must be concerned that their "value added" programs might some day be viewed as "derivative works" and need to be made available to the world in source code form for free.

While the copyright attribution and notice requirements in open source licenses are relatively innocuous as compared to the issues outlined above, they nevertheless can become burdensome for the commercial software vendor. Some open source projects have multiple contributors and modules that have been created under various licensing forms. According to the terms of most open source licenses, the licensee must give each of these contributors full copyright attribution and reproduce the entire text of the license agreements for the open source code included in the product. These notices and licenses can clutter up documentation files and confuse end user customers.

To state the obvious, open source software offers opportunities and disadvantages. The opportunities include having a vast pool of software talent with access to, and the ability to improve upon, open source software; and the ability to access and utilize software that could be of great use but whose acquisition might otherwise have been cost prohibitive.

The disadvantages include the risk of utilizing software that infringes intellectual property rights, and that may have problems not readily apparent. The terms of various open source licenses may pose other inherent problems that may not be apparent to those not skilled in the legal nuances of licenses.

Specific Licenses:

Traditional open source licenses

GNU GPL (copyleft)

Library GPL

MIT X Window license

BSD Style license

Commercial "open source" style licenses

Netscape Public License -- Mozilla

Sun Community Source

IBM Jikes

Opensource.org

Debian.org

Apache.org

Articles:

"Opening Up to Open Source", Shawn W. Potter, 6 Rich. J.L. & Tech. 24 (Spring 2000)

"How Copyleft Uses License Rights to Succeed in the Open Source Software Revolution and the Implications for Article 2B", Robert W. Gomulkiewicz, 36 Hous. L. Rev 179 (Spring 1999)