What issues should I be aware of when using open source software?

QUESTION:

I have a startup, and we’re using a number of open source software packages, including WordPress, Ruby on Rails, MySQL, etc. The list is pretty long. In general, what issues should I be aware of when using open source software?

ANSWER:

Ethan Stone

by Ethan Stone, Stone Business Law

First, a quick but important clarification: I’m not your lawyer and this answer doesn’t establish a lawyer-client relationship. I’m giving a generic answer to a generic question to educate the users of this site. The information below is general in nature and should not be understood as a substitute for personal legal advice.

Why Do I Care?

I’m a lawyer. I’m just naturally fascinated with copyright law and the details of open source licenses. But you aren’t. So it’s first worth discussing why open source compliance should matter to you.

First, failure to keep track and comply can complicate deals. If you don’t keep track of your use of open-source code, you won’t know what rights you have to your product. This can cause you huge problems when you try to raise financing, sell the company, or license your product to a sophisticated third party. The fact that you haven’t been keeping track of open source code and licenses and can’t account for them will come out quickly in the diligence process. At very least, it will cause delay and expense. In many cases, poor control of open source will lead to worse economic terms (lower quality rights means less value). In extreme cases, it can sink a deal altogether.

Second, actual failure to comply (which is likely if you don’t know what you have) can lead to further consequences. There are people out there policing compliance (http://www.gpl-violations.org, for example). If they find you using things without the right to do so, they could potentially shut you down or force you to pay damages. More commonly, they require you to go through expensive exercises to make up for your failure to comply and ensure ongoing compliance. These can include requiring you to ship code to all of your customers, hire an open source compliance person and report to the copyright holder periodically.

What Should I Do?

1. Know Your Code. A very common mistake is to assume that open source code is public domain. A public domain work is one that isn’t subject to any copyright, for example the works of William Shakespeare. Anyone can use it in any way without getting anyone else’s permission. By contrast, open source code is copyrighted. Just like any other copyrighted work (e.g. a Danielle Steel novel or Microsoft’s Windows operating system), someone who doesn’t hold the copyright can use it only with a license (permission of the person who holds the copyright).

I’ll discuss the licenses below, but the bottom line is that you need to keep track of whose code you’re using and how you use it. Make sure you track linking as well as actual integration since linking can have implications under some licenses. Also, make sure you pay attention to code coming in from third parties, such as commercial software providers and contractors/consultants.

An important part of having a working open source policy and tracking system is training. If there are only two or three people in the company, that’s not a big deal. Once you have multiple engineers (or if you’re getting services from multiple engineers through contractor/consulting arrangements), educating everyone in the policies and making sure they’re following the process gets increasingly difficult. It’s also increasingly important.

If you’re starting with a blank page, it’s best to come up with an open source approval process and tracking system. If there’s already a body of code that has been developed without those processes in place, you’ll need to go back and look through it to determine what’s in there. There are different ways to do that, ranging from sitting down and eyeballing what you have (which might make sense if there are two or three engineers and not much written yet) to commercial providers such as Black Duck (http://www.blackducksoftware.com/), OpenLogic (http://www.openlogic.com/), and Palamida (http://www.palamida.com/). In between those, there are a number of open-source utilities available. The Linux Foundation provides or links to a number of them here: http://www.linuxfoundation.org/programs/legal/compliance/tools.

2. Know Your Licenses. Once you’ve identified the open source code you’re using, you need to figure out what right you have to use it. That means looking for the license. Open source licenses typically require anyone distributing the code to include a copyright notice and a copy of the license with the code. So generally, you should have it, often in a text file labeled “license.”

If there wasn’t a good open source policy in place when the code was developed, you may find code that you suspect is open source without any associated license. This usually means that someone (one of your engineers or the person you got it from) deleted the information. In those cases, you can either backtrack to figure out where the code originated or you can try to use one of the tools referenced in #1 above to identify it. Bear in mind that you can permanently void some licenses by stripping out the copyright notice or license text. In other words, simply restoring the information doesn’t always fix the problem. So once you’ve found this kind of code, identified it, and determined the license that applies, you need to evaluate that license to determine how to proceed. It would be wise to get a lawyer to help you with this process to make sure you’re fixing the problem, rather than making it worse.

The system you use to track your open source code should also track your licenses. Make sure to record places where you integrate or link between code that is subject to different licenses.

3. Comply. Once you know what code you have, how you’re using it, and which licenses apply, you need to evaluate the steps necessary to comply with the licenses.

In many cases, compliance just means including a copyright notice and/or the text of the license with the code. Unfortunately, some of the most popular open source licenses (including the GPL family of licenses) impose more restrictions and obligations. For example, GPL licenses (and other “reciprocal” licenses) generally require you to distribute source code and/or compiling instructions under certain circumstances. That obligation might require only that you redistribute the code as you got it. Depending on the circumstances, however, it may mean distributing the source code for portions of your work, as well. Generally, the obligation to provide source code arises when you distribute code to others, for instance by allowing someone to download a program in object code. In some licenses, however, it can also arise in “software as a service” deployments.

Most annoyingly, complying with one license can be inconsistent with complying with another license. That can pose problems if code that is subject to those incompatible licenses is integrated or linked.

By the way, there’s a project going to create a uniform system (the “Software Package Data Exchange”) to record and communicate the open source components and licenses in software packages (http://www.spdx.org). It’s not yet completely operational, but you might want to check it out and, perhaps, start using it.

For additional information, you might take a look at the Software Freedom Law Center’s “Practical Guide to GPL Compliance” (http://www.softwarefreedom.org/resources/2008/compliance-guide.html) and the Linux Foundation’s white paper on open source compliance (http://www.linuxfoundation.org/lp/page/sign-up-for-foss-compliance-whitepaper).

Good luck! Keep your code clean and legal!