International In-house Counsel Journal Vol. 10, No. 38, Winter 2017, 1

Open Source Software: Compliance and Risk Mitigation

SHILPI SNEHA In-house Counsel, India

1. Introduction – a brief history of where it all began The proprietorship of software was not a familiar concept in the 50’s and 60’s. The hardware and software were seen as an inseparable “system” and the cost for the or any associated software used to be included in the price of the hardware. The human readable form of software i.e. source code were distributed along with the hardware to ensure that the user can their own changes or modification for smooth running of the hardware. Users generally distributed the software, bug-fixes and any modification with each other freely as there were no strict licensing terms and even if there were few organisations who included license terms, enforcement of such terms was not usual. With the increase in many organisations and corporations who invested time and resources for development and betterment of software and the industry itself, software became the source of revenue opening a huge consumer market and protection of the software or its source code became the need for these corporations to survive beneficially. Upon being adequately famous and having dependable customer base, in the 1980s, AT& stopped the free distribution and started charging for patches. One can also refer to the famous open-letter written by Bill Gates to the “hobbyist” (as the earlier free distributors or contributors were known as) in 1976 wherein he clearly mentioned the discontent on the free distribution of Microsoft’s proprietary software in as many words as possible. To a great extent it made sense that the people who have invested so much of resources and have taken up the development of software as a career should be able to reap the commercial benefits arising out of the software as a “reward”. It’s only but natural for every ideology to have a counter-ideology. While commercial organisations were more interested in protecting the benefits of their investment and hard work, the “hobbyist” or the “hackers” wanted the freedom to use, distribute, modify the software as per their own requirement which would also have included the option of fixing the bugs themselves or through a free or economical alternate. It is very much possible that a group of people like would have faced similar problem, who wanted to fix a printer but could not because he was not allowed to access the source code of the software. Richard went on to launch GNU Project in 1983 and the first version of GNU GPL in 1989. The GNU Project was launched with the objective of developing an operating system and the other complimentary software required for functioning of a computer to be freely available to the users for use, modification, distribution and contribution. The first free operating system came into being when Linus B. Trovald developed Linux kernel and released it under GNU GPL v2.0 in 1991. The intent of this paper is to understand the basics of open source, the evolution of industry from being OSS phobic to being OSS supportive through citation of example (and some important recent contributions to OSS by giant players in the industry), OSS as a beneficial business model and also to emphasize why it is important for every organisation to have OSS management and what risk mitigation steps can be taken for better protection.

International In-house Counsel Journal ISSN 1754-0607 print/ISSN 1754-0607 online

2 Shilpi Sneha

2. , Open Source Software and Freeware: a general understanding a. Free Software: The was established by Richard Stallman. The philosophy of the foundation was that the software to be “free”, not of cost, but of restrictions. Hence, a free software does not necessarily mean that the programmer will not be able charge for a copy of the software but the programmer will have to give freedom to users to use the software for purposes such as studying of how the program works, freedom to modify the program, redistribute the copies of original program along with source code and redistribute the modification of the program to other users. It is critical to note that the programmer redistributing the program or the modification can charge the user for such redistribution or modification. However, such modification will have to be distributed under the same terms and conditions as the original software and it cannot be distributed under a proprietary or restrictive license terms and conditions. b. Open Source Software (“OSS”): The term OSS was coined in 1998 in order to come up with a term which is less ambiguous than “free” software and which makes it clear that the commercialisation of so called free software is not barred or restricted. It is important to clarify that while free and Open Source Software has been separately mentioned in this paper, the reason to do so is to historically document the usage of the different terms. The Free Software Foundation was founded earlier than Open Source Initiative (“OSI”) and hence the term Open Source Software is more recent than free software though they have overlapping philosophy. The reason for coining the new term was discomfort of people industry wide in using a confusing term “free” (which generally associated it to cost rather than freedom) and a slight change in the philosophy over a period of time. The term free software and Open Source Software are used inter-changeably and the official website of OSI enlists all the OSS that has been mentioned in this paper. Under the OSS licenses the users get same freedom to use, study, modify and redistribute the original software and modification with or without charge. Under the OSI initiative there are multiple licenses which are not copyleft and hence don’t require the modification or derivative work to be contributed back under the same terms and conditions. The programmer for the modification can choose to redistribute the modification under restrictive proprietary license terms and conditions. . Freeware: The term Freeware refers to the software which are actually made available to the users “free” of cost but the governing licenses may be restrictive and thereby the access to source code might not have been allowed (let alone modification or redistribution of such modification). Some of the best example of such Freeware is Adobe and different kind of games that are available on the Android or iOS to the user free of cost though the source code is never made available to the user. 3. Types of Open Source Software: The OSI has its own license review process to ensure that the licenses comply with the objective of the initiative. Some of the famous licenses have been used across the industry has been mentioned below: a. GPL (General Public License), LGPL (Lesser General Public License) and AGPL (Affero General Public License): the copyleft or viral ones GNU GPL is a copyleft license whereby the freedom of use, modification or distribution is granted on the conditions that anything derived from the original software shall also be governed by the same terms and conditions. The preamble of the license reads as follows which clarifies the very objective and intent of releasing source code under these terms and conditions:

Compliance and Risk Mitigation 3

“To protect your rights, we need to prevent others from denying you these rights or asking you to surrender the rights. Therefore, you have certain responsibilities if you distribute copies of the software, or if you modify it: responsibilities to respect the freedom of others.” The object of the license is to ensure that all the users enjoy same rights and responsibilities and give back to the community rather than monopolising or commercialising the original software or any further contributions. GPL, however, does provide a linking exception, an example of which is GNU Classpath, which allows the proprietary software to be linked to code under GPL without being subject to the terms and conditions of original GPL terms and conditions. The wording of this exception may vary for each software libraries and few of the examples can be drawn from GNU Classpath, GNU Guile and release of Java SE and Java EE with same linking exception as GNU Classpath. While LGPL and AGPL are also extension of the same philosophy, LGPL is applicable for libraries and AGPL is applicable for software that could be shared over a network. LGPL does provide the similar linking exception as mentioned above for GPL with an additional requirement that reverse engineering of the library that is used must be allowed for debugging of the modification. b. MIT, BSD and Apache – the permissive ones: These are the more permissive licenses which allow the user to distribute the modification under proprietary or other licenses provided the user complies with the copyright notice and other applicable terms and conditions. The 4-clause version of the BSD was incompatible with GPL, however Modified (3- clasue) and Free (2-clause) BSD version are very much compatible with GPL. Apache v2.0 and GPL v3.0 are compatible with each other. Any other version of Apache and GPL are incompatible with each other. Incompatibility of different OSS terms with each other: The incompatibility of the licenses means that if different component of the software are licensed under different OSS or proprietary license, the inherent terms and conditions might conflict and it becomes unclear as to what terms and conditions will govern. For example: since GPL requires the contribution of any modification back to the public under same license terms, a proprietary license term obviously conflicts with the terms of GPL and it is needless to say that the whole proprietary software will become OSS in certain cases of combination of these two different software. Incompatibility of GPL with non-copyleft licenses such as Apache v1.0, BSD v1.0 (4-clause version) is well known specifically due to the clause related with advertising. In certain cases the question of incompatibility of licenses has been resolved by relicensing of the incompatible parts (i.e. contacting the concerned contributors and getting their consent for relicensing). However, relicensing is a viable and easier option in case the software was developed by one contributor. Examples such as the relicensing is tri-licensing of Firefox browser and relicensing of linux kernel header files to BSD license by Google for an Android library enforce this faith. If a software has multiple contributors (and in different geographies), bringing everyone on same page might be a problem.

4 Shilpi Sneha

4. Business models depending on OSS: The philosophy of founding Free Software Foundation or OSI was not to restrict commercialisation of the efforts. Rather if we examine the philosophy in detail it distributes the benefit of efforts to a larger group. As you will notice with most of the OSS, there is no restriction in charging fee for sharing a copy of the software or for creating modification or subsequent distribution. The OSS in reality opens the market for multiple vendors who have the capability to work on the same software/program/code. Most of the proprietary software are licensed, implemented, integrated or supported by the original manufacturer or their authorised partners who are on-boarded through a strict process and are regularly monitored. In the case of OSS, once the software is in public domain, the user can choose to implement or modify the software himself depending on his capability or go to an innumerable vendors for procuring any services or support required related with the software. The user has the option to change the vendor in between without any restriction (except for the contractual obligation agreed between user and vendor) if the user is not happy with the services of the vendor. Additionally, if the user believes that the software needs to be customised or modified in any way it can get the same done (either himself or through vendor) and either (i) contribute the changes back to the original software, if the software was licensed under copyleft license terms, allowing even the vendor to propose similar customisations to multiple other users; or (ii) keep the customisation or modification solely for himself, if the software was licensed under the permissive license terms and conditions. A brief description of some of the successful enterprises has been provided below as an example of OSS being a successful business model: a. Red Hat Inc. is a US based multi-national software company (with subsidiary in India, which is a private company, and multiple channel partners in India) founded in 1993. The major products, that Red Hat is associated with, are Red Hat Enterprise Linux, Red Hat Mobile Application Platform, Red Hat Directory Server, Red Hat Certificate System, Red Hat Satellite, JBoss Enterprise Middleware, Red Hat Storage Server, Red Hat Cloud Forms, Red Hat OpenShift and Red Hat Virtualisation which extends the Red Hat business into storage, operating system platforms, middleware, applications, management products, and support, training, and consulting services. Red Hat even acquired many corporations with proprietary software and went on to release it under open source. Red Hat went public in 1999 and its net income in 2016 was USD 199 Million with approximately 10,000 employees. b. Canonical Limited is a UK based private company providing support and services for Ubuntu. Canonical employs staff in more than thirty countries. The major products that Canonical is associated with are Ubuntu, Launchpad, Bazar, Landscape, Ubuntu One etc. c. SUSE was founded in 1992 and is a Germany based multi-national open source software company with major products as SUSE Linux Enterprise, SUSE Manager, SUSE OpenStack Cloud, SUSE Enterprise Storage, SUSE Studio. It is also significant to mention the names of VA Linux Systems (or VA Software later on and now Geeknet, Inc.) and Cygnus Solution (acquired by Red Hat Inc.) as few of the earlier organisations who based their business entirely on OSS. While the above mentioned names are related with mostly open source based operating systems, open source is playing is a major role in cloud computing as well and one of the major example is OpenStack. OpenStack is mostly deployed as infrastructure as a service

Compliance and Risk Mitigation 5

(“IaaS) which is licensed under Apache v2.0. OpenStack was initiated in 2010 jointly by Rackspace Hosting and NASA. It is currently managed by a non-profit organisation named OpenStack Foundation. Rackspace uses OpenStack as the basis for its public cloud, whereas few others are packaging components with OpenStack to make it into a product which can be easily sold to the enterprises. Some of the major supporter and contributors for OpenStack are Rackspace Hosting, Red Hat Inc., Dell, HP, IBM, Cisco, VmWare, Canonical, SUSE etc. Dual/Multiple-licenses: Due to incompatibility between different terms and conditions of different OSS, sometimes the programmers may release the software under dual licenses i.e. the software can be governed by multiple set of license terms and conditions and the user has the option to choose which license terms and conditions would they comply with. It becomes more important for instances where programmers or commercial organisations are completely avert to the idea of using GPLed or LGPLed software/codes. As an example Mozilla project was earlier licensed under Netscape Public License and Mozilla Public License, it has now moved to triple license of MPL, GPL and LGPL. Dual/multiple-licenses are not only for combination of multiple OSS licenses with each other. Dual licensing has also emerged as a business model where the software is released under both the OSS license terms (mostly GPL) and proprietary license terms and conditions. By releasing the source code under GPL, the programmer may restrict the competition since any modification, changes or fixes will have to be released back under the terms of GPL itself which will benefit the original owner too. Any organisation which does not want to use the GPL but wants the software for using it in conjunction with its proprietary software or other development work (without facing the implications of GPL) may procure the proprietary license. The proprietary license may include some additional patches, functionality or support too. This business model increases the reach to users as well as the revenues. The organisation may still charge for services, support or modification (if user reaches out to such organisation with such requests) even if a user has chosen GPL license terms. The users/organisations who want to use the software for commercial purpose will still use the proprietary version and pay the respective fees for the licenses. Some of the examples of this business model are MySQL, Sleepycat, Asterik, Sendmail, Jaspersoft, SugarCRM and Trolltech. Major corporations who released their software under OSS: The above example shows that the benefit of a faster and cost saving innovation has taken the advocates of proprietary software in stride too. The major proprietary software players are not only investing in open source initiative and new innovation they also release their own proprietary software under open source for greater good as well as benefiting from the feedback provided by a much larger audience. Some of the examples of big corporations releasing their proprietary software under open source are provided below: a. .NET Framework and Chakra was released by Microsoft under the MIT license in 2014 and 2016 respectively. b.StarOffice (Oracle open office) was release as open source in 2000. c. Java was released by Sun Microsystems under GPL in 2006. d.Netscape Enterprise Server and Netscape Navigator were released under the BSD and Mozilla Public License. e. Tesla Motors has opened its patents for larger community to benefit from.

6 Shilpi Sneha

5. The symbiotic relation and the risks: Since the beginning of the free software philosophy or initiative, the corporation who benefited from the proprietary software were concerned about the implication of mixing the proprietary software with the OSS. Rightly so, as the GNU GPL has a clear implication that every modification, combination or covered work needs to be released under the GPL causing a threat that any mixture of the proprietary software with GPL will cause the whole proprietary software to be subjected to GPL. With evolution of more permissive OSS it became clearer that OSS and proprietary software could co-exist. As a result most of the proprietary software do include OSS component (to save time and cost on development of smaller components) with the disclaimer that they might include OSS which will be governed by its own terms and conditions. While most of the time these OSS used is permissive and not copyleft licenses, it is always advisable to ensure assessment of these OSS if the software is being licensed or if there is a prospective merger or acquisition on the way. It is not only critical for organisations to sensitise their employees about the implication of using OSS in development of proprietary software, what is allowed to be used and what is strictly prohibited, every organisation shall have a OSS management system in place to track down any inclusion of OSS in the proprietary software not only for compliance but also to ensure that any incompatible licenses or copyleft licenses are not included in the proprietary software by any consultant, subcontractor or any third party as well. If at all the OSS is being included, it is critical to comply with the terms and conditions of the OSS licenses such as include the copyright notice and acknowledging the OSS. OSS scanning software There are multiple products available in the market which scans the software code to check if any OSS or any part of the OSS is included in the software. Most of the organisations use the OSS scanning software while procuring any software, finalising a merger and acquisition deal, procuring any consultancy services or its own proprietary code developed in-house to ensure that nothing in the software will harm their intellectual property rights and there are no copyleft licenses included in the software. Few of the leading OSS scanning software available in the market are BlackDuck, Protecode, Palamida, OpenLogic etc. The quality of these products depend on the data base of OSS that these products have which is also updated on a periodic basis. While there are always chances of error since the product cannot always be updated about each and every OSS available in the market, the products are at least better than any manual or no assessment at all. These products also give an option to define the protocols and hence if the organisation is already comfortable with certain kind of OSS, the product will not highlight it as it would be considered approved by the OSS management product which saves lot of review time. The list of approved OSS can be updated by the organisation on regular basis. Case laws: With the fame and wide spread usage of OSS and multiple organisations attaching themselves to OSS initiative, the number in litigation related with OSS has also increased. Few examples have been highlighted below to showcase the kind of risks non- compliance of license terms may bring on the user: a. Versata v. Ameriprise: Versata owned a proprietary software product know as Distribution Channel Management (DCM). The DCM included an open source component licensed under GPLv2.0 from XimpleWare. The DCM was licensed to Ameriprise and Ameriprise gave the access to the DCM to a subcontractor for procuring services. Versata sued Ameriprise

Compliance and Risk Mitigation 7 for a breach of license. Ameriprise counter-sued Versata as they were of the opinion that DCM was nothing but the derivative work based on the open source component and hence whole of the source code should be released under GPLv2.0. The DCM didn’t include the copyright notice for GPLv2.0 and it seems that Versata did not know that DCM includes open source. When Ximpleware became aware of this suit, they sued Versata, Ameriprise and other customers of Versata for infringement of intellectual property. The case has been settled last year and the court ruled that if an intermediary does not comply with the terms of open source, it would not affect the rights of other licensees to whom the software was distributed by the intermediary. b. Oracle v. Google: Java was originally developed by Sun Microsystem which was acquired by Oracle in 2010. Java has been released as open source software under GPL in 2006 by Sun but some parts are still proprietary. Google did discussion partnership and licensing terms with both Sun and Oracle but an agreement was not reached while Google still went on to include Apache Harmony implementation of some of the of Java Standard Edition. Oracle sued Google claiming infringement of intellectual property and sought damages of USD 6.1 billion. Google’s defence included the fact that Android used Apache Harmony and hence did not infringe Oracle’s intellectual property. The district court observed that APIs are not copyrightable. Oracle appealed to Federal Court which partially reversed the district court ruling observing that APIs are copyrightable and it should be assessed whether Google’s use amount to fair use or not. On a further appeal by Google, in June 2016, a United States Federal Court ruled in favour of Google, stating that its use of the APIs was fair use. 6. How to safeguard your organisation’s interest contractually In addition to OSS management in the organisation, it is critical to also ensure that your organisation is adequately protected contractually either when you are distributing OSS as part of your proprietary software or when you are receiving the OSS as a licensee or customer. Most or rather all of the OSS disclaims any and all warranty or liability related with the software. It does cause security concern to anyone who would want to use these OSS. As a licensor or developer of proprietary software which includes OSS, the best foot forward for any organisation would be to similarly disclaim any and all warranties and liabilities related with these OSS. On the other side of the spectrum if you are a licensee or customer who wants to procure proprietary software which includes OSS, the biggest concern is what kind of OSS might be included in the software that is being procured and what implication they may have on the system or network of the licensee. As a licensee it would always be helpful to include few safeguards in the contract. It would seem only fair that the licensor should keep the licensee updated with any changes in the OSS that is used with their proprietary software to ensure compliance and governance of usage by the licensee specifically if copy-left OSS have been used. While it is an understandable position from licensor’s perspective that if they don’t receive any warranty or protection under the OSS license terms they would not take the responsibility for the OSS as well, it is only fair that the licensor shall remain responsible in case the OSS provided by them affect the rights of the licensee to use the proprietary software or harm licensee’s system and network in any way since licensors are the ones responsible for bringing the OSS on the table. At the end of the day licensee is paying for the whole value and functionality that the proprietary software brings into licensee’s organisation irrespective of the fact that the licensor opted to include the OSS for saving their own time and cost. The above mentioned logic goes for the service providers as well and most of the time a service procuring organisation would either very clearly mention that they would not

8 Shilpi Sneha want any OSS or freeware at all or would like to approve each and every third party component (including any third party proprietary software) before they are included in the end product. 7. Conclusion A detailed look at the current scenario, the fame, the interest and the support that OSS has got, warrants a hopeful and more flourishing future for the OSS. Since the functioning of the industry has changed over the time, it would not be wrong to say that somewhere the OSS and proprietary software have struck a balance with each other where OSS brings the benefit of (i) being time and cost effective; or (ii) providing feedback, ideas and quick reviews for betterment. Sharing of ideas with each other have been a general trend across manufacturing and automobile companies and OSS facilitates the same for the programmers and developers across the world whether on behalf of any corporation or as an individual. I am not sure if this sharing should be tagged as beneficial for the industry but it definitely has impacted and impressed multiple generations including the change in the perspective of giants which were against the philosophy in the beginning. It would be interesting to see how the dynamics between OSS and proprietary software unwraps in the times to come. *** Shilpi Sneha is an in-house counsel with an experience of more than 6 years. She has graduated from New Law College, BVP, Pune, India in the year 2010 and joined an India based software MNC right after. She has a thorough experience of working on different commercial contracts. While working with her first employer, Shilpi got the chance to be part of OSS compliance team and has been interested in the subject since then. In her current role, Shilpi looks into alliance agreements globally. Shilpi is currently working for a US based MNC that provides IT and consulting services.