border

OPEN SOURCE - 1 Jun 2006


Taming the Open-Source Monster

Once considered bleeding-edge, the open-source beast is now more revered than feared, but legal headaches still abound.

When it comes to open-source software, Steve Howe doesn't hide his enthusiasm.

"The primary driver is the cost," says Howe, who is the head of open-source initiatives at Dresdner Kleinwort Wasserstein (DrKW). "In many cases, the quality of open-source software is actually better than traditional software. Maintenance becomes a lot easier."

DrKW uses several open-source applications and even developed its own open-source enterprise software, OpenAdapter, which developers around the world are free to tweak and improve. "We can end up with a lot of code that we don't have to write ourselves," says Howe. "We've got people around the world fixing bugs for us."

Call it a sign of the times, but the open-source software movement that began in garages and underground computer clubs has gone mainstream. And it's not just a few companies out there tinkering with open-source code. It's much of the corporate world, including investment banks and other financial-services firms.

"Many organizations have been very successful with open source," says Byron Sebastian, founder and CEO of SourceLabs, which helps firms manage open-source projects. Investment banks have started embracing open-source software for everything from databases to customized trading platforms. "They were the early adopters," says Bryan Sims, counsel at Squire, Sanders & Dempsey and a former vice president at open-source vendor Red Hat.

"Open source" denotes software that publishes its source code, allowing for modification by the adopter. Advantages for corporate users include lower cost, greater customization and quicker deployment times. But open-source licenses can be confusing and ambiguous. "It was a challenge initially to understand it," says DrKW's Howe.

Stephen Fronk, an intellectual property attorney at San Francisco-based Howard Rice Nemerovski Canady Falk & Rabkin, says "gray areas" abound. "That's part of the frustration for legal counsel trying to counsel clients," he says. "There's always going to be risk."

The open-source community has created dozens of licensing flavors, each with their own legal obligations and caveats. Just as with traditional proprietary software, firms have an obligation to abide by the terms of each license. "If you're not paying attention and don't have a formalized program in place, you could be causing problems for your company," says Sims.

In fact, violating any software license terms—open-source or not—can put executives at personal liability risk. That's because the Sarbanes-Oxley law requires corporate directors to certify that the company complies with all laws and contracts, including software license agreements. In the world of proprietary software, internal checks and balances often link to the purchasing system. "You would have some kind of person in place to make sure you review the licenses and are compliant," says Ira Heffan, an attorney in the Boston office of Goodwin Procter. "Typically, that is part of the purchasing process."

With open source, however, a developer in the IT department might simply download free source code and incorporate it into the company's overall software matrix—without telling anyone or vetting the license. "Because the developers can just download it, it's not necessarily going to go through that purchasing channel," says Heffan. He says the nature of open-source code can create unexpected risks. "That's what the SCO case is about," he says.

In early 2003, SCO Group, which owns the intellectual property for the Unix operating system, sued IBM for allegedly copying SCO's proprietary Unix code into the free Linux operating system. Linux, which has exploded into corporate use in recent years, is a free open-source program that falls under the commonly used General Public License category. GPL allows developers to copy and modify the source "kernel." They can keep those changes to themselves if the software is used internally. But if they distribute the modified software in any way, they must make those changes public, either to the community at large or just to third-party users, depending on certain factors. That GPL principle is seen by many as the central tenet that allows open-source software to constantly evolve and flourish.

The pending SCO case, however, highlights one of the greatest risks of incorporating open-source code. "Everyone assumes that Linux is open source, but along came SCO asking people to pay some money per each server," says Heffan. When it comes to liability and risk, open-source software and the GPL concept are evolving beasts that haven't yet survived the scrutiny of the US legal system. "There are some things that are very vague," says Fronk. "Until it's litigated, it's hard to know what it means." A win by SCO could force investment banks that use Linux to pay license fees for something they thought was essentially free.

Welcome to the inherent risk of using open source.

The liability issues raised by the SCO case, as well as general risks surrounding the integrity of open-source code itself, give some experts pause, despite the fact that much open-source software is free or very low cost. "It just opens up so many potential liabilities," says Seth Hishmeh, co-founder and COO of consulting firm USAS Technologies. "Whether the risk outweighs the benefits of free software, I don't know." In fact, he says long-term costs can be higher. "You've got all of these unknowns," Hishmeh says.

FUD Busting

Open-source advocates say such concerns can spook corporate decision makers. "They hear about it in the media, and they say, 'We don't want to use open source,'" says SourceLabs' Sebastian. "The risks are a lot lower than you often read about. The more you learn about it, the more you realize that the fear is unfounded." Indeed, experts argue that it's not the open-source software itself but lax internal oversight that puts institutions at risk.

"Open source has all of the same issues as proprietary software," says Jim Harvey, co-chair of the global technology and sourcing practice group at law firm Hunton & Williams. "But if left unmanaged, some of those issues might be more acute."

One risk involves GPL's requirement to disclose modifications whenever altered software gets distributed publicly. When it comes to something like a customer-facing trading platform, experts say gray areas are inevitable. For example, an investment bank may not have to disclose changes if the software resides on a corporate server and only touches the customer through a Web browser interface. But if the customer must download software to a computer to use the platform, that could potentially trigger such obligations under the GPL. "Once your customers are downloading something, then you're in the land of distribution," says Heffan.

Further ambiguities abound. For example, what if the software remains at the server but the user must download applets or browser plug-ins that contain some open-source components? Is that distribution? There's no real consensus on that or myriad other questions surrounding GPL obligations, although most lawyers seem to agree that internal use doesn't trigger sharing requirements. "My personal view is that deployment of code is not synonymous with distribution of code," says lawyer Jay Seirmarco, vice president and general manager of SourceForge.net, which hosts more than 116,000 open-source projects. But much can depend on the license in question. "As soon as you give a customer access to it, that's when you have a potential issue," says Sims.

Another open-source risk is the mixing of proprietary and open-source code into new applications. "If you don't manage open-source software appropriately, you may end up in a situation where some of your proprietary code is subject to an open-source license when you don't want it to be," says Harvey, noting that many compliance departments don't even know whether their IT developers are using open source. "If compliance or legal departments think there is no open source being used in their institutions, I think they would have a big surprise coming if they really checked."

Industry experts agree that such lack of communication between departments is among the biggest mistakes institutions make. Linda Eagle, founder of compliance training firm The EdComm Group, says the legal divisions within many investment banks and other financial firms are too often out of the open-source loop. "It gets particularly hairy because there is often not excellent communication between your compliance department and your IT department," she says. "We need to make sure that we keep the lines of communication open. Does the compliance department even know what open-source software is? Do they know what's being used or what changes are being made?"

If the answer is no, Eagle says the compliance department needs to take the initiative. "They have to explain to the IT manager what Sarbanes-Oxley is," she says. "It's a real simple fact. You can go to jail for it. It's not just a corporate responsibility; it's a personal responsibility."

SourceLabs often must figure out what open-source code is being used because investment banks and other financial institutions have failed to keep track themselves. "We're seeing a huge gulf in these large financial institutions between development and central IT, and the legal practices," Sebastian says. "In some of these organizations, there has definitely been a breakdown in the process." Sebastian says he has even found such breakdowns within IT departments themselves, noting cases in which central IT managers have claimed they don't use open-source software even though developers are, in fact, using hundreds of open-source kernels. They just haven't told anyone. "Central IT hasn't recognized the reality that open source is being used," he says. "They're heads are in the clouds, so to speak."

Furthermore, such lack of knowledge can raise other issues. Mergers, acquisitions and even initial public offerings can end up in turmoil when an investment bank's valuation hinges on proprietary trading systems, databases or other applications that may contain some open-source code. That can affect overall valuations because the firm may not actually "own" the code. Often, such bombshells explode during the due-diligence process. "That comes up in mergers-and-acquisitions transactions all the time," says Lennie Nuara, partner and chair of the technology and intellectual property practice group at law firm Thacher Proffitt & Wood. "There's a constant need for due diligence, and many people are not aware of this lurking issue."

For example, Nuara says an investment bank could download free software under GPL and then modify it to create a superior trading platform. But when valuing the firm in preparation for an acquisition, it becomes difficult to place a value on the platform because the firm may not technically own it outright. "You can take something everybody else has and make it your own," he says. "But the sloppy person might say that you own it, which you can't say." Such a claim could botch a merger, acquisition or public offering, and could trigger Sarbanes-Oxley liability. "You have to sign off on the methods and processes, and you can't overstate your assets," Nuara says. "It would depend on the circumstances and the specific valuation claims. The question is how broad the statement can be."

Doug Levin, CEO of Waltham, Mass.-based software compliance firm Black Duck, says investment banks might use software that involves tens of thousands of lines of code—any portion of which might be open-source. "It might have third-party code in there that has not been properly documented," he says. He says investment banks often outsource or even offshore software development work, increasing the chance that a developer might use open-source code without anyone's knowledge. "Deadlines are hard to make, and engineers don't like to reinvent the wheel," notes Levin. "They like to use code that already exists."

As investment banks tread into the open-source waters, they have plenty of factors to consider. But experts agree that astute firms can manage risk effectively as long as they stay on top of their IT departments and coordinate efforts. Says Hunton & Williams' Harvey: "If you're on the lookout for it, it can be readily managed."


Latest Issue

 
 
© Incisive Media Investments Limited 2010 | Terms & Conditions | Privacy Policy | Accessibility | Media jobs
Published by Incisive Financial Publishing Limited, Haymarket House, 28-29 Haymarket, London SW1Y 4RX, are companies registered
in England and Wales with company registration numbers 04252091 & 04252093