In a commercial software company, it is common practice for software developers to download free open source and incorporate that source within their own software. Most developers ignore the license obligations that come with the software. They usually think that because the software is royalty free, the license obligations probably don’t matter.

In many cases, though it does matter, at least if the software developer is using the open source software inside the commercial product, and distributing the open source to external customers.

Open Source comes with a variety of licenses. Some like public domain have no restrictions or obligations for the software developer using, distributing, or modifying either the source code or the object code.

Other licenses, though, can have restrictions on distribution or modification of the software, and can impose obligations on attribution and re-distribution of the software.

For approximately 60% of the open source packages, there is also a provision called “copy-left” which can go viral, and contaminate the proprietary commercial software which is not open source. For many commercial software developers, this is considered unacceptable.

Of course, many organizations have negelected these open source obligations, which has recently led to a series of lawsuits. In most of the lawsuits, the courts have ruled that open source license obligations are enforceable, even if no money changed hands. Thus, it is no longer a prudent option for commercial organizations to download and incorporate open source inside their commercial products without attending to the license obligations that come with that open source.

All of this leads to the need for the commercial software developer to create polices about incorporating open source inside the commercial software and to scan for open source using either manual methods or a professional open source audit firm such as Source Auditor.

Essentially, the commercial software organization needs to decide which open source licenses contain obligations and restrictions which are acceptable to that organization, and which licenses are not acceptable. For example, the organization could create an approved license list, for example (Public Domain, BSD, MIT, Apache, SUN Binary License, Common Public License and its derivatives), while considering other license such as GPL or LGPL not approved.

The organization should also audit its current commercial software to understand a census of open source inside. Any open source inside which does not meet the organization’s policy as posing acceptable obligations and restrictions, should be replaced.

This policy should then be enforced going forward, ie, when a software developer downloads open source and considers incorporating it into the commercial software, the policy should specify whether the license that comes with that open source is an approved license for that organization or not. There should be a review board that would review new submissions to decide if new licenses should be added to the approved list.

For more information about Open Source License Obligations and about tools to audit and track open source

Firms Struggle With Open Source

Comments are closed.