Felix Crux

What You Need To Know About Free & Open Source Software Licensing

This talk was presented at PyCon 2016 in Portland, Oregon on May 31st 2016.
The recording was graciously provided by the conference organizers. An edited
textual transcript and a selected bibliography are available below.

Talk Description

Free/Open Source software is everywhere, and software licensing is what enables
it. Even though many of us use or develop such software, we often skim over the
legalese and hope for the best. But these licenses are vitally important tools
in ensuring that others can (or can’t!) benefit from our work in the ways we
intended, and the nature of the copyright system is such that ignoring it or
making no choice of license means nobody can use your code at all. This talk
will cover just what you need to know about intellectual property law, how it
relates to software, and why licenses are so important.

We’ll examine a number of popular licenses, and in what ways they differ — and
how you can use them to achieve different goals. We’ll discuss the difference
between permissive and copyleft licenses, and how the copyleft/Free Software
movement is using the copyright system against itself to promote their social
aims.

Promoting any specific license or type of license is explicitly not an objective
of the talk, but popular choices within each category will be highlighted.

You should come away from this talk with a better understanding of intellectual
property law; why it’s important to care about software licenses; what different
licenses require from you; how copyleft-style licenses differ from permissive
ones; and how to go about choosing a license for your own work.

Plus, you’ll hear about the corporate lawyers who had to ask for a special
software license allowing them to do evil!

Video

Slides & Transcript

This is an edited and condensed version of the talk based on my speaker
notes. It differs only in minor and unimportant ways from the video above.

Hi. My name is Felix, and this talk is “What You Need To Know About
Free & Open Source Software Licensing”.

I wanted to talk about this topic because even though Free and Open
Source software are ubiquitous now, the legalese that makes it all work
can be kind of confusing, boring, and even intimidating; and sometimes
it might seem a bit like meaningless magic incantations that you just
have to chant in the correct way and hope that everything works out.

But, really, it turns out that the core ideas that underpin the
system are pretty easy to understand, and if you take the time to do so
— like by coming to this talk — it can not only help you see why things
are the way they are, but it can give you new ways to influence and
control how your software is used, and help you make sure it achieves
the goals you set for it.

So that’s the objective for this talk:

To learn the basics of how intellectual property law (in particular
copyright) works;

To understand how licenses are built on top of those principles;

And to enable you to work effectively with free and open source
software, both as a consumer of someone else’s work and as a creator.

This is an overview of what we’re going to cover. It’s not like you
need to memorize it, it’s just to anchor you as we go through and let
you know what to expect coming up. Broadly, we’re going to cover some
background information, we’re going to look at some specific licenses,
and we’re going talk about some of the related practical concerns about
implementing and using them.

But first a big big important caveat up front! I am not a lawyer!

I know, right, that’s exactly what you want to hear from someone
giving this talk.

But yes, I am not a lawyer. I am not an expert in your countries’
local legal systems. I am not speaking on behalf of anyone or conveying
legal advice. This is general non-specialist background information.
This talk is going to cover about 80% of the material that around 80% of
lawyers in the home countries of maybe 80% of you would probably give in
response to, let's say, 80% of your questions.

So we’re talking at a high level about what can be a pretty deep
subject. But, fortunately, that actually covers almost everything that
you really need to know to operate on a day-to-day basis. And if you
need to know more, because you have some specific legal question, you
should take that to an actual lawyer. You’re not gonna get those answers
from any talk or from the Internet or whatever.

I’m glad that disclaimer is out of the way. Let’s get started.

What is intellectual property? It’s kind of strange, because the term
intellectual property covers a whole grab-bag of kind of unrelated
things that just have one attribute in common: the law gives the creator
of an intangible “creation of the mind” certain rights that it withholds
from everyone else, even though there isn’t necessarily a physical
thing that the creator holds and controls and keeps hidden from
everyone else.

For this talk, the kinds of intellectual property we’ll cover are
copyrights, patents, and trademarks.

Copyright is what this talk is mostly about. The idea is that to
encourage people to make expressive — creative — works, we have laws
that give them exclusive rights to copy, distribute, and build on and
modify their work, even though there may be no technical restriction
that would otherwise keep anyone else from doing so.

You just create something, and you automatically have the right to
control how it is used, for a limited time. Actually I say limited time,
and that’s the theory, but in practice no copyrights have expired in the
USA since the 70s. Every time we get close to the new deadline, the law
gets changed to extend the duration.

Moral rights are a very closely related concept to copyright. In some
countries they’re considered just a subset of copyright, and in some
places they’re a bit different, and in some places they don’t exist at
all. Moral rights are sort of the non-commercial part of copyright. It’s
not so much about making money off your creation, it’s about things like
the right to be identified as the author, or the right to the integrity
of the work. Integrity in this context means keeping people from
changing or presenting your work in ways you don’t like, like putting on
a display defacing your art, even if they own it.

Moral rights, unlike basic copyright, might not always be
automatically granted in all countries. In the UK for example, you have
to “assert” them, which basically just means you have to say that you
want to have them.

Moral rights also behave very differently. They might not be
time-limited, they might last forever. They might even pass down to your
heirs. So your grandkids maybe will have a say in what people are
allowed to do with your software. And, in some countries, you cannot
waive, reject, give away or sell your moral rights. It’s just not
allowed, like how you’re not allowed to agree to be murdered. We’ll talk
more about the implications of that later on, and why it’s important.
And yes, the fact that in some countries you cannot get rid of your
moral rights does turn out to be important.

The next big kind of intellectual property I want to talk about are
patents. Where copyright was about creative works, patents are about
protecting functional inventions. The deal is that if you share the
details of how your new gizmo works, society in exchange gives you this
exclusive monopoly on the invention for a little while.

For the purposes of this talk, which is about licensing, we’re mainly
concerned with patents as they relate to sneaky patent trolls and some
of the tricks they can try to pull. For example, the owner of a patent
might try to get their patented software technique adopted as a
standard, so that anyone who implements that standard has to pay them
money for a license or risk getting sued. Or they might even contribute
the code that implements their technique, and then later, either because
they planned it, or just because they changed their minds, they might
come back and try to sue you for using it. Some licenses have
protections against this kind of thing, and when we talk about those I
will call it out. It’s a good thing to have.

As a side note, there is also something called a “design patent”,
which covers the way a product looks. That is not the same
thing as a regular patent. It doesn’t work the same way. It’s not meant
to cover the same kinds of things. But you’ll sometimes see people
getting confused and angry and saying stuff like “oh no so and so is
trying to patent the rectangle or the colour blue”. If you hear stuff
like that, don’t get worked up; just send them a link to the Wikipedia
page on design patents. Which are not the same thing
as regular patents.

And really quickly, last up, are trademarks.

The idea behind a trademark is to protect consumers from fakes that
might be trying to take advantage of the good reputation of a particular
brand by imitating or copying their name or logo or identifiers like
that. This doesn’t usually come up in software licenses directly, but it
can definitely be an issue for software projects, especially user-facing
ones.

You might remember that in 2013, the PSF had to defend the name
“Python”, and up until very recently earlier this year, the Debian
GNU/Linux distribution shipped Firefox under the name Iceweasel because
of disagreements about trademarks, even though the licensing of the code
was fine. It was a friendly disagreement, though, and both sides had
very good points, and they’ve now sorted it all out, which is great.

But again, most licenses don’t have anything to say about trademarks,
but you should know what they are because they might be an issue. If you
expect end users to be able to recognize the name and brand of your
project, think about what rights or requirements you might want to give
to people who fork your code. Can they associate themselves with your
brand?

In general, just try not to rip off anyone’s name or logo.

There are other kinds of intellectual property as well, but they’re
not really relevant to software licensing, so we’re just going to ignore
them.

So why do we need licenses at all? Well, intellectual property law is
a reality, whether we like it or not. And since copyright is both so
powerful and automatic, we have to live with it and operate within its
boundaries. But it’s not just a bunch of restrictions: We can also work
within the confines of these laws to achieve the outcomes we want for
our software. We can use the law in ways that are beneficial and that
actually help spread our work.

A license is a set of permissions you give to someone. When you
create something like a piece of software, you alone have rights to it
and you have control over how to share those rights with others.
Licenses are what we use to give people rights they wouldn’t ordinarily
have. Like the right to use the software, to modify it, or to copy and
share it.

Licenses can also be used to set conditions or create obligations.
The most obvious example is proprietary software, which generally has a
license that only gives you the right to use it, but prohibits you not
just from copying and sharing it but often also from reverse engineering
it, or in some cases, even from things like benchmarking the performance
of the software and sharing that data, like some proprietary database
licenses do.

Those are some pretty odious parts of some proprietary licenses, but
free and open source license agreements usually have obligations and
requirements as well — they’re just of a different nature. We’ll look at
some of those in a moment.

Usually, if you don’t comply with the obligations that a license
creates, you lose all the rights it would otherwise have given you, and
there may be other penalties as well.

The key idea is that without a license nobody has any rights to the
software, and the license is the thing whereby the creator grants those
rights.

And no, just publishing the source code, like by throwing it up on
GitHub without a license does not give anyone any rights. That’s not
code you can use. It’s just code that you happen to be able to look at,
just like you can look at my laptop sitting up here right now, but you
don’t have the right to take it home after this talk. Without a license,
the code is not for you.

All right; enough background! Let’s look at some licenses.

The first category I want to talk about are known as “permissive”
licenses. These are the simplest kind. They almost just say “you can do
pretty much whatever” with this software. You can build proprietary
stuff on top of the code. You usually just have to provide attribution,
meaning you have to give credit to the person who wrote it, and there’s
often also a warranty disclaimer that says the author isn’t responsible
for what you do or how you mess up using the code. That’s a good idea to
have, by the way. You should not use a license without that.

You’d generally pick a permissive license like this when your goal is
just for the code to be shared and used as widely as possible. You’re
trying to make life as easy as possible for developers, by making
everything available to them for whatever use they want, even if they
don’t want to reciprocate by sharing their improvements.

This is a very pragmatic approach. It’s very business-friendly, and
having companies who care about improving your code and can pay people
to work on it can be very powerful. Just be sure that you would really
be OK with seeing someone make a lot of money off of your work and give
you nothing in return. Because that can and does happen, and they’re
well within their rights.

People from the communities around these licenses usually talk about
“open source”, not about “free software”, and it’s very non-political,
non-activist. It’s about the practicality of the process of developing
in the open. It’s about working more efficiently, not about overthrowing
copyright.

There are a number of licenses like this. Here are a bunch. They
differ in minor ways, and some are more popular in certain communities.
The JavaScript world seems to be fond of the X11 and Expat licenses,
usually lumped together as “the MIT license”; also very popular with
Python devs. The BSD folks, like OpenBSD and FreeBSD, they
unsurprisingly like the BSD or ISC kinds.

Honestly, all of these are pretty similar. If you want to go with
this approach, read them and pick one you like the look of, or one your
community uses a lot.

Just one caution on that suggestion, though. Don’t go too overboard
with the idea of just picking what your community uses. Right now the
cultural fashion is sort of to go very permissive, to maybe not even
think about the question at all and just throw the MIT license on
everything. But remember that licenses are tools, and they serve
different purposes. These are all good licenses if they match what you
want them to do, the way that any brand of screwdriver is gonna be fine
to drive a screw. But if you actually need to hammer a nail, you
shouldn’t grab a screwdriver just because it happens to be nearby. So
it’s worth sitting down and really thinking about what you want to
achieve with your project, and also what you don’t want people
to do with it. If you decide you want a permissive license, that’s
great. But you should decide that, you should think
about it and reach that conclusion on your own, rather than ignoring the
question and picking whatever happens to be popular right now. End of
sidenote.

There is one popular permissive license that’s a bit different,
though, and that’s the Apache 2.0 license, named after the Apache
Software Foundation. It’s a little more verbose than the ones we just
looked at, and it has some kind of slightly annoying requirements about
putting notices in files you’ve changed, but it also has a really
important clause that the others don’t: and that’s a “Grant of Patent
License”.

Going back to what we talked about earlier, about patents, this is
the kind of clause I said is great to have and that I would call out.
This is a whole wall of text, but with a bit of editing we can snip it
down to just the key ideas. Let’s do that.

What this clause does is it makes it so that anyone who contributes
to the code is also granting everyone who uses the code a license to use
any of their patents that would otherwise be infringed upon by the code
that was contributed. This is basically a patent-troll killing
anti-patent-ambush clause.

It actually goes even further and says that if you do sue anyone over
patents related to the software, then you actually lose those patent
licenses that everyone else granted you. It’s almost like a
mutually-assured destruction clause, where if you start a patent war,
you’re opening yourself up to the same kind of retaliation.

Now, do you need this for your software? It can never hurt, it’s
never a bad thing. But sometimes maybe you want to use a different
license because it’s popular in your community, or because you don’t
want to deal with the Apache requirements about notices of modification,
or whatever, so you’ll just have to think about whether your particular
project is particularly susceptible to patent issues.

Things like video codecs, for example, are a minefield, but honestly
the whole software patent field is so full of noise that it’s hard to
tell what might or might not be dangerous. If you’re working with
anything that’s high risk, I strongly recommend you use a license with a
patent clause, and among the permissive licenses, the Apache 2.0 one is
the best one in that regard.

The second major family of licenses I want to talk about are the
Copyleft ones. Historically, this is the category associated with the
Free Software movement, which is the activist and political part of the
community. It’s also, really, the origin of most of this movement. Some
of the revolutionary zeal has fallen away, and maybe people are focusing
more on the practical benefits of developing in the open, but it’s worth
understanding where these licenses came from and what their creators
intended.

The motivation behind a copyleft license is to promote
user freedom. It’s not to make life easy for developers, it’s
not to let you bootstrap your startup faster, it’s not to invite
collaboration from industry, although all of those can happen… but
really the goal is to guarantee that users have the so-called “four
freedoms”: the freedom to use the program as you wish, for any purpose;
the freedom to study it and change it; the freedom to share the program;
and the freedom to redistribute your changes as well.

To guarantee these freedoms, the central idea that makes a license a
copyleft one is that it requires you to share the changes you make under
the same terms that others shared them with you. This ensures that even
if many people layer changes on top of the code you’ve released under a
copyleft license, the end users of that product will still have those
freedoms you wanted to give them. Copyleft licenses don’t prevent you
from making commercial software, but they do prevent you from
making proprietary software.

Unlike permissively licensed code, which people can take and
incorporate into closed-source software, copylefted code spreads
copyleft to code that mixes with it. This also means that you can
incorporate permissively licensed code into a copyleft project, but not
the other way around. This property is sometimes described as “viral”,
people say copyleft infects code and spreads in that way. I think they
mean for that to sound scary and dangerous, but an organically-growing
viral spread of free software is exactly the point of these
licenses.

You don’t have to use them, you don’t even have to agree with them,
but you do have to respect them. And if your goals with your project are
aligned with the Free Software movement, then these are probably the
licenses you want.

The first, and most well-known license in this category is the GPL:
the GNU General Public License. Everything I said a moment ago about
about what copyleft is, is really what the GPL is, because the GPL
created and defines this whole category.

One key thing about it is that the “viral” clauses that require you
to share your code only kick in when you redistribute the software in
some way. If you just make a local copy and change it for your own use
and don’t give it to anyone, you’re not required to share those
changes.

The GPL disallows you from adding other restrictions to the licensing
of the software (that’s how it guarantees the code stays free). That
obviously means you can’t combine GPL code with code that’s under a
license that’s more restrictive than the GPL, because you’d either have
to violate the GPL by imposing those additional restrictions, or you’d
have to violate the other license by not imposing them. This is mainly
an issue with the GPL version 2, which notably is not compatible with
the Apache license, partly because of that excellent patent clause that
it contains, which, although it’s a good extra restriction, is
an extra restriction, which the GPL forbids. Version 3 of the GPL fixes
this, by also including that clause. So GPL version 3 is both more
compatible, and includes patent protections, like the Apache 2.0
license. If you want to use the GPL, you should use version 3, and even
a lot of things that were originally licensed under version 2 are
actually licensed under “version 2, or any later version”, which is the
standard, recommended, way to use the GPL.

There’s a closely related license called the LGPL: the
Lesser GNU General Public License. It differs from the regular
GPL in that the “virality” aspect only applies to the specific code its
attached to, not to anything that’s just linked to it to build a larger
software application. So you can have a LGPL library as part of even a
proprietary application, and you only have to share your changes to the
LGPL part.

It also comes with some requirements that are intended to make sure
that users can always take advantage of the LGPL nature of that linked
library code. Essentially users have to be able to replace the version
you’ve shipped with whatever version they want, which might be a newer
version from upstream or their own custom one or whatever. The idea is
that if you ship a non-free application built on top of an LGPL library,
but then you decide to not support it or to change how it works or
whatever, users have the freedom to control what version of that library
they use on their system, so they can keep it up to date even if you’ve
stopped supporting it, or they can change behaviour that they want to be
different or that they disagree with you about.

The third big license in this category (and to be clear, there are
others, but they tend to be more specific to particular communities;
these are the big ones), the third one I want to talk about is the AGPL,
the Affero General Public License. The newest version is actually
related to the GNU GPL and is more properly called the GNU Affero
General Public License, so all of these form one big happy family.

This particular license was created to address what some people might
perceive as a loophole in the regular GPL. The GPL requires that you
redistribute your source to anyone you distribute the application to.
But there’s a big category of software that never actually gets
distributed to its users: that’s network applications. Servers that
users only interact with remotely, through a client application, which
includes web browsers. These are obviously big complex applications that
end users are using, and which they rely on just as much as any
desktop application, but technically the software was never distributed
to them; it’s just running on the service provider’s servers somewhere.
So the GPL’s sharing requirements don’t kick in, even if the code
running on that server is GPL’d and meant to be shared.

The AGPL fixes that. It’s very similar to the GPL, but its sharing
requirement kicks in even for users that just access the application
over the network. That definitely scares some people, but again,
remember that different licenses are used to achieve different goals,
according to what the creator wants for their software. These copyleft
free software licenses are deliberately very aggressive vehicles for
ensuring the independence of users from the developers and
service providers they would otherwise rely on.

The AGPL, LGPL and GPL 3 are compatible with one another; you can
safely build an application that combines code under both licenses, but
that’s not the case for older versions of those licenses.

Now, maybe you’re looking at these choices, and your head is
spinning, and you’re thinking “this is a mess, I don’t know what to do”
or maybe even raging “I hate copyright law” and you conclude that you
don’t care about licensing, and you want to just throw the software out
there and let anybody do whatever they want, no license.

It doesn’t work like that.

Just like you can’t opt out of other laws you don’t like. I’d love to
not have to pay for cheeseburgers, but I can’t just go in to McDonald’s
and declare that I’m a sovereign entity and I’m gonna walk out with a
free burger. If you don’t have a license, nobody has rights to the code,
even if you wish they did, and even if you put it up on GitHub.

Some people still argue, like, “oh I’m not gonna sue anybody or
anything like that, you can use my code, go ahead”. That’s a great thing
to say! Please, put that promise in writing! And distribute it with your
code! Preferably in a file named “LICENSE”. Except don’t use your own
words, just pick one of the licenses we talked about earlier. It will
save us all a lot of trouble, and honestly, it’s not that much effort to
do.

Now, some of you are thinking at this point, “what about the public
domain? Can I just say my stuff is public domain and forget about
licenses?”. And for those of you who don’t recall, the Public Domain is
what we call stuff that’s outside of copyright, either because the
copyrights expired, or it wasn’t eligible for copyright protection in
the first place, or it was deliberately freed in that way.

And yes, you’ll encounter things out there that are attempting to
sidestep the whole issue by more or less placing things in the public
domain. Examples of this are the Unlicense and Creative Commons Zero.
This is better than nothing, but overall, I can’t really recommend it.
At the very least you should protect yourself by including the warranty
disclaimer language that licenses usually have. Even the Unlicense web
site suggests that as an option.

The reason I can’t recommend the Public Domain approach has to do
with those Moral Rights we talked about earlier, in the intro to
intellectual property when we talked about copyright in general. Moral
Rights were the ones like the right to attribution, and in some places
they’re irrevocable and forever, and I promised we’d talk more about
that later. Well, later is now, and this is why they matter.

When you say you’re putting something into the public domain, or that
people can do literally anything, you’re trying to give up those moral
rights. And in some places, that’s just not something the law lets you
do. Just like you can’t have a legal contract that lets someone murder
you. The law actually limits what actions you can take that are
detrimental to you. Usually this is put in place to protect against
coercion and exploitation.

So when you attempt to give up the moral rights that you can’t give
up, you’re creating a legal uncertainty and a risk that the whole public
domain dedication will get thrown out, and that your software will be
treated as if you didn’t give anyone any rights to it at all. Because
legally, that public domain dedication might not be a meaningful,
coherent, document. It might be null and void.

The Creative Commons Zero authors were actually aware of this
problem, and if you read the full text of CC0, it’s really actually a
public domain dedication, followed by a regular license that basically
says “if the public domain stuff doesn’t work, here’s a license”. But if
you’re doing that, you might as well have gone with a regular license in
the first place.

Now, to be honest, this is mainly an issue outside of the United
States and places with similar legal systems. But even if you are
American, writing code in the USA, please don’t make life harder for
people just because they come from a country with a different legal
tradition.

At the end of the day, choosing something like the Unlicense might
feel like an anti-copyright political statement, but really you’re just
creating difficulty for people in other countries, and you’re not
gaining anything that you wouldn’t get by just using a very permissive
standard license. Think of your European colleagues and please use a
proper license.

And on that note, I’ll also ask that you please pick an
existing license. Don’t write your own. Sometimes people
correctly understand that they need a license, but they also think that
their situation is somehow really unique and that they have to make up
their own new license. Or, more likely, give a pile of money to a lawyer
who will happily accept it in exchange for doing absolutely minimal work
by just rephrasing the same stuff that’s already in other licenses.

The truth is that there are already licenses out there for every need
you can think of. Find one that works for you.

Every new license that shows up in the wild just makes a lot of extra
work for developers (and lawyers) who have to evaluate it and figure out
whether it’s compatible with all the other licenses they’re using. It
imposes a very real cost, and you lose out the benefits of using common
licenses like shared legal precedents and the common understanding and
good-will that the community around an existing license has built
up.

You can see an example of how this plays out with Doug Crockford’s
well-known JavaScript tools like jslint. The license is pretty standard
except it adds the line “the software shall be used for Good, not Evil”.
Now, admittedly, that is pretty hilarious, but the practical upshot of
it is that Debian, Fedora, the GNU project, and others can’t carry and
redistribute it from their repositories, because obviously they have no
control over how their end users use the software.

However there is one organization that can redistribute it, and
that’s IBM, because IBM’s lawyers got a special exemption where Doug
Crockford said “I give permission for IBM, its customers, partners, and
minions, to use JSLint for evil.” And again, that’s hilarious, but IBM
is right here. Good for them for protecting their users and making sure
they don’t end up in front of a jury somewhere arguing about whether
their business practices or maybe their political activism, is evil or
not. But the whole thing represents a bunch of work, a bunch of pain, a
bunch of wasted effort that could just have been avoided by sticking to
a standard license.

And even after all that, jslint is still being obsoleted by jshint,
partly because it has a better license. And that’s how it works for a
big name famous person like Douglas Crockford: if you’re just starting
out, and your project is obscure, the most likely outcome is your
software will just be ignored. People will be uncomfortable with it
because of the weird license. So pick an existing, well understood,
common one.

So far we’ve been focusing on code. But projects are usually more
than that. At the very least there’s documentation (there is
documentation, right?), but also there are logos, tutorial videos, all
kinds of non-code things. Often this is all just distributed under the
same terms as the software, which is usually fine, nothing wrong with
that.

But remember, the idea is to make use of licenses to further our
goals. And the goals for non-code things might be different from the
goals for code. For example, your code might be under a copyleft license
that requires people who modify it to share their source too. That makes
less sense for a video tutorial, or even just for documentation.

So you should be aware that you can license that stuff differently,
under terms that are more suited to that kind of work. On the copyleft
side, there’s the GFDL, the GNU Free Documentation License, which works
much like the GPL, except it’s not for code.

And then there’s also the whole Creative Commons suite, which has a
really clever mechanism where you can pick and choose exactly how you
want your license to work. They have these four atoms you can combine:
attribution (meaning people have to give you credit), non-commercial
(meaning people can’t make money off your work), no-derivatives (meaning
people can’t change your work), and share-alike (which requires that
people release their changes under the same license). And you can
combine these to make your license. Except attribution is non-optional,
because of the moral rights issues we talked about earlier, and of
course share-alike and no-derivatives are mutually exclusive.

So for example you might use CC-BY-SA, meaning you require
attribution, and changes must be shared the same way. That’s like a
copyleft license. Or you might say commercial use is prohibited, but
otherwise people can do whatever. That’s a very hippie license.

But it’s up to you, and these options work really well for stuff that
isn’t code. At the end of the day, you should know about these so you
can deploy them when you need to to help your project succeed.

So far we’ve talked a lot about how to share something that’s
entirely your work with the world. What about things
other people are contributing? Or what about when you’re just
adding a small piece to an existing codebase? There are a few options to
be aware of.

At one extreme, there’s copyright assignment. That means that the
owner or manager of a software project wants contributors to actually
give them ownership of the copyright, that is, not just license
it to them, but make them the copyright holder.

Unless you really, really, trust the manager of that codebase, this
isn’t something you should agree to. It just puts you in an ugly
situation where the owner of that repository can do things like take the
entire codebase proprietary and lock you out of your own work.

The one exception to this is if you have some really specific,
targeted, reason to want that person to have ownership. For
example, if you’ve got an agreement with the Free Software Foundation to
have them bring a GPL enforcement lawsuit. That is not a common
situation.

A bit less extreme is something called a Contributor License
Agreement. This is a document that you have to sign before the project
owner will accept your code. You still keep the copyright, but have a
specific legal agreement in place that covers what rights they have, how
they can redistribute your code, and so on. These are a bit of a hassle,
but can be perfectly OK and serve valid and important purposes. They
vary a lot, so it’s impossible to generalize about whether they’re good
or bad. You’ll just have to read the specific one you’re presented with
very carefully and decide whether you’re OK with it. The Python Software
Foundation one is fine, by the way.

And finally, the most lightweight option, and in my opinion the best
one, is something called the Developer Certificate of Origin. This is
something the Linux kernel project came up with, and it’s basically just
a statement where you say that yes, you have the right to submit this
code to the project (because you wrote it or the person who did said
that you could), and yes, you agree that the project can distribute it
under the same license as their other code. It’s very lightweight, low
hassle. There’s no signing of paperwork, you just say “yes, I agree to
this”. In fact, for projects using Git for version control, you can even
have Git automatically tag your commits with your sign-off.

What it provides is protection for the project. If it turns out you
lied and you were trying to sneak code in that you shouldn’t have,
that’s now on you. The project had good reason to believe this was code
they could use, because you said it was. It protects maintainers from
both malicious actors and from simple accidents that someone might try
to capitalize on later. It also makes it guaranteed and explicit that
they’re allowed to incorporate your code, instead of just implicit
because they think you sent them that patch that they think you were
allowed to send. And, as Python developers know, explicit is better than
implicit. You can easily adopt this for projects your maintain, just ask
people to agree to those very short little assertions.

Now we’ve covered the core ideas of intellectual property law, and
both sharing your code, and accepting code from others. That’s pretty
much what you need to know about free and open source software
licensing.

So, to sum up:

Pick a license

And pick a license that is already established, proven, and in wide
use;

The Open Source Initiative, the Free Software Foundation, and
choosealicense.com all maintain online resources with lists of licenses,
their details, and things to keep in mind about them, so do some
research there.

And pick a license that makes sense within your community;

For example, Perl developers tend to use the Artistic License. There
are other licenses that for all practical purposes are totally
equivalent, but that’s the one you would want to use if you want to
interoperate with that community.

And pick a license that is appropriate to the nature of the work;

Consider Creative Commons or GFDL for art, documentation, and things
like that. And do use a real, full license, with a warranty disclaimer
for code.

And pick a license that furthers your goals for the software;

If you want to make life easy for developers, and be
business-friendly, and generally be very permissive, consider a
permissive license like Apache 2.0 with its patent clause.

If, on the other hand, you want to protect users, and make sure the
free commons of software continues to grow, consider a copyleft license,
like the GPL, LGPL, or AGPL version 3.

But above all, I hope you will feel more comfortable navigating
software licensing, and I hope you’ll care about licenses, and how they
can be tools that work for or against you, and I hope you’ll think about
how to license your software, instead of doing nothing or guessing at a
“default”.

I hope you’ll find ways to make it work for you, and that it will
help you accomplish what you set out to do when you first sat down, and
started your project, and wrote that first — creative and
copyright-protected! — line of code.

Thank you all.

Selected Bibliography

This section lists both works used in creating the text above, as well as
sources for further reading to explore various topics in more depth.