Using open source in your start-up and getting it right from the start

Virtually all high-tech companies use open source. Yet many of them have no procedures in place to manage or control this use even though it warrants due care and attention.

What is open source software?

Free and Open Source Software (FOSS, OSS or open source – which are often used interchangeably) refers to software that is licensed under terms that provide the liberty (i.e., freedom) to deal with the software by way of running it for any purpose, studying, changing and improving its source code, and copying and distributing it. FOSS fundamentally differs from proprietary or commercial software which are typically licensed under terms that prohibit copying the software, changing, reverse engineering or redistributing it.

FOSS licenses are usually classified by two major categories:

  • Permissive licenses (also known as “Academic Licenses”). These licenses permit the liberties mentioned above and impose restrictions and requirements that are usually few and quite easy to follow. The requirements focus on the need to provide proper notice and a copy of the license text to downstream recipients of the code. Typical examples of these include the BSD, MIT and Apache licenses.
  • Copyleft licenses (also known as “Reciprocal Licenses”). These are further subdivided into two categories:
    • Weak reciprocity licenses. These licenses require that a developer using the FOSS give recipients an opportunity to enjoy the same freedoms regarding the FOSS just as the developed had them. Hence, if you combine a FOSS that is under a weak reciprocity license, as a component within your own proprietary code, then subject to certain conditions you do not need to give your recipients access to the source code of the whole combined result, just access to the source code of the weak reciprocity FOSS component within it. Typical examples of these kinds of licenses are the Mozilla Public License and the GNU Lesser General Public License (LGPL).
    • Strong reciprocity licenses. The most famous and widespread of these is the GNU General Public License (GPL). One of the primary and often onerous requirements of the GPL provide that any software that is ‘based on’ a GPL’d FOSS, must itself be distributed under the GPL. What is or is not considered code based on a GPL’d FOSS is a highly debatable question. There is also extremely little case-law on this point, which leads to even greater uncertainty. The result is that integrating proprietary code with code released under a strong reciprocity license like the GPL may render the proprietary code itself subject to the provisions of the strong reciprocity license. This might then force the developer of the proprietary code to expose the source code of his or her own developed software. This is the so-called “viral” effect of strong reciprocity licenses.

The benefits and risks of using FOSS

Companies understand that using FOSS can enhance their ability to leverage technological, marketing and business opportunities. It can accelerate product development by using pre-existing FOSS code and reduce costs since most FOSS is offered free of charge.

But using FOSS entails certain risks. Legal liability can arise for violating even the relatively trivial requirements of FOSS licenses and even if the violation is unintentional. For instance, many FOSS licenses require that the full license text accompany every onward distribution of the FOSS component. Yet this seemingly trivial requirement is responsible for a surprisingly large number of compliance issues.

Yet another risk to consider is holdbacks in investment rounds and M&A’s because of insufficient due diligence information about the company’s use of open source components.

Moreover, in some circumstances, using a copyleft component can trigger the viral effect of a copyleft license. This viral effect then imposes the copyleft requirements on the proprietary software which in turn can require the disclosure of the source code of the proprietary software and the licensing of the proprietary software under the copyleft license – a result with detrimental effects to a company’s own IP.

A representative example is a lawsuit litigated nowadays against VMWare in Germany. The lawsuit alleges that VMware combined Linux code licensed under GPL with VMWare’s own proprietary code. The lawsuit claims that VMWare distributed the entire combined result without offering the complete, corresponding source code of VMWare’s own proprietary code under terms of the GPL.

A FOSS policy

In order to properly manage and mitigate the risks of using FOSS, companies first need to be aware precisely which FOSS they are using. The first step is having an organizational policy for compliant use of FOSS. The policy aims to facilitate the beneficial use of FOSS in the organization while preserving and safeguarding the intellectual property interests of the organization. It also aims to reduce the legal, business and operational risks that arise from the use of FOSS.

A FOSS policy establishes procedures for approving the use of FOSS at the company. It is based on the notion that the company should not use FOSS unless approved beforehand according to a predefined approval process.

A FOSS policy requires continuous internal enforcement within the company as well as education and training. Training is not about instructing developers and managers how to analyze FOSS licenses or how to review their legal implications. The purpose of training is to bring staff to a fair degree of awareness regarding FOSS risks and the established policy and educate them to understand that FOSS is not unrestricted simply because it’s freely available online.

Automated FOSS management tools

As a standalone mechanism, a FOSS policy has a number of disadvantages that are focused around the human factors of the policy.

The effectiveness of the policy clearly depends on cooperation on the part of developers. If developers use FOSS but neglect or forget to apply for approval, the organization may be heading for trouble. Development inertia, forgetfulness, pressures from project deadlines, lack of awareness or sheer indifference can bring developers to disregard the procedures of a FOSS policy.

Another disadvantage is the lead time for FOSS approval. The approval process may not be fast enough to meet the needs of development. Developers might view this lead time as an obstacle and this might incentivize them not to follow protocol.

Manually maintaining an exhaustive list of FOSS used is yet another disadvantage of a standalone FOSS policy. A list compiled manually will almost never be exhaustive. This is not only because developers might not report all FOSS they use but also because most FOSS includes numerous subcomponents and dependencies, each potentially subject to a different license. It is very difficult, time consuming and error-prone to rely on human eyes to inspect each individual FOSS file used.

Automated FOSS management tools are able to mitigate many of the shortcomings of a standalone FOSS policy because they streamline the entire FOSS management process and can automatically analyze, detect, audit and generate reports of the FOSS used in a software development project.

In short

Use of FOSS is widespread and entails legal, operational and business risks. A FOSS policy can help manage some of those risks if it is properly established and implemented in the company. At the same time, the human factor is a significant drawback of any FOSS policy but automated FOSS management tools can help overcome many of these drawbacks.

The information presented is not legal advice, is not to be acted on as such, may not be current and is subject to change without notice.

About the Author:

Att. Dotan Hammer
Dotan Hammer is a senior associate at the Internet, IT & Copyright practice group at Pearl Cohen Zedek Latzer Baratz. Dotan regularly counsels clients on copyright issues and open source matters, privacy and data protection, software and SaaS user agreements and licensing and other IT law matters.

Leave A Comment

Accessibility