Much as some people would like to paint Open Source licensing as a viral disease that can cause untold problems for innocent software companies, the truth is a lot less dramatic.

Not a New Problem
Having to deal with "foreign" code under specific and sometimes restrictive licensing conditions isn't a new problem, nor is it confined to Open Source code. Many commercial software products contain code written not only by the companies selling those products but by other companies whose code components are licensed under different conditions.

The conditions for using third-party code have been different than for code licensed under the GPL. In fact, they are almost the opposite. Traditionally it has meant safeguarding the licensed code from disclosure, using it only for specifically licensed purposes, and paying the appropriate fees. Open Source licenses, on the other hand, typically require that the code be made available, letting it be used for just about any thing with no fees attached to its use. There may, of course, be other conditions attached to its use such as requiring that notice be given that it's included in a product, along with a copy of the license, or that the whole product adopt the same licensing terms.

Actually these are just a new set of license terms, and a price that a commercial software company has to evaluate as it would any other conditions. The decision to adopt the code or not is based on usual value for money and the commercial advantage of using proven, available code versus developing and maintaining yourself.

What's New
What's new is that Open Source code is freely and widely available and much more likely to find its way into a commercial product "accidentally" than conventionally licensed third-party code. This can happen in any of a hundred ways from an unthinking employee seeing "free" code and simply incorporating it in his project to an employee or contractor behind schedule deliberately incorporating it.

Of course, when any reputable software company discovers such a thing, it will take steps to correct it. However, correcting the situation may not be trivial. Assuming that GPL code has been "inadvertently" incorporated, there are essentially three ways of dealing the problem:

1.  Approach the author(s) of the code, explain what has happened, and ask them to re-license the code under an agreeable set of conditions for an agreed-upon fee. Given goodwill on both sides, this might be an acceptable solution. However, the code could be owned by too many people to deal with, or one of them may not want to license it under any other terms than those already established.

2.  Rewrite the functionality of the code in question and replace the Open Source code. The problem here is that this takes time to do. And during this time the company is in breach of the Open Source copyright. The Free Software Foundation usually takes a relaxed view when a company shows a willingness to correct the breach, but corporate lawyers are generally averse to spending any more time in a compromising situation than they have to. Developing, testing, and distributing a modified product (along with recalling the dicey one) can be expensive and for that reason not feasible.

3.  Re-license the whole product under the GPL. This is in certain quarters the source of the "viral GPL" claim that gets so much coverage. This may actually be a viable alternative in some cases, but in most it's probably not - either because it could potentially damage the business model that the product is based on or because there are other components in the product whose licenses would be violated by the GPL.

Of course, these same problems and solutions exist if commercially licensed code, meant to go into one product, finds its way into another. It's not a situation a company wants to be in wherever the illegitimately used code comes from. The only difference when Open Source code is involved is that it's more likely to be noticed and there's the possibility of a potentially unpalatable remedy - open sourcing all the product code.

Mainly a Big Company Problem
Managing third-party software components is generally only a problem for mid-sized and large companies. Smaller companies have smaller development teams that are typically aware of what each member of the team is doing, and are all generally aware of the existence of third-party code and the rules surrounding its use. In larger organizations more formal policies, procedures, and processes are generally required.

Usually these policies have focused on limiting access to the licensed code, which used to be a pretty good device. But Open Source code is freely available; traditional management policies can't deal with this.

So some companies have tried strictly enforcing a rule forbidding any Open Source code to be imported into their internal networks. This has two disadvantages. First, it shuts a company off from any the commercial benefits of using some Open Source code and products in a controlled way, which competitors may not be doing. And second, although it's relatively easy to contain a small amount of third-party code, it's hard to seal out an outside world that's awash in freely available Open Source code.

A Business Opportunity
Of course, one man's problem is another man's business opportunity, and this is a big enough problem dogging enough companies with deep pockets to attract a solution.

Perhaps the best-known solutions come from Black Duck Software (www.blackducksoftware.com) and Palamida (www.palamida.com).

Basically, they both take all the free software they can lay their hands on, and break it up into normalized logical units, calculate a signature (such as an MD5 checksum), and store in a database.

A customer anxious to verify that his latest product doesn't contain any unsuspected Open Source components then checks his source code against the Black Duck or Palamida databases for any matches.

As you might imagine, the key to the success of these system is in the algorithms and heuristics used to do the code normalization and determine the logical unit boundaries from which to calculate the signatures.

Both companies have created complete compliance management systems around this core technology. They are easily extensible to third-party code fragments. They can be processed to produce customer-specific databases to check against, so a final compliance verification of a product's source code can list what third-party and Open Source code is in it and list the relevant licenses so all of the license terms are both compatible and complied with before the product ships to a paying customer.

In many ways, the growing prevalence of Open Source software and its licenses has done the software industry a favor in forcing it to face up to the issue of IP management and give it the due diligence it deserves, but often lacked in the past.

Any self-respecting software development organization should be able to determine the origin of all the code used in a project, and product management should understand the licensing terms of each component and how they affect the final product.

If this can be done in the organized chaos of the Linux kernel development certainly it's not too much to ask of any "professional" software development organization?