Introduction To Open Source

What is open source? Back in 1997, Bruce Perens, a prominent Linux operating system developer, wrote a document concerning the distribution and development of the Debian Linux distribution. He later removed references to Debian and created what is now known as The Open Source Definition. Among other things, the Definition states that open source software must be distributed without royalty, that the distributor must make the source code for the software freely available, and the derivative works from the code must also be released as open source. Open source is essentially a cousin of the Free Software Movement, created in 1983 by Richard Stallman to promote the free distribution of software unfettered by standard proprietary code restrictions. Free software's rules are codified by the General Public License (GPL), which as of October 2006 was under review for its third revision. There are literally dozens of Open Source Initiative certified licenses, each with its own peculiar rules that require close examination by any company looking to use open-source software. These rules are usually quite generous for anyone who merely wishes to use open source software. The requirements for redistribution, however, can require careful scrutiny to avoid potential license violation issues. Why use open source? The first reason many companies begin looking at open-source software is simple: price. And the return on investment of the open-source model has been clearly demonstrated. Open-source software can be downloaded, installed and operated free of charge. In its early days, this low cost made it a tempting option for developers interested in trying new tools or building new applications but without the budget to do so. This freedom led many developers to start contributing to the open-source movement, resulting in such industrial-grade software as the Linux operating system, Apache Web server, JBoss Java application server and Eclipse development environment—among thousands of other projects. It wasn't until the late 1990s, however, that corporations began noticing open source at the executive level. With developers touting the quality and cost savings of using open source, and with IT budgets under constant pressure, many large companies began investigating open source for enterprise projects. Early large-scale adopters included The Weather Channel, Cendant Travel, and Employease and Sabre. Especially during the heavy growth of the Internet, open source let companies quickly ramp up their online operations without the need to constantly buy new licenses for commercial software. This scalability also lent itself to development and test environments, reducing the cost to simply try new things without the added drag of commercial software pricing—and the mandatory budgetary process—getting in the way. Perhaps not surprisingly, the fact that the source code is available for open-source products is usually not a big draw. While having the right to modify or fix code at will is certainly seen as a plus, many companies

find that they'd rather not get into the habit of maintaining the code themselves, instead depending on the community of developers that exists around popular products to keep the code up to date and debugged. Why not to use open source The arguments against open source generally boil down to a handful.

1. The software is free as in "free puppy." You can download and install it for free, but training users on it and maintaining it can ultimately cost more than the overall cost of commercial software, or so the argument goes. This claim, trumpeted perhaps most loudly by Microsoft, does carry some intuitive weight. Whether it's true or not depends on the specific situation and which analyst report you happen to be reading at the time.

2. Support can be hard to come by. In the early days of open source, when development and support were handled primarily by groups of volunteers or "communities," this could be an issue. But while many organizations find that community support is sufficient for their needs, today there are numerous support options available, including support for major open-source projects from the likes of Hewlett-Packard and IBM, giving corporations the much-valued "one throat to choke" should something go wrong.

3. Development of new features takes longer than with commercial software. This depends largely on the type of software you're using. The Firefox Web browser, for instance, is touted as a first-rate example of the speed at which open source can adapt to user needs. Linux's past history of coming in well behind Windows to support technologies such as USB ports demonstrates the other extreme. For enterprise-class software, however, such slavish attachment to the latest and greatest video card or sound chip is likely not as critical as stability and performance.

4. The legal ramifications are uncertain. The variety of open-source licenses and the fact that open-source code is often contributed by end users of the products would seem to make it a scary proposition for use in corporations. But a careful review of open-source licenses with your corporate legal representation can alleviate many of the fears. Some open-source vendors and third parties also offer indemnification against damages, should open-source code you use become embroiled in a lawsuit.

How should I get started with open source? Today, nearly every sort of business software product, from e-mail servers to ERP tools to voice over IP, are available as open source. But many companies begin using open source on the Web side of their business, where a number of industrial-strength, long-used applications exist. These tools are commonly referred to as the LAMP stack (standing for Linux, Apache, MySQL and PHP—or Perl or Python, depending on the situation.) Linux is a well-regarded, widely used Unix-like operating system. Apache is the most popular Web server in use today. MySQL is a database product that competes favorably with expensive commercial tools. And PHP, Perl and Python are programming or scripting languages commonly used for open-source Web development. Java-based open-source websites also often use the JBoss Java application server. Once you become familiar with using open-source tools and the differences—and similarities—between them and commercial products, you'll likely find other opportunities. You may also be surprised to find that your developers have been using open source under the radar for some time.

Server apps are fine, but what about open source on the desktop? End users frequently find use for open-source desktop tools, such as Mozilla Firefox's Web browser. Sun's OpenOffice office productivity suite has even found favor with some corporations and government organizations as a replacement for Microsoft's Office. But while some organizations have taken the plunge and moved to open-source operating systems such as Linux on their desktops, Windows continues to dominate the space. End-user-friendly versions of Linux such as LinSpire have failed to break the Microsoft hold on the PC, often because of concerns over end-user training time and costs as well as the fact that most commercial software packages—upon which many companies depend —are developed for Windows first and Linux later, if at all.

Can I sell open source-based products? Yes, of course, but as the Open Source Initiative points out: "What you can't do is stop someone else from selling your code as well." But many companies have found ways to make money with opensource code. Some wrap services around the code, providing enterprise-level support options that corporations are more than happy to buy. Others maintain two versions of their code: one that's open source, and another, more advanced version that includes proprietary add-ons for which customers must pay. This mixed model is becoming increasingly popular, with the likes of SourceFire, SugarCRM, Alfresco and others making use of the model.

Introduction Open source doesn't just mean access to the source code. The distribution terms of open-source software must comply with the following criteria:

1. Free Redistribution The license shall not restrict any party from selling or giving away the software as a component of an aggregate software distribution containing programs from several different sources. The license shall not require a royalty or other fee for such sale. Rationale: By constraining the license to require free redistribution, we eliminate the temptation to throw away many long-term gains in order to make a few short-term sales dollars. If we didn't do this, there would be lots of pressure for cooperators to defect.

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 wellpublicized 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. Rationale: We require access to un-obfuscated source code because you can't evolve programs without modifying them. Since our purpose is to make evolution easy, we require that modification be made easy.

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. Rationale: The mere ability to read source isn't enough to support independent peer review and rapid evolutionary selection. For rapid evolution to happen, people need to be able to experiment with and redistribute modifications.

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. Rationale: Encouraging lots of improvement is a good thing, but users have a right to know who is responsible for the software they are using. Authors and maintainers have reciprocal right to know what they're being asked to support and protect their reputations.

Accordingly, an open-source license must guarantee that source be readily available, but may require that it be distributed as pristine base sources plus patches. In this way, "unofficial" changes can be made available but readily distinguished from the base source.

5. No Discrimination Against Persons or Groups The license must not discriminate against any person or group of persons. Rationale: In order to get the maximum benefit from the process, the maximum diversity of persons and groups should be equally eligible to contribute to open sources. Therefore we forbid any opensource license from locking anybody out of the process.

Some countries, including the United States, have export restrictions for certain types of software. An

OSD-conformant license may warn licensees of applicable restrictions and remind them that they are obliged to obey the law; however, it may not incorporate such restrictions itself.

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. Rationale: The major intention of this clause is to prohibit license traps that prevent open source from being used commercially. We want commercial users to join our community, not feel excluded from it.

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. Rationale: This clause is intended to forbid closing up software by indirect means such as requiring a non-disclosure agreement.

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. Rationale: This clause forecloses yet another class of license traps.

9. License Must Not Restrict 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. Rationale: Distributors of open-source software have the right to make their own choices about their own software.

Yes, the GPL is conformant with this requirement. Software linked with GPLed libraries only inherits the GPL if it forms a single work, not any software with which they are merely distributed.

10. License Must Be Technology-Neutral No provision of the license may be predicated on any individual technology or style of interface. Rationale: This provision is aimed specifically at licenses which require an explicit gesture of assent in order to establish a contract between licensor and licensee. Provisions mandating so-called "clickwrap" may conflict with important methods of software distribution such as FTP download, CD-ROM anthologies, and web mirroring; such provisions may also hinder code re-use. Conformant licenses must allow for the possibility that (a) redistribution of the software will take place over non-Web channels that do not support click-wrapping of the download, and that (b) the covered code (or reused portions of covered code) may run in a non-GUI environment that cannot support popup dialogues.