Open Source (OSS) Licenses
Currently, open source software (OSS) usage not only represents an ever-growing portion of the software market, but is nearly a necessity of doing business and developing modern software. Utilizing OSS software allows companies to leverage the work of large communities and benefit from the collaboration of those communities’ users to create better software with lower costs.
While this approach allows speed and efficiency that writing proprietary code cannot, individuals and companies that use OSS must be aware of and understand the licenses that come with OSS.
What is Open Source Software?
In the software industry, open source refers to a specific approach to building software projects. Open source software is software whose source code any user can view and modify, with source code referring to the code that programmers write and manipulate to change software.
Making source code available to users allows them to customize and improve programs to their liking, and allows them to add on to code or make modifications to optimize it to accomplish different tasks.
Software that is not open source code is known as closed source or proprietary code, the source code of which can only be seen or accessed by the creator or group of creators of the program. Examples of this proprietary software are often programs from large, corporate software companies like Microsoft.
One thing that both open source and proprietary programs have in common is that both software types require users to agree to follow the guidelines spelled out in a license. These licenses provide terms and conditions of use, outlining what users can and can’t do with the software. Within these licenses, however, the language and legal terms of open source licenses can differ dramatically from those in proprietary software licenses.
Open Source Licenses
Open source software is usually not in the public domain, and is generally only available for use under the aforementioned licenses. These licenses provide legally binding restrictions in terms and conditions that users must agree to whenever modifying or otherwise consuming OSS. The licenses specify under which conditions users can legally use, modify and redistribute OSS, with failure to comply potentially putting organizations at risk of lawsuits or relinquishing exclusive ownership of proprietary code that uses OSS.
In some repositories for OSS, no license is listed with the source code. In this case, default copyright laws may apply, but the use of OSS without a license is considered inadvisable as it may contain tainted software and is therefore not recommended for commercial use.
Types of Open Source Licenses
There are a multitude of different OSS licenses, all created by different individuals and organizations, and all with their own unique terms. The most notable differences in many of these licenses are the rights granted to users when they distribute software containing OSS, be it modified or simply added in with other code. Most licenses fall under one of two categories:
When distributing software containing OSS under a copyleft license, any software added onto or used to modify OSS must be made open for use. This means that if a user’s program is based on or comprised of OSS in any way, that program must be made OSS itself if it is released for use. Some examples of copyleft licenses include the GNU General Public License (GPL) and Microsoft Public Licenses (Ms-PL).
Permissive licenses on OSS software are far less strict about the use and release of software containing OSS. These licenses are sometimes referred to as “Anything Goes”, as they grant large amounts of freedom of use, modification and distribution.
Permissive licenses also allow proprietary derivative work, meaning that if software is released that contains OSS, users are not required to release the source code.
Risks Involved With OSS Licenses
Failure to follow the requirements of OSS licenses can result in legal repercussions, including copyright claims and lawsuits. In these disputes, offending organizations can be forced to spend time and money either changing their product or paying licensing fees if they are found to have violated OSS licenses. This can occur when programs that contain OSS are distributed without source code, against license requirements.
Legal trouble can be avoided by forcing violators to change their code to comply with restrictions, however, this may be unfeasible due to the time and financial commitments that this code modification would require. Another common remedy is requiring the offending company to pay licensing fees to the IP owner.
Two relevant cases involving legal disputes over software licenses include Google v. Oracle and SCO Group v. IBM.
Google v. Oracle surrounds Google’s use of the application programming interfaces (API) used in Java, a subsidiary of Oracle. Oracle claims that APIs are copyrightable, and that Google didn’t have legal right to use them. The results of this case, still being contested in the Supreme Court, has significant implications for the future as it will possibly redraw the boundaries for where copyright laws apply in software.
SCO Group v. IBM involved the use of the Linux operating system, in which SCO Group claimed ownership of key parts of Linux, and further claimed that IBM had violated licenses while developing Linux code. SCO additionally threatened several other corporate users of Linux with legal action.
Failure to follow the terms and conditions manifested by OSS licenses today can cost individuals and companies time, money and energy down the road. Even without a cash payout or relinquishing ownership of proprietary software, license violations will create added work and an unnecessary hassle that can be avoided be keeping OSS licenses organized.
Clearly, the risks in incorporating open source software into your products can be significant as these cases show.
How do you know what open source software is being used in the software products you’re developing and what your risks are? By utilizing a Software Composition Analysis solution like SOOS, you’re kept aware of OSS packages being used in your projects and the license implications of each.