"We don't want to have our proprietary code dragged into the public domain," says the vice president of the Fidelity Center for Applied Technology at Boston-based Fidelity Investments.
Still, Brenner and others argue that the value of open-source tools greatly outweighs the extra hoops the licensing structures force you to jump through. They've learned that you should start jumping through the hoops before coding begins by establishing a written development process when open-source is involved. Next, you should design, code and test applications in ways that let you use open-source tools while complying with the extra layer of licensing complexity.
"People move to the complexity issue too fast," insists Eben Moglen, chairman of the Software Freedom Law Center in New York and a key contributor to the update in progress to the GNU General Public License (GPL), which is said to cover at least 70% of the 100,000-plus open-source projects listed on SourceForce.net. He argues that the primary objective of open-source licensing is "to protect users' rights."
True, but that protection comes at a price for IT because, like it or not, open-source licensing does add complexity to any application development effort. So much so that some CIOs raise barriers against open-source software. It's one of the major reasons why Robert Urwiler, CIO at Macromedia Inc. in San Francisco, says, "It's an uphill battle for open-source to get in through my door."
Before letting open-source inside your company, there are a few simple things to know. There are two general types of open-source licenses: permissive and coercive. The first, exemplified by the BSD or MIT licenses, puts no restrictions on whether you distribute the open-source software outside your organization, modify the code or combine it with your code -- the three cardinal sins covered by coercive licenses, says Mike Olson, CEO of Sleepycat Software Inc. in Lincoln, Mass. He acknowledges that his own Sleepycat license as well as the GPL on which it was based are good examples of coercive licenses.
To foster and control open-source inside Fidelity, Brenner says he helped put together the Open-Source Support Center (OSSC), an internal team of technologists and attorneys who evaluate open-source projects to ensure that they meet the company's technical and legal standards. The OSSC writes the rules governing Fidelity's use of open-source and publishes a list of acceptable licenses so developers know before they download code whether the license is acceptable.
Still, Brenner doesn't discourage developers from checking out tools whose licenses aren't on the list. He says if the OSSC considers the software a good technical fit, Fidelity will approach the owner of the copyright and negotiate a deal directly. Many of the dozens of licenses listed on the Open Source Initiative Web site (www.opensource.org) include a clause suggesting the copyright holder is willing to deal.
For example, Olson says, Sleepycat has signed more than 300 standard commercial licenses with companies because his firm owns all the copyrights to its embedded database software, BerkelyDB. In addition, few people know how many copyright holders there are to parts of Linux, which is covered by the GPL.
Service with a smile
Despite the trend toward software running as a service, most coercive open-source licenses consider the physical movement of bits from one machine to another to constitute unlicensed distribution. If you design your application to "isolate code segments so that they are calling each other as services," you're likely to be safe, Brenner says. That may change in future revisions to open-source licenses, but for now, Olson agrees that a service-oriented application architecture stays within the letter, if not the spirit, of open-source licensing.
When you do need to combine your application code with open-source, say, by making library calls to it, the Library GPL (LGPL) is an ideal license, suggests Michael Mullis. He's the chief technology officer at Scientific Games Corp. in New York, which provides lottery software to state governments. The LGPL license permits calling the open-source code from a stored library in your application.
Mullis adds that even if your company has a group like Fidelity's OSSC and you follow stringent best practices and employ zealous technical leads to apply them, you still must audit your code for open-source license transgressions. Your oversight group needs to establish milestones where audits should take place throughout the software cycle.
That central group needs to have real authority, says Diane Peters, general counsel at Open Source Development Labs Inc. in Beaverton, Ore. For example, if you're involved in a project to deliver software tools to your customers or supply chain and the group has concerns about a license obligations, it should have the power to stop the project in its tracks, she says.
Mullis recalls an incident at a prior employer when a contractor, who was not aware of the open-source-use policies, included some free code into an application. Had Mullis not discovered it, his former company would have had to reveal its entire proprietary source code to the world. "It would have been a serious legal problem," he says.
Fingerprints
Not every company is going to have someone with Mullis' expertise, so IT vendors offer tools specifically to detect open-source code buried inside source files. Paul English, CTO at Kayak Software Corp. in Norwalk, Conn., uses a service from Black Duck Software Inc. in Waltham, Mass. Black Duck CEO Douglas Levin claims that his service detects more than 400 instances of open-source code found in projects on SourceForge and elsewhere.
English says it's critical for his business that Kayak pass a code audit because one of his firm's business scenarios involves being acquired. "We have to show due diligence that our code is clear," he says.
Black Duck and its main rival, San Francisco-based Palamida Inc., "fingerprint" your code. According to Ray Waldin, CTO at Palamida, a fingerprint is a unique mathematical token that the services compare against the millions of tokens they have on file. But, he adds, the process involves more than generating a hash (or token) of the code and doing a simple comparison. Palamida's service also evaluates code behavior - that is, the function of a given code snippet -- which can reveal code that's been modified or moved. His service ranks the portions of your code that allegedly contain open-source, identifies the projects involved and then, of course, points you to their licenses.
You don't actually send your source code to Black Duck or Palamida to be scrutinized. They send you a software tool that fingerprints your code by running a multipattern search that detects a source file's coding patterns.
Naturally, you can take a chance that you won't get caught violating an open-source license. But you should know that the Software Freedom Law Center is hiring more lawyers whose job will be to show you the error of your ways.
Side bar
Best practices and questions to ask before using open source
-- Consider using tools that determine whether your code includes open-source.
-- Will all your software pass an audit during a merger or acquisition?
-- Determine how software will be distributed.
-- Is there a chance your code will be used by partners, suppliers or customers outside your company?
-- Create a remediation process for software that incorrectly includes open-source.
-- Do you have a process to handle exceptions?
-- Perform code audits.
-- Do you have the expertise to identify open-source in your code?
-- Establish a central group to develop corporate policies on acceptable use of open-source code by programmers.
-- Do you prefer a service, or would you rather use products inside the firewall?
-- Create a list of licenses that are acceptable as a guide for developers to choose open-source projects.
-- Are you willing to release your code to the world, or would you rewrite?
Sidebar
Licensing do's and don'ts
There more than 55 open-source licenses listed as "approved" by the Open Source Initiative. All include provisions that the source code is used "as is" and, just like proprietary software, the licenses offer no warranties; plus, they all require you to include the copyright or patent notice of the source code owner. Here are some other provisions:
Apache License 2.0: You must include a prominent notice of all changes that have been made to source code.
BSD: You may distribute modified or combined open-source code with or without including your source code.
GPL: If you modify open-source code or combine it with your own, your code must be made open when you distribute the new code.
Mozilla: If you discover after distribution that a third party claims ownership rights to code, you must take steps to notify all the parties you have distributed code to.
Sleepycat: You must negotiate specific rights with copyright holders.
Sidebar
Risky business
When major technology vendors smiled upon open-source, even conservative companies gave the software a green light for internal use.
"What helps is that we're a mainframe shop, and when IBM comes in and says open-source is good, it's like the pope blessing it," says John Welch, open systems administrator at Kansas City Life Insurance Co. in Missouri.
But that blessing is not a dispensation from the risks involved, says Daniel Egger, CEO of Open Source Risk Management Inc. in New York. "Forces that are hostile to open-source have exaggerated the risk," says Egger. "But it would be false to say the risk is zero."
He says that in some cases, if you're caught distributing open-source code that you've modified or combined with your own, the license can compel you to release all of your related code into the public domain. After Cisco Systems Inc. bought Linksys, it discovered that Linksys had violated the GPL, and it had to unveil what it had hoped would be proprietary code as open-source software.
Egger's firm works with third-party insurers to offer up to $10 million in risk insurance in case your company botches an open-source license restriction. But it will also protect you against a SCO-like attack on open-source. SCO, he points out, has been clumsily trying to sue end users of the Linux operating system for alleged copyright violations. But so far, the company has failed in all of its legal maneuvers.