A blueprint for open source software adoption

Mahshad Koohgoli |
March 14, 2011

Open source software is probably the most defining element of software innovation in the last decade. But the complexity of today's development environments makes open source license violations a real and common possibility.

FRAMINGHAM, 14 MARCH 2011 - This vendor-written tech primer has been edited by to eliminate product promotion, but readers should note it will likely favor the submitter's approach.

Open source software is probably the most defining element of software innovation in the last decade. But the complexity of today's development environments makes open source license violations a real and common possibility. After all, today's software combines elements of open source, commercial and other third-party code as well as contributions from developers and outsourced developers. By the time all of the pieces are integrated, tested and readied for release, it can be difficult to understand exactly what is inside.

It can be costly and time consuming to perform the required due diligence to identify what problems exist, so naturally it is best to adopt safe development practices early on in the process. A preventive approach, aided by policies, education and automated tools, goes a long way to avoid license compliance issues.

Increasingly, organizations are viewing open source and third-party software license management as part of their software quality development process. The quality checklists may include all or part of the following blueprint.

The organization in this context can be a product group, a project group or the whole company. The policy addresses questions such as what license terms are acceptable and unacceptable, what vendors are approved, and what software products or packages are authorized for use.

The policy also defines the procedure for pre-approval of packages, for auditing software at different stages of development, and what to do once a policy violation is detected. Capturing the licensing policy digitally allows linking the policy with automated license management tools used in other steps of an open source software adoption policy.

Typically the business manager, a licensing or legal counsel, and a representative of the development agency define the policy and the mandated workflow for the detection of policy violations in the code base.

2. Software package pre-approval. This optional step defines and implements the procedures that determine approved software packages in an organization. Pre-approval is required in companies with tight third-party software policies to ensure only a limited set of packages of specific release versions are used. Software package pre-approval process involves the following steps:

a. Requests -- where a developer can request a specific package to be authorized. The request contains as much information about the package as possible such as its name, authors, license, pointers to where additional information can be found or package could be obtained.

b. Logging -- where a request database tracks requests and their approval status.

c. Investigation -- where the examiners can examine a request; an examination usually requires an audit of the requested package (manual or automated scanning).

d. Approval (or rejection) of the request.

Once a software package is approved, the package approval is logged and its status is available to the organization.

3. Existing portfolio assessment. This necessary step involves auditing the existing portfolio and establishing a baseline of what already exists in the organization. Establishing a baseline is best done with an automated tool, ideally linked to the digitally captured licensing policy and, if the organization has implemented package pre-approval process of Step 2, also linked to the database of pre-approved packages.

4. Incoming third-party software assessment. This necessary step involves a software licensing audit of any package that is brought into the organization. In this context, third-party software could be the content delivered by the outsourcers or the contractors to the company. It could also be any software that is brought in for evaluation, purchased from a vendor, or an open source package, even if the organization has implemented package pre-approval process of Step 2.

Similar to the audit carried out in Step 3, this step ensures there is a full knowledge of, and compliance with, the licensing policy of Step 1. The audit is carried out using the same automated tools used in the previous step, again linked to the captured licensing policy and pre-approved package databases.

5. Regular software assessment. This stage, although popular, could be bypassed if automated library check-in or real-time preventive assessment steps as described in steps 6 and 7 are practiced.

Regular software audits are best carried out on predetermined intervals (e.g. weekly or monthly). An automated tool, again linked to the licensing policies and pre-approved package database, is invaluable here. Intelligent tools can detect the "new" software compared to the software that was previously analyzed. The scanning process can be carried out very quickly since the content-delta between the scans is typically small.

6. Real-time library check-in assessment. This optional step ensures that any content committed to the organization's source control management system is well understood from a licensing obligations viewpoint.

Library check in-assessment provides a near-real-time visibility of the content that could find its way into a company's products. Any deviation from established organizational policies that are detected and remedied at this stage would reduce the time and costs of remedial actions further down the road. Any practical implementation of this step requires an automated auditing tool linked to the software library system, licensing policies of Step 1 and Step 2.

Any deviations from organization policies should be automatically flagged to the person checking the content into the library. Scanning reports should be examined, and the offending content should be removed, sent for package pre-approval, or tagged for further investigation.

7. Real-time assessment by automated developer assistants. This optional step is highly valuable in that it ensures licensing compliance right at the developer workstation.

This procedure is only possible and feasible if done automatically and carried out in the background without disrupting development. During the course of development, a developer may access content from a Web site, download a whole package from an open source forge, or bring in content already accessed from a storage medium (such as a USB stick).

An automated tool called a developer assistant that is integrated within the developer workstation detects new software files and analyzes them in the background. Linked into the captured organizational licensing policy (Step 1) and a database of pre-approved packages (Step 2), it can instantly alert the developer of any potential violations and allow them to either remedy the problem or enter a comment and continue.

8. Preshipment software assessment. This necessary step ensures there is a full understanding of the content and obligations associated with the product before it is released to the market.

Again, automated tools, linked to the final build process, can simplify the task and provide an accurate list of software packages and components used in the shippable product. A final license list, together with an actionable list of all license obligations depending on the way the packages are used, completes the release checklist. Any license incompatibilities will be clearly highlighted at this stage.