Welcome!

Release Management Authors: Pat Romanski, Elizabeth White, David H Deans, Liz McMillan, Jnan Dash

Related Topics: Open Source Cloud, Linux Containers, Eclipse, Release Management , Apache, FinTech Journal

Open Source Cloud: Article

Which Open Source Software License Should I Use?

There are different considerations for every project

I've recently been involved in several discussions that are variations on, "Which open source or free software license should I choose for my project?" Here is my way of looking at the large and growing collection of licenses in the wild. First let's make sure we all understand that I Am Not A Lawyer. This is not legal advice. Depending upon your needs and your comfort with risk around your software, you'll want to confirm your legal choices with counsel in your jurisdiction.

The first and obvious consideration is whether or not the license is approved as an open source license by the Open Source Initiative (OSI). The OSI created the Open Source Definition in the late 1990s as a set of attributes that a software license must support to be considered "open source". Anyone can take a license to the OSI for debate and discussion and if approved as meeting the OSD, then the license is added to the canonical list.

While this seems an obvious place to start, I was recently surprised to discover a license called the "Clear BSD License." It attempts to clarify explicitly that patents are not being discussed in the license. It is not on the OSI list (while the New BSD and Simplified BSD licenses are) and is therefore not worth considering. Inventing new licenses as small derivatives of existing licenses is not helpful and creates costly legal busy work. There exists a broad collection of OSI-approved licenses today. These licenses cover millions of lines of software involved in billions of dollars in procurement. One would be hard pressed to describe a serious set of circumstances that isn't already covered by an OSI-approved license.

There are several big levers available when considering an open source license:

  • How much license reciprocity is required with respect to the software, modifications, and any derivatives someone develops?
  • What is said about patent licensing and litigation?
  • What legal jurisdiction covers the license?

The reciprocity issue is all about "copyleft" and whether or not using the software source code attaches the license to the modifications and derivatives, and whether the source code to those modifications and derivatives needs to be published.

On one end of the spectrum are licenses that have no copyleft requirements. These licenses essentially allow anyone to use the software in anyway without requiring much more than maintaining copyrights. Licenses that fall into this set include the New and Simplified BSD licenses, the MIT license, and the Apache 2.0 and Microsoft Permissive licenses.

There are a set of licenses that maintain a sense of copyleft around the software itself but support the use of the software in larger works of software which may contain software that is licensed differently (e.g. closed and proprietary). These licenses include the Eclipse Public License, the newer Mozilla Public License 2.0, and the Microsoft Reciprocal License.

On the other end of the copyleft spectrum are strong copyleft licenses. Software freedom is defined by the Free Software Foundation in terms of the freedoms a user of software must have. Strong copyleft supports software freedom. Many developers support software freedom, and demonstrate this support using one of the family of GPL licenses (GPL2.0, GPL3.0, and the Affero GPL3.0) as a way to ensure the strongest copyleft and strongest license attachment when the software in question is used in building and distributing other software.

Software patents weren't really an issue when software was beginning to be widely shared on the early Internet and so weren't mentioned in the early licenses. By the late 1990s, software patents were on the rise and corporate legal teams were becoming more involved in the writing of open source licenses as they became more involved with open source software and developing the open source foundations around evolving projects. The Apache 2.0 License, Mozilla Public License 2.0, Eclipse Public License, the newer GPL licenses, and both Microsoft licenses reflect this shift in language. Each license explicitly talks about patent licenses. Each license has language that covers patent litigation to varying degrees.

I mention legal jurisdiction in the big levers category because some licenses explicitly mention it and this can be a real show stopper for some people. For that reason alone I treat it as a Big Lever. (The Mozilla Public License 2.0 specifically tries to deal with jurisdiction as one of changes from the original MPL, as that was often a criticism of the earlier license.)

Other considerations in license choice include:

  • Are there project specific affinities?
  • History of the license and foundation/corporate/commercial involvement?

The "language" projects (Perl, PHP, Python) each have their own licenses (Artistic License 2.0, PHP License 3.0, and Python License 2.0 respectively). If you are working on a project that closely ties to a specific open source programming language community then you should obviously consider that community's license as the question of mixing modules and dependencies will be simplified with respect to open source license.

As software IP law has evolved and the Internet has become an enormous space for people to collaborate on software development, commercial organizations became involved. We have seen the creation of open source software foundations with specific licenses associated with them. Corporate legal teams have become involved in authoring open source licenses, and the language and structure of these licenses (e.g. terminology and definitions) reflects this involvement. Lawyers without a lot of experience in open source licenses may feel more comfortable reviewing these newer licenses.

So to recap, presuming that your primary motivation is to co-develop and collaborate on an open source project, in my way of looking at open source licenses your choices break down roughly as follows. (I'm keeping the discussion here to widely used licenses, and/or licenses where large commercial organizations with conservative counsel or neutral non-profit open source foundations had a hand in their creation.)

If you want to allow anyone to do anything at any time with the software, use the MIT or new (3-clause) BSD license, i.e. no copyleft and no discussion of patents. Both of these licenses came from the academic world, and both from a period of time where software patents were not a focus.

If you want to allow anyone to do anything with the software (so no copyleft), but feel something needs to be said about patents and license termination in the face of litigation, and/or you want a license that corporate counsel is more comfortable reading then look at either the Apache 2.0 license or possibly the Microsoft Permissive License. These licenses were written to continue to encourage a completely open sharing environment but were written with a more corporate view (note the structure and language), and both begin to cover patents with varying (and subtly different) degrees of patent retaliation built into them.

If you feel others should be able to build [possibly product] around your software, but want to ensure changes to the core software project itself remain open source (i.e. the changes must be published), you likely want to look to either the Eclipse Public License, the newer Mozilla Public License 2.0 or the Microsoft Reciprocal License. These are modern licenses developed from commercial/corporate perspectives supporting "weak" copyleft. [N.B. The EPL does name NY State as the jurisdiction.] Pay attention to patent statements in each.

If you are a firm supporter of software freedom or want to ensure that if your software source is used anywhere that the resulting derivatives are maximally published as open source ensuring software freedom then you should look to GPL2.0 or GPL3.0 depending upon your needs.

There are a couple of interesting side ideas I've come across in the open source licensing space as different projects wrestled with how best to create the "right" licensing for their software.

  • Many companies are concerned about their patent portfolios when creating open source projects. Google took an interesting approach to the problem when they released the WebM project. They chose the New BSD license and then created a very specific "Additional IP Rights Grant" to cover the patent language they needed.
  • It is the nature of IP law that the owner of the property can license it as many ways to as many people as they choose. This is why the Microsoft EULA for a personal copy of the Windows operating system is different from an Enterprise License Agreement and how MySQL AB developed a line of business around closed software licensing as well as their GPL-licensed project. In the early days (up through PHP3), the software from the PHP project was similarly "dual" licensed under both the GPL2.0 and an earlier PHP license to allow the software to be included in as many places as possible because the GPL was not directly compatible with the PHP license of the time.

I have deliberately not tried to create a table or decision tree for license choice here. I believe there are sufficient edges and nuances to license choice that it can never be properly "automated" with the licenses we have today that reflect their rich background of needs and history. There is always one more legal question of "what about the situation when ...?" Such questions will likely involve legal counsel and may be very jurisdiction sensitive.

Likewise, open source software licenses don't simply reflect a set of legal choices. In the early stage of an open source project when the author or authors are first publishing the software, the choice of license reflects as much of the social contract that is being made for the project as any legal requirements. It is the first governance document of the early possible community that comes into play long before formal governance, mission statements, and codes of conduct may be created around growing community.

Full text of all the licenses can be found on the Open Source Initiative at:http://opensource.org/licenses/alphabetical

Excellent information on how to consider various software licenses in combination with the GPL can be found here: http://www.gnu.org/licenses/license-list.html#SoftwareLicenses

If you need to get a lawyer up to speed, consider pointing them to: http://www.ifosslr.org/ifosslr

More Stories By Stephen Walli

Stephen Walli has worked in the IT industry since 1980 as both customer and vendor. He is presently the technical director for the Outercurve Foundation.

Prior to this, he consulted on software business development and open source strategy, often working with partners like Initmarketing and InteropSystems. He organized the agenda, speakers and sponsors for the inaugural Beijing Open Source Software Forum as part of the 2007 Software Innovation Summit in Beijing. The development of the Chinese software market is an area of deep interest for him. He is a board director at eBox, and an advisor at Bitrock, Continuent, Ohloh (acquired by SourceForge in 2009), and TargetSource (each of which represents unique opportunities in the FOSS world). He was also the open-source-strategist-in-residence for Open Tuesday in Finland.

Stephen was Vice-president, Open Source Development Strategy at Optaros, Inc. through its initial 19 months. Prior to that he was a business development manager in the Windows Platform team at Microsoft working on community development, standards, and intellectual property concerns.

IoT & Smart Cities Stories
Never mind that we might not know what the future holds for cryptocurrencies and how much values will fluctuate or even how the process of mining a coin could cost as much as the value of the coin itself - cryptocurrency mining is a hot industry and shows no signs of slowing down. However, energy consumption to mine cryptocurrency is one of the biggest issues facing this industry. Burning huge amounts of electricity isn't incidental to cryptocurrency, it's basically embedded in the core of "mini...
Every organization is facing their own Digital Transformation as they attempt to stay ahead of the competition, or worse, just keep up. Each new opportunity, whether embracing machine learning, IoT, or a cloud migration, seems to bring new development, deployment, and management models. The results are more diverse and federated computing models than any time in our history.
At CloudEXPO Silicon Valley, June 24-26, 2019, Digital Transformation (DX) is a major focus with expanded DevOpsSUMMIT and FinTechEXPO programs within the DXWorldEXPO agenda. Successful transformation requires a laser focus on being data-driven and on using all the tools available that enable transformation if they plan to survive over the long term. A total of 88% of Fortune 500 companies from a generation ago are now out of business. Only 12% still survive. Similar percentages are found throug...
Japan DX Pavilion at @CloudEXPO Silicon Valley
The graph represents a network of 1,329 Twitter users whose recent tweets contained "#DevOps", or who were replied to or mentioned in those tweets, taken from a data set limited to a maximum of 18,000 tweets. The network was obtained from Twitter on Thursday, 10 January 2019 at 23:50 UTC. The tweets in the network were tweeted over the 7-hour, 6-minute period from Thursday, 10 January 2019 at 16:29 UTC to Thursday, 10 January 2019 at 23:36 UTC. Additional tweets that were mentioned in this...
In his general session at 19th Cloud Expo, Manish Dixit, VP of Product and Engineering at Dice, discussed how Dice leverages data insights and tools to help both tech professionals and recruiters better understand how skills relate to each other and which skills are in high demand using interactive visualizations and salary indicator tools to maximize earning potential. Manish Dixit is VP of Product and Engineering at Dice. As the leader of the Product, Engineering and Data Sciences team at D...
At CloudEXPO Silicon Valley, June 24-26, 2019, Digital Transformation (DX) is a major focus with expanded DevOpsSUMMIT and FinTechEXPO programs within the DXWorldEXPO agenda. Successful transformation requires a laser focus on being data-driven and on using all the tools available that enable transformation if they plan to survive over the long term. A total of 88% of Fortune 500 companies from a generation ago are now out of business. Only 12% still survive. Similar percentages are found throug...
Where many organizations get into trouble, however, is that they try to have a broad and deep knowledge in each of these areas. This is a huge blow to an organization's productivity. By automating or outsourcing some of these pieces, such as databases, infrastructure, and networks, your team can instead focus on development, testing, and deployment. Further, organizations that focus their attention on these areas can eventually move to a test-driven development structure that condenses several l...
The term "digital transformation" (DX) is being used by everyone for just about any company initiative that involves technology, the web, ecommerce, software, or even customer experience. While the term has certainly turned into a buzzword with a lot of hype, the transition to a more connected, digital world is real and comes with real challenges. In his opening keynote, Four Essentials To Become DX Hero Status Now, Jonathan Hoppe, Co-Founder and CTO of Total Uptime Technologies, shared that ...
Over the course of two days, in addition to insightful conversations and presentations delving into the industry's current pressing challenges, there was considerable buzz about digital transformation and how it is enabling global enterprises to accelerate business growth. Blockchain has been a term that people hear but don't quite understand. The most common myths about blockchain include the assumption that it is private, or that there is only one blockchain, and the idea that blockchain is...