Michael Overly. Optimize. January 2004.
Despite the popularity of open-source software, chances are you don’t know how widely this software has penetrated your company-and you likely aren’t aware of the substantial risks involved. Perhaps the issue doesn’t seem like a big problem. By its very nature, open-source software is supposed to be freely available, modifiable, and shareable.
Think again. In March 2003, the SCO Group filed a $1 billion lawsuit against IBM, claiming that Big Blue infringed its intellectual-property rights in Linux, the most popular open-source operating system. Last month, a federal judge gave the SCO Group until Jan. 23 to produce evidence supporting its claim against IBM. As part of this battle, SCO is threatening direct litigation against users of Linux. What’s worse, the SCO lawsuit likely represents just the beginning of potential litigation involving open-source software.
In other words, you should be very concerned about the spread of open source, including Linux, in your company as it may expose your business to considerable risks. Your company could become an unwitting victim to the fallout of the SCO/IBM intellectual-property dispute. This risk is exacerbated by the nature of the open-source culture, which freely modifies and distributes the software but without standard warranties, indemnities, and other contractual protections. And in another twist, numerous commercial applications come with embedded open-source software. However, the vendor often hasn’t notified the licensee that open-source programs are part of its commercial application.
Companies, therefore, should act immediately to limit and manage their risk. They must put in place rigorous managerial controls to regulate the use of open-source software by their personnel. In addition, they should make a vigorous effort to identify the open-source code embedded in the commercial software they buy.
To limit the risk, your company should adopt a best-practices approach comprising three basic steps: Implement appropriate management controls regarding use of open source; educate employees about the unique aspects of open source; and enforce compliance with these controls and policies.
The management process begins with an inventory of all open-source applications installed on your systems. Why? Each open-source application is subject to its own license terms and conditions. In many cases, businesses have never reviewed these terms and conditions or even received a copy of them. Failure to comply with applicable license agreements may result in liability for breach of contract and exposure for infringement of the licensor’s intellectual-property rights. In addition, a complete inventory simplifies the task of updating your software to include recent bug fixes, including security patches, and new software releases. Though time-consuming, a thorough inventory of open-source applications must be conducted for every open-source program.
Once the open source has been fully cataloged, personnel should be required to justify each new use of open-source software. The company should develop a questionnaire for each new application or any material change in the use of an existing application. The employee should clearly articulate:
- How the open-source software will be used, including whether it will be used in a critical business function, modified, and/or distributed to others.
- The specific license terms governing use of the application.
- Whether any traditional commercial-software alternatives are available.
With this information, legal counsel can evaluate the risks posed by the proposed use, and business owners can assess whether the intended use is appropriate for software provided “as-is”-that is, without warranties or other common contractual protections. This question becomes central when a company relies on an open-source application to provide a critical function. The business owners must balance the benefits of using an open-source application against the lack of any contractual protections.
As a final management control, companies should adopt guidelines for the installation and use of open-source software. These procedures typically grow out of the information obtained from the inventory and questionnaire. At the least, a company’s open-source policy should educate employees about the unique aspects of open-source software and identify the following:
- Personnel authorized to approve the licensing of open-source software. Since use of open source raises unique legal and business issues, the range of personnel who can approve licensing of open source is generally narrower than those who can approve more traditional applications.
- Personnel who will have access to the source code for open-source software. Vendors usually provide source code with open-source applications, but that doesn’t mean every user should have access to it. Remember, modification and distribution of the source code may have significant legal and business implications. So, most businesses limit source-code access to only those employees with a specific need.
- The circumstances under which open source may be modified. Modifications to open source may need to be licensed to others. That’s why companies usually put strict controls in place so that modifications occur only in a supervised and controlled environment. Business owners and legal counsel should specifically review and approve those controls.
Educating Employees
Employee education may be the most important tool for gaining control over open-source software. Training shouldn’t bias employees against the use of open source, but should give them an appreciation for the business and legal risks posed by this type of software. Most employees and many managers continue to view open source as free software with no strings attached-a virtual free lunch. CIOs must be educated on the potential threats to intellectual-property ownership, the lack of contractual remedies, and the support issues that can arise. Brief educational sessions followed by periodic memoranda can increase employee awareness of open-source risks.
Your overall program should establish an enforcement mechanism. From time to time, employee use of open source must be reviewed to ensure that it comports with company policy and applicable license restrictions. Companies also should check that use of the software hasn’t changed over time-that the original business and legal analysis permitting its use remains valid. Company policy, for example, may limit source-code access to those programmers specifically authorized to modify the application. As part of their policing activities, compliance personnel, such as a chief compliance officer or CFO, may identify instances in which unauthorized employees were given access to source code. Similarly these CXOs should review the activity of authorized developers to be sure their modifications conform to company guidelines.
Hidden Risks
Even after you’ve instituted rigorous controls and policies to limit and manage the risks of open-source software, you’re not out of the woods. You face a second thorny problem: how to identify and deal with open-source software embedded in commercial software. This issue may prove even more challenging because controlling a third party’s actions and disclosures is very difficult.
Consider the real-world example of a bank that’s licensing a new back-office processing system. The license fees exceed several million dollars, with substantial yearly support and maintenance fees. The bank will use the software, in part, to process customer-account information.
The vendor’s license agreement and documentation make no mention of any third-party software, let alone open-source software. The bank understands the potential problems that may arise if third-party software is embedded in or provided with the vendor’s application. The presence of such software may mean that additional license fees must be paid to the relevant third-party vendors, and additional, potentially more restrictive license terms and conditions may pertain to the third-party applications.
The issue of support further complicates the situation. If something goes wrong with the system, the licensee may have to mediate between the primary vendor and the various third-party vendors to determine whose software is at fault. For these reasons, the CIO wisely requests that the vendor provide a clear warranty that its application contains no third-party software.
In response, the vendor sends a list of several dozen open-source applications embedded in its software. The text file supplied with the software containing these licenses is nearly 200 pages in length. Though no additional license fees must be paid for these open-source applications, the presence of the open-source software in such a critical system raises a number of substantial questions:
- Who’s responsible for supporting the opensource components of the overall application?
- If a failure occurs, will the vendor of the commercial application be the single point of contact for resolving the problem? Are updates to open-source components included in the overall support fee for the commercial application?
- Who will implement these components?
- What if the open-source vendor ceases to support its software?
- What quality-assurance and other assessments have been done to determine the reliability stability and security of the open-source components? Are the components -well-known and widely used, and therefore generally accepted as reliable? Or have they had little scrutiny by the user community? Even if the open-source components have been adequately tested, who’s responsible in the event of a major failure? If the bank pays millions of dollars for an application that malfunctions because of a failure in an open-source component, what remedies will the bank have? The open-source developer probably doesn’t have deep pockets, and the license from that developer will disclaim all liability and warranties, so the bank would have little recourse against the developer of the open-source component. This raises the question of whether the primary vendor will assume responsibility for a failure of one of the open-source components. Because the vendor made the original decision to incorporate the open-source component and saved the cost of developing the programming in-house, one could argue that it should assume responsibility for a failure.
- Suppose the bank is sued by a third party claiming that one of the open-source components in the overall application is infringing a patent or copyright. Suppose a court enjoins the bank from continuing to use the application because it’s infringing. What then happens to its multimillion-dollar investment?
The answers to these questions often turn on the size of the transaction, the motivation of the vendor, and the sophistication and persistence of the licensee in demanding adequate protections from the vendor. Not surprisingly a vendor will more often assume responsibility for open-source components in its software in larger transactions involving substantial fees.
Unfortunately most commercial vendors simply remain silent about the extent, or even the mere presence, of open-source components in their applications-even when asked. Yet it’s common to find large, commercial applications with dozens of opensource components.
The inclusion of these components can be viewed as a “win-win” for everyone. The software vendor can save the expense of using its own limited resources to develop the software, perhaps even passing those savings to the licensee. In addition, the use of certain open-source components may increase the overall interoperability of the application because the opensource components tend to be standardized.
But it’s essential that the application vendor clearly identify any open-source software to the licensee. Ideally, a company should open a dialogue with a vendor on this issue and request a “no open source” warranty. That is, the licensee should request that the license agreement include a warranty that clearly states the licensed software will contain no open-source code. In many cases, simply requesting this warranty will force the vendor to disclose the presence of one or more open-source applications.
Once the open-source components are revealed, the licensee can evaluate how to proceed. This evaluation will likely include asking the vendor the type of questions posed in the example above. In some instances, the number of open-source components disclosed may prompt the licensee to question the fees the vendor is charging. If the application being licensed is essentially a framework for numerous open-source components, what work has the vendor really performed and are the fees reasonable?
If the identification process reveals the presence of open-source components in the software, the licensee should next determine the extent to which the vendor will assume responsibility for the performance and support of those components. The bigger the transaction and the more critical the application, the more important that responsibility becomes. It’s one thing to require the purchaser of an inexpensive, off-the-shelf application to accept the risk posed by an open-source component or two. It’s quite another thing to expect the licensee of a critical information system to accept any of the substantial risks. In such instances, the licensee must insist on specific contractual protections to ensure that the open-source components are included within all of the vendor’s responsibilities under the license agreement. The most important of these contractual protections are highlighted in the following checklist:
- A warranty that all items of open source have been specifically identified in an exhibit and copies of all relevant licenses are attached to the exhibit.
- A warranty that the licensor has all rights necessary to distribute the open-source software or to include modified portions of the software in its products.
- A guarantee that the vendor will support the open-source software to the same extent as the licensed software.
- A guarantee that the open-source software will be treated as if it is licensed software. In particular, the terms and conditions of the applicable open-source licenses shouldn’t materially impact the licensee’s use of the overall application.
At first, managing open-source software within a company may appear to be overwhelming. But it’s really not. After an initial inventory, companies can use management controls to keep their use of open source in check. In addition, they should always press commercial vendors to reveal their use of open source and take responsibility for it. In this way, businesses will take a significant step toward mitigating the open-source risks.