How to Apply a License to Your Open Source Software Project - FOSSA (2023)

We begin this post with the assumption that you’ve already decided what open source software license you'll use for your project, and so the next question is: How do you assign it to your project?

While it may be tempting to throw a quick answer — i.e. “just put in the README," — there are more than a few options for doing so, and it can be problematic if, for instance, multiple licenses are mentioned in multiple places across a single project.

Which license prevails if more than one is mentioned?

And then there is a related subject of copyright. Do you need to have copyright messaging in your sources? Do you need to say “all rights reserved”? What year should you place there, and if you do so, are you obligated to keep updating it as time goes by? In other words, would a statement like “© 2016 Wizard” still apply today, in 2021?

And, finally, can a consumer of your library claim damages against you if your software didn’t work as expected? Or, perhaps it inadvertently caused data corruption, subsequently resulting in a massive headache, a time sink for their engineering team, or in the worst-case scenario, permanent data loss? Can the company that chose to use your free software go after you in court and try to recoup the damages? Mistakes happen, and they can happen to anyone, even the most talented and diligent programmers, so it’s only reasonable to desire not to be liable for the mistakes in the software you are giving away for free.

Choosing an Open Source Software License

We previously posted about choosing an open source software license, so to avoid repeating ourselves, we’ll condense this section to a simple diagram, courtesy of the BSD Magazine — just follow the flowchart to determine what license is the most suitable for your particular use-case.

It’s hard to overstate the importance of choosing the appropriate license for a popular open source project. For instance, in one example, a change in licensing terms resulted in version downgrades and removals of the popular nmap binary from various open source linux distributions. Eventually, the authors reverted the change in license. That said, nmap is an open source project with a real business model — and it’s that business model which makes it much more sensitive to the licensing language and requirements than other projects that are not tied to a revenue stream.

Applying an Open Source Software License

In the most common scenario, you will want to place a file named LICENSE at the root of your project sources. You are certainly allowed to use any appropriate file extension to identify the file’s markup — i.e. this could be LICENSE.md for markdown, .adoc for AsciiDoc, .html for HTML, and so on. Having said that, and considering that this file contains very specific legal verbiage, it is best to leave it be plain text and named just LICENSE without any extension.

But please, for all our sakes, please do indeed use all caps in the file name. Such is the convention, and conventions exist for a reason. Most of the time, anyway.

Adding an Open Source Software License to New Projects

Many modern SaaS tools such as GitHub and GitLab will allow you to choose the license when the repository is first created. This is, perhaps, the single simplest way you can ensure your projects contain the right legal protections from the start.

Once you start the “Create new repository” workflow, GitHub will present you with the following screen, which contains a relevant checkbox toward the bottom. Checking the box opens up the drop-down with numerous licensing options to choose from.

Adding an Open Source License to Existing Projects

For existing projects without a license, just drop the LICENSE text file at the top of the repo, commit, push, and cut a new release.

If your project did not have any license up until this point, nobody can legally use it, even if it’s public and visible to the entire world.

Can someone theoretically use it without a license? Sure. But is it technically legal? No, and so most corporations and nonprofits will not be able to take advantage of your creativity until you add a license.

Why did we suggest that you “cut a new release”? Most software projects support a feature called “releases” or “tags” (which can be used interchangeably or separately). For example, GitHub supports both tags and releases. If you are already using tags or releases — great! You will want to create a new version with the new license, even if the only difference between the last version and this one is the presence of this file. This is because such action tells the world: “Starting with version X.Y.Z, my project is distributed under license A.”

In the future, you may change your mind. You may decide to use a different license, or perhaps withdraw it altogether, or even make the project private and closed source. All of these options are available to you, but they will only ever apply to future versions, and not to the past versions that were already released. For example, if someone downloaded your software legally under the MIT License, they are allowed to use and modify it as is (that particular version) in perpetuity.

Is a License Required Anywhere Else?

As a matter of fact — yes. In addition to placing the top-level LICENSE file, your project may also be subject to the specification requirements imposed by the packaging and distribution format.

For instance, if you are writing a Ruby library (known as a “ruby gem” and distributed via the RubyGems.org website), there is a detailed specification that is required for the file to be considered a valid gem (otherwise RubyGems rejects it). Part of that specification is the license designation, which must match with one of the known licenses. Almost all popular Ruby libraries use the MIT License, with few exceptions.

Most modern languages such as Rust support license designation directory in the library specification metadata. Once again, the trend in the open source industry is to standardize license declarations to make it easier for consumers of the software to answer the question: Is it legal for me or my entity (a company, a nonprofit, an individual) to use this software in a particular capacity?

What Open Source Licenses Permit and Prohibit

This is an important topic that you should understand before you publish your open source software under any given license. Once again, we offer a diagram courtesy of the BSD Magazine:

Dependencies, Cyclic Graphs, and the Weakest Link in the Chain

Whether you release software under a copyleft or permissive license, your goal is most likely that your library will receive wide adoption, resulting in a never-ending stream of beer that users of your library buy you in gratitude.

However, very few libraries come with “no strings attached” — meaning, in this context, dependencies. It is common to have “runtime dependencies” and “build-time dependencies.” In the Ruby Gem terminology, the build dependencies are called “development dependencies.”

Each of your runtime dependencies may have its own runtime dependencies, and so on and so forth. If you programmed in Ruby before Bundler was released, managing dependencies was quite a challenge, as you had to manually figure out which versions of downstream dependencies are cross-compatible among your main dependencies.

History aside, the multi-level dependency graph that is generated by taking all of your dependencies, then their dependencies, and so on, until every dependency of every other dependency is discovered, is exactly what Bundler does when you run bundle update.

For more information on Bundler’s dependency resolution algorithm based on Molinillo, we refer you to this most excellent article by Dependabot: “Fixing Bundler's dependency resolution algorithm and making it 2x faster.”

What concerns us in this article is how dependencies affect licensing and subsequently wider adoption of your work.

In a nutshell, if your dependencies are distributed under open source licenses different than the one you are using for your own library, the resulting obligations on your users, from a legal perspective, are going to be determined by the strongest license across all of your dependencies, and their dependencies, and so on.

Let’s say you chose the ubiquitous MIT License to distribute your library. A staff engineer at AcmeCorp Inc. discovers your library and decides that it is exactly what they need. They integrate it into their project, run bundle install, and everything works as expected.

Six months later the company is in talks to be acquired by a much larger tech giant, which is a publicly traded company on the stock market. Being a public company places additional legal burdens on the organization, and one of the consequences is that they must perform a technical audit of your software to ensure compliance.

Well, it turns out that your library depends on another library, which depends on yet another library, which is distributed under the stronger GPL license. This has consequences to your engineering audit. Typically, components distributed under such licenses may not be used unless the company that uses them also releases modified source code — a deal breaker for most commercial uses. This might mean that you have to replace or rip out a dependency in order to achieve compliance, or obtain a separate license from the authors of that GPLed component.

Compliance with Licensing Obligations

Compliance simply means that any and all of the legal obligations defined by the licenses of the open source dependencies that might be used at runtime or during development are satisfied. There are at least 70 active open source licenses in wide use, as reported by the Open Source Initiative. There are thousands more obscure, derived, or made-up licenses that are not even listed there. This makes compliance across a large set of dependencies a hard problem to solve for your legal team.

This is where tools like FOSSA come in handy — they automate this otherwise incredibly challenging manual process.

For example, a technical audit may reveal that one of the downstream dependencies is distributed under the GNU General Public License (GPL), which is famously not compatible with any proprietary software. The FAQ on the license states:

This General Public License does not permit incorporating your program into proprietary programs. If your program is a subroutine library, you may consider it more useful to permit linking proprietary applications with the library. If this is what you want to do, use the GNU Lesser General Public License instead of this License.

Copyright and Contributor Licensing Agreement

In addition to the open source license, if you peek at any existing popular project’s source code, you will undoubtedly find a copyright statement at the top of most files. For instance, the top of most Ruby files in the Ruby on Rails source code have the following:

# frozen_string_literal: true
#--
# Copyright (c) 2004-2021 David Heinemeier Hansson
#
# Permission is hereby granted, free of charge, to any person obtaining
# …. [stipped for brevity]

According to Wikipedia,

“...Software copyright is the application of copyright law to machine-readable software. [snip] Software copyright is used by software developers and proprietary software companies to prevent the unauthorized copying of their software. Free and open-source licenses also rely on copyright law to enforce their terms. For instance, copyleft licenses impose a duty on licensees to share their modifications to the work with the user or copy owner under some circumstances. No such duty would apply had the software in question been in the public domain”

What does this all mean, however, in plain English?

Typically, even with open source licenses, the author retains the rights to the software. Among other things, this means the author can choose to make any future versions no longer open source. Adding your copyright simply marks the software as written, e.g. created, by you.

However, what happens when your project accepts contributions from other people and incorporates them into your work? Does that change the copyright? Should you add every contributor to the ever-growing list of authors of each file? While this seems reasonable, it certainly isn’t practical, especially if the project ends up having hundreds of contributors over the years.

There are two main ways that open source projects handle this scenario:

1. Some projects include a “contributor licensing agreement” (CLA) that contributors must agree to before their contributions are accepted. For example, open source projects under Google’s initiative (such as Bazel Build System) may require you to read and agree to Google’s CLA terms and conditions before your pull request becomes permitted for review. Some CLAs go as far as to require contributors to either automatically transfer the copyright to the original project author or to agree in advance to any changes to the licensing the primary author might want to enact in the future.
   
2. Others simply consider every contributor to be a copyright owner. This is the default method that applies to most projects without an explicit CLA like Google’s.

   The only downside of this method is if the primary or original author decides to change the license in the future. In this case, they must collect written permission from every single contributor. On projects with many contributors, some may actually no longer be alive, and therefore the author will need to track down the next of kin and try to explain why they must sign this strange document they know nothing about. This is nearly impossible to pull off, so if you are accepting contributions from others without an explicit CLA, practically speaking you won’t be able to change your license without going through a very expensive set of hurdles.

Considering that option 2 is much more common than option 1, many projects adopt the following approach to the copyright statement: Instead of placing “© Copyright 2021, <Author’s Name>” in each file, they instead put something like this:

# © Copyright 2021, <Project>’s Authors <or Contributors>

This is a more general approach and relies on the fact that the list of contributors can be collected from revision control history; or, some projects maintain a top-level file called CONTRIBUTORS listing the name and email address of every contributor whose modifications to the projects have been accepted and merged onto the mainline.

A statement such as this means that:

• The project is copyrighted
• The author(s) have licensed it for distribution and incorporation in other projects under whatever license is declared by the LICENSE file
• The author(s) or project contributor(s) wish to retain the ownership of the copyright

Whether or not such a project can be incorporated into a proprietary codebase depends solely on the license chosen. But the copyright remains with the contributors.

For more information about the contributor license agreements, check out these two posts

• What You Should Know About Contributor License Agreements in Open Source Projects
  By Stephen E. Kabakoff; Nicholas D. Petrella
• Legal Side of Open Source — Does my project need an additional contributor license?
  By the Legal Guide to Open Source on Github

Warranty Waiver and Liability

One of the key aspects of most open source licenses is the warranty waiver clause, which typically reads like this:

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

This is yet another good reason to include a license in your project. It explicitly absolves you — the author — of any damages your library or a tool may cause, for instance, in a commercial production environment.

The developers that choose to use your software under the terms of the license are the ones responsible for the production outage, not you. But don’t get carried away with this absolution — things get quite a bit muddy when there is a provable intent to cause harm that’s disguised in an open source project (such as malware distributed as part of Ruby Gems).

Summary

To summarize, for new projects we recommend using the built-in features of your source code repository provider such as GitHub and GitLab to apply an open source license to your project. If you are looking to use a permissive license, the MIT License is the most popular and allows anyone to use your creation in any form, commercial or not.

Speaking of the popularity, here are the top 10 licenses used across projects sampled by the BBVA Innovation Center:

To attach a license to an existing project, create a plain text file called LICENSE at the root of your project and copy the text from the license while substituting your own name for copyright. Once your LICENSE file is done, tag your project with the new release, and publish the new version. Starting with this version, your project is officially open-sourced under the chosen license.

Decide whether or not you want a contributor license agreement, and whether or not you want contributors to grant you copyright for any change, keeping in mind that without the explicit contributor agreement, any future changes in licenses require written permission from every contributor.

Keep in mind that licenses also protect you from damages that may occur because of mistakes or misuse or any other reason somehow connected to the use of your software.

Finally, use tools that are able to analyze your dependencies and bring to your attention any potentially problematic licenses. FOSSA.com offers this service free of charge for open source projects.

Acknowledgments and Notes

The diagrams in this article are used under the BSD license and were created by the BBVA Innovation Center for The BSD Magazine.

You can read more developer-focused content from the author of this post by visiting the website kig.re.