Be legally proactive before using open-source software

If your company develops or uses software, attorneys and industry insiders have a message for you: Beware and be proactive, especially when it comes to “open-source” software.

That’s the kind of software where the underlying programming code is available to the users to read, make changes to it and build new versions of it incorporating their changes.

The Wall Street Journal has written open-source software is one of the “most important forces” in all of technology.

It’s easy to get – and less expensive than proprietary software – and that has led to massive growth. How much growth?

It’s hard to know exactly, according to the folks at the Open Source Initiative, a nonprofit that manages and promotes open-source software. Officials at the initiative say because a lot of it is spread via free downloads from the Internet, nobody has real total sales figures.

Linux, an open-source operating system, is reported to have millions of users. And indirectly, the initiative reports that everybody who sends e-mail or uses the Web is using open-source software because the Internet is almost entirely open source.

The key, attorneys and others say, is the license agreement attached to software.

Jonathan Corbet of LWN.net, a Boulder-based trade publication that’s been covering software since 1998, says businesses need to understand the license agreement.

“Closed-source software often comes with agreements which can give the vendor the right to shut down the software remotely and restrict the right of the customer to publish reviews,” Corbet says. “Any company which employs such software without understanding the terms of the license is looking for trouble.”

As far as using open-source software, Corbet says the commonly used license agreements have “almost nothing to say.”

The most common license is the general public license, he says. “This license says, ‘the act of running the program is not restricted,’ so there is little for a company to worry about,” Corbet says.

However, Jason Haislmaier, a partner in the intellectual property group of Holme Roberts & Owen LLP in Boulder, says there are plenty of risks for companies to be concerned about with when it comes to the general public license, often called the GPL, and open-source software in general. But he says the risks aren’t equally applicable to all companies.

“A software distributor incorporating open-source software into its software will have a different risk than a bank using open-source software in its data center, and each of these will have different risks from a consumer electronics manufacturer that imbeds open-source software in their electronic devices.”

Open-source software can benefit companies developing or licensing software, he adds, but users must understand that open-source licenses create binding obligations on the licensees of open-source software.

“Companies need to determine their particular open-source risk and then weigh that against the benefits they hope to get from using the software and determine whether they should use open-source software,” Haislmaier says.

He recommends raising awareness among IT personnel that while open-source software may be “open,” it is not “free” and is subject to license terms.

When licensing software, he advises to watch for exclusions of “open source” or “third party” software from the terms of licenses for proprietary software. “And insist that your licensor disclose whether open-source software is part of the software that is being licensed and what open-source licenses apply; and seek an intellectual property infringement indemnification that includes open-source software.”

Corbet adds that trouble can surface if a company incorporates open-source software into its products and sells it without understanding what it’s getting into.

“Just like what happens if they ship somebody else’s proprietary software in their products,” Corbet says. “The GPL says that if you ship GPL-licensed software to somebody, you must make the source code available to them under the terms of the GPL. So if you take software, modify it for your needs, then put it into a device, you must make your modified software available under the GPL.”

Corbet says that requirement “still takes some people by surprise.”

Some companies shipping GPL-licensed code in violation of its license have hit trouble. “In general, when this happens, they face the choice of making their source code available or withdrawing the product. Nobody has ever been interested in going after big-ticket damages,” Corbet says.

The biggest source of GPL violations appears to be with companies that outsource their production to others and aren’t careful about how those others are getting the job done.

For example, Corbet says LinkSys and D-Link had Taiwan Inc. build their routers and then glued their nameplate on them. Because LinkSys was selling the product, LinkSys got into trouble and had to pressure its suppliers to live up to the licensing.

As with any other part of their product, businesses need to know what they’re shipping and the agreements they’ve entered into to be able to ship it.

“No company need fear risks to its intellectual property brought on by use of open-source software,” he says. “Companies that wish to keep their own software proprietary should not incorporate it into code derived from GPL-licensed software.”

Steps companies can take before using open source

Jason Haislmaier, a partner in the intellectual property group of Holme Roberts & Owen LLP in Boulder, recommends the following for companies concerned about open-source software issues:

1. Develop an open-source risk profile and consider the following questions:

_ Do you generate a large percentage of revenue directly or indirectly from software licensing?

_ Do you rely on revenue from hardware or related services and maintenance?

_ Do you maintain a large portfolio of patents? Are those patents related to software?

_ What revenue, if any, is obtained from licensing those patents?

2. Conduct open-source audits to see open-source software usage and assess “the nature and context of all open-source usage.”

3. Create an open-source policy to address potential scenarios related to maintaining records on open-source usage and procurement. It also should address the company’s participation in the open-source community including releasing software under an open-source license, employee contributions to open-source projects, or company sponsorship of open-source projects.

4. Create a compliance team staffed with management, software development and legal personnel. And consider others, such as risk management and procurement along with outside counsel or consultants, as adjunct members of the team.

5. Develop open-source education and training to foster and promote a “culture of compliance” and “build awareness and understanding” among employees about the issues relevant to open source.

on Facebook on LinkedIn