“Open source is the ground zero for the development of technologies like the Metaverse. All the biggest projects in the last five to ten years that have been able to garner the most attraction are the ones that are open sourced — artificial intelligence, blockchain, and containerization, to name a few.
Open source comes with a great number of benefits. It allows you to collaborate with the smartest minds from every corner of the world; your work gets constantly reviewed and used, and there is a constant feedback loop,” says Gandhali Samant, director, cloud solution architecture, digital and app innovation, Microsoft, India[1].
In today’s world, open-source software underpins almost everything: A whopping 97% of applications leverage open-source code, and 90% of companies are applying or using it in some way. GitHub alone had 413 million open-source software (OSS) contributions in 2022[2]. OSS has become an indispensable part of software development. Both modern cloud systems and mobile computing technologies are largely based on solutions which contain open source code.
“Open Source” is a software-licensing model where the source code of the software is typically made available royalty-free to the users of the software, under license terms which allow redistribution, modification and addition, though often with certain restrictions.[3] It is developed in a collaborative manner by various individuals and teams. Any person can contribute to the source code and develop the software by adding inputs. OSS represents a revolutionary shift away from the prevailing proprietary rights model of software access and use. Proprietary rights model typically refers to the proprietary software whose use thereof is governed by copyright – i.e. only by virtue of grant of license to the licensee to use the software as per the terms set out in the agreement, and usually subject to payment of consideration, though not all proprietary software is necessarily commercial. Examples of the same include Windows OS by Microsoft.
Products such as Linux, Apache, Ubuntu, MySQL and Firefox are open source software which are widely used. Massachusetts Institute of Technology (“MIT”) uses a creative commons public license for an OpenCourseWare project that licenses all 1800 MIT courses. Other public licenses support the firefox web browser, wikipedia, android, VLC media player, etc.
Usage and Licensing of Open Source Software
The use of OSS may be understood from the perspective of business and development. From the perspective of business, OSS is used to provide customized software solutions for clients since the source code contained therein is modifiable and redistributable. OSS vendors earn revenue by allowing free downloads of OSS applications and then converting the user base into paying customers or selling hardware compatible with the OSS. From the perspective of development, the development of OSS promotes a collaborative work approach since there are multiple teams from various companies / entities who are involved in the development of the OSS [4]. OSS is usually free, and if not cheaper than proprietary software – hence its use is popular owing to barriers of access to proprietary software.
It is a misconception that OSS exists in the public domain. For the usage of OSS(s), a certain type of license is required. This is, however, not protected by the traditional copyright system. Instead, the open source model has come up with a legal innovation of the traditional IP rights system known as ‘copyleft’. The modus operandi is to copyright the software and mass license it for use, improvement, or modification. In this, the alteration is done on the basis of reciprocal terms – i.e. alterations are contributed back to the software development community [5]. Some of the prominent licenses include GPL (General Public License), Mozilla Public License amongst others. Another category of OSS is permissive open source license. “A “permissive” license is simply a non-copyleft open-source license – one that guarantees the freedoms to use, modify and redistribute, but that permits proprietary derivatives”[6]. This type of license allows proprietization, grants use rights and the right to relicense. MIT License, BSD licenses, Apple Public Source License and Apache license are prominent examples of permissive OSS.
Open Source Software and the Traditional IPR Regime
As companies increasingly combine the use of proprietary software and OSS at various levels, the legal complications arising from the claims of infringement of OSS have put technology companies at risk of costly litigation.
In respect of copyright law, a clear conflict is seen to have emerged between the proponents of OSS model and traditional copyright model. The reason being both the models are antithetical to each other. This is because the latter protects the proprietary rights model and has the effect of ‘restricting access’ to the general public. In Jacobsen v. Katzer, Jacobsen’s work was made available via Artistic License 1.0 (a license for free-to-use public software), which Katzer used in its commercial software without due attribution. The US Federal Court of Appeals held that license terms are enforceable copyright conditions under federal copyright law, in addition to enforceability under state contract law[7]. Since Katzer failed to comply with the terms of the license by affixing required copyright notices to the derivative software, their use of the code constituted copyright infringement.” [8] Hence, OSS license gives rise to copyright obligations.
As far as patents are concerned, the use of OSS components in the development of proprietary software often brings the risk of infringement (in a similar manner as it does under copyright law), and hence, even when minimal infringement is detected, it can bring the whole process of development to a grinding halt. Some of the ways in which open source deals with patent related issues includes the incorporation of patent-related terms in Open Source licenses[9]. An example of the same would be the one where a company wants to use one of these more permissive licenses (Google Inc, in this instance, with regard to WebM VP8 video codec technologies) – it added a patent license grant and peace terms in an additional clause, tying the patent grant to its implementation of the patent claims[10]. The impact of this is twofold: the code that Google has distributed is effectively granted under the open source license (in this case, the MIT license), a recognized and standard open source license permitting easy use and adoption, while users of Google’s version of the code are given comfort and protection as regards claims with respect to patents that Google and other contributors may hold in the codec”[11].
Recent Developments
The open source community closely followed the litigation between Google and Oracle due to its potential impact on the reuse of APIs. The US Supreme Court’s landmark ruling in Google v. Oracle[12] ended a decade-long legal battle between the tech giants, finding that Google’s copying of over 11,000 lines of Oracle’s Sun Java application programming interface (Java SE) code was permissible fair use under copyright law. Google was accused of copying the names and syntax of 37 API (s)[13] for the development of its mobile operating software, Android. Though in its defense it had only rewritten the implementing code[14] (which contained the functionality of the Java methods) and retained only the declaring code required for method declaration. The Supreme Court ruled that Google did not violate fair use provisions on the grounds that: the nature of its use did not separate it from the overall organization of the API, the purpose of the use was transformative, the amount and substantiality of the copying was minimal, and Android did not pose any market threat to Java SE[15].
The SC judgment in the present case provides a breather for the tech industry and the OSS community in particular. Owing to the fair access to the APIs, there can be an innovative cross-compatible software ecosystem built on universal and common standards, by using the same declaring code for each improved method. This is a huge benefit and supercharges the open source development ecosystem. For example, startups will not have to pay for licensing or develop separate API (s). A level playing field for tech companies and startups of all sizes will be created because it would prevent gatekeeping of API (s)[16]. It is beneficial for developers as well as their skills would be transferable without learning a new set of API (s). Most importantly, the freedom of reimplementing API(s) and having open API(s) itself fosters ‘interoperability’. Interoperability is at “the backbone of the internet. Having “open, documented sets of instructions that third parties can use to ensure that information can successfully pass back and forth between programs” is what allows computers and the internet to actually function[17]. Though on the flip side, the scope of copyleft terms in such cases may be reduced because no derivative work is created in the reimplementation of the API[18]. Also, sidestepping the crucial question of the copyrightability of API (s) will lead to further ambiguity in the tech industry and threaten longstanding API-related practices.
Transactional Pitfalls
There are umpteen instances of IT contract negotiations wherein one can see OSS pivoting itself as a major sticking point. To not let OSS act as a spanner in deal closures, various customers insist on the requirement of a clause on warranty which categorically should state that no OSS is included in the software product. However, in actuality this stance is impractical. It is almost impossible to not include OSS in software products, and while there is always some degree of risk involved, most of the time OSS is perfectly safe with minimal onward restrictions. A customer can try to include an umbrella warranty to ensure that the “software as a whole” is free of potentially harmful onward restrictions. In addition, a customer should push for the service provider to provide a list of the OSS used in the product. However, the tables turn from the perspective of a service provider, and the seller should try to push for a routine approach of disclaiming all warranties, and only permit express warranties to its licensee. The effectiveness of the disclaimer format is questionable and varies from the contractual obligations’ parties are getting into.
As far as indemnity is concerned, a licensee generally prefers to stick to a typical IP indemnity clause because it usually does the trick wherein if a third party sues the licensee for redistributing the service provider’s software without using the open source model, the usual IP indemnity protects the licensee. It would require that the vendor defend the suit and pay any settlements or judgments. But some contract drafters prefer to leave no iota of doubt and instead prefer adding caveats regarding such infringement of open source software.
When representing a customer of a software or the software company itself, there is a substantial difference in risk between a customer having a direct claim and only the developer having the claim. Open source licensing requires that the author of a particular piece of code be acknowledged. This requirement is often satisfied by providing adequate attribution and retaining the author’s copyright notice on the code created. It is crucial to include such relevant licensing terms in agreements. If there is a failure in compliance with the OSS requirements it may result in legal action by the original licensors.
It’s rightly said, “The days of open source software free lunches are rapidly coming to an end, and that means enterprises that fail to stick to the terms of open source licenses can expect to be sued”.[19]
Footnotes
[1] Laveesh Kocher, The importance of Open Source in the Metaverse January 25, 2023, https://www.opensourceforu.com/2023/01/the-importance-of-open-source-in-the-metaverse/.
[2] Taryn Plumb, GitHub’s Octoverse report finds 97% of apps use open source software, https://venturebeat.com/programming-development/github-releases-open-source-report-octoverse-2022-says-97-of-apps-use-oss/.
[3] See generally Open Source and Commercial Software, Business Software Alliance, available at
wipo_ip_cm_07_www_82575.pdf (last accessed on April 24, 2023)
[4] Id.
[5] Vikrant Vasudeva Open Source Paradigm and IPR 17 Journal of Intellectual Property Rights 511 (2012).
[6] Open Source Initiative Open Source Initiative – The steward of the Open Source Definition, setting the foundation for the Open Source Software ecosystem..
[7] 609 F. Supp. 2d 925.
[8] Azzi, R. Michael (2010). “CPR: How Jacobsen v. Katzer Resuscitated the Open Source Movement”. University of Illinois Law Review. HeinOnline. 2010 (4): 1271–1302.
[9] Bain, Malcolm; Smith, P McCoy (October 2022). “Chapter 10: Patents and the defensive response”. In Brock, Amanada (ed.). Open source law, policy and practice (PDF) (2nd ed.). Oxford, United Kingdom: Oxford University Press. pp. 213–255.
[10] Id.
[11] Id.
[12] 18-956 Google LLC v. Oracle America, Inc. (04/05/2021) (supremecourt.gov).
[13] An application programming interface (API) can be described as a tool that enables one software module to pass on information to another.
[14]Morris Manning and Martin LLP, Impact of Google v. Oracle Open Source and Other Implications (June 12, 2020) available at https://www.mmmlaw.com/media/impact-of-google-v-oracle-open-source-and-other-implications/ (last accessed 12th June 2023)
[16] Id.
[17] Id. at 44
[18] Morris Martin and Manning LLP, supra note 14
[19]News Roundup by Dr. Roy Schestowitz, BioShock Infinite for GNU/Linux, Makulu Unity Alphas, http://techrights.org/2015/03/18/makulu-unity-alphas/.