Channels ▼


Legal Compliance: Open Source and Quality Assurance

Bringing Legal Compliance Assurance into the Development Process

Figure 1 highlights the main options for addressing the legal compliance of software within the development process itself.

Figure 1

The #1 situation is highlighted in red because it's the one that should not be considered at all.

Some companies -- especially small and mid-size ones -- consider that proper training and project planning (#2 above) is sufficient in normal situations, accepting to undertake an audit during imposed due-diligence efforts. Naturally, the more the developers are trained on matters of software legal compliance issues, the more effective the development process will be. This is a rather expensive proposition, given the explosive growth in number of distinct software licenses, the high cost of developer training, and the constant churn within the development environment. Also, no warranty of compliance is available at the end of the project.

The next option is #3 which can take the form of external (a) or internal (b) auditing and fixing in the final stage of testing and quality assurance process. Using professional resources -- external or internal - is quite expensive. Some automatic tools for software analysis and detection of violations to an IP policy are available in the market [Ref 4], helping significantly reduce the auditing costs. Still, there is the matter of the costs and time-to-market delays brought about by the necessary "after-the-fact" corrections and the ensuing mandatory re-testing of the software.

Option #4 implies periodic auditing of the software project and follow-through fixes if any policy violations are detected. This can be done with automatic tools and is less expensive than Option 3 thanks to the shorter delays in getting the fixes done and re-tested.

Option #5 is clearly the best: having the detection of license violations right at the developer workstation in real time. The development process is not disturbed and the cost of corrections is minimized as the corrections necessary -- justification of selection, code changes or replacement -- are done on the spot without involvement of other resources and without need of re-testing. These tools are unobtrusive, easy to adopt and, most important, do not require any developer training in matters of legal compliance.

Software Lifecycle IP Management

The critical elements of software IP management in an organization are:

  • The existence of an IP policy for each project undertaken and a process to disseminate and apply it. Corporate IP policies must be based on the organizations' business goals and they should be clear and enforceable.
  • The availability of a central code library, which includes the legacy code in the organization, together with an automated process for ascertaining the pedigree of all components to ensure compliance to all legal obligations.
  • The processes and tools for ascertaining the legal obligations and managing the IP of software created and/or acquired in the organization.
  • The customer assurance and support concerning the quality and IP cleanliness of software provided.

The best results are obtained when record keeping and IP management are treated as integral parts of the software development and quality assurance process.

Modern software IP management tools allow the implementation of a simple and efficient process for managed open source software adoption which allows developers the freedom of selecting best solutions appropriate with the corporate IP policy. The main stages of such a process are:

  1. The definition and tool-capture of an IP policy together with the actions to be taken in case of violations.
  2. Ensuring the legal compliance of legacy and/or acquired code.
  3. The real-time detection and fixing of any IP policy violations by new code created or brought in by developers.
  4. The automatic verification of any code checked into the organization repository/library.
  5. The automatic product build-software analysis and IP policy compliance certification via a complete software BoM.

Such a software lifecycle management process ensures automatic compliance with the IP policy without imposing specific pre-approval of open source components. An optional stage dedicated to pre-approval of open source components and the management of a repository of approved open source can be considered as part of stage 3 above.


A cost model developed for understanding the economic implications of legal compliance of software and the impact of detection of IP policy violations within the development environment shows that:

  • Detection of IP policy violations at the build or QA stage may bring savings of 40 to 70% depending on the size of the project and the number of 3rd party software components it contains;
  • The preventive use of tools to detect IP policy violations right at the developer workstation raises the savings considerably to 60 to 95% depending on the size of the project, the number of developers and the density of third-party components.

Fortunately, nowadays there are tools at our disposal to do pedigree analysis and IP policy violation detection automatically -- on demand, on schedule or even in real time within the development process. Some of these tools lend themselves well to an institutionalization of proper record keeping and safe software development practices. As the critical factors driving the economics of software IP management are the efforts to fix the software IP issues and minimize the associated delays in product introduction to market, everything should be done to ensure its legal compliance throughout the development process and have the Quality Assurance process issue an appropriate software BoM.

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.