Which Open Source License?September 9th, 2008 by jeremychone
For a commercial entity, building an effective open source strategy can be a relatively daunting task. Open Source strategy discussions tend to revolve around licensing. Typical questions are, ”Should we use dual licensing?,” “Should we use GPL or BSD?,” “What are the risks of GPL?,” “Can the licensing help us drive users to our commercial assets?,” or “What are the competitive risk associated with each type of license?“
Well, while the licensing questions are pertinent and will need to be answered at some point, the real questions are “What? Why? And How much [open]?”
The “What” and “Why” are very dependent on the entity’s business model and should be carefully thought out. Open Source is a useful tool to lower the entry barrier, change product perception, increase adoption, and create awareness. However, it does not come for free, definitely does not reduce engineering cost, and often requires a specific DNA. The key to determining the “What?” is to not only think about what the entity is ready to give to the community, but also, what the community would be interested in taking from the entity. In other words, don’t ask yourself what you can give to the community, but what the community wants to take from you.
The “How much [to open]?” is the main question which will help determine the appropriate license, the challenge being that among your users you will have competitors that you cannot really individualize. To facilitate this thinking process, I made the following matrix which lists the main usage capabilities for the different types of open source licenses.
“Download” and “Evaluate” are often the easiest ones since most technology companies want their “open” or even proprietary technologies to be freely accessible for evaluation. Obviously, all open source licenses allow these two usages.
The “Deploy” is where most misunderstandings come from and where open source differ the most from proprietary software licensing. For server technologies, all open source licenses (1) allow users to freely build and deploy applications on top of the open source [server] asset without any restrictions on their application licensing. Restriction applies only when redistribution of the asset occurs, and typical end-user usage (over the Internet) does not qualify as asset redistribution. For example, Google is using a highly modified version of Linux (GPL) and has not had to give anything back to the community (Note: Google gave some of its customization back, though). Note that for client side open source components, GPL can be a little bit more complicated (not covered in this post).
Redistribution of an application is where GPL differs the most from other open source license types. GPL is very viral by design, and can be a great tool for an entity wishing to control the redistribution of its open source asset by assuming that many potential customers or distributors will not want to play by the GPL rules. Dual-licensing (GPL + Commercial License) is often used for this purpose by allowing users to opt-out of the GPL licensing restriction if they agree to the commercial terms. There are a lot of caveats to this dual-licensing approach (e.g., open contribution, community uptake, and corporate development opportunities), but it has proven to be working (e.g., MySql). MPL and BSD-like licenses (and in some ways LGPL) are designed to allow free redistribution of the open source asset.
Modification of the open source asset is where BSD-like licenses (Apache, BSD, MIT) differ the most from other ones. All other open source licensing forces modifications to their asset to be submitted back with the same original license, whereas BSD/Apache-like licenses do not have such requirements. I personally think that this is one of the principal reasons why Apache products and assets have been broadly adopted by commercial entities such as Oracle in their commercial offerings.
So, in short, for server-side assets, open source licenses cannot really be used to control deployment, but more redistribution and modification. If there is a good OEM business opportunity, then dual-licensing (i.e. GPL + Commercial) might be an option, but if community and adoption are the principal objectives, the Apache/BSD license types are probably the most effective ones. While GPL might give the most control (in some ironic ways), it might also limit market adoption and business opportunities.
My philosophy is that leadership comes from contribution and not control (i.e. licensing).