Overview of Open Source Software Governance in Projects

In an earlier post, I introduced the topic of the increasing use of Free & Open Source Software (FOSS) in Digital TV projects. This post provides a brief overview of the various areas to consider as part of managing open source software in projects.

I am pleased to share this as my first guest blog post, by Steven Comfort. Steve works as a Software Compliance Analyst, we crossed paths when I started searching for support & consultancy on implementing an end-to-end FOSS governance program. This is still a work in progress, but we'd like to share with you our take of our experience / learning to date - in the hope it would help others who might be thinking of doing the same...

Open Source Compliance

With the partial exception of mobile phones, the embedded device operating system wars can realistically be said to be over, with Linux in its various flavours emerging as the clear winner. Coupled to the proliferation of open source software stacks and applications, it is highly unlikely that any device you purchase will be devoid of open source software.

When Free and Open Source Software first started penetrating traditionally proprietary software solutions, many people were sceptical and the cliche "There is no such thing as a free lunch" were commonly heard. Hopefully this short piece will assuage those suspicions, because there is in fact a cost associated with using open source software. Put simply, this cost is associated with fulfilling the license obligations concomitant on that usage.

Open Source Licences

The Open Source Initiative is recognised as the custodian of the definition of what an open source license is. (www.opensource.org). Simply put, open source licenses can be broadly categorised into three types:

• Restrictive 
• The classic examples are the various General Public Licenses (GPL) that are designed by Gnu. These ‘copyleft’ licenses mean that integrating open source code and proprietary code must be done with great caution if the tag of ‘derivative work’ is to be avoided. Putting it as simply as possible, if your proprietary code relies on GPL’s open source code in order to compile, then the chances are high that your proprietary work would be considered a derivative work. Under the terms of the GPL license, your hitherto proprietary work must be made open source.
• Intermediate
• The classic example is the Lesser GPL (LGPL). Here you may link against the open source code, without the code that you are linking being considered a derivative work.
• Permissive
• Examples are the Apache, BSD and MIT license families. Pretty much all rights are granted to the user of software under such licenses, with the concept of derivative work not being present.

A nice visualisation of the above is shown here (courtesy of David Wheeler's slide):

Common to all the categories of licenses are the basic requirements to:

• Disclose the usage of the open source within the product
• Attribute copyright and propagate the license terms
• Disclaim any warranties by the original author of the open source software.

In essence these common properties are about respecting intellectual property rights.

Elements of Compliance

The activities comprise the elements of a FOSS compliance program are:

• Discovery & Closure
• Review & Approval
• Obligation Satisfaction
• Community

Disclosure and Discovery

Before open source obligations can be fulfilled, an organisation needs to know what open source packages (and associated licenses) are contained within a build. This generally involves two practices:

• Disclosure
• Here your development team or contractors tell you what open source they either have used or plan to use. Typically a review board would exist that would certify the usage of specific software packages and licenses. (Generally GPLvX will be deprecated).
• Discovery
• There are many reasons why you may not know of the presence of open source in your code base such as: developer churn, sub-contractors, legacy code. Even more problematic is identifying what code may have originated from an open source project, because headers and copyrights may have been stripped. To resolve this one would generally utilize one of the commercially available scanning tools. Such tools are relatively big-tciket items costing in the tens of thousands of dollars per annum. Major vendors include Black Duck Software, OpenLogic, Palamida and Protecode.

Review and Approval

Having identified the licenses associated with each open source package contained in the code base, the next step is to get the legal department to specify what the associated obligations are.  In addition to this, the legal department in conjunction with a review board should approve packages and licenses for use within the organisations products. The aim should be to build up a database of approved packages that may be used by developers without having to seek prior approval.

Obligation Fulfillment

Depending on the license obligations this will vary from releasing the package plus modifications and any derivative works, to simply acknowledging copyright. The general approach is to direct the end users of a device to a corporate website. This website should display all open source license information associated with a particular product, as well as links via which the end user may download the open source package(s).

Community Involvement

Open source software is very much a community driven approach. To successfully leverage open source, interaction with the community around a particular package is very helpful when modifying or porting the package for instance. Organisations should publish a policy governing the ways and means by which their employees may interact with open source communities.

Other: Strategy and Policy

As with all processes, these are vital elements. The strategy should be determined by personnel at C-suite level. Strategies may vary on a spectrum from “Open source is the devil’s work, and all usage is banned”, to “Open source offers fundamental development advantages and shall be leveraged to the greatest possible extent”. Once you know what the strategy is, write a policy that defines inter alia what the usage policy is, who governs open source usage, what the penalties are for not following the policy, contact points, roles and responsibilities. Typically the structure of such policies will be dictated by whatever process framework is followed by your organisation (CMMI, CoBIT, etc).

Other: Handling enquires

A procedure needs to be in place to handle enquiries from end-users regarding open source content. This procedure should be customer service oriented, and should aim to handle enquiries rapidly and professionally. A typical flow during an enquiry is illustrated below.

Sample Procedure Flow

Further Resources

As the official custodians of Linux, the Linux Foundation should be your go-to place for more detail. (www.linuxfoundation.org/). In addition to a wealth of white papers about open source compliance, the Linux Foundation also offer very comprehensive training programs on the subject.