Open Source License using in corporation - lowlights

Developing Code in the Open-Source Kitchen
Philip H. Albert, newsfactor.com
June 8th, 2005

magine you love Italian restaurants but you are highly allergic to garlic. To ensure your meal doesn't make you sick, you could carry around a mass spectrometer to detect the particular chemical signature that gives garlic its characteristic odor and flavor. An easier way might be to watch the kitchen prepare your pasta and note what ingredients they use.
ADVERTISEMENT

Like food lovers, software developers and companies with products that depend on software can get allergies too and must watch the proverbial kitchen to make certain everything turns out just right. For example, improperly incorporating someone else's intellectual property into a development project can make a company and its customers sick.

Copying -- or the incorporation of somebody else's protectable software without a license -- is copyright infringement. It can lead to disruptions in product releases, legal liability, public humiliation and a rash of other problems.

Understandably, everyone who produces software should be concerned that any use and distribution of products that include the code of others is done within the specific license that covers the included code.

Allergic Reaction to the GPL

Many software executives break out in hives at the mere mention of the General Public License. Most likely, this is due to the section of the GPL I call the "restriction on downstream restrictions." This clause sets the GPL apart from other open-source licenses that allow downstream users to license derivations restrictively.

Essentially, the GPL says that you can do whatever you want with the software you licensed under the GPL, except that you cannot add restrictions when you license out the software or a derivation of the software. This causes heartburn as developers want to maintain restrictions on their own code yet still benefit from the open-source code. But the combination of the two often can be considered a derivative work, which requires compliance with the license on the open-source software used.

While many open-source licenses do not have such restrictions, this restriction against downstream restrictions makes the GPL a popular choice among open-source program creators, lest they see their freely contributed code coopted into someone else's expensive program. Like hay fever, we just have to live with it.

Open Source Is No Different

The concerns over open-source inclusions are no different than concerns over incorporating any intellectual property of others into a product. Inclusion of someone else's open-source code without the necessary license is just as harmful as inclusion of someone else's trade secrets.

Granted, usually it is easier to get hold of someone else's open-source code than it is to conduct industrial espionage, and often it can be obtained without any purchasing department oversight. But, however the intellectual property of others is obtained, there has to be a moment where someone says "Hey, here's some code we should include in our code base for our new product."

Training programmers, project managers and code custodians is the key to avoiding improper inclusion of the intellectual property of others. At minimum, someone should document what chunks of code came from where. Everyone involved has to understand that they cannot include code without knowing where it came from and informing the custodian of the code.

Whatever area of the organization is charged with tracking such inclusions -- whether it is the legal department or the project-management department -- someone should be able to produce a list of what was included and the license under which that inclusion was brought in.

Automated Code Detectors

Several vendors currently offer systems or services that can scan a project's code base to detect the use of open-source software. It is likely these systems do more than look for the string "Licensed under the GPL" in the comment fields.

As some of their literature describes, the systems scan for signatures of known open-source programs. This, of course, requires knowledge of most open-source programs and their probable variations. It also requires constant updating as is done with virus signatures.

Such an approach is not nearly as reliable as checking the code at the outset. Code signatures assume that the detector vendors have access to all relevant open-source code. This seems unlikely, given that many code writers who choose the GPL write software programs informally. They don't spend time ensuring that their code propagates to all the popular code repositories.

Meanwhile, back at the Italian restaurant, let's change the scenario slightly. Instead of watching food preparation in your own restaurant that you control, imagine yourself someplace you've never been -- where the unexpected is commonplace and you don't control a thing. Such is the case with licensing code from other developers for inclusion. In such cases, signature checking is probably the only way to detect potentially dangerous inclusions.

If you inherited code, or you are licensing code from a third party that you cannot entirely trust, then go ahead and run the code through a detector. Just remember to rely on it only so far as the detector vendor is willing to guarantee accuracy.

Legal Implications

Legal institutions necessarily trail business and technical developments, and open-source usage is no exception. There are not yet any hard and fast legal rules about what happens when an organization is spotted using someone else's open-source code that is not entirely in compliance with the license for that someone's code.

Even IBM (NYSE: IBM - news) v. SCO is not strictly such a case. So even if it ends up making case law, it might not apply to many situations. Most instances of code inclusion will be attributable to individuals acting without authorization of their employers, either because the employing organization really was unaware and did not authorize the inclusion or because proof is lacking of any involvement.

A sensible organization will quickly extract the improperly used code and replace it, or will seek a license that is consistent with its prior actions. In the long run, it always costs an organization more in terms of management time, hard costs and damage to its reputation than it does simply to operate a tight ship in the first place.

Maybe it's unfair to compare brilliantly creative software code with fantastic pasta, but keeping an eye on the chef is easier than post-construction analysis any day. Like scanning the menu, post-construction scanning of code is likely to lead to a false sense of security if it is overused. There is simply no good substitute for having everyone on the team trained in the proper use of tools and ingredients.

So whether you are allergic to food or the legal ramifications of life as a programmer, make sure you study the license agreement and all the ingredients carefully. Bon appetite.

Philip H. Albert is a patent attorney and partner with the San Francisco office of the intellectual property law firm Townsend and Townsend and Crew LLP.