by Dave McAllister
"This must be Thursday. I never could get the hang of Thursdays."
While this quote from The Hitchhiker's Guide to the Galaxy by Douglas Adams may seem off the topic, it's really pretty accurate. Just exchange licensing for Thursday and you'll get it.
When you hear the term open source, you immediately assume it means having access to the source. And it mostly does. Open source gives you the chance to look at the source code and modify it as you like. It should let you redistribute it freely without restriction. And yet, when it comes to open source licenses, it seems that the world will never have enough. Each license tries to solve a slightly different problem or to protect the owner in some unique way.
Currently, the Open Source Initiative (OSI) lists 72 approved licenses, with about nine either superseded or retired — which, within limits, can be used for new code. OSI uses 10 rules to define what makes up an open-source license. Of the top 10, some of these are well known, such as Free Software Foundation's GNU General Public License (GPL) and the Berkeley Standard Distribution (BSD) license. Some are vanity licenses (usually with a company name or project as part of it) and some are mostly open, which means the user needs to be aware of just what it says.
Fortunately, we don't need to dive into a detailed examination of each of these licenses — and since I'm not a lawyer, I'm not the person who should be examining them anyway. It's more important to consider these licenses by class and see how they fit.
There is a large spectrum of licenses. At one end of the spectrum is the reciprocal licenses and at the other are the academic licenses. Reciprocal licenses require that changes, when distributed, are also under the same terms of the license of the software. GPL is probably the best known of these. Academic (or permissive) licenses allow any use of the source, including the right to modify it and release it under a new license. BSD is possibly the best known license of this class.
In other words, reciprocal means: Here's some code. Change it as you want. But we still get to tell you how to license it. Academic means: Here's some code. Do with it what you want. Have a nice day.
Each of these meets the definition of open source. Each provides access to code to modify and distribute. However, the intent of the license makes it imperative to consider your purpose when releasing or adopting open-source code.
(There is also a public domain class of licenses, which it can be argued is not open source because it doesn't meet all the rules from the OSI. When Adobe announced support for SQLite, there was a lot of discussion about whether SQLite was open source or not. Legal implications aside, SQLite is code you can use, modify, and distribute without concern, so for all practical purposes, it falls into the same open-source code category.)
At Adobe, as we release technology to open source, we consider the purpose and goals of our release in our choice of license. Over the last 18 months, we've released several technologies, such as Tamarin, Tamarin-tracing, XMP, Flex SDK, and BlazeDS. And each of these ended up with an approved license from the OSI list.
But each of these engendered a new discussion. For every product, there is a need to consider the impact on intellectual property, revenue, and competitor enablement as well as on governance. It's all a matter of balancing considerations.
Do we plan to offer a closed license version of the product? This dual-license practice is one of the major business models offered by open source. License consideration must take into account just what that means.
Do we care if a competitor uses our code? Well, sometimes we might (and you might too), especially when that competitor doesn't plan to contribute back to the code base for everyone's benefit.
How do our customers view the license? In a release of technology during 2008, we had several large customers request clarification and assurance on the choice of license. They need to consider what they build and how it impacts their own software.
How complex is the code? Does it mingle several separately licensed components? Do all the licenses play well together? Keep in mind that a reciprocal license says your modifications must be released under the same license, so mixing certain licensed codes is not legally possible.
Adobe's philosophy for open source is really about enabling developers to build and deliver rich experiences in applications. This single statement immediately narrows our view of acceptable licenses to a small subset of approved licenses. We use both reciprocal and academic licenses.
Since the release of Tamarin to the Mozilla Foundation, Adobe has favored the use of the Mozilla Public License for a reciprocal license. It is a strong reciprocal license and thus reduces concerns that we are enabling competitors. However, it also allows our customers (when they don't modify the code) to distribute the project without concern for their own code.
For much of our code, where we feel adoption is good for everyone, we often use an academic (permissive) license, such as BSD. That's also a good choice for sample code applications, and we use it as such as well. We also use the MIT license in projects such as the Adobe Source Libraries.
From a corporate perspective, there are excellent reasons for adopting an open source strategy:
However, it's the licensing that determines how well the projects can thrive in the wild world of developers and adopters.
So whether you're thinking about adopting open-source code for your project or company or releasing software to the open-source community, you should be sure to consider the impact of the license choice. Just like Adobe, consider using OSI-approved licenses, and be wary of the fine print.
Learn more about Adobe Open Source initiatives by visiting the Adobe Open Source website.
Dave McAllister is Director of Standards and Open Source at Adobe.