But there are business risks to OSS, as well. We'll explore the risks that potentially arise from OSS and the ways to manage those risks.

RISK: If I use open source, I'll have to make my own applications part of the OSS community as a result.

Analysts agree insurers, which are end users of technology, don't have to worry about releasing their proprietary code if they use OSS within their architecture or internal applications.

“If they don't distribute their software, they do not need to distribute source code,” says Karen Hiser, director of compliance services at risk consultancy Open Source Risk Management (OSRM).

The scenario may change if an insurer does distribute its software based on the licensing details of any OSS code incorporated into that software. There are two basic types of open-source licenses: restricted and unrestricted. Unrestricted licenses do not limit the distribution of “derivative works,” or applications an insurer may create using open-source code. Restricted licenses do, and the most common of these is GNU's general public license (GPL).

Sometimes called “copyleft” (vs. copyright) licenses, restrictive licenses require distributed software that uses open-source code be given back to the OSS community that holds the license. These sometimes also are called “viral licenses” for their ability to “infect” systems otherwise protected by an insurer's proprietary intellectual property (IP) rights.

“One of the greater concerns [to the protection of IP] is the GPL license,” notes Zachary. “So some end users are scared of letting any GPL code in.”

For instance, consider a rating application incorporating some open-source component an insurer makes available to agents. The insurer might assume, since it isn't selling the software, its IP is protected. That is a potentially dangerous assumption, cautions Mark Radcliffe, partner and co-chair of the technology and sourcing practice group at law firm DLA Piper Rudnick Gray Cary.

“The agent could redistribute [the system] without cost, and a competitor could end up giving the software to the competitor's agents in both source code and object code form,” he says.

If an insurer extends an application to an agent but doesn't distribute the code, for example, making a rating system online rather than as a client-side installation, Radcliffe adds, the company has no obligation to distribute source code. Hiser agrees but warns the scenario hasn't been settled by case law.

“I could make the argument it is [distribution] because those [agents] have access to the application. It's not a whole lot different than giving those people the executables to run on their machines,” she says. “Also, the newest version of the GPL [version 3] is likely to include clauses that allow copyright holders to treat optionally hosting as distribution, which may introduce new issues in the future.”

RISK: If there's a legal problem with the OSS we use, we're the ones who will get sued.

In March 2003, the SCO Group sued IBM claiming IBM had included SCO's proprietary code in a distribution of Linux. Shortly thereafter, it mailed warning letters to Fortune 1000 companies and then sued Linux end users AutoZone and DaimlerChrysler, arguing the companies either violated licensing agreements or were liable as users of Linux that violated copyright.

Although the DaimlerChrysler suit itself and many of the claims in the IBM suit have been dismissed, the legal actions made it all too clear the cost of a lawsuit, whether successful or not, is a risk. As always, the deeper the pocket, the more attractive the target, and insurers do have notoriously deep pockets.

“The legal risks are serious,” Driver maintains. While he admits the SCO suits are “extreme examples,” he anticipates seeing more suits against both companies and open-source projects. “These 'patent trolls' wait for a big enough bucket, then they'll sue,” he says.

Of course, there are risks to using commercial software, too: Nothing is to stop a disgruntled competing vendor from suing a deep-pocket end user. “We've seen more IP lawsuits [between software vendors] in the proprietary software than in the open-source world,” Zachary says. Since open source is, by definition, viewable by the public, he adds, it's actually easier to identify and remedy, or even prevent, IP infringement.

Still, in order for people to sue you for your use of open source, they first need to know you're using it. “There is no 'master list' of open-source customers. Oftentimes the software simply is on the server for download, and there are no statistics kept,” Zachary notes.

However, an important difference in the risk management assessment is while commercial software companies frequently offer end users either standard or negotiated warranties against copyright infringement, many OSS licenses do not. Also, Kenneth Brown, president and director of technology research of the Alexis de Tocqueville Institution (ADTI) and author of a 2005 ADTI report on the topic of open source, argues OSS code may not be vetted for IP violations to the extent commercial code is.

“Show me the diligence in the open-source community compared with a multibillion-dollar company with 100 lawyers. There's no way they could be the same. The open-source community has not had to settle anything yet,” he says.

RISK: Although upfront costs are lower with OSS, I'll get killed with long-term support costs.

“The back-end costs for open source can, if you don't manage them, get out of control,” Gosnell claims.

That's because companies often must support OSS within their organization, learning new skill sets as they go, or hire consultants. And the fluid nature of some open-source projects is a cause of concern for long-term viability. “Open source that's immature and driven by a community of developers can go in a different direction,” Gosnell says. “You have to be sure you're not jumping in too early.”

Reducing support costs is a key goal in Pacific Life's decision to move away from open-source technologies in some areas. Eight years ago, the company began using the Apache Web server to support its human resource system from Lawson.

“When Lawson first introduced Web-based self-service applications, we had three primary choices at the time: Apache, [Microsoft] ISS, or [IBM] WebSphere,” reports Scott Johnson, assistant vice president of human resource technology. “We decided on Apache because it was free and a logical extension to our Lawson UNIX environment.”

Four years ago, Pacific Life enhanced the security of the system by adding OpenLDAP and OpenSSL, teaming up with Apache consultant Covalent, which provided an Apache bundle with the two security components.

Now, though, the company is planning on replacing the server environment with Microsoft systems, including Windows Server 2003 and Active Directory, IIS 6.0, and SQL Server. “We're looking to standardize our applications on the Microsoft platform to take advantage of some cost savings” as well as to provide common cross-application authentication based on active directory, Johnson says.

“We have a very solid, mature, and secure authentication scheme, but it took us eight weeks and considerable expense just to refactor the authentication scheme the last time we had to upgrade with Lawson,” he relates. “If we were running Lawson on the Windows platform, we would be using Active Directory credentials, so that piece always would be done, and we wouldn't have to worry about it.”

The move also will allow Pacific Life to leverage its internal Microsoft knowledge.

RISK: If our IT staff is part of the OSS development community, our code suddenly will show up in that community.

There is a risk proprietary code can make it into public distribution through IT staff involved in open-source projects, either intentionally or by unintentionally recreating substantially similar code.

In fact, Zachary cautions this is one of the key IP risks when companies allow employees to become involved in open-source projects either on or off company time. “There is risk for 'seepage' [of proprietary code] into the open-source code, and that's difficult to manage,” he contends.

This concern has led some carriers to institute controls over staff involvement in open-source projects. “We do lock that down pretty well,” says Gosnell.

Step one in managing any risk associated with OSS is assessing objectively just how great the potential costs and likelihood of incurring those costs actually are to a particular company.

“There is a fair amount of knee-jerk response and hysteria to open source and copyright,” says Mitch Pirtle, founder and CEO of JamboWorks, which provides services and add-on software for the open-source content management platform Joomla. “Most of the companies that sit down and study the open-source licenses basically can get an understanding of what their position is with regard to IP without a whole lot of effort,” he claims.

Step two is to develop a policy for the use of open-source software, something Driver describes as still lacking at most insurers. “Most mainstream companies do not have that in place. They've ignored it, swept it under the rug,” he says.

An open-source policy should outline the allowable use of OSS for both internal and distributed systems and applications. It also should address some of the specific risk factors mentioned earlier in this article, including setting rules for staff involvement in open-source projects and acceptable open-source licenses.

Put into practice, this policy should lead to several ongoing activities that are important to OSS risk management. First, you can't manage what you don't know you have, so you need a library system to track proprietary, commercial, and OSS code, and you need to audit that library for license compliance. “If you're a large organization with a large IT budget and staff, it may make more sense to have auditing software rather than a manual process,” Hiser suggests.

Auditing, or code-compliance, software is akin to virus-checking software (perhaps appropriate given the nature of the viral GPL), with models updated regularly based on known open-source code and applicable license types. The OSRM offers its own proprietary scanning technology to clients, and the two primary software vendors specializing in code compliance are Palamida and Black Duck. Both of these companies report there hasn't yet been much interest in their software by insurers. Most of the interest has been from companies involved in mergers and acquisitions as part of due diligence or from software vendors themselves.

For instance, Black Duck customer BladeLogic, which provides data center automation software, uses OSS on an ongoing basis in its software development for commoditized subprocesses. In order to keep its proprietary code proprietary, the company has in place a “no GPL” policy.

Each time BladeLogic creates or modifies its code, it reprocesses the code through Black Duck's matching engine, which is updated monthly. The compliance system identifies suspected open-source code along with the applicable license type, letting BladeLogic focus only on areas that violate its policy.

“We've found the Black Duck tool has given us a way of getting answers to where we are with respect to those [licensing] goals and to do due diligence without having to hire [auditing] staff,” says George Moberly, product manager at BladeLogic.

Second, try to use vendors that provide indemnity. “More and more IT organizations are demanding from their vendors, and not unique to open-source vendors, some kind of warranty and indemnity if there is an [intellectual property] violation within the software. The problem, however, with some open-source software is, because of the communal nature of the code, it's difficult to track the [contribution] process, so many organizations are unwilling to provide indemnification,” remarks Driver.

“If I'm a CIO at a Fortune 500 company, it's an expectation [indemnification] will be there,” Hiser says. “Smaller [open-source] organizations have told me they are losing deals, having deals delayed, or having to bet the farm in order to provide indemnification.”

Finally, keep a low profile. “'Covert' is an overstatement, but let's say 'don't publicly disclose,'” says Zachary. “Use open source, but don't become the case study for its success. You can reduce risk by not advertising the fact you're using it.”

For companies particularly concerned about the business risks of complying with open-source licenses, there's an insurance policy available. In late 2005, the OSRM, in concert with Lloyd's of London underwriter Kiln, began marketing Open Source Compliance Insurance.

But as of yet, no insurer “has deemed the risk worth the investment,” says Andrew Aitken, managing partner of open-source consultant Olliance Group.

The insurers that are particular targets for the coverage are those that have made a “substantial” investment in OSS within their internal infrastructure or within applications they may have distributed as well as companies entering into a merger that are required to warranty compliance with OSS licenses.

“If someone's looking to acquire a company, the buyer needs to be sure the technology assets truly are owned by the seller and won't come back to haunt the buyer later on,” Hiser advises.

Just because something carries risk doesn't mean it shouldn't be used; after all, insurers are experts at managing risk. So, expect the insurance industry to keep up with the trend of increasing the utilization of open source both within IT infrastructure and in application development.

“We use a fair amount [of OSS] today, and it will continue to expand and grow, but I don't know at what rate,” comments Gosnell. “The advantages from a cost-benefit standpoint are attractive.”

Johnson also indicates Pacific Life's doors are open to OSS despite the anticipated consolidation of the insurer's human resources infrastructure to Microsoft. “We have a decentralized IT structure, and it would be a divisional choice whether someone wanted to do something with Linux or another open source,” he says.

“The realistic trend is toward a managed adoption of open source–to use it for certain licenses, in certain scenarios, from certain trusted vendors,” concludes Driver. “But that formal decision framework and risk management policy have to be in place.”