What Coders Should Know About Copyright Licensing

Developers may think that their GitHub repos don’t need a license. But unlicensed code is actually more copyright-restricted than if it were properly labeled “open source.” And if repos contain protected code or embedded licenses, there could be legal trouble down the line.

What Coders Should Know About Copyright Licensing

On Monday GitHub launched a site called for anyone whose legal knowledge about software licensing is a little rusty. Or, you know, nonexistent.


It’s meant to be a resource for coders when they start a new repository and go to select a license, partly so users can understand their options and classify their work appropriately. But partly because so many GitHub users aren’t choosing a license for their work at all.

The overall culture on GitHub is one of openness. Post what you want to post, fork what you want to fork, and find new opportunities for collaboration. It sounds downright utopian. But reality always creeps in somewhere, and the fact that 77% of GitHub projects carry no license is not necessarily a move toward sharing and the free flow of ideas. As GitHub’s new site explains, if a project doesn’t have a license it may actually have more legal protection under federal copyright laws than code that has been designated with specific terms of use.

You’re under no obligation to choose a license and it’s your right not to include one with your code or project . . . But generally speaking, the absence of a license means that default copyright laws apply. This means that you retain all rights to your source code and that nobody else may reproduce, distribute, or create derivative works from your work. This might not be what you intend.

As part of an investigation into licensing, Black Duck Software surveyed one million projects across a number of code sharing sites, and found that overall 40% of them are unlicensed. On average this shows better licensing implementation than on GitHub, but the bottom line is that if you want your code to be open for use you need to choose a license that frees it up in the right ways. And this could save a lot of people a lot of money.

On GitHub the three main types of software licenses are:

The MIT License, which is meant to be extremely straightforward and open. It permits users to do anything with a given project as long as they credit the developer and don’t hold him or her liable for the project’s use.

The Apache License, which is similar to the MIT License, but also explicitly grants patent rights to users.


The GPL License, which is older, more limiting, and less popular than the other two. It is a copyleft license that requires users to track their changes if they modify and then distribute a project. Different versions of this license also restrict the use of modified code in various classes of hardware.

But other options include:

Affero GPL
Artistic License 2.0
BSD 3-Clause License
BSD 2-Clause license
Eclipse Public License v1.0
GPL v3
LGPL v2.1
Mozilla Public License Version 2.0
Public Domain (Unlicense)

Unlicensed code is concerning in itself, but companies looking to utilize open source software may be shying away because of a related problem: embedded licenses. An open source project may build on code from a number of sources. And this code may or may not have been licensed. Unless a developer investigates and declares the license restrictions of all her source code, a company looking to save money on open source software is opening itself to legal issues by using the project. As a blanket protection, many companies won’t use unlicensed software at all to try and avoid accidental rights infringements. Black Duck found that 42% of the million projects they surveyed had embedded licenses that were different than or conflicted with the projects’ own license status. Resolving these issues could lead to major industry savings, Black Duck estimates $59 billion. is motivating entrepreneurs and developers to be more vocal about licensing concerns. On Wednesday, developer John Mertic tweeted, “Yes @github users, you need to pick a license for your code. Especially if you expect others to use it seriously…” And tech writer Marco Tabini added yesterday that, “Instead of a license chooser, maybe GitHub should put out a license conflict detector.” Honestly, it would be a smart next step.

About the author

Lily Hay Newman is interested in technology and eating lunch so she has hung around at Co.Labs, Gizmodo, IEEE Spectrum, Popular Mechanics, Discover and MetroNY. She writes about web apps and materials science more than sandwiches, but you never know when the tide will turn