International In-house Counsel Journal Vol. 5, No. 20, Summer 2012, 1

Corporate Use of Open Source Software: Dispelling the Myths with a Policy

HEATHER E. MCNAY Senior Counsel, Landis+Gyr, USA

Abstract Many companies do not understand open source software and choose to avoid it completely instead of creating an informed policy. Avoiding the issue can lead to developers using open source software incorrectly and potentially exposing proprietary company intellectual property through mandated public disclosure. The legal department for every technology company needs to work with the software development group to create a comprehensive Open Source Policy. The policy should ensure that every piece of open source code that is used by the company is reviewed pursuant to a prescribed process. A good policy will require that the requesting developer list the planned use of the open source code and provide the name of the license covering the code, if known. The proposed use of the code is important because stand-alone, or separably compilable, applications will not trigger certain license’s obligations, such as the publication of source code. There are many distinct open source licenses being used today, each with very different terms. With knowledge of the use and the license, the legal department can investigate the license and make a recommendation based on whether it is a ‘viral license’ (requiring publication) or not. Then, together with the technical point of contact, an informed decision can be made about all source code used by the company. Organisations will discover that using open source software in controlled manner can provide actual cost savings without exposing the company to any risk.

Keywords: Open Source General Public License GPL Corporate Policy Software License

International In-house Counsel Journal ISSN 1754-0607 print/ISSN 1754-0607 online 2 Heather E. McNay

1.0 Introduction The prevalent myths about open source code diminish the common sense and legal education on the topic. Misunderstandings can prevent developers from using a useful, cost-saving tool. Worse still, misunderstandings can put a company at risk if open source code is used improperly. If your company develops or uses any software, it is likely that portions of that software are ‘open source’ code. Open source code is software that is free to use, and readily available on the Internet, but can be governed by very strict licensing terms. Understanding open source code and the accompanying licenses can be intimidating. There are still many companies around the world that do not fully understand open source and choose to avoid it completely. Unfortunately, having a policy prohibiting all open source code or having no policy at all can lead to software developers using open source software incorrectly and can even lead to charges of or to the losing of company intellectual property rights if release and publication of company source code is mandated. On the other extreme, there are companies that allow unmonitored use of open source software. Despite the myths about open source code, the truth is that many developers use it. Software developers are usually working on very tight schedules and know that widely used open source code is stable and well tested. However, the developers may not realize that such use can expose the company to risks. Therefore, each corporation must monitor the use, make educated decisions about the use and educate their employees on open source code and the various licenses. While open source code, being free, can reduce the costs of development and can provide stable, tested applications, the risks must be explored and weighed. Open source code does not come with warranties or indemnities, and can carry far-reaching license obligations. The solution is for every organization to have a concise Open Source Software Policy that sets forth a clear review process. Each potential use of open source software must be reviewed by a designated employee from the development or engineering department while an attorney identifies and evaluates the open source license governing the desired code. In addition, there must be an education initiative to teach the company’s employees about the policy, its processes and the basics of open source software licenses. 2.0 Open source code and licenses 2.1 Open source basics Open source software began as a movement to encourage the sharing of knowledge. In the U.S., the idea goes back to the creation of the Foundation, in 1985.1 This non-profit corporation was founded with noble goals; the basis being that use of the software code, regardless of copyright or patent coverage, must remain free for all to use. This movement is also sometimes called ‘’, as opposed to copyright, to designate freedom to copy. The established the most widely know open source license, General Public License (GPL) 2.0 (also known as the GNU™ License).2 The Free Software Foundation also had the goal to collect enough free software so that no one would ever have to use software that was not free.3

1 Free Software Foundation; www.fsf.org. 2 GNE General Public License V2.0; www..org/licenses/gpl-2.0.html. 3 Free Software Foundation. Open Source Software 3

The original label for the code governed by these licenses was ‘free software’. The term ‘open source software’ was coined in 1998 by the (OSI), another U.S. non-profit organisation.4 OSI chose the label ‘open source’ because they believed ‘free software’, being not necessarily ‘at no cost’, was confusing and discouraging business adoption.5 For example, the GPL 2.0 specifies that while the code is free, “you may charge a fee for the physical act of transferring a copy, and you may at your option offer warranty protection in exchange for a fee”.6 There are many myths about why not to use open source code, including: one cannot use open source software in a proprietary environment; all open source licenses require the release of all source code; and it is easiest to just reject all open source software. Myths on the other side include: open source licenses are not enforceable; no one will ever find out if you use open source software; and you are protected if your corporate policy says that you do not use open source software.7 However, as this paper will set forth, all of these are truly myths. The truth is somewhere in the middle. With proper analysis, a stable policy and education, any company can benefit from open source code and avoid the pitfalls. 2.2 Open source licenses Both commercially sold code and open source software are governed by the same types of laws in every country, contract law and intellectual property law. The myth that open source licenses are not enforceable is completely untrue. The user is bound by whatever license terms agreed to by the user, whether by written contract, ‘click- wrap’ or simply by use of the code. U.S. courts have consistently upheld open source licenses. For example, in the U.S. Federal Court of the Northern District of California, the Court held in Jacobson v. Katzer that open source licenses are enforceable under U.S. copyright laws.8 There are many different licenses governing open source code. The Open Source Initiative reviews open source licenses and lists approved licenses on their site.9 The most common open source licenses are: GNU General Public License (GPL) 2.010, GNU Lesser GPL (LGPL) 2.0/3.011, ™ Foundation License12, Common Public License (published by IBM™)13, (Apache Software Foundation)14 and BSD (Berkeley Software Distribution) License15

4 www.opensource.org. 5 www.fsf.org/licensing/essays/free-software-for-freedom.html. 6 GNU General Public License V2.0. 7 Copenhaver, Radcliffe, Vescuso; Introduction to Open Source Licenses; Black Duck Legal Webinar Series Presentation Materials/ http://www.blackducksoftware.com/media/_slides/LWS-Intro-Open-Source- Licensing.pdf ; June 2010. 8 Jacobsen v. Katzer, No. C 06-01905 (N.D. Cal. Dec. 10, 2009). 9 Open Source Initiative; www.opensource.org. 10 General Public License V2.0. 11 GNU Lesser General Public License; http://www.gnu.org/copyleft/lesser.html. 12 Mozilla License; www.mozilla.org/MPL. 13 Common Public License; www.opensource.org/licenses/cpl1.0. 14 Apache License; www.apache.org/licenses. 4 Heather E. McNay

Each open source license has slightly different terms, and some licenses are considered more onerous than others. One particularly invasive attribute is when the license is ‘viral’. The GPL is considered ‘viral’ because the license provisions travel with the code and apply to any and all modifications of the code and can even apply to neighbouring code dynamically linked or integrated to the modification. If a company uses an open source application covered by the GPL and then creates a modification of the code that is incorporated into the company’s product, the GPL license states that the obligations under the GPL license apply to the modification. Then, having the modification incorporated into the entire project, the GPL terms will apply to the entire software product. The resulting obligation is that the modification, and all related code, must be made public in the same manner as the original open source code.16 This could cause a company to lose a competitive advantage if all competitors had access to the source code previously held as a trade secret. There are limits to the viral aspects of the GPL if the open source code is kept separate and not integrated into proprietary code. For example ™17 is generally covered by GPL but applications running on Linux are not necessarily governed by the GPL unless they directly interact with GPL modules. The LGPL is basically the same as the GPL, but it specifically allows dynamic linking to proprietary code, meaning that dynamic linking will not trigger the viral obligations of publication and disclosure. The License and the Common Public License (as published by IBM) are considered ‘hereditary’ because while there is a flow-down of obligations, it is only vertical and only flows down to any modification, not to code that is linked to or hosting the open source code. The Apache and BSD licenses are considered more permissive and are classified as ‘non- viral’ because there are no publication or disclosure requirements due to modification or integration. Like the Apache license, these only require the preservation of the appropriate open source copyright notice and disclaimer. The majority of open source licenses, in particular the ones reviewed and approved by the Open Source Initiative, are basically fair and do not automatically mandate the disclosure of a company’s proprietary code. Very few of the common open source licenses are viral or even hereditary, and those obligations can be easily avoided if the open source code is kept separate from the company’s proprietary code. Therefore, to dispel two of the myths, use of open source does not necessarily demand a release of all source code, and a company can safely use open source code in a proprietary environment. There are risks to the use of open source software. For one, there are no risk-sharing provisions, such as warranties and indemnities. The GPL license for example specifically states that there are no warranties given.18 There is also no support for open source code; however, there are companies that have risen to fill that void. (Red Hat, Inc., for example, sells support for Linux open source products.19) Due to the fact that open source code is readily available on the Internet for anyone to download, a company cannot afford to ignore the potential risks associated with open source software. As with any code, one must also be careful to avoid open source software with security vulnerabilities. This is another reason that every company must strictly

15 BSD License; www.opensource.org/licenses/bsd-license.php. 16 GNU General Public License V2.0. 17 Linux Operating System; www.linux.org. 18 GNU General Public License V2.0. 19 Red Hat, Inc.; http://www.redhat.com/. Open Source Software 5 manage inventories of software components.20 Findings of vulnerabilities or flawed open source code are usually announced on the Internet, sometimes on the relevant license website. The company must be able to track open source code so it can be updated if flaws, fixes or new versions are announced.21 While all software has vulnerabilities, the risk is greater with open source than with other third party code due to the lack of warranties and indemnities.22 There are factors that mitigate the potential risks. Open source code is widely used and there is much community communication. The most common open source applications are well tested and virtually bug-free. In addition, the collaboration of developers from all over the globe creates very elegant solutions. When defects are found, they are quickly announced on the web. Then, the fixes are quickly published and tested. While not gaining monetarily, there appears to be great pride and bragging rights in having one’s version selected for inclusion on one of the respected open source websites.

3.0 Corporate Policy The safest approach is for every company to have a strict open source software review process set forth in a corporate policy. However, this cannot be a policy that is solely mandated by the legal department. The legal department must work closely with the company’s technical division to create the process, draft an Open Source Policy and enforce the provisions. The policy should ensure that every piece of third- party code that is used by the company is examined and approved before use. A good policy will have the requesting developer list the planned use of the code and the name of the license covering the code. The policy should clearly state the scope of the policy coverage, the generally allowable uses of open source code and an overview of the most common open source licenses. A company’s open source policy does not need to state that particular licenses are allowed. The uses of open source can be evaluated for approval by the technical and legal team on a case-by-case basis. However, it is a good idea to list the most common open source licenses and educate the employees of the risks involved. With the knowledge of the intended use of the code (i.e., whether it will be modified or integrated into proprietary code) and the terms of the governing license, the legal department can then investigate the license and make a recommendation to the technical lead. The easiest policy to manage is one that covers all software development in the company. However, some companies may choose to have a policy only apply to certain divisions. While a policy of ‘no open source’ has its risks, this could be the best solution for some industries. Some analysts are arguing that a closed software system (e.g., Apple™, Inc. only allows their own code on all products) is more reliable, and should be used in certain industries, such as electric car charging stations.23 If strictly managed, such a policy is a viable solution. However, developers may still use open source applications. This type of policy demands strict policing.

20 Rooney, Paula; Study: More Than 50% of Global 500 Use Vulnerable Open Source Components; http://www.zdnet.com/blog/open-source; 25 March 2012. 21 Id. 22 Id. 23 Tehrenbach, Kate; Why You Don’t Want Your Electric Car to be Open Source; www.gigaom.com/cleantech/why-you-dont-want-your-electric -car-to-be-open-source/; 12 April 2012. 6 Heather E. McNay

An Open Source Policy can also establish a catalogue of approved code, or even a repository for approved source code. This technique has not only been used by corporations, but many different organizations, including governments. Some countries have initiated programs to create and maintain a library of approved open source code for government employees to utilise. For example in Brazil in 2007, Brazil created a Public Software Portal (Portal do Software Publico Brasileiro). 24 This Portal is a central repository where all Brazilian government organisations can collaborate through shared open source software solutions. According to one report, Brazil had proven savings of approximately $3M from 2007 to 2009 by using the Portal.25 In addition to saving money, a central library can limit the number of new open source codes that need to be reviewed under a policy. The risk is that new versions of the code, that may be available on the Internet, may not make it into the repository. Therefore, such a repository or library does require management. In every company, someone must be the ‘champion’ of a new initiative and take the first step. An in-house intellectual property attorney is in a good position to see the risks of inaction and reach out to the engineering or information technology department to begin discussions about open source usage. 3.1 Use of open source code It is important for the corporate open source policy to set forth the process for evaluating the proposed use of the code. Certain uses can trigger source code publication requirements. For example, many companies will only allow open source code in stand-alone applications or only as ‘separably compilable’ code that is not mingled with the company’s proprietary code. Such a separate use would not trigger the ‘viral’ elements of certain licenses, such as the GPL discussed above. Therefore, the company gains the benefit of the free code and the company’s proprietary code remains separate and solely owned by the company. Compliance with the various licenses is more than simply cataloguing usage.26 There must be processes in place for monitoring and complying with license obligations such as publication requirements. In a large organisation, there is likely to be more code files and larger systems, but there is also infrastructure and personnel in place to handle larger projects.27 3.2 Education The myths around open source software are best dispelled by education. To be successful, the Open Source Policy must be launched as a new initiative, available to all on a company-wide forum, such as a company-wide Intranet, and must be presented and explained to the relevant employees. It is important that someone, either from the legal department or a technical lead, educate the applicable employees on the risks and benefits of using open source and the need for the policy and its review process. The relevant employees must be exposed to the topic multiple times and in multiple ways. This can be accomplished with informal training sessions offered on-site, and with online training modules. There should also be an initiative to review pre-existing uses of open source code. The technical lead and the legal department representative will need to follow the

24 Festa, Paul; Governments Push Open –Source Software; http://news.cnet.com/2100-1001-272299.html; 29 April 2001. 25 Id. 26 Winslow, Maria; You Need a Corporate Open Source Policy; www.Linuxplanet.com/linusplanet/reports/6267/1; 26 June 2006. 27 Id. Open Source Software 7 new policy process for every piece of open source code already being utilised by the company. In addition, companies would benefit from a catalogue of approved open source applications, posted on a company-wide forum. Not only would this save employees’ time in choosing applications, it would save the time of the technical and legal points of contact who would only have to review the proposed new use of the application.

4.0 Conclusion Once the myths are dispelled, the decision is not how to avoid open source software, but rather how to make the best use of it. As set forth above, there are many benefits to be gained by utilizing open source code. However, there are also the risks to be avoided. Fortunately, the risks are published clearly in the online license policies and a good policy will ensure that the company avoids the pitfalls. Despite the risks, most companies will find that developers are already using open source software in their programs. Open source is readily available from online libraries and is free to use. Every company with software development must educate employees and closely monitor all such use of open source software. This is a much more prudent approach than having a blanket policy of “no open source allowed” that may or may not be followed. A robust corporate policy protects a company while allowing for the cost-saving benefits of open source code. The policy must set forth a formal process where each requested use of open source code is evaluated by both a technical and legal point of contact. The decision of allowance should be based on the intended use, along with the particular license terms governing that particular code, and should be a joint decision between the legal and technical departments. The company would also benefit from a list of previously approved open source applications. The education of the relevant employees should not end with the publication of the policy. The proper use of open source code is a complicated topic. Employees will learn it more easily from informal training sessions that are offered frequently. Only by understanding the risks, such as charges of copyright infringement from violating an open source license or losing ownership of company intellectual property, will the employees appreciate the need for a strict process and policy. *** Heather E. McNay is the Senior Intellectual Property Counsel for Landis+Gyr North America, a Toshiba company. Ms. McNay earned her undergraduate degree in Electrical Engineering at the Georgia Institute of Technology and her law degree at the University of Georgia School of Law.

Landis+Gyr is a leading global provider of integrated energy management products, including smart meters and smart grid communications.