Gone are the days when Open Source software (OSS) was only being used in educational institutions like universities, research organizations etc. Today most organizations use open source for a variety of reasons such as accelerating time-to-Market, reducing cost of development, dynamic integration etc. There are many software development organizations that work closely with their customers to determine open source strategy before making them a part of product / application development. By 2016, OSS is expected to be a part of all mission-critical software portfolios in 99% of Global 2000 enterprises, up from 75% in 2010. (Source: Gartner, "Predicts 2011: Open-Source Software, the Power behind the Throne" - 23 Nov 2010).

But there are some serious concerns around the usage of open source in commercial environments. It is imperative to keep in mind the following possibilities if you are considering going the open source way.

Intellectual Property (IP) Infringement:The licensing aspect of open source code poses some unique challenges. Some of the licenses are permissive, while the others are restrictive. If you are unaware of this, you face the possibility of being subject to a “breach of agreement” on one hand or being subjected to claims of copyright infringement on the other hand. In fact, there have been several instances where organizations were asked to stop the commercial distribution of product shipments and product recalls. Recently Oracle sued Google (GOOG), alleging patent and copyright infringement of Java-related intellectual property in the development of Android mobile operating system software.

In some cases, organizations have been asked to make the source code available, leading to potential loss of Intellectual Property, loss of competitive advantage and/or possible financial obligations because they were using code from the most viral OSS licenses.

Open Source Software can be susceptible to security vulnerabilities: At the end of the day, open source software is nothing but source code and like any other source code, it is susceptible to security vulnerabilities. If the source code is not tested rigorously before moving it to production, it leaves the door open for an adversary to compromise the application running in production. For example, recently, there was a major vulnerability discovered in Apache Tomcat which could lead to denial of service if not patched appropriately

Unknown Source: Open source components can be made up of other open source components or derived from other open source components. So, whose code is it anyway? The original code might have been issued under special GPL license or commercial license forcing the organization to indirectly oblige to licensing terms specified by the original author of the code.


They are everywhere, yet hidden: Let us assume that the organization has a specific policy crafted for open source usage but is unable to document all the open source and/or third party components that are being used within the organization. During one of the audit engagements, we observed that the organization had visibility of only 40% of total open source components in use. So the issue is “the organization uses open source software, but it doesn’t know where they are”. Obviously this can lead to security or legal issues.

The risk of open source usage does not lie in the usage of open source itself, but on how the open source code is being managed in the organizational environment. If the organization does not keep track of the open source code it has adopted, then it is very difficult and expensive to deal with obligations and vulnerabilities that are associated with it. So, there is a definite need to create an open source compliance management program (including an assessment checklist, training programs and software tools to monitor open source software usage) which can establish a framework for due diligence to ensure both the security and legal status of resulting application or product.

Author

Jaykishan Nirmal
Practice Lead, Aujas Networks