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.

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

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 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.

(Video) Automate License Compliance with FOSSA

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

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 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:

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

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.

(Video) How to Achieve Continuous Open Source Compliance

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]

(Video) Getting Engineering Buy-In on OSS License Compliance

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

(Video) Fast Track Open Source Compliance with FOSSA

Warranty Waiver and Liability

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


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).


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:

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

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. 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

(Video) An Overview of Copyleft Licenses


How to Apply a License to Your Open Source Software Project - FOSSA? ›

Including an open source license in your repository

Under the file name, click Choose a license template. On the left side of the page, under "Add a license to your project," review the available licenses, then select a license from the list. Click Review and submit.

How do I add an open source license to a project? ›

Including an open source license in your repository

Under the file name, click Choose a license template. On the left side of the page, under "Add a license to your project," review the available licenses, then select a license from the list. Click Review and submit.

How do I license open source? ›

Applying a license to your open source projects
  1. Open your GitHub repository in a browser.
  2. In the root directory, click on Create new file .
  3. Name the file “LICENSE”.
  4. Click on Choose a license template .
  5. Pick one of the licenses (all the ones mentioned in this article are there).
  6. Once chosen, click on Review and submit .
Oct 17, 2017

Which license should I use for my open source project? ›

GNU General Public License (GNU GPL)

The GNU GPL is a copyleft license and perhaps the most popular of the open source licenses. It guarantees developers the freedom to take a program and modify it in any way they want, as long as they then distribute that altered version as free software.

How do I add a MIT License to my code? ›

To use the MIT license, developers need to copy the text as provided and include in source files as applicable. If using any other MIT licensed software in the project, retain the original license information at the top of the file, while keeping the copyright statements (if unchanged).

Does open source software require a license? ›

Open source licenses are licenses that comply with the Open Source Definition – in brief, they allow software to be freely used, modified, and shared. To be approved by the Open Source Initiative (also known as the OSI) a license must go through the Open Source Initiative's license review process.

Can I use open source code in my project? ›

Absolutely. All Open Source software can be used for commercial purpose; the Open Source Definition guarantees this. You can even sell Open Source software. However, note that commercial is not the same as proprietary.

How does open source software licensing work? ›

The simplest explanation is that open source licenses are legal and binding contracts between the author and the user of a software component, declaring that the software can be used in commercial applications under specified conditions. The license is what turns code into an open source component.

What are the two types of open source licenses? ›

There are two main categories of open source licenses: copyleft and permissive. This division is based on the requirements and restrictions the license places on users. Copyright is a law that restricts the right to use, modify, and share creative works without the permission of the copyright holder.

What is needed to be set up before adding a license? ›

Before you start adding license verification to your application, you need to set up your Google Play publishing account, your development environment, and any test accounts required to verify your implementation.

Who owns an open source project? ›

Who Owns It? Typically, for open-source projects, the creator owns the software but provides a license to other “contributors” to reproduce, modify and redistribute the software. The licenses offered to contributors and users of the software are often standardized (see MIT, GNU LPGL, and Apache as examples).

Can anyone join an open source project? ›

You can easily join an open source project by subscribing to the mailing list for that project. You can find mailing lists on official websites or on GitHub pages. After being accepted to the list, you can communicate with team members and get support if necessary.

Does MIT License mean free? ›

The MIT License is a permissive free software license originating at the Massachusetts Institute of Technology (MIT) in the late 1980s.

Who enforces open source licenses? ›

Because open source licenses flow directly from the author/owner to the licensee, the only party in a legal position to enforce the GPL is the author or owner of the copyright. Intermediate distributors do not have the power to enforce except with respect to any contribution they may make.

What are the four major types of open source licenses? ›

There are four main types of licenses for open source software:
  • Permissive.
  • Copyleft.
  • Weak copyleft.
  • Public domain.
Jan 4, 2023

Do you have to pay for an open source license? ›

Open source software has many benefits: It's usually free, because people working on it are typically volunteering their time or interested in having others use the software they created.

What is the easiest open source license? ›

Permissive licenses

Apache licenses contain a patent grant. The MIT License, which bears the name of the famous university where it originated, is perhaps the most used open source license in the world, perhaps because it is very short and clear and easy to understand.

What makes a project open source? ›

Open source is a term that originally referred to open source software (OSS). Open source software is code that is designed to be publicly accessible—anyone can see, modify, and distribute the code as they see fit.

What is the difference between open source software and licensed software? ›

Unlike open-source software, a licensed solution is developed in a controlled environment by a focused team. This team of dedicated developers are the only people who can view or edit the source code, meaning that the product is heavily audited and the risk of backdoor Trojans is considerably diminished.

What is the most popular open source license? ›

The Apache 2.0 license and the MIT License are far more popular than the GPL family, together comprising over 50% of the top open source licenses currently in use. Permissive licenses place minimal restrictions on how others can use open source components.

What are the bad open source licenses? ›

Which open source licenses are bad? You need to be careful about a few restrictive licenses, like GPL 3.0 or AGPL. In the worst-case scenario, you may be required to release your software under the same license, royalty-free.

What is an example of a proprietary software license? ›

A proprietary license model is based on the concept that the software company creates software and maintains control over its code, and therefore, its features and use. You most likely use programs that have a proprietary software license. These include Microsoft Windows, iTunes, Adobe Photoshop, Skype, and more.

How do I get a Google license? ›

Add user licenses on the Annual Plan
  1. Sign in to your Google Admin console. ...
  2. In the Admin console, go to Menu Billing. ...
  3. Click your subscription.
  4. In the expanded section, next to the number of licenses you currently have, click Purchase more.
  5. Enter the number of additional licenses you want to buy and click Continue.

How do I assign a desktop license to my work account? ›

In the admin center, go to the Users > Active users page.
  1. Select the row of the user that you want to assign a license to.
  2. In the right pane, select Licenses and Apps.
  3. Expand the Licenses section, select the boxes for the licenses that you want to assign, then select Save changes.
Mar 15, 2023

Can an open source project be sued? ›

A mere member of the public can't sue to enforce an open source license. Intellectual property laws narrowly limit standing. Only the owner of a copyright or patent may sue to enforce the copy- right or patent.

Do people get paid for open source projects? ›

Funding your own time. Today, many people get paid to work part- or full-time on open source. The most common way to get paid for your time is to talk to your employer. It's easier to make a case for open source work if your employer actually uses the project, but get creative with your pitch.

Can I monetize an open source project? ›

Support plans. Providing support to users, especially enterprise users, is one of the most mainstream ways of earning money with open source software for a developer. When they need to troubleshoot your software, chances are they'll be willing to pay for your support.

How do people make money from open source projects? ›

Many OSS vendors make most of their revenue from support and service. Customers who use open-source software often need help setting it up, configuring it for their specific needs, and troubleshooting any problems. As a result, these companies charge for access to customer support and services.

Is open source license public domain? ›

"Open source" isn't "public domain" in the IP sense, because it typically has an owner who provides it, often free, under a license granting a wide range of rights and obligations to the user. But it can be "public domain" from the export control perspective.

Why does everyone use MIT License? ›

Like the Apache 2.0, and BSD family of licenses the MIT License is a permissive software license that places few restrictions of reuse. Users of software using an MIT License are permitted to use, copy, modify, merge publish, distribute, sublicense and sell copies of the software.

Is MIT a copy left license? ›

Unlike copyleft software licenses, the MIT License also permits reuse within proprietary software, provided that all copies of the software or its substantial portions include a copy of the terms of the MIT License and also a copyright notice.

What is the opposite of MIT License? ›

The MIT and Apache licenses are the polar opposite and are classified as “permissive” licenses.

How do I install a license? ›

Installing a license
  1. Save the license file to your hard disk. Your desktop is a handy location. ...
  2. Click the About tab.
  3. In the Register area, click Browse.
  4. Locate the license file saved in step 1; then click Open.
  5. Click Install license.
  6. Verify license information is correctly listed in the About page. NOTE.

How do I upload a license file? ›

On a computer running any version of Windows with User Access Control enabled, you must start the development environment as an administrator. Verify that you are connected to your database. On the File menu, point to Database, and then choose Open. Upload the new license.

What type of file is license? ›

License file defined

A license file (previously called a provisioning file) is a plain text file that automatically supplies required information—such as product name, authorization number, and user contact information—to the Software Authorization Wizard.

How do I assign a license in MS project? ›

In the admin center, go to the Users > Active users page.
  1. Select the row of the user that you want to assign a license to.
  2. In the right pane, select Licenses and Apps.
  3. Expand the Licenses section, select the boxes for the licenses that you want to assign, then select Save changes.
Mar 16, 2023

How do I add a license to a Python project? ›

  1. create-license. Easily create license files. Requires Python 3.
  2. Installation. pip install create-license.
  3. Usage. create-license [license name] [?output] Creates the specified license. If no output file is specified, it will write to ./LICENSE . ...
  4. Add a License. To add a license to create-license: Fork this project.

How do I install an open source application? ›

Installing open source software depends on your operating system.
You will need to install a precompiled version.
  1. Go to the project website.
  2. Check for ports of the program. Find a port for either Windows or your version of Windows.
  3. Download and run the installer.
  4. Once installed, shortcuts will likely be created.

What is the difference between assign and license? ›

The key difference between a license and an assignment is that an assignment transfers rights away from the original copyright or patent holder. Whereas the licensor retains ownership of the intellectual property rights, the assignor gives up the rights entirely.

Can a project have multiple licenses? ›

Multi-licensing is the practice of distributing software under two or more different sets of terms and conditions. This may mean multiple different software licenses or sets of licenses. Prefixes may be used to indicate the number of licenses used, e.g. dual-licensed for software licensed under two different licenses.

Do you need a Microsoft Project license to view a project? ›

Microsoft Project and portfolio management solutions require a Project Server 2019 license for each running instance of the software, and CALs are required for each person or device accessing a Project Server. Learn more about Project Server licensing and software requirements.

What license should I use for my Python project? ›

Permissive Licenses
  • MIT. The MIT license is the most common license attached to python source code. ...
  • BSD. The BSD license has multiple tiers. ...
  • Apache 2.0. The Apache 2.0 license is one of the most popular licenses in the greater programming community.
Mar 3, 2021

What type of license is Python? ›

Python software and documentation are licensed under the PSF License Agreement.

How do I open an open source project? ›

In summary, the steps in the legal review process include:
  1. Consider the impact of open sourcing on your company's intellectual property.
  2. Ensure full compliance with open source licenses.
  3. Select an open source license for the source code to be released, document all licensing requirements very clearly in your project.

Do you pay for open source software? ›

Open source software has many benefits: It's usually free, because people working on it are typically volunteering their time or interested in having others use the software they created.

Does open source mean free? ›

Practical Differences between Free Software and Open Source

Nearly all open source software is free software, but there are exceptions. First, some open source licenses are too restrictive, so they do not qualify as free licenses.


1. A Patent Attorney's Journey to Open Source with Shebli Mikailli
2. How to Fulfill OpenChain's 6 Core Requirements
3. FOSSA Makes Open Source Management Collaboration Easy
4. How SmartThings Runs Open Source License Compliance
5. The FOSSology Project – Open Source Software for Open Source License Compliance - Anupam Ghosh
(The Linux Foundation)
6. FOSSA vs Black Duck OSS compliance offerings


Top Articles
Latest Posts
Article information

Author: Horacio Brakus JD

Last Updated: 10/23/2023

Views: 5431

Rating: 4 / 5 (71 voted)

Reviews: 86% of readers found this page helpful

Author information

Name: Horacio Brakus JD

Birthday: 1999-08-21

Address: Apt. 524 43384 Minnie Prairie, South Edda, MA 62804

Phone: +5931039998219

Job: Sales Strategist

Hobby: Sculling, Kitesurfing, Orienteering, Painting, Computer programming, Creative writing, Scuba diving

Introduction: My name is Horacio Brakus JD, I am a lively, splendid, jolly, vivacious, vast, cheerful, agreeable person who loves writing and wants to share my knowledge and understanding with you.