As the adoption of Linux and other open source software within corporations grows, enterprise IT managers should, using reasonable oversight, establish policies that allow open source to benefit the company. Open source may be free and not ordinarily expose a company to piracy claims, but open source usaage should not be ignored. For most companies it makes sense to establish policies and procedures for an employee's use of open source in order to minimize any legal and intellectual property risks.

In September 2003, Forrester Research delivered a report titled, "Your Open Source Strategy," with three general recommendations for companies deploying open source:

• Fund an open source advisory group to perform due diligence.
• Create policies to guide adoption and developer participation.
• Build a developer portal to track inventory and provide support.

For many companies, practical implementation of a compliance program should take into account a number of additional considerations. For instance, hardware and software vendors need to pay particular attention to open source incorporation in their products because the consequences of distributing open source can be so significant. They need to perform careful auditing of open source and establish strong controls. By comparison, because of the language in most open source licenses, the potential reciprocity and disclosure problems don't typically arise if a company is not distributing software, but merely using original open source for internal purposes.

Much of the business value of a hardware or software company depends on its intellectual property portfolio. Open source software can create some risks for a hardware or software company in areas of patents and copyrights. By comparison, a manufacturer of a soft drink may have an investment in trademarks and little other core intellectual property. Open source usage at this kind of company is not much of an issue. However, a hardware or software company that has created patents and copyrighted material should be diligent in making accurate and timely assessments of its open source use.

There is a number of reasons for this. First, if the modified open source software is publicly distributed at all, most open source licenses contain reciprocity clauses that require public disclosure of all source code modifications. As a result, a hardware or software company might be forced to disclose modifications to open source programs that the company had intended to keep confidential.

Second, the GPL and other licenses use broad language in appraising derivative works, and therefore have the potential to force the reciprocity provision mentioned above onto non-GPL software programs that may merely link to nonmodified GPL programs. In short, developers should be trained to consider the method of their planned implementations of open source software in order to properly avoid their work becoming subject to open source reciprocity or patent provisions.

Last, a recent example illustrates the potential complexity of the issues facing managers. In this instance, Broadcom, a producer of semiconductor solutions for broadband communications, contracted with an offshore third party to develop some software drivers for its communications products. These drivers were licensed to Linksys to be included in their wireless products. Cisco thereafter acquired Linksys for approximately $500 million and inherited the rights and obligations of the software incorporated in the Linksys products.

As explained by Eben Moglen, general counsel of the Free Software Foundation (FSF), in late 2002 and early 2003 the FSF started seeing a pattern of license violation reports concerning whole distribution. Because the whole distribution was predominantly GPL software, multiple potential copyright infringements and claimants existed. Upon investigation by the Free Software Foundation, it became apparent that multiple parties had received their free software from the same upstream supplier. The FSF followed the trail back to Broadcom, the chipset vendor for various OEM systems, including the Linksys product.

At this point the Free Software Foundation attempted an enforcement order requiring Cisco, which had acquired Linksys, to make public the open source code in question. Upon conducting post-acquisition due diligence, Cisco discovered GPL open source code in some of the drivers written by the offshore third party for Broadcom. After a number of weeks of negotiation, Cisco agreed to make the specific open source libraries publicly available on the Cisco Web site. Fortunately for Cisco, the intellectual property value of the open source code did not turn out to be significant. The experience nevertheless demonstrates a potentially serious situation that can occur when open source issues are not properly identified and managed.

The need for diligence isn't reserved just for hardware and software companies. All public companies and companies in many highly regulated industries also need to monitor open source adoption and use. Most managers understand the regulatory nature of their business as compared to other industries and should give some thought to the significance of open source.

For instance, financial institutions need to consider the "IT Examination Handbook" issued by FFIEC, which addresses operational and legal risk considerations in acquiring and using free and open source software (FOSS) with this introduction:

The agencies are of the opinion that the use of FOSS does not pose risks that are fundamentally different from risks presented by proprietary or self-developed software. However, the acquisition and use of FOSS necessitates implementation of unique risk management practices.

The FFIEC goes on to enumerate guidelines for the use of FOSS that financial institutions will need to carefully consider:

Similarly, privacy regulations related to HIPAA necessitate that companies in the health care industry monitor and control software implementation and functionality, including open source.

Under Sarbanes-Oxley, public companies have higher regulatory burdens than private companies. In particular, they must provide financial reporting transparency, which in most cases is directly related to any software implementation. As an example, reliance on undocumented spreadsheets can complicate the requirement of transparency under Sarbanes-Oxley, creating an unacceptable degree of risk in financial reports.

A company with concerns about open source usage should first determine the extent that open source software exists in the company. In today's Internet-connected corporate environment, it's hard to imagine any large company that doesn't have open source software somewhere on its computers. Accurately assessing the extent of open source in-house usually requires the help of professionals specializing in internal software audits. Interviews are the most effective audit method when performed by individuals with experience.

A white paper from Olliance Group describes a number of best practices based on the experiences of major companies such as Charles Schwab, Hewlett-Packard, and Microsoft. According to Andrew Aitken, one of the authors, such an open source compliance program may include the following:

• Procedures for efficiently and effectively auditing existing open source usage
• Establishing robust yet flexible developer policies for future open source usage
• Applying operating strategies to avoid potential open source licensing violations
• Setting policies for engaging with the open source community
• Clarifying roles and responsibilities for open source program management
• Developing a real-time open source tracking and usage database, preferably online
• Educating and training employees on open source usage and policies

Being proactive about open source compliance can reduce the risk of litigation, increase a company's valuation, remove intellectual property impediments, and facilitate business with customers. Open source is here to stay. It's time to have policies in place that deal with it.