Open Source – Dirty Code, Licenses and Open Source

Karen Copenhaver, a partner at law firm Choate, Hall & Stewart, tells a story about running a seminar for a large company. The goal of the seminar was to make it clear that software developers had a responsibility to abide by their company’s guidelines surrounding the use of open-source, free and other third-party code.

Copenhaver thought it went well. Then the development group’s manager came up to her and said, “You know, these fellows can’t get everything they need to get done every day and worry about all of this stuff.”

The manager’s words lie at the core of an issue that affects countless development departments around the globe today. Faced with shrunken budgets, tight deadlines, the fear of jobs being shipped off to the lowest bidder and expanding demands for ever-more-complicated software, programmers are tempted to grab bits, pieces and even large bites of code from various third-party sources in order to get things done more quickly.

The consequences of this (to be kind) borrowing can be anodyne; that is, no one ever notices the code, the product ships (either externally or internally), and life goes on. Or the consequences can be catastrophic. Dirty code, according to intellectual property lawyers, has led to expensive delays during many mergers and acquisitions. And thanks to the efforts of a single programmer—Linux kernel contributor Harald Welte—at least 100 companies have been forced either to remove or release as open-source various pieces of GPL code that they borrowed without properly complying with the license.

It doesn’t have to be this way. Companies can avoid problems resulting from the use of open-source code. Legal experts we spoke with offered numerous tips and tactics for maintaining the flexibility necessary to take advantage of this important tool in the software developer’s box while limiting the risk.

Assume You’ll Get Caught

Copy some code, change the variables, tweak the white space…. Who’ll ever know? Perhaps at one time there wasn’t much chance that anyone would identify code that had been illicitly lifted from someone else’s work. But times have changed. Source-code compliance tools from the likes of Black Duck and Palamida, which can scan millions of lines of code and compare them with huge databases of known software, allow companies to locate (and locate pretty quickly) previously created code—even if variable names and white space have been modified by the borrower.

Black Duck’s client list has grown more than 300 percent during the past year and now includes 11 Fortune 500/Global 500 companies. Its hosted code assessment service, ProtexIP/OnDemand, has been downloaded by hundreds of companies and has been used in more than 140 merger and acquisition due diligence transactions totaling an estimated $9 billion, according to the company. Searches for suspicious code are becoming de rigueur during the due diligence surrounding mergers and acquisitions. The culture surrounding open-source and free software has had an impact as well. Whistle-blowers have outed their employers over open-source code misuse. Some GPL violations have also been called to the attention of the world by interested users who notice suspiciously familiar behavior in commercial products. (For instance, network hardware maker Linksys, soon after its 2003 purchase by Cisco, was famously inspired to release the firmware to its WRT54G router when motivated users uncovered that pieces of the firmware were based on Linux.)

Dedicated GPL defender Welte, who owns copyrights on pieces of the Linux firewall code, has used that copyright to encourage (or, through suits brought in German courts, force) more than 100 companies either to remove infringing code or release their corporate source code to the public. The companies involved range from smaller firms to corporate giants, such as Asus, Belkin, Fujitsu Siemens and others. Welte’s plans to create a nonprofit organization in Germany to aggressively pursue such copyright infringement may help accelerate his efforts.

“In our view, it is necessary to raise public awareness and to make cases public,” Welte says. But, he insists, “this is not a witch hunt or some kind of religious battle. It’s just making corporate users play by the rules when they have, for whatever reason, overlooked them.”

Even given all this, the odds that you’ll get caught may still be slim. However, as open-source software finds its way into ever-more-critical systems inside your company, the risk to your company if you are caught has increased dramatically.

Talk to the Lawyers

What unusual patent provisions exist in the Mozilla Public License?

How far does the GPL go to protect derivative works?

Heck, what is a derivative work?

Like it or not, attorneys—not developers—are in the best position to answer questions like these, particularly as they pertain to your business or to your approach to using open-source software. Getting your legal department involved early is the best way to ensure against running into problems in the future. The key is to make it clear up front that open source is a critical piece of your development plans so that the legal folks will take that into account.

It might seem easier to simply avoid the hard questions, but doing so only increases your risk. “It really is incumbent on CIOs and other IT managers to understand that this is a real issue,” warns Mark Radcliffe, a partner at DLA Piper Rudnick Gray Cary and chairman of a committee working to develop GPL 3.

Just because you bring in the lawyers, however, doesn’t mean you’ll get decisive answers to all your licensing questions. Open-source case law isn’t a well-trodden path. “It would be easier to advise clients if there was more case law in the area,” admits Ira Heffan, an associate at Goodwin Procter who in 1997 wrote a law review article that argued that the GNU General Public License was enforceable. He notes, however, that there have been efforts to reach some consensus on open-source matters, including a so-called moot court held in early 2006 at the University of Washington that produced legal briefs and helped establish dialogues with some federal circuit judges on various open-source matters.

Create Ground Rules

While meeting with your legal representation, it also will pay to establish some ground rules for open-source use. “Some people used to rely on a simple prohibition,” says Radcliffe. “That’s not realistic.” Instead, he says, companies must establish rules. In his experience, those rules can vary dramatically. He knows of one “major Silicon Valley company,” for instance, that has a development agreement that refers to open source as “infectious software.” Others, he says, have developed entirely separate due diligence processes for dealing with open source during acquisitions. And he knows of one company that uses open source internally but prohibits it in products it makes available to customers.

The key is to give developers rules for when and how to integrate external code of any type into their projects. “What is very clear,” Radcliffe says, “is that if the people who are actually doing the coding don’t have direction and some type of enforcement mechanism, they’re going to pull whatever they can off the Internet whenever they can.”

Investigate Your Code

While a few years ago a claim of “we didn’t know about this open-source stuff” might have carried some weight in court or with a potential (and now unpleasantly surprised) merger partner, that’s no longer the case. Open-source products are mainstream now, not esoteric, and the responsible use of code has become a given.

Consequently, legal experts say that it’s important for companies to have a process in place for carrying out investigations into the provenance of their code. Choate’s Copenhaver, who is also a counsel for Black Duck, says that companies should establish a schedule for senior executives to be briefed on issues and possible remediation at a set time after the investigation is complete. The goal, she says, is to keep the company from feeling a need to react to incomplete findings.

The process also should involve regular meetings with developers who are found to be using free or open-source code without properly following licenses, she says. These developers need to be made aware of the consequences of not following the rules—not just for the company, but for themselves too. “Anyone who’s had the experience of having just finished something only to have to take it all apart and re-QA it” will not want to repeat the experience, says Copenhaver.

And to keep developers from feeling the need to grab code on the sly, management needs to help them. “The problem with the fellow who says, ‘These guys can’t get their job done and worry about all this,’ is that he hasn’t built a structure to support the developers so they can get their questions answered quickly,” says Copenhaver.

Getting those answers, she asserts, will be a matter of building trust between the development and legal staffs. “What we really want to get to is an honest conversation. If what you’re saying is, ‘Just say no, we don’t use any of this [open-source] stuff,’ what you’re really saying is, ‘Don’t ask, don’t tell.’ What you need to be saying instead is, ‘We can get an enormous amount of leverage and competitive advantage by making the best use possible of these available resources. But [we need to do] it fully understanding what our compliance obligations are.’”