Channels ▼


Managing Open Source Licensing

Principle Aspects of License Management

A complete approach to assuring open source license compliance will generally include three major aspects:

  1. Definition of a licensing policy which must be met by all software projects.
  2. Auditing of all project software to detect any third-party source code including open source that is unacceptable based on the licensing policy.
  3. Corrective processes to ensure that all released software conform to the licensing policy.

The creation of the licensing policy is an important step as it forms the basis upon which decisions regarding acceptance of open source software will be made. The licensing policy should be defined in accordance with both the business goals of the organization as well as its engineering processes, and generally requires the involvement of business and engineering managers, as well as legal counsel.

Software auditing is required to ensure production code conforms to the licensing policy, although the audit implementation can take a number of forms depending on the preference of the development organization. Audits can range from ad hoc developer training and post-development cycle auditing to proactive automated approaches such as periodic and real time auditing.

Options for Managing Open Source Licensing

The following options are available to address license compliance at different points in the development process.

  • Do nothing: This option ignores the compliance issue because it carries the lowest up-front cost, but imposes the highest business risks and largest corrective costs as a product moves closer to launch.
  • Developer training: Some companies consider developer training and project planning is sufficient enough. This however, can be an expensive labor-intensive option given the increasing diversity of software licenses, the high cost of developer training, and the constant churn within the development environment. With this option, compliance depends solely on busy developers and is prone to human error.
  • Post-development license audits: Auditing late in the project lifecycle does not impact the development workflow and can be implemented manually or using automated software tools. This option does, however, lead to more expensive rework due to additional system retesting cycles.
  • Periodic assessment: Licensing analysis during development allows for corrections along the way if license violations are detected. This type of analysis can be automated and tends to be less expensive than post-development assessment since changes and re-tests are always easier to undertake earlier rather than later in the cycle.
  • Real-time preventive assistance at the developer workstation: The most proactive approach is to audit software in real time at the developer workstation. The development process is not disturbed and the cost of corrections is minimal as there is no impact to system integration and testing. This process can be automated and generally requires very little developer training.

Regardless of the type of auditing approach, the overall goal is to minimize the time and cost of correcting the final software release so that it meets all functional, quality and license compliance requirements. Figure 1 illustrates how the cost of detecting and correcting "licensing bugs" escalates in later stages of the development process.

[Click image to view at full size]
Figure 1: Software development lifecycle phases.

Each organization must consider their approach, balancing the short term cost of developer training and tools versus the potential longer term cost of post-release legal problems.

Automating Open Source License Management

Tools are available to automate open source license detection and analysis. They can operate on demand, on a periodic schedule or in real-time within the development process. Generally such tools find compliance problems sooner, lowering the overall cost of license compliance and significantly reducing any risk of legal issues that could affect the deployment of semiconductor-based products.

Related Reading

More Insights

Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.