Protecting Against Open Source Legal 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 open-source 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 open-source 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 open-source 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.

Michael Overly is a partner in the e-Business and Information Technology Group in the Los Angeles office of Foley & Lardner.