Open Source Software….A Quick FAQ
Some complicated topics are easy and some easy topics are complicated. This one is actually both. So let’s just start with some of the fundamentals:
What is the difference between "closed" source and "open" source?
When we talk about "open source" software, we are generally talking about software that is licensed for use, modification and distribution in a fundamentally different manner than "closed" source proprietary software. There are many different flavors and nuances of both open and closed source, but let’s focus on one of each to understand the distinction:
Closed source proprietary: Microsoft Word….you are only permitted to use Word as set forth in the applicable Microsoft software license (which you or your employer paid Microsoft for), you are not given any access to the human readable source code of Microsoft Word, and you are not permitted to copy or redistribute the Microsoft Word application to anyone.
Open source: Apache OpenOffice…the current version is made available for free (in both machine readable object code and human readable source code) under the Apache License 2.0 (http://www.apache.org/licenses/LICENSE-2.0.html). You are permitted to use, modify and redistribute the code, and the only restrictions placed on you in the license are that you have to provide a copy of the Apache License 2.0, you have to mark the files that you have changed and you have to include the attribution notices in a file or display as part of the software. You are not required to make the source code available to your licensees downstream (i.e. you can distribute just object code if you want).
That Apache license seems to permit quite a bit….how is it different from a so called "copyleft" open source license?
Because the Apache license has only a few restrictions (relating to marking and providing the attribution notices) it is actually called a "permissive" open source license (two other "permissive" open source licenses in frequent use are the BSD and MIT licenses). As the question suggests, there is a more restrictive form of open source license (more restrictive in the sense of what it requires of the user downstream) called a "copyleft" license (which is a play on words from the closed source reliance on "copyright" to control the user downstream). A "copyleft" open source license generally allows the user to freely modify and distribute the open source provided to them, however it also requires that any further distribution (or propagation) of the modified open source MUST ALSO MAKE AVAILABLE THE MODIFIED OPEN SOURCE CODE AS PART OF YOUR DISTRIBUTION. The GNU General Public License (the GPL) is the most widely used of these "copyleft" open source licenses. https://www.gnu.org/licenses/gpl-3.0.en.html
So wait, if I just use or modify a "copyleft" open source program, I have to make available the original or modified source code to everyone?
NO. This is one of the most frequently misunderstood nuances of open source. You are free to use or modify "copyleft" open source for your internal/private use. The requirement to provide the human readable source code to others ONLY applies to the extent you distribute (or propagate, that is make available) the "copyleft" code. The most frequent way that this manifests itself is when a piece of "copyleft" open source code is combined into a proprietary closed source program and then the combined code is distributed to another party. By the terms of the "copyleft" license requirements (sometimes called the liberty or death provision) you only have the right to distribute the modified open source code IF YOU COMPLY WITH THE COPYLEFT REQUIREMENTS (INCLUDING MAKING THE MODIFIED SOURCE CODE AVAILABLE).
What if I don’t want to make my proprietary source code available?
Then don’t combine it with "copyleft" open source code….that is the cleanest and easiest way to avoid the "copyleft" requirements. As noted above, the "permissive" open source licenses have requirements to meet, but those requirements don’t extend to requiring you to make available your source code, and so that is generally the much better choice for licensors who want to maintain a proprietary "closed" source licensing structure downstream.
So as long as I use just "permissive" open source I’m in the completely in the clear?
NOT REMOTELY. Sorry to be the bearer of bad tidings, but we want you to approach these issues with "open" eyes (apologies for that). While using "permissive" open source does not subject you to the "copyleft" requirements as noted, you should nevertheless be aware that your use/distribution of open source software is going to almost certainly going to show up in due diligence questionnaires and in representations and warranties that you have to make to both end user customers and to potential acquirors of your startup. And it’s very possible that some of those parties also won’t understand the nuances that we’ve talked about in this FAQ…note also that the "permissive" open source licenses will be disclaiming all representations and warranties about the software provided, such that if there are copyright/infringement or other issues with the "open source" code, your ability to recover from the licensors from which you got the code is, for all practical purposes, going to be non-existent. So what we are saying is that you should weigh the risks and benefits before using ANY open source in your code whether permissive or copyleft or otherwise.
Anything else I should do with respect to open source?
YES. Make sure you keep track of all open source that you use, modify and distribute…where you got the code, what the license terms are (i.e. what is the specific open source license the code is provided under), whether the license is permissive or copyleft, and what you did with the code (did you modify it? did you combine it and distribute it? etc.). Maintaining all of that information on an ongoing basis will help you to understand exactly what you need to do to comply with the various open source requirements and it will be simply invaluable for the purposes of responding to due diligence and/or negotiating representations and warranties.
Any suggestions for further reading?
Well, we always plug information here on knowingstartups.com, so if you haven’t read through the articles above and below this one, then we definitely suggest you start there. In terms of more information on open source, here are two really good resources:
Beyond that, and for some much less dry subject matter, be sure to check out the law blog of David Gurwin (chair of the Technology Transactions group here at the firm)…it’s called "Gurwin’s Keyboard" and it covers legal entertainment and technology issues. Here’s a couple of his most recent articles:
http://www.gurwinskeyboard.com/spinal-tapped-out-harry-shearers-lawsuit-is-no-laughing-matter/
http://www.gurwinskeyboard.com/star-trek-fan-film-yes-it-will-boldly-go/