This article is written by Mahendar Bangeja, pursuing a Diploma in Intellectual Property, Media and Entertainment Laws from lawsikho.com.

Introduction 

The relationship between Patent and Software is not always clear. The software consists of both functional and creative aspects. The creative aspects are protected by the copyright law while the functional aspects are protected by the Patent Law. In the U.S.A in appropriate cases, patent protection is broadly available for computer-related inventions [1]. However, in India a computer programme per se is not patentable, the said programme needs to have a technical application to industry or must be in combination with hardware [2].

Most of the software we use today from Google Chrome to Netflix is built using the Open Source Softwares. And, many companies invest in Open Sources heavily in order to upscale the technology. Now, the question arises whether these open sources affect the rights protected by the patents? 

The relationship between the Patent and Open Source Software (“OSS”) is conflicting as the Open Source movement intends to provide free access to the source code of the software to the general public while the patent law strives towards the exclusive use of the patent by the patentee. This conflict is resolved by entering into an Open Source License through which the patentee can decide the rights which he/she allows to be distributed to the licensee.

An OSS can be borrowed, modified and redistributed. Many open-source softwares are released with their patents and copyrights with the sole purpose of further qualifying the borrowing, modification, and re-distribution of open-source code under various settings (commercial, personal, or academic) pertaining to the use of it[3].

Defining open source licenses 

Licenses are a set of permissions or grants (they may include the right to use, modify or sell) given by the patentee to the licensee. Licenses may also be used to set conditions or obligations. For instance, in most proprietary software licenses the licensee is restrained from redistribution and in many cases, the licensee is also prohibited from reverse-engineering the software itself. If the conditions provided in the license are not complied with then the licensee loses all the rights granted through that license and can also be liable for the penalty.

OSS licenses allow users to view and modify the source code of the software, thus it makes technology available for the general public and it further eliminates the fear of being sued to a limited extent. A license can be said to be an open-source license if it incorporates ten conditions stipulated by the Open Source Initiative [4]. Even, OSS licenses include certain obligations but their nature differs from license to license.

If the said obligations are not followed then the developer can sue and in such cases, the licenses will be treated like a legal contract [5]. In fact, in India the said license is an implied promise as provided under Section 9 of the Indian Contract Act, 1872, thus parties have the same remedies as they have under ordinary contracts in event of breach. 

It can be said without any license (whether proprietary or OSS license) no-one has any rights to the software and license is the medium whereby the creator grants those rights.

Broadly, OSS licenses can be divided into two categories:

1. Permissive Licenses
2. CopyLeft Licenses

Permissive Licenses[6] grants all the rights of the software to the licensee. The licensee can modify any software covered under such licenses and further make such modified software proprietary. While using the software code protected under such licenses the licensee generally has to give the attribution or credit to the original developer. Most of these licenses also contain a warranty disclaimer clause that protects the author from the claims of unfitness and non-merchantability of the software.

Copyleft licenses are licenses that guarantee user’s freedom. These licenses prevent the licensee from creating proprietary software as it requires the derivative software also to be shared freely. Therefore, it is said that a permissive license can become a copy-left license but copy-left can never be transformed into a permissive license.

In order to harmonize the conflict between the Patent Law and OSS, licenses expressly contain a patent grant in their text. In certain licenses, the said patent will be implied. Thus, a license can be further classified as follows based on the patent grant:

1. Explicit licenses: Express language in open source licenses granting patent licenses;
2. Implicit Licenses: The existence and scope of implied patent licenses in open source licenses;
3. Express but Non-specific Licenses: Express grants in open source licenses that do not include the term “patent;”

Patent rights of the modifier or the author

Even after distributing the software through the OSS license, the author can still apply for the patent. It may seem that such distribution may amount to prior publication in terms provided in the Indian Patent Act, 1970 (“the act”), however, it is important to understand that distribution of software through a license will be protected under Section 29(2) of the act.

It is also important to understand that once an author has entered into a license the protection provided to his/her invention by the patent is significantly reduced as most rights guaranteeing the exclusiveness of the invention are distributed to the Modifier.

Further, the modifier’s right to use, modify, or sell patented inventions of the author is completely governed by the OSS license. In most licenses, an explicit patent clause is provided while in others it’s upon the courts to imply the said clause based on the intention of the parties at the time of entering into the license [7].

Modifiers can also apply for a patent of their derivative work even though he/she has used the source code of the author. For the purpose of patenting the derivative work, the same must be an invention and it must be novel. Modifier has to add some increment or improvement on the previous source code in order to make it patentable otherwise it will be said to be devoid of any inventive step thus, non-patentable.

In the case of Apache 2.0, the “sub-licensing” is allowed, and also creating of derivative work is permissible, therefore, in such a case the modifier can modify the source code and create its own intellectual property. While in the case of GPL licenses (and most CopyLeft licenses) the right of the recipient is subject to the original GPL license, therefore, any downstream will be valid only if it adheres to the original GPL license [8]. 

The purpose of patenting an OSS is often debated as it is a common notion to not spend on the exclusivity of the software if the same is shared with the general public for free. However, the authors still tend to file a patent to protect the source code provided in the OSS for the following reasons:

1. The authors may retain the right to sue for infringement of patent if the license is breached.
2. The authors can release a version of the software which is not in OSS.
3. The authors may assert their right against the infringer who is not a party to the license.

Existing Licenses

If the author of an OSS has been granted the rights to a particular patent through an already existing license then the said author can distribute the said software by entering into OSS license only if the original license permits the same. If the author does not have any ability to sub-license then distributing such software is prohibited especially in GPL Licenses.

Explicit patent licensing 

Most of the OSS licenses contain an express patent grant but its scope may vary depending upon the language of the terms. The following licenses have explicit patent clause:

1. Academic Free License 3.0
2. Apache 2.0
3. Eclipse public service version 2.0
4. GNU General Public License 2.0
5. GNU General Public License 3.0
6. Mozilla Public License 2.0

Some of the above-mentioned licenses cover patents at the time of distribution while some include the after-acquired patent also. Some license grants cover only patents that are infringed by the original developers’ or downstream licensee’s contributions (e.g., modifications or enhancements) or their contributions in combination with the version of the OSS that the licensee received.

Some broadly grant rights to permit anyone downstream of the licensee to make additional modifications. The developer can choose the license as per his requirement and accordingly grant the rights protected by patent.

Implied licenses and its limits 

An implied license can be construed through the terms in the license itself or the action of the licensor in applying for the open source license and distributing the copies to the public. There is a presumption against adding terms which the parties have not expressed. However, there may be certain cases in which certain terms may be implied and without such terms, the contract will not be enforceable [9].

Any language used by the owner of the patent or any conduct on his part exhibited to another from which that other may properly infer that the owner consents to his use of the patent in making or using it, or selling it, upon which the other acts, constitutes a license[10].

Now, the limit of such implied licenses differs from license to license. Most OSS licenses grant the right to “use” along with the right to modify, copy, and distribute. The right to copy, modify, and distribute are rights under copyright law while the right to “use” arises in the patent. Therefore, employing such terms may result in implied patent licenses. Moreover, these licenses are not absolute and these terms shall read with other terms of the license to understand the intention of the parties.

In licenses such as GPL, the users or modifiers have a license to use the invention as per the terms of GPL. Such a license is not a blanket license and it must be construed along with the other restriction of the license. Thus, in a GPL license if a licensee intends to make the invention proprietary the license automatically stands revoked.

The scope of an implied license in OSS has not been fully tested by the courts, even in Ximpleware vs Versata Software [11]the courts did not consider the following aspects involved in the implied licenses:

1. Right to sell
2. Right to offer for sell
3. Right to make
4. Right to import

Unlike the right to use, these other rights are not provided in a license in such cases the intention of the parties is to be considered and accordingly, the terms are to be construed.

Patent exhaustion

The Concept of Patent Exhaustion is broader than Patent Licensing. Patent Exhaustion protects persons who are in lawful possession of the patented invention from being sued for using, selling, or importing those inventions. Exhaustion takes place when the patent holder puts the patented invention in the stream of commerce [12]. The rationale behind the concept of exhaustion is that the sale of a patented device exhausts the patentee’s right to control the purchaser’s use of that item because the patentee has bargained and received full value for the goods. Thus, one cannot profit more than from the sale of a particular item. 

In the case of OSS licenses, the Patent is generally exhausted by the third party as the author has certain rights against the licensee but the same rights are not available against the third party. For instance, ‘A’ puts the source code in Open Source and the said source code is used by ‘B’ after entering into a license, thereafter, ‘B’ gives the said source code to ‘C’ then in such a case ‘A’ will have not right against ‘C’ as the patent is said to have exhausted. However, ‘A’ may sue ‘B’ for any wrong committed. 

In order to understand the above example, we may rely on Cascades Computer Innovation, LLC. v. Samsung Electronics Co., Ltd[13] wherein Cascade had licensed some patents to Google for using them in Dalvik Virtual Machine and one such product was published on Android Open Source Project (ASOP) by Google. Samsung used ASOP code and further, compiled and distributed it. When Samsung was sued by Google, the court held that patent in such a case is exhausted because ASOP came from a producer with a license. 

One of the most common arguments to protect the BOSS from patent exhaustion is that since the source code in such cases is distributed for free, therefore, the same will not result in exhaustion of patent. However, the said argument has been repelled by the US Supreme Court in LifeScan Scotland, Ltd. v. Shasta Technologies, LLC et al[14] and it is held that Patent Exhaustion Principles apply to all authorized transfer whether it be sale or gift. The court has further added that in the case of an authorized and unconditional transfer of title, absence of consideration is no barrier to the application of patent exhaustion principles. Therefore, in order to ascertain the exhaustion of patent, the courts must analyze whether the title has been unconditionally transferred. 

There may be OSS Licenses wherein the patent rights are exclusively reserved for the patentee, the court in such cases have held that even when a patentee sells an item under an express restriction, the patentee does not retain patent rights in that product[15]

Some Prominent OSS Licenses and their implications

Conclusion

The OSS contributes to the movement of free software and strives to eliminate the unfair competition between the Davids and Goliaths of the software industry. Its main goal is technological advancement and if for that purpose certain rights protected by the patent are to be assigned to the users then so be it.

As if now there are no judicial decisions which interpret the OSS licenses and their implication on the Patent rights. Some of these licenses are self-sufficient concerning the issue of a patent while in the others we have to rely on the intention of the parties.

Every OSS license has its purpose, for instance, a GPL license believes in the idea of free software intrinsically, therefore, in such licenses there is no scope of proprietary benefit and on the other hand, an Apache 2.0 license makes the source code open but the user can take a proprietary benefit after modification of the source code.  

Therefore, the key is to understand the needs of the author and choose a license which caters to his needs. If the Author intends to retain maximum rights procured from a patent then in such a case a permissive license may be chosen and if the author is willing to distribute all the rights attached to the software then a Copyleft license is a viable option. 

References

[1] Diamond v Diehr 450 US 175; 1015 c.t 1048; 67 Led 2d 155(181)

[2] Section 3(k) of Indian Patent Act, 1970

[3] Campus EAI India Pvt Ltd Vs Neeraj Tiwari & Others LNIND 2019 DEL 1214

[4] For the list of conditions, visit the following link: https://opensource.org/docs/osd

[5] Artifex Software, Inc. v. Hancom, Inc., Case No.16-cv-06982-JSC (N.D. Cal. Sep. 12, 2017)

[6] Licenses such as MIT/EXPAT/X11, ISC/n-clause BSD.

[7] Flynt v. Life of the South Ins. Co., 2011 WL 5305431, 4 (Ga. App. 2011)

[8] Section 10 of GPL License 

[9] Hilgraeve Corp. v. Symantec Corp., 265 F.3d 1336, Fed. Cir. 2001

[10] De Forest Radio Telephone Co. v. United States, 273 U.S. 236, 47 S. Ct. 366 (1927), available at https://casetext.com/case/de-forest-co-v-united-states

[11] Case No. 5:13-cv-05161-PSG (N.D. Cal. May. 16, 2014)

[12] https://lwn.net/Articles/780078/

[13] Cascades Computer Innovation, LLC v. Samsung Electronics Co., 77 F. Supp. 3d 756 (N.D. Ill. 2015) https://www.casemine.com/judgement/us/5914fa77add7b049349a8497

[14] No. 13-1271 (Fed. Cir. Nov. 4, 2013)

[15] Impression Products, Inc. v. Lexmark International, Inc., 2d 1; 2017 U.S. LEXIS 3397

Students of Lawsikho courses regularly produce writing assignments and work on practical exercises as a part of their coursework and develop themselves in real-life practical skill.

LawSikho has created a telegram group for exchanging legal knowledge, referrals and various opportunities. You can click on this link and join: