Open source license usage on GitHub.com

Open source simply isn’t open source without a proper license. Unless you’ve explicitly told others that they can modify and reuse your work, you’ve only showed others your code; you haven’t shared it. Here at GitHub, we’re big fans of open source, so we set out to better understand how our users approached licensing their code by looking at license usage across public, non-forked repositories, in hopes of encouraging more users to share their work with others.

If you look at this graph of licensed repositories over time, you’ll notice that the percentage of licensed repositories has been decreasing, hovering around 20% throughout GitHub’s history (about 30% if you include forked repositories). The sharp spike in mid-2013 represents our first pass at making open source licensing on GitHub easier by launching choosealicense.com to demystify license choices, and introducing the license picker to encourage users to license their projects.

Breakdown of license usage

We also wanted to look at the relative breakdown of the most popular open source licenses. You can see their popularity expressed below as a percentage of licensed projects on GitHub.com:

Unsurprisingly, MIT, Apache, and GPL are the clear front runners, with some 15% of licensed projects opting for a non-standard license or standard license not among those listed on choosealicense.com.

Last, we looked at how license usage has changed over time. Again, you see a swift uptick of the three featured license (MIT, Apache, GPL) in mid-2013, with the relative percentages remaining otherwise steady over the past six years.

Developers use GitHub because they want to share their code with the world, and the data suggests that when the tools we use make it a little bit easier, developers do just that. When presented with the option, they choose to license, and they license very permissively.

Under the hood

To detect what license, if any, a project is licensed under, we used an open source Ruby gem called Licensee to compare the repository’s LICENSE file to a short list of known licenses. However, it’s important to note that this approach doesn’t count a project as licensed if the README indicates a specific license or if individual project files contain a named license in the code comments.

The licenses API

We want to make it easier for open source developers to license their code, and for open source consumers to verify that they are using open source projects under an appropriate license. To that end, we’re launching the Licenses API preview to retrieve information about a particular project’s license file, as well as metadata about open source licenses in general.

When you pass the appropriate preview media type, API requests for a particular repository will now include the project’s license, if any, represented by its SPDX-compliant and human-readable names:

{
  ...
  "license": {
    "key": "mit",
    "name": "MIT License",
    "url":  "https://api.github.com/licenses/mit"
  }
  ...
}

{
  ...
  "license": {
    "key": "mit",
    "name": "MIT License",
    "url":  "https://api.github.com/licenses/mit"
  }
  ...
}

The individual license endpoints (e.g., /licenses/mit) return additional information about the license, including what you can and can’t do with the software, and the full license body. For more information, see the developer documentation.

Share your code

If you haven’t already, we encourage you to add a LICENSE file to your project. To make things a bit easier, if you begin to create a file named LICENSE via the web interface, we’ll even provide you with a list of common license templates to choose from.

This is just the start. Look forward to a more in depth analysis over the coming weeks as to how license usage affects project success, as we delve deeper into the numbers. Of course, in the mean time, we encourage you to explore license usage on GitHub using the Licenses API.

Happy open source licensing!