The Open Source Risk – Are you Managing it?

“What risk?”

When managers think of “risk management,” they typically first picture slip and fall cases or natural disasters. They may think of insured perils (fire, flood, etc.) and even security breaches. Chances are, however, that they do not think of the risks potentially hiding in their IT department. Risk management takes its general approach from Scouting: “be prepared.” When applied to litigation risk management, that often means taking an inventory of your gaps and preventive measures.

So what risks might hide among your servers, keyboards and empty Mountain Dew cans? Open Source software (“OSS”) licenses. If your IT department incorporated open source software into any part of your business, even as a component within another product that was added by the vendor, you need to know the license restrictions on that software.

Too many managers still think OSS is the same as “freeware.” Anything that does not appear to have a price on it is attractive when budgets are tight. Nonprofits and small businesses alike flock to OSS to meet their technology needs while minimizing expenses. OSS is not without strings, even if it is without an initial price tag. The strings to worry about are the licenses attached to the OSS. There is at least one and may be several, depending on how many OSS components are in the software.

An acquaintance of mine, Jason Haislmaier, blogs on this topic frequently, drawing from his active practice representing businesses who are exposed to this very risk. In a recent post discussing the Jacobsen v. Katzer decision, Jason wrote:

“For those companies that have elected not to comply with open source licenses or, as is the case with many companies, have chosen to remain unaware of the open source software licenses to which they may be subject, Jacobsen should be all the incentive that is necessary to adopt and implement a sound open source license compliance program.”

Bob Brill also has a good post on the case here. Brill delves into related areas and risks that abound if you fail to implement what Haislmaier calls “a sound, open source license compliance program.”

“What is a sound, open source license compliance program?”

A good OSS license compliance program begins with a great contract management system. At a minimum, you need an inventory and documentation. The software licenses are contracts just as much as your copier lease or your accounting services agreement.

Make a current list of every contract in effect in every aspect of your business. It probably requires a separate system. You can buy software to help you, create the list in Excel or write it on notebook paper, but do it and keep this list safe. The essential details to record are:

>Vendor/Author Name
>Contract/License Date
>Subject of the Contract/License
>Effective Date
>Expiration Date
>Location of the actual, fully-signed version, if any
>List of any clauses that survive the end of the contract

It is that last item that will keep you awake at night. For software licenses of all types, you also want to know who is using the component and for what purpose as well as where the original version of the software is stored. This may be the DVD the software came on or the original download files. Make sure for OSS you have the completely unaltered version of the software saved somewhere.

“AFL, OSL or GNU?”


There are a number of OSS licenses floating around. Typically, the original software author inserts a comment into the code stating the license that the writer intends to apply. Make sure you note that reference AND any subsequent references by authors who add to the original code. The Open Source Initiative maintains a registry of those OSS licenses that conform to the Open Source Definition and that the software itself does as well. Be aware that over time a number of iterations of many OSS licenses have been released. You need to know which specific version applies to the component in your inventory.

Some software can be transferred to others as long as you also pass along the license and the recipient agrees to honor the license. Read the license regarding transfers and make sure you understand how to comply. If you dispose of, sell, give away or otherwise transfer possession of any software, make these additional entries:

>Recipient
>Terms of transfer (including price)
>Date of transfer
>Reason for transfer
>Confirmation of delivery of license to recipient
(any other information that will help prove you complied with the license at transfer)

With the Katzer decision, OSS authors may become more litigious. Help yourself by knowing what you have, complying with your contracts and documenting your compliance every time there is some event that the contract addresses.

Finally, be careful: you do not necessarily know whether your OSS was compliant when you received it and it may be hard to tell. You are still at risk. The most prudent practice is to discard any software that you cannot prove you acquired completely in compliance with its license(s).