Canada: Focus on Technology, November 2006 - Sun Microsystems Shines New Light on Open Source Software: Effectively Managing the Risks of Using Open Source Software

Sun Microsystems Shines New Light on Open Source Software: Effectively Managing the Risks of Using Open Source Software

On November 13, 2006, Sun Microsystems ("Sun") announced that it would be releasing the source code of its implementations of Java technology as free software ¹ under the terms of the GNU General Public License (the "GPL") ². This phased release, which is scheduled to be completed in the first quarter of 2007, was referred to by Sun as "one of the largest source code contributions under the GPL license". With over 3.8 billion Java technology enabled devices, it also represents one of the most significant moves into the open source software model by a commercial enterprise.

The move by Sun is being hailed by many of the leading supporters of the open source movement as a "bold move". It also serves as an important reminder to organizations that develop and distribute software (either as a stand-alone product or embedded into hardware or other devices) of the increasing pervasiveness of open source software and the risks that are associated with its use.

Open Source Software

While most people involved in the technology industry are familiar with the concept of open source software, a brief overview is necessary for the uninitiated. Most commercially available software (for the purposes of this article referred to as "closed software") is only made available in machine readable form (commonly referred to as "object code"), pursuant to the terms and conditions of a software licence that permits only limited use of the software and prohibits the user from making modifications to the software, or reverse engineering the software to discover its source code. As a result, users of such software are dependent on the supplier for bug fixes and improvements to the software.

Under the open source model, the source code to the software is also made available to the end user. While some are under the mistaken belief that open source software can be used without restriction, software distributed under the open source model, as is the case with closed software, is distributed under the terms and conditions of a software licence. The terms of such open source licences, however, are generally more permissive than closed software licences, and include the right to modify, and redistribute, the source code to others.

The Risks of Open Source Software

Despite the benefit of having access to source code and being able to modify it, many companies have been reluctant to use open source software in their software development activities. This reluctance is due to several risk factors. These include: (i) uncertainty regarding the origins of the software and the reliability of the software programmers; (ii) concerns over potential intellectual property infringement, including patent infringement; (iii) lack of indemnification for infringement claims; (iv) the shifting of risk of errors, viruses, etc. to the licensee (i.e. no warranties); (v) the "viral" nature of some open source licences (e.g. GPL); (vi) the forking of code development; (vii) inadvertent granting of patent rights by distributing open source software; (viii) patent retaliation provisions in some open source licences; (ix) incompatibility of some open source licences with one another ³; (x) uncertainty regarding the interpretation and enforceability of some open source licences; and (xi) potential liability for damages and/or risk of an injunction if use of open source software does not comply with the terms of the applicable licence agreement.

One of the most discussed of the above referenced risk factors is the so-called "viral" nature of some open source licences, such as the GPL. Under the terms of the GPL, any modifications made to the source code which are distributed by the licensee, must also be made available in source code form. In addition, if a licensee wishes to distribute a work that includes or is derived or based on code licensed under the GPL ⁴, the licensee must distribute the entire work under the terms of the GPL, and must make the source code to the entire work available to its licensees. In the case of Sun's licensing of its Java implementations, it has added what is called the "Class path exception" to the terms applicable to some of its technology. This exception allows for linking code licensed under the Class path exception with closed software without triggering the "viral" effect of the GPL.

For companies that distribute their software under the traditional closed software model, using software licensed under the terms of the GPL (or similar licences) in the development of their closed software products can have unintended and disastrous consequences. By way of example, consider the following scenario:

John is a the Vice-President of sales for an up and coming technology company. In meeting with potential customers, John discovers that while they really like his company's product, it is missing a few features that are found in John's company's main competitor's product. John tells the President and the CTO of his company that sales will likely double if they can add the missing features into the next version of the product.

The request finds it way down to Bob, the beleaguered head of software development, who, already faced with a looming deadline must now find a way to include these features in the next version of the product. He hands the assignment to one of his developers who promptly begins searching the Internet for possible solutions. His developer discovers that there is a company that has developed code that offers the missing features. A licence to use and distribute such code, however, will cost $50,000, plus on-going royalties. In addition, only the object code is made available, and Bob's company will have to enter into an annual maintenance agreement with the supplier to receive bug fixes and new versions. The developer also discovers that a clever programmer from Sweden has developed similar code and has posted the source code on the Internet. Given that there is no budget to pay the licence fees requested by the first supplier, and there is no time to develop the code from scratch, Bob and his developer make what they decide is a "no-brainer" decision. They download the Swedish developer's code and incorporate it into their company's product.

The new version of the product is a success and sales for the company have sky-rocketed. With this success has come increased attention from several companies who express interest in purchasing the company. After reaching a tentative agreement on a purchase price with one of the company's suitors, the prospective buyer discovers some unsettling things during its due diligence review.

First, it discovers that the code licensed from the Swedish developer was licensed under the terms of the GPL. By including the GPL code in its closed software product, and licensing such product under the customary terms of a closed software licence, the company has violated the terms of the GPL. It also learns that the Swedish developer has been sending letters to other companies who have used his software reminding them of their obligations under the GPL, including making available the source code to works in which his code has been incorporated, and threatening to take legal action if they do not comply. The prospective purchaser's due diligence also reveals that the company has made representations and given warranties in its agreements with its large corporate customers that its software does not, and will not, include any third party code licensed under the terms of the GPL. Finally, the prospective purchaser discovers that the company's products include several other instances of open source code, much of which is licensed under the terms of different software licences, the terms of which appear to be incompatible.

Upon such discovery, the negotiations to purchase the company come to a grinding halt as the prospective purchaser indicates that it needs time to assess whether it wishes to proceed with the deal, and if so, what impact these discoveries will have on the purchase price.

As this example demonstrates, the risks associated with using open source software are not trivial.

Managing the Risks of Open Source Software

Despite the risks associated with using open source software, one cannot ignore its benefits. As a result, many organizations have made the decision to use selected open source software in their businesses. In electing to use open source software, however, it is important to implement a strict procedure for evaluating the merits and risks of using each particular item of open source code under consideration. While each organization will need to tailor such procedure to its own needs and structures, some of the common elements found in a typical open source software management procedure include the following:

(a) Open Source Committee

A committee to oversee the management of open source software use in the organization should be created. The committee should include technical, business and legal representation. The committee's purpose is to educate the company's personnel and institute controls over the use of open source software.

(b) Open Source Policy

One of the commonly used devices for educating personnel and controlling the use of open source software is the creation of an open source policy. The policy should educate personnel regarding the risks of using open source software, as well as set out the process for seeking approval to use open source software and the process for ensuring compliance with the policy.

(i) Approval Process

The approval process should be structured in manner that allows for an efficient assessment of each request to use open source software and that results in a well-reasoned "Yes" or "No" response. Again, the approval process should be tailored to the structure of the organization, but in creating an approval process, the following elements should be considered:

A. review of the supplier (e.g. Red Hat v.s. "guy in his basement");

B. search for known problems (e.g. Internet search for any known, or alleged, intellectual property infringement issues);

C. quality control standards - does assessing organization have minimum requirements for code quality, documentation, support, warranties or indemnities?;

D. identify intended use of open source software (e.g. internal use only, modification, combination with other code, redistribution);

E. identify any other sources of code which address problem, including potential for developing in-house; and

F. review of licence terms for open source code - is intended use permissible? Are there licence incompatibility issues? Is the license of the "viral" variety and how will the intended use affect other code developed or used by the organization? Does the licence included mandatory patent license or patent retaliation provisions? Identify compliance obligations.

(ii) Guidelines for Making Modifications

The open source policy should also include guidelines for making and approving modifications to open source software. Questions to be considered include: Will the organization be making modifications to the open source software? If so, are modifications for internal use only or for redistribution? If required by the licence terms, is the organization comfortable with releasing the source code to such modifications?

(iii) Contributions to the Open Source Community

The open source policy should prohibit contributions of the organization's source code to open source projects without approval. If the organization wishes to contribute code to the open source community a full analysis needs to be conducted, including ensuring that the organization has all necessary rights to disclose the source code to others and that the appropriate open source licence terms are chosen. The open source policy should also set out restrictions on an employee who wish to participate in an open source project that is unrelated to his job, including requiring prior disclosure of such participation, that he must not use the organization's resources and equipment in doing so, and that he must not identify his employer.

(iv) Compliance with Open Source Policy

A policy is only useful if it is diligently followed. As a result, it is important that the organization implement measures that allow it to track its adherence to its open source policy. One common method for tracking compliance is the performance of regular audits of software development projects (e.g. using automated auditing tools) for the presence of open source software and comparing the results to the approvals granted during the approval process.

(v) Licensing and M&A Transactions

As we have seen from the example above, it is possible for company executives to be unaware that open source software has been used in the development of its products. As a result, an organization's open source policy should set out the standard of due diligence it requires when licensing or acquiring technology from third parties, or considering an investment or acquisition of a company. At a minimum, the applicable transaction documents should include appropriate representations and warranties regarding the use of open source software (with appropriate carve-outs from any caps on liability). We have also found it useful to have the licensor or target company complete a short open source software questionnaire as part of the due diligence process so as to highlight the importance of the issue and focus attention not only on the use of open source software, but also to try to gain an understanding of the manner in which it is being used and under what licence terms.

Summary and Endnotes

As Sun's recent announcement illustrates, the use of the open source model to distribute software is increasing. While, in the past, open source software might have been dismissed by some as a fringe movement with which commercial software developers need not be concerned, open source software and the impact of its use on your organization can no longer be ignored. As shown above, remaining in the dark regarding the risks associated with the use of open source software can have disastrous consequences for your organization. Such risks, however, may be mitigated by gaining an understanding of open source software and creating appropriate policies and procedures for managing its use.