Mohiuddin Khan Inamdar, Senior Solutions Architect at Xavient Information Systems
The risk of OSS contamination has grown increasingly high, especially as more software companies use open source software (OSS) to create proprietary software products, in order to beat the ever shortening time to market. In our effort to understand Open Source “License Contamination” in the simplest of forms, let’s consider an example of books. The government grants authors, a temporary monopoly of distribution of their books, which is called a copyright. That means, for the time that the book is copyrighted, nobody can create copies of the piece for distribution. A sort of similar logic applies to code as well. The source code is copyrighted by authors too and the author decides the rights to use this code. Contamination most often occurs when software developers combine OSS with their own proprietary code.
The Open Source Software (OSS) movement encourages the disclosure of source code and is facilitated through copyright licensing. OSS is often referred to as “Free Software”, but the catch is that it is not a “freeware”.
Most, but not all, OSS licenses put significant conditions on the modification or re-distribution of the source code; whereas some OSS licenses, such as the MIT or BSD license, are more “freeware”- with only minimal conditions on developers such as copyright attribution or disclaimers of warranties. Mostly, the source code is no less than a secret recipe and it is believed that competitors too can learn much from this, thus making organizations often carefully guard it. But not all developers are of the same thought, some do see benefits and opportunities in making their source code available, and the intersection of these two mindsets creates unique legal challenges. Essentially, OSS developers disclose source code to recipients with the thought that this would initiate innovation in the industry and the collaboration would lead to efficient and effective software solutions.
In order to reduce the time to market, software developers many a times run afoul of important open source licensing rules, which eventually leads to infringement suits and copyright complaints. The most frequently-used OSS license is the General Public License (GPL), which allows the use and modification to GPL-licensed source code. For instance, if you distribute your application free of cost, and use GPL or any third party GPL code as part of your application (considering only linking at run-time to a library), without changing the GPL software in any way –even then you must always make the source of your application available.
As the OSS community continues to grow, so has the enforcement of the Terms of Use included with each OSS license.
How to Avoid License Contamination
Open source contamination can quickly spiral into a serious legal issue, as well as a PR nightmare, which can have serious financial implications and not to mention time loss. There are ongoing high profile lawsuits against large corporations failing to fulfill the open source compliance. Typically, an organization risks making the source code for their proprietary product public and available for anyone to use, free of charge. To mitigate this risk, we require more employee education, more approval cycles and even more internal audits. Hence, here are few tips to prevent contamination during the software development cycle:
- Educate People across organization, including your stakeholders
Most software companies believe that providing access to the source code would give undue advantage to competitors. This is surely a huge risk and thus, this advice is as big as it sounds. It is necessary to make people understand the types of open source licenses as well as their implications in terms of legal, costs and time. It mitigates the risks involved, to a great extent, as everybody is aware of the rules and equally careful while using it.
- Organizational Licensing Checkpoint Authority
Scan the software. This step is indispensable. There are products and outsourced vendors available to do this at negligible costs and are definitely worth the expense in the long run.
- Setup Company Policies
Make it a set companywide policy. Don’t allow the use of any open source code in any of the projects. This may sound counterproductive, though but there are many companies that follow a “zero tolerance” policy against using OSS in order to avoid contamination. Having said that, it still needs to be kept under check, as the code may still enter the existing codebase via helpful websites inadvertently, via developers trying to solve common issues.
- Acquisitions and Purchases
Many a times, software is purchased or acquired via mergers and goes unchecked for contamination issues. Thus, due diligence is a must. Also, procuring codes via bidding websites brings in increased risk of licensing and other risks such as disclosure of secrets, patent complications, etc.
In most cases preventing contamination is as simple as doing your due diligence when it comes to reading and understanding the OSS license’s Terms of Use. A careful inspection by an appropriate agent should keep your company free from violations.
