America’s history of protecting intellectual property is older than America itself, beginning with Parliament’s passage of the Licensing of the Press Act 1662. By the late 18th century, issues around intellectual property were seen as so crucial to the underlying principles on-which America was being founded, that the protection of intellectual property was baked right into Article I of United States Constitution which gives Congress the power:
“[t]o promote the progress of science and useful arts, by securing for limited times to authors and inventors the exclusive right to their respective writings and discoveries.”
More than two and a quarter centuries later, while the world may be a very different place than it was in 1789, the core foundation of how we protect “written” work remains the same.
There are two distinct worlds of intellectual property that most developers will encounter: Copyright and Licensing. Though related, they are not synonymous. A copyright comes with a set of ownerships rights the creator of a work, sometimes referred to a a bundle of rights. Included in this bundle, is the right to control the use of a work and to permit use by others. This latter-most right is the right of the creator to license others to have some sort of access or use to a work. To think of it another way, if a copyright is the deed to a house, a license is the lease allowing someone else to live there. The landlord still owns the home, but the tenant has the right to use it.
When creating a new repository in GitHub, for example, you are presented with a dozen different choices for adding a public license to your code, and one choice to forgo a license all together. These do not represent all licensing options, but using GitHub’s built-in tools to automatically generate licensing documentation within your new repository is hassle-free and easy to do. So let’s take a look at some of your options; including those incorporated directly into GitHub.
While it may be tempting to forgo a license altogether, one should be aware of the full implications. Without any license, your code cannot be used, copied, changed, or distributed by anyone other than its creator. So long as that creator is you, you’re in good shape. But as soon as you involve other contributors, you are no long the creator, and access to your own work begins to become restricted. If your intention is a completely closed-off piece of software, this may be the way to go. However, I suggest that when going this route one should include an express restriction indicating as much.
Also, if posting your code to GitHub, be aware that you are already agreeing to give GitHub a license “to do things like host Your Content, publish it, and share it.” (see GitHub TOS, sections D4 through D7 https://help.github.com/articles/github-terms-of-service/#d-user-generated-content )
tl;dr: Do nothing at all.
GNU General Public License v3.0
GNU General Public License (GPL), was the first widely used copyleft license. Copyleft is term used to describe the inverse of copyright. Where a copyright creates a set restrictive limitations for end-users, a copyleft proscribes affirmative permissions to an end user to modify and distribute a work. In other words, a copyleft is a kind of license.
The GPL affords that a user may modify, copy, and redistribute a work, including commercial redistribution. This is a key difference between GPL and other public licensing schemes, and it is born from the notion that freely distributed software should place few restrictions on the end user, even the restriction against making money off of it. However, GPL requires that a subsequent distributor may not place “further restrictions on the rights granted by the GPL”, such as non-disclosure agreements.
In order to take advantage of the above, an end-user must make the source code of the original work freely available, with a record of any changes made to the original work. This include providing adequate attribution to the original author.
tl;dr: Do whatever you want, as long as you provide the original, document changes to the original, and provide attribution.
The MIT License is short, to the point, and highly permissive. This license provides that an end user may do almost anything they wish, as long as the original “copyright notice and this permission notice [are] included in all copies or substantial portions of the Software,” and like the GPL, the MIT license permits commercial-use/sale. Unlike GPL, it even allows the creation and distribution of completely closed-source modifications
Notably, Ruby on Rails, Node.js, Babel, and jQuery are all distributed with the MIT License.
tl;dr: Do whatever you want, as long as you provide the original copyright notice.
Do What The F*ck You Want To Public License
All the way on the other end of the spectrum from issuing no license at all, is the use of WTFPL.
This license — which is itself copyright protected — states in no uncertain terms that “you” (i.e., the end user) can “just DO WHAT THE [heck] YOU WANT TO.” Ironically the text of WTFPL’s own licensing is longer than the WTFPL itself, though it too is permissive in allowing “[e]veryone . . . to copy and distribute verbatim or modified copies of this license document, and changing it is allowed as long as the name is changed.”
In essence, using WTFPL is the same as placing a work directly into the public domain. It is important to recognize that when putting something into the public domain requires an affirmative action on the part of the original creator, and this is one way of accomplishing that.
tl;dr: Do whatever you want.
Using an Open Source License in GitHub
So you have decided that you want to include a license with your software and you are keeping it in a GitHub repository. No what?
If you have already created a repository and now you want to add a license to your existing code, it is a good idea to put that license in a spot others will know to look for it. Typically that means placing it into
LICENSE.md right in the root directory of your project, though putting your license in your
README.md is also a good option. All you need to do is dig up the licensing language (Choose A License is a great place to start your hunt), and drop it in
You can also use GitHub’s built-in tool, by creating a new
LICENSE.md file directly in your repository, and clicking on the “Choose a license template” on the left hand side.
And now you know how to make your own license.