Comprehensive software reviews to make better IT decisions
Deciding Between Open Source and Closed Source Licensing for Your Products Is Not Just About Code
When deciding on how to license your products or components, you don’t start with debating open vs. closed source code. It starts with asking simple questions around your overall goals.
- Are you looking to directly monetize the release of this product?
- Are you concerned about IP/trademark/patent protection?
- Are you concerned about being viral and being in as many places as possible?
- Do you want to give back to the community and serve your user base in different ways?
With that in mind, there are many different licensing models for you to consider. Each confers different rights and obligations upon the licensee.
Different Licensing Options
The following represents a summary of some of the different possible licensing options out there. The options are in order of restrictiveness to the licensee.
Licensing Options and Their Rights
There is great detail available on the different license types and their rights. Below is a simpler way to look at this. Note that you can get a much more complete list here.
When it comes to picking a license, your choice does not have to be so binary. It sometimes can be combined with great success.
Looking at a Real Example: Dropbox
Dropbox went through a detailed evaluation when deciding whether it want to open source a particular component called “Lepton,” its streaming image compression format. It describes its decision making in great detail in its blog entry: Balancing open source and proprietary IP—they can co-exist.
Before getting started – Dropbox thought about its goals – the why behind what it was trying to do. This ended up being a combination of platform promotion, protecting its IP, and ensuring its technology would get into as many non-Dropbox-built clients as possible.
Once this was understood, it looked carefully at the options and followed a blended approach that worked: both open sourcing its component via an Apache 2.0 license and filing patents to protect its IP rights.
Our Take
First and foremost, legal counsel is highly recommended before making any final decision around a licensing choice. You are making decisions that impact your IP and your ability to make certain product decisions in the future.
In terms of licensing choices: The rights conferred to the licensee needs to be thought about carefully in terms of your own rights as the IP holder versus your product goals. For example, if you choose to not grant explicit use rights to your patents so that developers can use your code and one of your key goals is the viral adoption of your particular code, there is clear contention.
Looking at Dropbox’s specific choices: You may wish to think of the answer as “right” or “wrong.” However, there is no perfect answer here. It’s about business goals. Dropbox could have decided to not to open source this component. It simply would not have gotten Lepton into non-Dropbox clients as easily.
In addition, when thinking about open source vs. closed source licensing – people apply a broad hammer to the question. You may not be talking about your entire product, but a single component. If you are careful, you can license different components in different ways.
Additionally, remember to think about simplicity from the licensee point of view. If your license is too restrictive or has too many exceptions, then developers may not want to leverage your licensed component. This is why sticking to one of the standard licenses is highly recommended.
Want to Know More?
Whether you are licensing code or building out a product plan – understanding your goals upfront is critical. This will inform your decision-making process, thereby ensuring alignment with organizational needs