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.
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
COVID-19 has forced software companies and their suppliers to refocus efforts around prioritizing systems and workflows that are nearly 100% digital in nature. As a result, Info-Tech has observed the quick emergence of six market themes that are highly relevant after COVID-19. This note series will profile key vendors and how they fit into the post-COVID-19 world.
IBM is changing the terms of its ubiquitous Passport Advantage agreement to remove entitled discounts on over 5,000 on-premises software products, resulting in an immediate price increase for IBM Software & Support (S&S) across its vast customer landscape.
Is it true that everything that can go wrong will go wrong? Don’t bet on it to not.
While Microsoft is not a prominent player in the RPA space now with its Power Automate solution, compared to Blue Prism, UiPath, and Automate Anywhere, its latest acquisition of Softomotive, maker of WinAutomation, demonstrates Microsoft’s dedication to mature and expand its RPA offerings.
Test data management tools offer you the ability to provision, mask, and govern the access and use of your test data, alleviating these manual, laborious and error-prone tasks from your testing, operations, and DBA teams.
When trying to implement Agile as a defined process, Scrum turned BAs or other roles into order takers with the title “product owner.” This undermines the entire value proposition of product management.
Agile systems delivery (implemented through Scrum) is quickly becoming an accepted norm in IT. But using Scrum successfully in an organization requires a deep understanding of how it works and why. For example, many of our members don’t understand the importance of selecting a Product Owner who has three ears.
Reeling from the pandemic response executed by governments all the over world, companies are accelerating their implementation of low-cost automation. That bodes well for UiPath – a leader in RPA aiming to go public this year.
Thor, the Norse God of Thunder, tells Jane Foster, the woman he’s trying to impress, that on his home world of Asgard, the realm eternal, science and magic are two sides of the same coin. Had Jane been a part of the operations teams at Google (or other mature online service providers), she would have immediately realized we have a similar technology right here on good old Earth. We call the science site reliability engineering (SRE), and service level objectives (SLO) is the magic behind it. SRE is a powerful concept for organizations that are serious about keeping their customers happy. It is therefore important for them to develop well-thought-out SLOs and make certain that management is intellectually equipped to derive valuable business perspectives from them.