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.