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 Intellectual Property 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 copyright infringement 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 Free Software 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 ‘copyleft’, as opposed to copyright, to designate freedom to copy. The Free Software Foundation 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.gnu.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 Open Source Initiative (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, Mozilla™ Foundation License12, Common Public License (published by IBM™)13, Apache License (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 proprietary software 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 Linux™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.