Does IT need a “Open Source Compliance Officer?”


This is an interesting thought in an article in Information Week, citing the recent lawsuits that have been won by open source advocates. The article notes that Xterasys settled a lawsuit with the Software Freedom Law Center, where they admitted not following the provisions of the General Public License after downloading and incorporating Busy Box open source within their own product. The kicker is that Xterasys agreed to create the post of Open Source Compliance Officer to insure they would not violate the provisions of open source license obligations in the future.
For a software developer, tracking the use of open source is something they should be doing, just as tracking the use of proprietary software is something they should be doing. Providing that the software developer has a policy on open source licenses (they know the licenses which their organization would accept) the task of tracking what open source is used within the organization is relatively simple. If desired, Source Auditor provides the means to audit the code and set a baseline inventory, which can then be easily maintained.
IT’s Newest Title: “Open Source Compliance Officer”
Can the unfulfilled legal obligations of open source inside my source code really lead to lawsuits?


There have been a series of lawsuits related to unfulfilled legal obligations from open source licenses over the years. Verizon, for example, was sued by the Software Freedom Law Center on behalf of Busybox, which is a GPL licensed package. The claim was that one of Verizon’s subcontractors used a GPL licensed package in Verizon’s wireless routers, without fulfilling the re-distribution obligations of GPL. This claim was settled when Verizon’s subcontractor agreed to provide its source code free to the public.
Similarly, in recent years there have been similar successful claims against Cisco, Monsoon Multimedia, and Xterasys (see articles in the links section below). In the Cisco/Linksys case, Cisco chose to re-engineer their routers to avoid GPL based re-distribution obligations. Xterasys was settled when Xterasys agreed to pay an undisclosed sum and to meet their GPL re-distribution obligations. The Monsoon Multimedia case is still in litigation.
Open Source Governance – How can I manage open source downloads that my engineers make so we can maximize productivity but eliminate the risks of open source?


There are four recommended strategies for managing open source within the engineering environment:
- Establish an open source policy. The policy should identify the license types that are acceptable to the organization (perhaps such as Public Domain, MIT, BSD, and Apache), any considerations for particular modules or source directories that are already approved or disapproved, approval process for including open source and consequences for not following the policy?
- Isolate 3rd party and open source code in the source repository. Establish separate directories, or even separate repositories to hold the 3rd party code. Establish a naming convention that helps identify the package and version.
- Track the open source used. Track the URL downloaded from, the original package, the licenses, and any modifications to the original package.
- Review the check-ins and enforce the policy. For small companies, this can be done manually. For larger operations, commercial tools such as Source Auditor may greatly aid in the review of open source check-ins.