So you want to release some code under an open source license? You are smart to consider the license before you make a choice. My hope is that this article can help you to consider a few important things that will help you make a smart decision.
Contents |
The first thing to consider is that I am not a lawyer, and my guess is that, most likely, you aren't one either. This article is meant to serve as an aid or a guide, and does not replace legal advice. If you want solid legal advice, well, you are going to have to pay a lawyer for that. If you are employed as a software engineer, your company should pay for it. And you may need to help them understand that they need to pay for it.
Many who are new to open source confuse it with public domain. It is easy to do this, as open source software is usually readily available over the internet and can be downloaded for free, at no cost. However, there are a few key differences.
In particular, you can think of public domain as "no strings attached." If something is in the public domain, it is free to be used however you like with no restrictions.
Open source is not necessarily freely available with restrictions. Open source is made available under the terms of an open source license; use of the software and/or the code is subject to the terms of the license. The Open Source Definition, located at the web site of the Open Source Initiative (OSI), proposes what is required in order for software to be considered open source.
The OSI lists open source licenses that are approved by the OSI and meet the Open Source Definition. Not every open source license is available at the OSI's website; however, many in the open source community are hesitant to recognize software as open source if it is not licensed under an OSI-approved license.
Some software companies (intentionally unnamed here) and other organizations have been known to release source code available for the public to view and use under the terms of their own license instead of an OSI-approved license. Often these parties term this code as "open source." However, it is often the case that these custom licenses fail to meet the Open Source Definition, and so most in the community do not regard the code as being truly open source.
Releasing open source code under the terms of a custom license or a license that is not OSI approved often appears to be a warning flag that the code is not truly open, even if it is. Along with Martin Fink of Hewlett-Packard, I recommend that you select an existing OSI-approved license for your code instead of trying to create your own.
Copyleft is a term coined by Richard Stallman and the Free Software Foundation. Many, but not all, open source licenses can be considered "copyleft licenses."
The main thing to remember about copyleft licenses is a redistribution requirement. Basically, what this means is that if you create a derivative work of licensed code, and if you redistribute binary versions of the derivative work, the source code of the derivative work must be made available under the terms of the license of the original work. More about this later.
Simply put, non-copyleft licenses do not include a clause that requires the redistribution of derivative works. In other words, you can include code with this type of license in your own application, distribute binary versions of your application, and keep your source code closed if you wish.
Probably the most popular open source license in use today is the GPL, or GNU General Public License. This is one of the first open source licenses. It is also a copyleft-style license.
My guess is that many people who use the GPL do so after a simple self-interview. They ask themselves, "Do I want to preserve my right to view and take advantage of changes to my application?" If the answer to this question is "Yes" then a copyleft-style license is required, and usually the GPL is selected.
At this point I urge stronger consideration than just that simple question. It is true that non-copyleft open source licenses do not preserve your right to see changed versions of your application. However, we are not just talking about changed versions of your application; we are talking about derivative works. A "derivative work" is an admittedly vague term to describe a work that has some basis in another work. Consider the following:
In which of these cases is my application a derivative work? Some lawyers would argue that my application is a derivative work in all of these cases. Others would argue that it depends on the code that was copied (copying a counting loop is much less shady than copying a unique algorithm implementation).
So the point is, it is not just new versions of your application we are talking about. Do you want to preserve your right to view and use source code for any application that uses your code?
Copyleft licenses protect the participants in the development of the application from having their code used in ways that they cannot profit from (monetarily or otherwise). However, being compelled by a copyleft license to return derivative works as open source is not even the best reason for doing so.
Imagine that you have created an application and I want to make use of your application. Your application meets almost all of my needs, and I intend to implement a few key features that I need that are not in your application. (The license for your application is immaterial in this discussion.)
So I go ahead and make the changes. Now the code that I have is different from yours, but mine functions fine - in fact, it meets all of my needs now. The problem is, you are going to continue to develop your application. You will add features in the future that I will want to use. In fact, you may even implement the features that I just finished implementing. Newer versions of your product may be more stable; they may even include critical bug fixes or security patches. As long as I maintain a different version of your product, I must go through a complex code merging process every time you make changes, OR I must forfeit those changes.
If I submit my changes back to you, you might find my changes valuable and include them in your distribution. I get to then see the value of having the open source community use and test my features, as well as build upon them and perhaps even fix bugs in them. Plus, when the new version of your application comes out, I can upgrade without having to merge.
When you select an open source license, don't just ask yourself whether you want the changes back. People that understand the value of open source will submit changes back regardless of the license you choose. People that don't understand open source might violate a copyleft license and keep the changes anyway - so does it really matter which license you choose?
Not from this perspective. You might choose to think of it a different way:
That last statement may ruffle a few feathers, for sure. Am I saying that copyleft licenses discourage participation?
It depends on who I'm talking about. Many would be more inclined to participate in an open source project that had a copyleft license because they know they will gain the value of other contributions.
Before you choose a license, you should think about how corporations and professional software engineers will interpret the license. Many companies will be hesitant to get involved with copyleft-licensed software because of the requirement to open all derivative works. In fact, some companies have policies prohibiting the download of copyleft-licensed source code without a legal review first. They don't have this restriction on non-copyleft software. Many software engineers have similar concerns about copyleft software.
According to copyright law in the United States, a work violates the copyright of another work if the first work is "substantially similar" to the second. What is meant by "substantially similar" is left to a court to decide. Keep in mind, however, that the court may not be comprised of people with a good enough technical background to determine properly whether two works are substantially similar. Also, copyright law does not require that the works be direct copies; portrayal of substantially similar ideas can violate copyrights even if the portrayals differ. This also means that a person doesn't need to consult a work directly at the time of duplication to violate the copyright; if the person has ever seen the original work, a substantially similar work could be created from memory, intentionally or not, that violates copyright.
For these additonal reasons, companies and individuals are even more cautious about the use of copyleft software. Due to an engineer's prior work on with copyleft software even years ago, a company may limit that engineer's opportunities today based upon the potential, unintentional duplication of copyleft software in a work that might be substantially similar to the one the engineer worked on before.
You may be saying, "That is ridiculous! That isn't what copyleft means at all!" In my opinion, that is certainly not what most people think of when they think of copyleft software. What matters, however, is not what most people think of copyleft software, or even whether that is an unexpected and unintentional side effect of copyleft licenses. Even if you disagree with the way that a corporate lawyer might interpret copyleft license use and the consequences thereof, you need to understand that I did not make this up. Companies DO interpret this in similar ways as I described. If you choose a copyleft license, you might discourage participation from companies that might otherwise use your software and participate with you to make it valuable.
Choosing an open source license for your software is not a trivial matter and should not be taken lightly. There is no single best open source license, and both copyleft and non-copyleft licenses provide great value to the open source community in their own ways. In my opinion, way too many people open source their software and select a license without understanding what that license means or what the implications are. I believe the most fundamental question to ask yourself is which you value more - encouraging open participation, or ensuring that you always get all the changes back. Whether or not you agree with common legal interpretation will not change how others perceive their ability to be involved, so choose carefully.
© 2008 Novell, Inc. All Rights Reserved.
