The basics about open source software licenses

Open source software creates freedom for businesses. Instead of being locked down by seat-license fees or contracts, a business using open source software can build, use, and maintain its technology stack with much more freedom, and often at a lower cost.

But even though you don’t buy open source software from a company that owns the code, your open source software will still come with a license.

And not all open source software licenses are the same. In fact, there are many varieties in use, as this graph from Black Duck Software shows.

So it’s important for you to understand what open source software licenses say and don’t say, and what some of the differences are, before you bring open source software into your tech stack.

Before we get started, we need to emphasize that open source software licenses are legal documents. You may want to have an attorney review the specific license used by the software you’re considering. This post is meant to provide an overview, but not legal advice.

The first thing you need to know is that there is an official list of open source licenses managed by the Open Source Initiative. These licenses meet the 10 standards of the Open Source Definition.

Because of this, all open source software licenses have important similarities, including:
* Free distribution
* Allowing modifications and derived work
* Rights that can be used for any product and by any person
* Allowing any technology and cooperation with any other software

However, different licenses have major differences as well, when it comes to:
* What can be patented
* How the software you build must be shared

That second issue, often called reciprocity, is key. Basically, some open source software licenses force developers to publish all code built with a specific piece of software to be shared back with the open source development community.

The keyword to look at when it comes to licenses is “copyleft.” A license can be strong copyleft, or it can be permissive. A permissive license lets you build what you want with few other requirements after the fact. A copyleft license is more restrictive because it forces you to share your code improvements with the larger open source community. Basically, copyleft is the opposite of copyright—everything is shared, instead of protected intellectual property.

It’s a big difference, and so it’s important to understand where the license you’re considering fits before making a decision.

Popular Open Source Licenses

The Open Source Initiative lists the following open source licenses as popular and widely used, or having strong communities. So they’re a good place to start when it comes to understanding licenses.

Apache License 2.0 (Apache-2.0)

3-clause BSD license (BSD-3-Clause)

2-clause BSD license (BSD-2-Clause)

GNU General Public License (GPL)

GNU Lesser General Public License (LGPL)

MIT license (MIT)

Mozilla Public License 2.0 (MPL-2.0)

Common Development and Distribution License (CDDL-1.0)

Eclipse Public License (EPL-1.0)

Earlier this year, a WhiteSource study found that the MIT license is the most popular, with about 25% of the market, with GPL 3.0 at 19%, Apache 2.0 at 15%, and GPL 2.0 at 14%. MIT and Apache 2.0 fall on the permissive side; GPL 2.0 and 3.0 fall to the copyleft side.

Since these four licenses account for nearly three-quarters of all licenses used in 2016, let’s look at them a bit more closely. (We also link to the actual licenses in case you need full info.)

MIT

The MIT license—created by the Massachusetts Institute of Technology—is a generally permissive license, and therefore is compatible with many other licenses, whether they’re copyleft or permissive. For example, software with the MIT license can be integrated into GPL-licensed software, but not the other way around. 

With this license, users can do whatever they want with your code, as long as they attribute it and don’t hold the original developer liable. That includes copyrights. Developers often choose it because they want to make it as easy as possible for other developers to use their code, for whatever reason.

Apache 2.0

Apache 2.0 is another permissive license. One big difference between MIT and Apache is that Apache software is compatible with GPL 3.0 but not with GPL 2.0. (The resulting software will carry a GPL 3.0 license.)

The big difference between MIT and Apache is that Apache provides an express grant of patent rights from contributors to users. Because its language is more detailed in this and other ways, it provides more clarity when it comes to receiving software patents or avoiding patent issues.

GPL 3.0 and 2.0

The GPL 3.0 license—officially called GNU GPLv3—is a copyleft license, as is GPL 2.0. Both require anyone who distributes code or a derivative work to make the source code available, which makes it harder to copyright.  The idea is that open source software developers using this license want people who use their code to share the improvements they make with the larger open source community, instead of keeping it for themselves. The different versions have different sharing criteria, so you’ll want to dig in to make sure an option meets your needs.

There are more differences, of course, so continue doing your research before you make your choice. We can’t tell you what license is right for your software project or your business—but by describing the options, we’re hoping you can find the right fit in your particular situation. That will set both your open source software project and your business up for success.

Project CTA

Looking to bring your ideas to life?

We are committed to guiding you towards the best solution for your business.

Schedule a Call With Us

About Worthwhile Storyteller

We'll never tell you a lie, but we might tell you a success story that protects the intellectual property of our clients and partners. Our Worthwhile Storyteller is an amalgamation of all of our thoughts, experience, and expertise brought together to give you the facts about our relentless improvement in the software development space.