If you've ever created a repository on GitHub, you will have seen this repository creation dialog.
Right at the end there it says "Choose your license". That sounds important, it's right there in the repository creation dialog after all. But what is a license and why do you need to choose one?
Licenses are a fundamental part of developing Open Source Software (OSS). Without a license attached, your software project might as well be not be published at all, since without a license no one can actually utilize it - more on why in a bit.
We've all heard the term Open Source, and many of us will also have come across the term Open Source License, but what these things actually mean, how they come together and why you as an OSS dev should even care is still a mystery to many. This post hopes to help clarify this subject a bit more.
Before we dive into the gritty details of OSS licensing however, a word for my own sake: I am not a lawyer but merely an Open Source Software developer with almost two decades of experience. All of that which I'll explain here is my own understanding and it does not constitute legal advice in any shape or form. I'll also simplify some things and not go into the distinction between Free and Open Source Software or the philosophy behind the Free Software Movement. The goal of this post is to give a short intro to Open Source software licenses and help clear up some general common misconceptions - nothing more, nothing less. Phew! With that disclaimer out of the way, let's dive right in.
What is Open Source?
Many people think that Open Source simply means availability of the source code of a project, but that does only tell part of the whole story.
The Open Source Initiative (OSI) provides a commonly accepted definition of what constitutes Open Source. To summarize that, in order to be constituted Open Source,
a work has to allow free redistribution,
the source code needs to be made available,
it must be possible to create further works based on it,
there must be no limitations of who may use the work or for what purpose (so something like "no commercial use" or "no military use" won't fly with Open Source),
the work must not require an additional license on top of the one it comes with,
and finally, the license must not depend on a specific distribution format, technology or presence of other works.
So, you see, it goes way beyond "the source code is available", in fact, a whole lot more requirements are stated that must be fulfilled in order for a work to really be considered Open Source.
Note however that it doesn't say "must be free of charge" anywhere there. A common misconception is that OSS must not cost anything, or that you are not allowed to earn money making it. That is wrong, and the term Free Software often encountered alongside Open Source usually gets further specified as "free as in speech, not as in beer" to make this distinction clear. Commercial services built around OSS are fine, and so is selling OSS, as long as the licenses are adhered to and the sources are made available alongside.
What is a license and why would I need one?
Any work that you create by default makes you the copyright holder of it. That means only you are allowed to distribute whatever you created. If you want to transfer this right to other people as well, you can do that via a so-called license. Consider it a set of rules that define how others may use, distribute, modify and otherwise interact with the work you created, and under what terms.
Let's say you have written a software tool and you want to host its source code repository on GitHub. Without a license attached, people will be able to look at it, and fork it (because both of that is allowed via GitHub's own Terms of Service), but they may not use it in their own projects, modify it or otherwise do anything else with it. You alone have the exclusive copyright.
By adding a license to it, however, you can extend what can be done with your code, and - if you want - with certain obligations attached. For example, you could add a license that states that people may modify or build on your tool as long as they share their resulting derivative with the source code as well. Or you could add a license that states that people may freely use, redistribute and modify your code, but only if they keep your name on it. And - probably most importantly - you could (and should) add a license that only allows to utilize your code if in turn whoever uses it acknowledges that no guarantee of its correctness or functionality comes attached with it, that there is no warranty and no liability, meaning you can't be sued for damages if something in your code breaks and causes someone grief.
So, long story short, a license allows you to define additional rights and obligations regarding your work that go beyond the copyright you own, and it can protect yourself.
What options are there?
Thankfully you do not have to write your own license (and frankly, neither should you, there be dragons). There are a multitude of existing licenses for you to choose from already, and I'm going to introduce you to some of the most common ones.
Please note that I'm going to focus on Open Source software licenses here, so licenses that fulfill the Open Source Definition by the OSI, as those are also what I'd recommend to restrict yourself to when choosing a license for a new OSS project. However, I will also briefly outline Creative Commons licenses, as they are often encountered on hardware projects, and Public Domain, as it is often encountered in the wild.
"Copyleft" licenses: GPL, AGPL, LGPL
Remember when I said that you could require anyone who modifies your work to share its source as well? Having to adhere to similar terms is commonly referred to as being viral and the most popular member of the family of viral Open Source licenses are the so called copyleft (in contrast to "copyright") licenses GPL, AGPL and LGPL.
The GPL, or GNU Public License, is viral (so derivatives must be distributed under compatible terms), rules out any claims of warranty (so you cannot be sued), and states that any kind of attribution ("written by J. Random Hacker") must be kept in place. The license and its siblings are OSI approved and thus commercial use is no problem.
The AGPL, or Affero GNU Public License, expands on the virality clause such that even if derivatives are only accessed through a network connection, their sources must be made available under compatible terms.
The LGPL, or Lesser GNU Public License, on the other hand, dials back the virality a bit, stating that derivatives only linking against the work don't have to share under the same license terms. What considers linking has been a subject of quite some debate, but in general the idea here is that as long as your work is only used like a library and not directly build upon, the virality clause doesn't trigger.
Permissive licenses: MIT, BSD, Apache, ...
If the copyleft philosophy isn't your thing for any reason, there is a family of quite permissive Open Source Licenses that are not viral but still offer attribution and protection against liability.
The MIT, BSD and Apache licenses are all pretty similar. All of them require that attribution must be kept in place, warranty & liability are strictly ruled out and - being OSI approved - commercial use is no problem at all. The differences between the members of this family lie in permission of patent claims and trademark use. The devil here is truly in the details, so pay close attention when choosing between the various permissive licenses. For a quick comparison I suggest to take a look at the licenses on tldrlegal.com.
Creative Commons
If you are into hardware development, you might have come across the family of Creative Commons licenses. Creative Commons is a bit like a choose-your-own-adventure of licensing - you have a base license which rules out warranty, and various modules that you can attach to it as well if you want:
BY: requires the author to be stated
SA: any derivatives must be "shared alike", so under the same license terms - this is the virality module
NC: commercial use is forbidden - if this module is included, the license is no longer Open Source under the OSI definition
ND: derivatives are forbidden - if this module is included, the license is also no longer Open Source under the OSI definition
As you can see, Creative Commons can mean trouble when it comes to Open Source compatibility. As long as you stay away from the "NC" and "ND" modules, your work should still be Open Source by definition, but since the license is not itself OSI approved, you might run into compatibility problems with anything you depend on, or make your work difficult to build upon.
Public Domain, CC0, Unlicense, ...
It might happen that you also come across software that has been released into the Public Domain, meaning that all copyright claims have been forfeit. This concept seems to be quite attractive to people who really just want to set their code free and don't care at all what happens to it.
It should be noted that even though this might seem a quite charming concept at first, there is a huge downside to it: no warranty waiver. You really do not want to make yourself vulnerable to legal threats simply for having written some code that caused someone issues due to a bug, so if you want to go this route my recommendation is to at the very least consider something like the Unlicense because it at least contains the warranty waiver and thus protects you from liability.
So how do I license my Open Source project?
Depending on whether your project is stand-alone or building on the work of others, there are different things to consider.
If you are creating a standalone project, you can freely decide on a license. Take a look at other projects in your development community, or similar projects, and what they have chosen. Make sure you understand the license you plan to use, and that you are comfortable with it. If the thought that someone might take your code, build something new on it and not share the source of that sickens you, a permissive license might not be the best choice and a viral copyleft license like GPL might be more your cup of tea. If on the other hand you just want people to be able to whatever with your code, as long as your name stays in it and you won't get sued over it, you probably want to take a look at a permissive license like MIT instead. Take a look at choosealicense.com if you need a helping hand.
If you are building on other works however, things get a bit more complicated. You need to check and understand their licenses, and also understand that you will be restricted to something compatible in your own choice. If you are building on something licensed under GPL, keep the virality in mind. If you are building on something under a Creative Commons license, be very careful, you might not even be allowed to build on it, depending on the flavor. For the GPL specifically, there is a helpful compatibility list you may want to consult.
Regardless of whether your work is standalone or you are building on the work of others, I cannot stress enough the importance to understand and be comfortable with the license you choose for your code. If at some point you realize you regret your decision, you will find that changing the license of future versions of your work has its challenges (and is simply impossible for already released versions). Anyone who contributes to your project does so under the license you have stated. They give you access to their own copyrighted works under the terms of your project's license - even if it is just fixing a typo. You cannot change the license of the whole codebase if you are not the sole copyright holder, you need to seek permission from everyone who contributed. Depending on the history and scale of your project, that can be difficult to outright impossible. Hence the strong recommendation to really understand the license and make sure you are comfortable with it.
Once you have chosen your desired license, copy it into a LICENSE.txt file in your project root (GitHub will usually also detect this and show a little license summary on your repo - neat!). Also, make a note of it in your README file. You might also want to put a license header in your project's source files. In short, make it easy for someone with a copy of your code to figure out the license.
You've done all of that? Congratulations, you have licensed your project!
tl;dr
Unless you put a license on your source code, your exclusive copyright applies and no one can really utilize your code. There is a huge number of available licenses to choose from, and before you decide on one you should make sure you understand it, are comfortable with it and also don't run into any kinds of incompatibilities with things you depend on. Best stick to established, well-known and proven licenses instead of the more obscure ones, and never try to roll your own.
Happy coding!
Further reading
tl;dr Legal - Software Licenses in Plain English: Short overview over pretty much all licenses in layman's terms. Also great to compare licenses with each other.
Choose an open source license: Small decision helper
OSS Watch License Differentiator: Filter OSS licenses by certain criteria to help you finding possible candidates
Various Licenses and Comments about Them: GPL compatibility list
What You Need to Know About Open Source Licenses (PyCon 2016): Great talk on licenses from PyCon 2016