email article printer friendly more resources

Evaluate Open Source Risks
Open source software can help your organization maintain costs and provide functionality commercial vendors don't offer. Assess the benefits and risks to decide if it's the best choice for you.
by Thomas Murphy

October 2002 Issue

Thomas Murphy

With the ever-increasing amount of concern for software security, corporations have begun to focus on the safety of open source software. When your organization chooses to use application software third parties have developed, the decision comes with inherent, but recognized, risks, such as copyrights and patents, liability, security, and quality. Using commercial software provides a certain sense of safety because the vendor assigns specific rights, defines legal limits, and provides a named commercial entity that theoretically stands behind the code. When it comes to open source software, however, the picture becomes murky. In this article, I'll talk about how you can evaluate and manage risks associated with various forms of open source software and how it compares with commercial software. I'll also touch on the software tools you can use to evaluate third-party software.

Developers can choose from several forms of third-party software, including commercial components and frameworks, organized open source software (such as Apache), vendor examples and blueprints, magazine articles, community sites (such as gotdotnet.com), newsgroup examples, and books. The Internet has greatly increased the availability of this software and, while this provides many options, you should consider each form individually to assess the risks and value associated with the code. Because open source use is destined to become virtually unavoidable (especially in the Java market where several vendors already build from open source foundations) it's important to create a set of policies for your developers around code acceptance and use.

Set Your Policy
Start by defining the source of the code. For example, developers might get code from a magazine example, vendor's Web site, open source organization, vendor-published open source, or an ad hoc project. Each source will have specific published copyrights and license agreements. Your legal department should review all licenses before you authorize the use of the software or code. Each of the major open source bodies (Sun's Netbeans.org, IBM's Eclipse.org, Free Software Foundation, and Apache) has different twists to the license verbiage that should be understood. This is also important for software that's published online as examples, such as the Java Blue Prints, or on Microsoft's new .NET Architecture site (see Resources). You must understand what rights have been assigned to you. When you acquire software, reviewing contracts and licenses from a legal standpoint is probably part of the acquisition, and your company budgets for this process. You'll need to budget for expenses you'll incur when you review the legal verbiage for open source software as well. However, when you accept specific types of source software, for instance all that's distributed under the Apache license, you limit the reoccurring cost for each new package from a site.

Beyond understanding the rights and permissions for a package, you need to define policies for several other forms of risk. You should know whether a license can be revoked. You should also determine if someone maintains ultimate ownership and liability for the source. When you acquire software from a commercial vendor, a company is behind the product, and can provide support and take responsibility if a problem should arise. This is especially important in the case of liability. If you build an application on top of open source and the software has a problem, who is liable? Companies looking at open source often fear that source packages without a backing means the company takes on the liability. However, even commercial software license agreements typically limit the vendor's liability, especially when it comes to life-critical systems.

Once you've reviewed licensing issues, focus on two other primary issues: reliability and security. Reliability is often cited as one of the benefits of open source. Because you have access to the source and you can attempt to debug and fix problems with the application, you have greater control of the product. This is where the costs of open source appear. Although the product itself might be free, you'll undertake the expense of release management and support. Costs vary depending on the type of open source.

Interesting, in many cases, open source is the foundation of a commercial product. For instance, Sun uses its open source Netbeans IDE to create its commercial Sun ONE Developer product, and several vendors use Apache as the underlying Web server for their Java application server. In this case, you use the software as you would any other commercial product. You buy a specific product version and the vendor handles release management and support. Generally, however, you've also lost the capability to debug the code, because the vendor has proprietary versions it doesn't release as part of the open source. In all cases, the question is the same: Does the software provide value greater than its total costs?