Understanding Open-Source Software Licenses

Introduction

A software license is a legal agreement that defines how a given piece of software can be used. For software developers who may want to exercise certain rights, permissions, and control over how the work is used, modified, and shared by others, choosing a software license is an important decision. Some developers may want to place strong restrictions over how their software can be used. Others, however, may choose to license their software with few or no restrictions. This may be because they want their software to be as widely used as possible, or perhaps they oppose restrictive software licenses on philosophical grounds.

Regardless of their reasoning, developers can accomplish this by implementing an open-source software license. Broadly speaking, open-source software licenses make the source code available for use, modification, and distribution based on agreed-upon terms and conditions. There are many different open-source software licenses, and they vary based on the restrictions a creator may want future users to abide by.

When it comes to long-term planning for your project, it’s useful to understand the open-source software licenses available so that you can make an informed decision about which one best suits your project’s needs. In this article, we will share information about rights you have when your work is created (such as copyright), and how licensing helps establish the legal agreement you want your users to abide by when using your software. We will also discuss the differences between proprietary, free, and open-source software, permissive and copyleft licenses, and information about the open-source software license options suggested when creating a GitHub project.

Defining Copyright and Licensing

In the U.S. and many countries, there are certain legal protections you are automatically granted for any creative work you produce, one of those being copyright. The U.S. Copyright Office defines copyright as “a type of intellectual property that protects original works of authorship,” specifically when the “author fixes the work in a tangible form of expression.” This means with copyright you are not the owner of the idea, but rather the material expression of the idea. If a copyright owner desires stricter legal protection over their work, this can be achieved through patents, trademarks, and intellectual property laws. Copyrighting your work does not require a formal process to ensure these rights are given.

Copyright grants the owner various rights, such as reproducing and distributing copies of the work. If an owner wants control over how their work can be used by others, then they must implement a license that outlines the rules by which those users must abide. If the copyright owner states the work is “All Rights Reserved”, this means that their work cannot be used or modified by anyone at all, except themselves.

Another complexity to acknowledge is the creative work you produce for your employer. If you’re engaging in what is known as work for hire, this means that any work you create for the company or organization you work for belongs to that entity, since they’re paying you for the work. As a result, sharing this work without permission has legal consequences since you do not have ownership rights to copyright or licensing.

Proprietary Software, Free Software, and Open-Source Software

Proprietary software is any software with a license that restricts how it can be used, modified, or shared. Video games are a common example of proprietary software. If you purchase a video game (whether as a cartridge, disc, or digital download), you aren’t allowed to make a copy of that game to share with friends or sell for profit. It’s also likely you aren’t permitted to modify the game’s code to run it on a different platform than the one you originally bought it for.

Software users are typically held to certain restrictions with an end-user license agreement (EULA). If you’ve ever purchased software, you may have assumed you own that piece of software. However, if you’ve purchased proprietary software, it will likely come with a EULA that specifies you do not own the software. Instead, you’re the owner of a software license that permits you to use that software. EULAs may also define how you can use the license itself, and they typically limit you from sharing it with others without the permission of the software owner (the software’s developer or publisher).

Another legal instrument similar to a EULA is a Terms of Service agreement (ToS). Sometimes known as Terms of Use or Terms and Conditions, a ToS outlines the rules a user must follow in order to be allowed to use a program or service. It’s more common to see an EULA included with software that requires a one-time purchase, while ToS agreements are more common for subscription services and websites. Oftentimes, the first time you start a given piece of proprietary software, a dialog box will appear which explains the EULA or ToS and contains an I Agree button (or something similar) which you must click before you can use the program.

Software with such restrictions hasn’t always been the norm. Before the 1970s, software was typically distributed along with its source code, meaning users were free to modify and share the software as they desired. With time, though, software publishers began imposing restrictions on these activities, typically with the goal of increasing profits by reducing the number of people who used their software but didn’t pay for it.

This development had repercussions in the form of two closely related movements: the free software and the open-source software movements. Although the two are distinct, the free software and open-source software movements both argue that software users should be allowed to access a program’s source code, modify it as they see fit, and share it as often and with whomever they like.

Open-source software advocates still encourage developers to distribute their software with a license. However, instead of a proprietary software license outlining what users may not do, they recommend using an open-source software license that outlines the freedoms available to users of the given piece of software. These licenses are often distributed as a single file within the program, typically named LICENSE.txt or a similar naming convention.

Over the years, there has been some disagreement about what specific freedoms should be guaranteed by an open-source software license. This has led to the emergence of many different open-source licenses, but most of these can fall into one of two categories: permissive and copyleft licenses.

Permissive and Copyleft Open-Source Software Licenses

A permissive license, sometimes referred to as a non-copyleft license, grants users permission to use, modify, and share the source code, but users also have the option to change some of those terms and conditions for redistribution, including derivative work. In the context of software, a derivative work is a piece of software that is based on an existing program. If the original was released under a permissive license, a creator can choose to share their derivative work with different terms than what the original work’s license might have required.

A copyleft license, also grants users permission to use, modify, and share the source code, but offers protection against relicensing through specific restrictions and terms and conditions. This means that software users creating derivative work are required to release under the same copyleft license terms and conditions of the original work. This reciprocity is a defining aspect of copyleft licenses, and is intended to protect creators’ intentions by ensuring that users will have the same rights and permissions when using works derived from the original software.

In addition, there are public-domain-equivalent licenses that grant users permission to use copyrighted works without attribution or required licensing compatibility. For a creator, this means that any rights over their work are completely forfeited. Although there is some overlap in the philosophies behind public-domain and free and open-source software licenses, there has been disagreement over the years about whether a public-domain-equivalent license truly qualifies as open source. In 2012, the CC0 license was submitted but ultimately denied approval by the Open Source Initiative (OSI), a nonprofit organization that defines standards for open-source software and maintains a list of approved open source licenses. However, the OSI did approve a public-domain-equivalent license called the Unlicense in 2020.

Why Include an Open-Source Software License?

As a developer starting a project from scratch, it’s important to have some familiarity with the open-source software licenses available to assess how you’d like others to use your work. Recognizing these licenses is also important to users so they can understand the permissions or restrictions set by the agreement they’ve made when using the creator’s work.

Again, any original work will have copyright upon completion, but without a license, it’s unclear what is and isn’t allowed for those who want to use it. Consider the following reasons why you might include an open-source software license:

• Improvement: The open-source community prides itself on cultivating a culture that encourages collaboration and innovation. Using an open-source software license invites users to engage in community development. This creates a shared sense of responsibility to consistently improve the source code or expand the program further to everyone’s benefit.

• Ownership: If you want to exercise more power over your work, choosing a license that can place those restrictions will help you do so. For instance, if you want any derivative works to grant the same permissions as the one you originally chose, you may want to opt for a copyleft license. Fortunately, an open-source software license provides transparency to future users on how much control you have over the work, whether it’s a lot or a little, is up to you.

• Competition: There’s a plethora of software out there and if you want to break into that market, using an open-source license can help put you on the map. Some popular examples of open-source software that were developed to compete with established proprietary alternatives include the Linux operating system, Android by Google, and the Firefox browser.

Keep in mind that it is possible to monetize an open-source software project, but the typical business practice for monetizing software is to use a proprietary license to protect the software from being shared or stolen.

These reasons for using an open-source software license may not all be applicable to you, and we encourage you to do your own research on the subject before choosing a license for your next project. Additionally, you may want to seek the assistance of a legal professional to confirm a full understanding of what a license would signify for your work in the present and future.

As mentioned earlier, this article focuses on the open-source software licenses listed when creating a new repository for your project on GitHub. You’ll notice at the end of the page there is an option for choosing a license. Once you click the box, a drop-down list of licenses will appear for you to select from, like in the following:

In the next sections, we will provide brief descriptions of the types of open-source software licenses you can choose from for your next project, starting with the permissive licenses recommended by GitHub.

Permissive Open-Source Software Licenses

Permissive licenses grant software users permission to use, modify, and share the source code. Additionally, creators of software derived from permissively licensed software can change the licensing conditions for redistribution.

Please note, the following list is not representative of all the permissive open-source software licenses available. Rather, this list is taken from the license options offered by GitHub when starting a new project. Also, these brief descriptions are not comprehensive. We recommend carefully reading through the documentation for any license you’re interested in using or speaking with a legal professional for more information.

Apache License

The Apache License is written by the Apache Software Foundation (ASF). With this license, users do not have to share their modified version of the source code under the same license and can choose to use a different one, this is known as sublicensing.

MIT License

The MIT License is from the Massachusetts Institute of Technology (MIT) and is one of the shortest to read with few restrictions. Similar to the Apache license, it also gives users the option to sublicense the software.

BSD Licenses

GitHub lets you choose between two BSD licenses, the BSD 2-Clause “Simplified” License, sometimes referred to as the “FreeBSD” license; and the BSD 3-Clause “New” or “Revised” License. The main difference between these two licenses is with the 3-clause. This clause restricts software users from using the name of the author, authors, or contributors, to endorse products or services.

Boost Software License

The Boost Software License, is from the Boost Libraries of C++ and was approved by the OSI in 2008. This license is similar to the MIT and BSD licenses, except it does not require attribution when redistributing in binary form.

Copyleft Open-Source Software Licenses

Copyleft licenses grant software users permission to use, modify, and share the source code, but also protect against relicensing through specific restrictions and terms and conditions. This represents the reciprocal characteristic of this license that requires users’ work to adhere to the original rights outlined in the license.

Again, the following list is not representative of all the copyleft open-source software licenses available. Rather, this list is taken from the license options offered by GitHub when starting a new project. Also, these brief descriptions are not comprehensive. We recommend carefully reading through the documentation for any license you’re interested in using or speaking with a legal professional for more information.

GNU Licenses

There have been a number of versions of the GNU General Public License (GPL) that have been released by the Free Software Foundation, four of which users can choose from on GitHub. The GPL v3.0 requires users to state any modifications to the original code and make that original code available when distributing any binaries used on their work under that licensed software. This license also made it easier to work with other licenses such as Apache, which the previous version (v2.0), did not have compatibility with.

Before the current GPL v3.0 version, a second version was created, the GNU Public License v2.0. This license shares similar terms and conditions as v3.0, but is considered a strong copyleft license. A strong copyleft license requires that any modifications to the source code get released using the same license. The primary difference with v2.0 is that software users are allowed to distribute work if they adhere to the requirements of the license, regardless of prior legal obligations. The goal of this clause is to prevent an individual or party from submitting a patent infringement claim that would limit a user’s freedom under this license.

There is also the GNU Lesser General Public License , referred to as LGPL, and also v2.1 of the GPL v2.0. This license is meant to serve as a middle-ground between strong and weak copyleft licenses. The main difference with this license is that software users can combine a software component of the LGPL with their own and are not required to share the source code of their own components. Users can also distribute a hybrid library, which is a combination of functions in the LGPL library and functions from a non-LGPL, but there must be a copy of that non-LGPL library and information on where it’s located.

Another GNU license is the GNU Affero General Public License v3.0, referred to as AGPL. The main difference with this license is that it is specific to software programs used on a server. This license requires users who run a modified program on a server to share this information and make the modified source code available for download to the relevant modified version that is currently running on the server.

Eclipse Public License

The Eclipse Public License, is from the Eclipse Foundation and is considered a weak copyleft license. A weak copyleft license requires software users to share any changes they make to the code. This license chose to implement a weaker copyleft as a way to reduce the stricter requirements users encountered with GNU’s General Public Licenses.

Mozilla Public License

The Mozilla Public License, or MPL, is from the Mozilla Foundation and is also considered a weak copyleft license. The difference with this license (in comparison with the Eclipse Public License) is that it is file-based copyleft, which means code can be combined with open-source or proprietary code.

Public-Domain-Equivalent Licenses

Public-domain-equivalent licenses grant users permission to use copyrighted works without attribution or required licensing compatibility. As you may recall, these licenses are not always OSI-approved.

Creative Commons Zero Universal License

The Creative Commons Zero Universal License, was written by Creative Commons and is considered a public copyright license. This means copyrighted work can be freely distributed. Please be aware that this license is not OSI-approved. The main point about this license is that users can use, distribute, and modify the source code, but must agree to waive any copyrights to ensure this work is accessible in the public domain. Additionally, users do not have to provide any attribution to the work and can use it commercially.

The Unlicense

The Unlicense was released in 2012 and is considered a public-domain-equivalent license that is OSI-approved. With this license, software users can use, modify, distribute source code, and compiled binary for both commercial and non-commercial purposes. This license also advises users who want to ensure contributions to the code or software are available to the public domain by including a statement about their commitment to sharing the code base with the public.

Conclusion

There are many factors to consider when choosing an open-source software license. Yet, there are certainly popular choices among the developer community. Common permissive licenses include the MIT License, Apache License, and BSD License. Some common copyleft licenses include the GNU General Public License and the Mozilla Public License.

Remember, this article only provided information about a few common open-source software licenses, specifically the ones suggested by GitHub. We encourage you to explore all of your available licensing options or consult the help of a legal professional to make an informed decision about what best fits the needs of your project.