Imagine That IP Law Blog

Software development has become a driving force behind innovation and progress across many industries. A key factor in this development is open source software, which has transformed the way technology is created and shared. In this article, we’ll discuss open source software, the risks associated with using such software and strategic insights for corporations who use open source software.

What is Open Source Software?
Open source software (OSS) is computer software that is licensed in a way that allows its source code to be publicly available. This allows anyone to view, modify, or distribute the software. The term “open source” generally refers to a community-based approach of creating intellectual property via collaboration, transparency, and frequent public updates. An important principle of OSS development is peer production, with products such as source code and documentation being made freely available to the public.

“Source code” is the part of the software that most computer users never see – it is the fundamental component of a computer program that is created by a programmer and allows them to manipulate how a piece of software works. Developers who have access to a program’s source code are able to improve that program by incorporating new features or fixing existing issues.

Open Source Software Licensing
In many ways, OSS is a license as much as it is computer code. Available licenses vary in their approach. OSS licenses encourage an exchange of information, the overarching goal being the development of better software and providing free and greater access to all users. These licenses try to balance the needs of end users with the need of developers.

OSS is typically distributed with a license that grants users the right to use, study, modify, and distribute the software and its source code. Each license is different, and each may have specific terms and conditions, such as requiring derivative works, (programs based on the software program), to also be open source.

The Open Source Initiative (OSI) is a non-profit organization relied upon by many governments, non-profit organizations, and multi-national corporations to identify computer software as “open source”. OSI has published a list of specific requirements for the organization to consider a product open source. According to OSI, the distribution terms of open-source software must comply with the following criteria:

1. Free Distribution. The license shall not restrict any party from selling or giving away the software as a component of an aggregate software distribution containing programs from several different sources. The license shall not require a royalty or other fee.
2. Source Code. The program must include the source code, and must allow distribution in source code as well as compiled form. Where a product is not distributed with source code, there must be a well-publicized means of obtaining the source code for no more than a reasonable reproduction cost, preferably downloading via the Internet without charge. The source code must be the preferred form in which a programmer would modify the program. Deliberately obfuscated source code is not allowed.
3. Derived Works. The license must allow modifications and derived works, and must allow them to be distributed under the same terms as the license of the original software.
4. Integrity of the Author’s Source Code. The license may restrict source code from being distributed in modified form onlyif the license allows the distribution of “patch files” with the source code for the purpose of modifying the program at build time. The license must explicitly permit distribution of software built from modified source code.  
5. No Discrimination Against Persons or Groups. The license must not discriminate against any person or group of persons.
6. No Discrimination Against Fields of Endeavor. The license must not restrict anyone from using the program in a specific field of endeavor.
7. Distribution of License. The rights attached to the program must apply to all to whom the program is redistributed without the need for execution of an additional license by those parties.
8. License Must Not Be Specific to a Product. The rights attached to the program must not depend on the program being part of a particular software distribution.
9. License Must Not Restrict Other Software. The license must not place restrictions on other software that is distributed along with the licensed software. For example, the license must not insist that all other programs distributed on the same medium must be open-source software.
10. License Must be Technology-Neutral. No provision of the license may be predicated on any individual technology or style of interface.

Although OSI requires the above guidelines to be met for a product to be considered open source, it is not necessary that the author of OSS strictly follow these guidelines. Some licenses may impose more rigorous or lenient distribution requirements. For example, some more user-friendly OSS licenses merely seek proper attribution of the licensed work and the free distribution of the source code of the licensed work. Other OSS licenses impose more rigorous distribution requirements, and potentially require that software incorporating the open source components also provide users copies of the proprietary software.

Open Source Software vs. Proprietary Software
The “open source model” is a decentralized software development model that encourages open collaboration. In contrast, some software has source code that only the person, team, or organization who created it can modify. This type of software is referred to as “proprietary” or “closed source” software. The open-source movement began as a response to the restrictive licensing model of proprietary software.

Only the original authors of proprietary software can legally copy, inspect, and alter that software. In order to use proprietary software, computer users must agree, (usually by “signing” a license displayed the first time they run this software), that they will not do anything with the software that the software's authors have not expressly permitted. Microsoft Office and Adobe Photoshop are examples of proprietary software.

Computer software companies that sell proprietary software are particularly concerned about duplication and distribution. In reaction to the ease of copying, the software industry and the electronic publishing industry have turned to shrink-wrap and click-wrap license agreements. These licensing agreements are designed to extend protection for the software producer beyond that offered by copyright law.

Shrink-wrap agreements are license agreements which state that acceptance on the part of the user of the terms of the agreement is indicated by opening the “shrink-wrap” or other packaging of the software, using the software, or by some other specified mechanism of acceptance of the terms. An agreement is formed when the purchaser or licensee accepts those terms by its conduct, (i.e., the retention or use of the software). Shrink-wrap agreements have been found to be valid and enforceable following the seminal case of Pro CD v. Zeidenberg, 86 F.3d 1447 (7th Cir. 1996).

Click-thru licenses are similar to shrink-wrap agreements, but eliminate the need to physically open a package or break a seal. A click-thru license, (also known as a click-wrap license/agreement,) confirms a user’s consent to a company's terms and conditions by clicking some form of "OK" or "I ACCEPT" button provided by a dialog box or pop-up window. In the reported cases that have challenged the validity of such licenses, the terms of the contract have been upheld.See Feldman v. Google, Inc., 513 F.Supp.2d 229 (E.D. Pa. 2007) (upholding forum selection clause); I. Lan Sys., Inc. v. Netscout Serv. Level Corp., 183 F.Supp.2d 328, 336 (D. Mass. 2022) (upholding a clickwrap agreement on two grounds: first, clickwrap is simply “Money now, terms later” contract formation; second, the court found that the “additional terms” of the clickwrap license was not material under UCC §207(2)(b).)

Risks of Using OSS

While there are clear benefits of using OSS (i.e., free to use, periodic improvements), its use may also pose significant legal risks to companies using such software. Many software developers are unaware of the risks of using OSS. Additionally, if a company uses independent software developers, it may be difficult to trace the origins of the different software development tools or components used in creating a program, and the legal obligations attached to the various OSS licenses.

OSS “Tainting”
One of the biggest risks to companies using OSS is that its own proprietary software may be “tainted” by a duty to open its source code to others. Some OSS licenses require that if any software is derived, in whole or in part, from OSS code, then the developed software must be licensed under the terms of the OSS license. The use of OSS code can have two major consequences: 1) the source code for the developed software must be made available to recipients of the software; and 2) recipients must have the right to copy, modify, and redistribute that developed software at no charge.

These rules generally apply to modified OSS that is distributed to third parties. There may be different, or fewer, obligations for modified software that is not distributed to third parties, and is used solely internally. Please note that OSS licenses can vary greatly, and each license can have its own specific terms and conditions. It is important to review the individual license terms of any OSS used to ensure compliance with its specific obligations and restrictions. If there’s any uncertainty, legal advice should be sought.

OSS Concerns with Software as a Service (SaaS)
On-demand software, also known as software as a service, (or SaaS,) is a software licensing and delivery model in which software is licensed on a subscription basis and is centrally hosted and available over a network. Under many OSS licenses, obligations can be triggered when software that contains OSS code is accessed by a third part over a network. These “network access” licenses can impose obligations even if the OSS is not actually distributed to customers, but rather is used in SaaS deployments.

Assumption of Legal Obligations
OSS is typically provided to users “as-is” with disclaimers of warranties, indemnities and other liabilities. However, an OSS license may require that if users make a commercial distribution of software using OSS components, the user may assume legal obligations such as indemnifying upstream developers for certain legal claims.

Strategies for Using Open Source Software
The risks and consequences of using and licensing OSS clearly indicate the necessity of identifying and reviewing such licenses and compliance statuses. However, while established case law has upheld the enforceability of OSS license provisions, most software developers and companies are generally unaware of the implications of OSS licenses and how to tackle incorporating and monitoring OSS licenses and compliance statuses. As a result, a few specific considerations for developers and/or software companies may be important to minimize any risk in using OSS licenses.

• Think about OSS as early as possible during developmental stages: OSS licenses should be addressed early, preferably in the developmental stages of the software being produced. Educating development teams, including outside contractors, early about OSS license compliance risks and ensuring that processes are in place to ensure compliance would be beneficial. The OSS used in a project should be tracked at all stages of development. These steps can help reduce the risk of a license breach at an early stage and help protect access to the company’s source code at an early stage.
• Identify who should be included in the process: Identifying personnel that should be included in the implementation, licensing, and review of OSS licenses is essential. Legal teams may mistakenly believe that developers are aware of the requirements of using OSS. It is very rare for development teams to have clear policies regarding OSS license obligations. Organizations are surprised to see large differences between what they think is being used and what is actually being used.
• Determine how you are using the license: Finally, determining how the OSS will be used by or with the developed software, and review the OSS license terms to ensure compliance with the provisions of any associated OSS license. Although using OSS solely within an organization may appear to impose fewer legal obligations, every OSS license is different and must be reviewed carefully. Additionally, future business plans may trigger different obligations based on the terms of the relevant OSS license.

Takeaways
The use of OSS can be beneficial to an organization in efficiently and economically developing products and services that are critical to the organization.  However, it is important for the legal team to ensure that developers are aware of the responsibilities and legal ramifications of OSS use.  Educating teams early, and tracking the origin and use of OSS components will greatly reduce potential legal exposures in the future.

Reprinted with permission from the June 28, 2024 issue of The Legal Intelligencer ©2024 ALM Media Properties, LLC. Further duplication without permission is prohibited. All rights reserved.