In-Depth

Make Optimal, Legal Use of Open Source

Ira Heffan discusses the issues you should consider when reviewing open source licenses.

Recently, I have heard virtually the same comment from a few different software developers, each working for different companies. Each time it was some variation of this, spoken in a remarkably similar-sounding tone: "Why do I have to think about licenses to write software? I'm a software developer, not a lawyer!" The speakers were all referring to the chore of reviewing and complying with the terms of the various open source software licenses that cover code they want to use in their commercial products. Hearing this comment repeated by different clients highlights the reality that developers now have to think about licenses, perhaps to a degree that they hadn't before, because the world has changed.

Seemingly overnight, commercial software vendors have gone from thinking that they should only develop software by themselves in a software development silo to thinking that they should develop and maintain important parts of their software collaboratively, in cooperation with a community. Developers now make more use of third-party code than ever before, in part because it is available on the Internet, and also in part because more open source code is mature and useful. Of course, "code reuse" has always been the Nirvana of software development, and programming languages such as Java make it even easier to modify and extend someone else's code. But because (for better or for worse) intellectual property rights apply to software—even to open source software—developers need to think about the terms and conditions that apply to each of the components that they want to use, which, in practice, translates into how their use of open source will impact their business.

There are well over 50 licenses approved as "Open Source" according to the Open Source Initiative's definition, and there are many, many more that are widely used but have not been submitted or have not made it through the approval process. They all have different terms and frequently use different words for the same types of obligations. What issues should you be thinking about when reviewing open source licenses? The same issues that you think about when considering a commercial software license.

Some of the concerns associated with using someone else's software are these: Does the software have sufficient functionality and performance? Can you get support if you need it? Does the license allow you to do what you intend to do? What will be the cost of compliance with the license? What happens if there is an allegation of intellectual property (e.g., copyright or patent) infringement? You would consider each of these questions, and others, in the context of a commercial license agreement, and you should likewise consider them as part of your evaluation of an open source program. Often, these questions get answered slightly differently in the context of open source, and might not even be addressed in the license agreement itself—for example, there might be more reliance on a "community" response than a contract with a vendor—but oftentimes companies can get comfortable with their use of open source code when they think these issues through.

Many companies think that they have to use open source software to be competitive, but "everybody else is using it" is not a reason to avoid considering each license and making sure that you can comply with its terms. For many development groups, it might be simply a matter of scheduling management and developer time to review open source usage. Others might look to the sophisticated automated tools that are now available to help manage the effort and to consultants who have deep expertise. Once you analyze the open source projects and the associated licenses, you should find that many of the answers to the aforementioned questions are straightforward, but if you come across one you can't answer, take the time to talk to your attorney. That way you will avoid a crisis down the road, and spend less time feeling like a lawyer yourself and more time developing code.