Hi everybody. Thanks — thanks for coming. I know there are some really fascinating,
exciting, talks going on right now, so I appreciate that you chose this one.
I guess you lot are the really serious-minded folks that really love legal stuff.
Like you're really pumped right now, like, "Yeah, let's read some legal licenses!"
I don't know. Maybe you just figured out that there's more power outlets,
or the Wi-Fi works better in this room or something, but...
Anyway! Hi! My name is Felix, and this talk is:
"What You Need to Know About Free and Open Source Software Licensing"
And, 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, and boring, and even intimidating, and sometimes,
you might think it's pointless and just a bunch of magic incantations that you
just have to chant in the correct way and hope that everything works out all right.
But, really, it turns out that the core ideas that underpin
the system are actually pretty easy to understand,
and if you take the time to do so — like by coming to this talk —
it not only helps you see why things are the way they are, but actually
gives you new tools, new ways to influence and control how your software is used,
and to help you make sure it achieves the goals that you set for it.
So that's the objective for this talk: to learn the basics
of how intellectual property law (and in particular, copyright) works;
to understand how licenses are built on top of those principles;
and then 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 sort of an overview of what we're going to cover.
It's not like you need to memorise it. It's just to anchor you as we go through
and to let you know what to expect coming up.
But broadly speaking, there are three big themes.
We're going to cover some background, some foundations;
we're going to look at some specific licenses;
and then we're going to talk about some of the related practical concerns
about implementing and using them.
But first — a really big important disclaimer/caveat up front:
I am not a lawyer! And I know, right,
that's exactly what you want to hear from someone who's giving this talk.
Like, "Yeah, that's really great. Not a lawyer." But yeah, I am not a lawyer.
I am not an expert in your countries' local legal systems; and a lot of this
stuff varies so much around the world. So I'm not speaking on behalf of anyone,
or conveying legal advice. This is general, non-specialist,
background information. We're going to cover about 80%
of the material that around 80% of the 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 are 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 do really need to know more,
because you have a specific legal question, you should take that to an actual lawyer;
because you're not going to get that from any talk, or reading Wikipedia,
or the Internet, or whatever.
I'm glad that's out of the way. Let's actually get started by looking at
"What is intellectual property?" Intellectual property is kind of weird
because the term covers a whole grab-bag of kind of really unrelated things that
just have one attribute in common; which is that 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 you
can protect and hold and keep away from everyone else. It's just ideas.
So for this talk, the kinds of intellectual property we're going to look at 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, build upon, and modify that work — even though there
may be no technical restriction that would otherwise keep anyone else
from doing the same.
Copyright is given to the creator of a work completely automatically.
You don't have to do anything to get copyrights, or to keep them.
That used to not be the case, but for a really long time now it's all been
fully automatic. In particular, you don't need to stick a little bit of text, like
"Copyright © 2016 John Doe." You don't need to put that on your work.
You get the copyright completely automatically.
And that gives you the right to control how it's used for a limited time.
Actually, I say "a limited time," and that's that's the theory,
but in practice no copyrights have actually expired in the United States
since the '70s. Every time that we get close to what would be the new deadline,
the law gets changed retroactively to extend the duration.
But that is a topic for another talk.
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 little bit different. In some places they don't even
exist at all. So they're very vague and they vary a lot from country to country.
And moral rights are sort of the non-commercial part of copyright.
It's not so much about making money off of your creation. It's about things
like the right to be identified as the author, or the right to the integrity
of the work. And integrity in this context means keeping people from
changing or presenting your work in ways that you don't like,
like putting on a display and defacing your art, even if they own it.
Moral rights also behave differently. For example, they might not be
time-limited. They might actually last forever. They might even last beyond
your lifetime and pass down to your heirs and descendants.
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, or give away,
or sell your moral rights. It's just not allowed, like how you are not allowed
to agree to be murdered. We'll talk a bit more later about the
implications of that — and it turns out that yeah, the the fact that in
some countries you cannot get rid of your moral rights, that turns out to
be really important.
But the next big kind of intellectual property I want to talk about briefly
are patents. Where copyright was about creative works, patents are about
protecting functional inventions.
The deal is that you share the details of how your new gizmo works,
and society in exchange gives you this exclusive monopoly on the invention
for a little while.
Now, 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 that they can try to pull. For example, the owner of
a patent might try to get their patented software technique adopted as part of a
standard, so that anyone who implements that standard then has to pay them
money for a license or risk being sued. Or they might even actually themselves
contribute the code that implements their
patented technique, and then later, either because they planned this in advance or
just because they changed their minds, they might come back later and try to sue
you for using that code that they themselves contributed to your project.
So some licenses have protections against this kind of thing, and when we talk about
about those licenses I will call that out specifically, because it is a great thing
to have in a license.
Also, as a side note, there's something called a design patent, which covers
the way a product looks, and 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 kind of things.
But because it's also has "patent" in the name, you sometimes see people
getting confused and angry and saying stuff like "oh no, so-and-so is trying to
patent the rectangle or the color blue." And 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 regular patents.
Really quickly, last up: 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. Now this doesn't usually come up in software licenses
directly, but it can definitely be an issue for software projects,
especially user-facing ones that have have brands and reputations to protect.
You might remember that in 2013 the Python Software Foundation actually
had to fight for the name "Python", and up until very recently earlier this
year, the Debian GNU/Linux distribution had to ship Firefox under the name
"Iceweasel", with a really cute different little blue logo because of disagreements
about trademarks — even though the licensing of that code was perfectly fine.
That was a friendly disagreement, though, and both sides had very good points, and
they've now sorted it all out; as of last month, which is great. But again, most
licenses don't have anything to say about trademarks — but you should know what
they are, because they do come up for software projects.
If you expect end users to be able to recognize the name and brand of your
project, then maybe spend some time to think about what rights or requirements
you might want to give to people who fork your code. Can they associate that
new project with your brand? In general, though, 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.
That works out well.
So, why do we need licenses at all? Well, intellectual property law is a
reality, whether you 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 actually also work within the
confines of the law to achieve the outcomes that we want for our software.
We can use the laws in ways that are beneficial and that actually help
spread our work.
So a license is a set of permissions that you give to someone. When you create something
like a piece of software, you alone have the right to it, and you have control over how
to share those rights with others. A license is 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 of course 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 also from things
like reverse engineering it, or in some cases even from really wild stuff like benchmarking
the performance of the software and sharing that data. Some proprietary database licenses
have that. And I mean, that's a pretty odious example of a requirement in a proprietary
license, but free and open source software licenses usually also have obligations and
requirements that come with them. They're just of a different nature, and we'll look
at some of those in a minute. Usually if you don't comply with the obligations that a license
creates, you lose all the rights that would otherwise have given you, and there might
be other penalties on top. But the key idea is that without a license, no one 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 up without a license,
that does not give anyone any rights. That is not code you can use. It's just code you
happen to be able to look at, like how you can probably see my laptop sitting up here
right now and you can look at it, but you don't have the right to take it home.
Without a license, that code is not for your use.
All right, enough background. Let's actually look at some licenses.
The first category i want to talk about are known as permissive licenses, and these are
the simplest kind. They're often very short, very quick to read through, and they almost
— but not quite — but they almost just say that you can do pretty much whatever with
the software. You can even build proprietary code on top of the the code that's been shared.
You usually just have to provide attribution, meaning you have to give credit to the person
who wrote it, and there's often — or usually there's also a warranty disclaimer that says
that the author isn't responsible for what you do or how badly you mess up using the
code. And that is a really good idea to have, by the way. You should not use a license that
does not have a warranty disclaimer.
Now, you would 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 back to you.
That's a very pragmatic approach. It's very business-friendly.
And having companies who care about improving the quality of your code,
and who can pay people to work on it — that can be really powerful.
Just be sure that you really would be okay 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 it's
well within their rights.
So, people from the communities around these licenses usually talk about the term "Open
Source," not about "Free" software and it's very non-political, non-activist. It's about
just 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's a bunch or a subset of some
of the more popular ones. These ones here really only differ in minor ways. And some
are more popular in certain communities. so the JavaScript world seems to be fond of the
X11 and the Expat licenses, which are usually just called the MIT license, just lumped together,
which is also very popular with Python devs. The BSD folks on the other hand, like OpenBSD
and FreeBSD, they unsurprisingly like the BSD license. But honestly, all of these are
pretty similar. If you want to go with this approach, read through these — they're like
three paragraphs — and just pick one that you like the look of, or one that 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, because 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 different tools serve
different purposes. These are all good licenses if they do what you want them to do, the way
that any brand of screwdriver is fine if you want to drive a screw. But if you actually
need to hammer a nail, you should not just grab a screwdriver just because it happens
to be sitting right there.
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. So if you decide that you want a
permissive license, that's great, but you should actually 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, because the choice does matter.
All right: end of that side note.
There is one really popular permissive license that is a little bit different, though, and
that is the Apache 2.0 license, which is named after the Apache software foundation.
It's a little more verbose than the ones we just looked at — instead of like three paragraphs,
it's more like three pages — 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 other ones don't, and that is a grant of patent license, which, going back to what
we talked about earlier about patents, this is the kind of clause that I've said is really
great to have and that I'd call out, so I'm calling it out now. Right now this is a bit
of a wall of text, but with a little bit of editing, we can snip it down to just the important
parts. So 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 other patents that would
otherwise be infringed upon by the code that was contributed. so this is exactly a patent-troll-killing
anti-patent-ambush clause. And it actually goes even further and says that if you do
sue anyone over patents related to this software, then you actually lose all of those patent
licenses that everyone else granted to you. so it's almost like a mutually assured destruction
where if you start a patent war, you're opening yourself up to the same kind of retaliation.
Now, do you need that 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 have to deal with the requirements about notices of modification
or whatever, so you just have to think about whether your particular project is really
susceptible to patent issues. Things like video codecs, for example, if you work with
those, those are a minefield of patents. 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. But definitely
if you're working with anything that's high risk, I strongly recommend you use a license
with a patent grant clause, and among the permissive licenses, Apache 2.0 is the
best one in that regard.
The second major family of licenses that 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, so, you know, have some respect for your elders. These days maybe some of
the revolutionary zeal has fallen away and people are focusing more on the practical
benefits of developing in the open, but it's worth understanding where all this came from
and what the creators of these licenses intended. So, the motivation behind a copyleft license
is to promote user freedom. It's not to make life easy for developers. It is not to let
you bootstrap your startup faster. It is not to invite collaboration from industry, although,
you know, all of those things can and do happen, and that's great, but the goal is really to
guarantee that users have the 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
your program, and the freedom to redistribute your changes as well.
Now to guarantee those freedoms, the central idea that makes a license a copyleft one is
that it requires you to share the changes you make under the license 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 that you wanted to give them. Copyleft licenses don't prevent you from making
commercial software, but they do prevent you from making proprietary software. Now, unlike
permissively licensed code, which people can take and do incorporate into closed-source
software, copyleft code spreads copyleft to other 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 that copyleft
"infects" code and spreads in this way. And I think that mean for that to sound scary
and dangerous and threatening, but an organically growing viral spread of free software is exactly
the point of these licenses. That is what they're meant to do. And 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 that you want.
The first and most well-known license in this category is the GPL, the GNU General Public
License. And everything I said a moment ago about what copyleft is is really what the
GPL is, because the GPL created and defines this whole category. One key thing about it
that makes it different from some of the other licenses is that the viral clause that requires
you to share your code only kicks 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, and that's
how it guarantees that the code stays free. And that obviously means you can't combine
GPL code with code that's under a license that's more restrictive than the GPL, because
either you'd have to violate the GPL by imposing additional restrictions, which it forbids,
or you'd have to violate the other license by not imposing the additional restrictions
that it requires. This is mainly an issue with the older version of the GPL that you
still find a lot in the wild, the GPL version 2, which most notably is not compatible with
the Apache license that we just called out as being so good because of that excellent
patent clause, which, even though it's a good restriction, it's an extra restriction, and
the GPL doesn't allow that.
Version 3 of the GPL, however, fixes this by also including that clause, so it's no
longer an extra restriction. So GPL version 3 is both more compatible and it includes
patent protections like the Apache 2.0 license. So 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 and lets you use version 3.
There is a closely related license called the LGPL.
Hmm. Interesting.
I have lost the ability to move my slides.
Oh, there we go.
This works.
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 it's attached to, not anything that's
just linked to it to build a larger software application. So you can have an LGPL library
as part of even a proprietary application, and you only have to share your changes to
the LGPL part.
It does also come with some requirements that are intended to make sure that users can always
take advantage of the LGPL nature of that linked library. So essentially users have
to be able to replace the version that you've shipped with whatever version they want, which
maybe that's a newer version from upstream or maybe they have their own custom version
or whatever. The idea is that even if you ship a non-free proprietary application, if
it's built on top of an LGPL library, then users will always have the freedom to control
what version of that library they use, so they can maybe keep it up to date even if
you've stopped supporting it, or they can change behavior that they just disagree with
you about.
The third big license in this category — and to be totally clear, there are lots of others,
but these are the big ones — the third one I want to talk about is the AGPL: the Affero
General Public License. and the newest version of this is actually based on the GNU GPL,
and so all of these form one big happy family. And 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 to whom you've distributed the application. But there's
a big category of software that never actually gets distributed to its end users, and that's
networked applications; servers that users only interact with remotely through a client
like a web browser. And these are obviously still 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
server somewhere, so the GPL's sharing requirements don't kick in, even if the code that was running
on that server is GPLed and meant to be shared.
So the AGPL fixes that. It's very similar to the GPL, but its sharing requirements kick
in even for users that just access the application over the network. And that definitely scares
some people, but again, remember that different licenses are used to achieve different goals
according to what the creator wants, and these copyleft Free Software licenses are deliberately
very aggressive vehicles for ensuring the independence of users from developers and
service providers that they would otherwise be reliant on. And as developers, that obviously
is a bit scary for us, but think of, you know, who are you building this software for?
AGPL, LGPL, and GPL version 3: all compatible with one another, all compatible with a lot
of other licenses. You can build an application that combines all of these. Not the case for
older versions.
Now, maybe you're looking at these choices and your head is kind of spinning and you're
thinking like, "augh, this is a mess! I don't know what to do." Or maybe even raging, like
"I hate copyright law!" And you conclude that you don't care about licensing, and what you
want to do is just throw the software out there and let anybody do whatever they want:
no license. Unfortunately, it doesn't work like that, just like you can't opt out of
other laws that you don't like. I mean, I'd love to not have to pay for cheeseburgers,
but I can't just go into a McDonald's and declare "I'm a sovereign entity that doesn't
believe in private property" and hope that they gave me free burgers. So if you don't
have a license, no one has any 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, but it doesn't matter because I'm not gonna sue
anybody or do anything like that. You can use my code." Great! That's really nice of
you 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
that we talked about earlier. It'll save us all a lot of trouble, and honestly it is not
that much work.
Some of you are thinking at this point, "what about the public domain? Can I just
put my stuff in the public domain and forget about licenses?". And for those who don't recall,
the public domain is what we call things that are outside of copyright, either because the
copyright has expired, or it wasn't eligible for copyright protection in the first place,
or it was deliberately set free in this way. And yeah, you will encounter a lot of things
out there that are attempting to sidestep the whole issue by more or less placing things
in the public domain. Some examples of this are the Unlicense and Creative Commons Zero.
This is much better than nothing, but overall, I still 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 website, which is a militant anti-license
site, even they suggest that as an option. Unfortunately they hid away in the Frequently
Asked Questions, so it's a bit hard to find, but even they agree that you should have a
warranty disclaimer for code.
But the reason I can't recommend the public domain approach has to do with those moral
rights that we talked about earlier in the intro to intellectual property section when
we talked about copyright in general. Moral rights are the ones like the right to
attribution. And in some places they are 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 that
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 is just not something
that the law lets you do. Again, just like you can't sign a contract agreeing to be murdered.
The law actually limits what actions you can take that it believes are detrimental to you,
and usually this is put in place for really good reasons. It's to protect against coercion,
to protect against exploitation. It just happens to work against us in this case when we're
doing it voluntarily.
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 you put up there
is going to get thrown out, and your software will be treated as if you didn't give anyone
any rights at all, because legally that public domain dedication, depending on where you
are in the world, might not be a meaningful coherent document. It might be null and void
nonsense.
The Creative Commons Zero authors are actually aware of this problem, and if you read the
full text of the CC0 instead of just the marketing blurb, it's really actually first a public
domain dedication followed by a full regular permissive license, with a little note that
says, like, "if the public domain stuff doesn't work and isn't allowed, here's a license."
But if you're gonna do that, you might as well just 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
legal systems like the United States. 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. Or even if they are American as well, they might operate
in a country with a different legal tradition.
So at the end of the day, choosing something like the Unlicense might feel a bit like it's
an anti-copyright political statement, and I can sympathize with that, 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. Please think
of your European colleagues and use a proper license.
And on that note, I'll also ask that you please pick an existing license. Don't write your
own. Yeah, the slide is pithy and kind of says it all, and i'm tempted to just leave
it at that, but I'll explain why. 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, they have to give a pile of
money to a lawyer who will happily accept it in exchange for doing minimal work by just
rephrasing the same stuff that's already in every other license. Because the truth is,
there is already a license out there for every need you can think of. Find one that works
for you. Every new license that shows up in the world 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 of the other licenses they're using. This grows exponentially, and it imposes
this very real cost, and you lose out on the benefits of using common licenses, like shared
legal precedent and the common understanding and goodwill that the community around those
existing licenses have built up.
You can see an example of how this plays out with Douglas Crockford's well-known JavaScript
tools like JSLint. The licenses to those are pretty standard, except that they have
the extra 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 a bunch of others can't carry and redistribute that from their repositories both becase
obviously they don't have any control over how end users are going to use that software,
and because it's incompatible with the freedom that they want to guarantee to let users use
it for any purpose, including evil. However, there is one organization that can redistribute
that code, and that is IBM: because IBM's lawyers got a special exemption where they
got Douglas Crockford to put in writing, "I give permission for IBM, its customers, partners,
and minions to use JSLint for evil." And yeah, again, that that is hilarious, but IBM is
right here. Good for them! Good for them. They are protecting their users, and they're
making sure that their users aren't going to end up in front of a jury somewhere arguing
about whether their business practices or their political activism or whatever they're
using their code for, arguing about whether they're evil or not. Would you want to, you
know, try to convince people who may disagree with you fervently about whether you've ever
done anything evil?
But the whole thing represents a bunch of work, a bunch of pain, a bunch of wasted effort,
that could just have been totally 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 that
your software will just be ignored. People will be uncomfortable with it because of the
weird license and just won't use it. So pick an existing well-understood common one, and
put your jokes somewhere else that's not the license.
Now, so far we've been focusing on code, but projects are usually a lot more than that.
At the very least, there's documentation. There is documentation, right? You do have
documentation? Yeah, ok, good. But also there's logos, there's tutorial videos, there's all
kinds of non-code things, and often all of that is just distributed under the same terms
as the software, which is usually fine. Nothing wrong with that. You can do that. But remember,
licenses are tools that we can make use of to further our goals, and the goals that we
have 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 to modify it to share their
source, but that makes a lot less sense for a video tutorial or even for documentation.
So you should be aware that you can license that stuff differently, under terms that are
more suitable to that kind of work. On the copyleft-like side, there's the GFDL, the
GNU Free Documentation License, which works kind of like the GPL except it's not for code.
And then there's the whole Creative Commons suite, which has a really nifty clever mechanism
where you can pick and choose exactly how you want your license to work. They have these
four atoms that you can combine: Attribution (meaning people have to give you credit),
NonCommercial (meaning people can't make money off your work), NoDerivatives (meaning people
can't change your work), and ShareAlike (meaning that if people do change your work, they have
to release it under the same license). And you can combine any of those to make your
own license, except attribution is not optional because of the moral rights issues, and
ShareAlike and NoDerivatives are mutually exclusive.
so to sum all of that up, you might have something like "Creative Commons (Attribution, ShareAlike)",
meaning you have to be credited as the author, and all changes have to be shared
under the same terms.That's like a copyleft license. Or you might have a license where
you say "commercial use is prohibited, but otherwise do whatever," and that's
like a hippie license. But it's up to you. And these options work really well for stuff
that isn't code. And at the end of the day, you should just know about them so that you
can deploy them strategically when you need to help your project succeed.
Different tools for different jobs.
Now, 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 end, at one extreme, there's copyright assignment, and this basically means that
the owner or manager of a software project wants contributors to actually give them the
ownership of that copyright — not just license them to let them use it, but actually make
them the copyright holder. Unless you really, really, really trust the manager of that code
base, this is not something you should agree to. It just puts you in a really ugly situation
where the owner of that repository can do things like take the entire code base proprietary
and lock you out of your own work.
There are some exceptions, like if you have some really specific targeted reason that
you want that person to own it, like if you have an agreement with the Free Software Foundation
that they're going to bring a GPL enforcement lawsuit. That is not a common situation, and
if you're in that situation, you know enough to make your own decisions.
A bit less extreme is something called a Contributor License Agreement, a CLA, and this is just
a document that you might have to sign before the project owner will accept your code.
You still keep the copyright, but there's a specific agreement in place that covers what rights
they have, how they can distribute your code, and so on. These are a bit of a hassle because
you have to usually actually sign something, but they can be ok. They can serve valid reasons.
But they do vary a lot, so it's impossible to generalize about whether they're good or bad.
You're just gonna have to read the specific one you're presented with very carefully
and decide whether you're okay with it.
By the way, the Python Software Foundation one that covers contributing to Python is fine.
It's good. Nothing nothing weird in there.
Finally, the most lightweight option (and in my opinion the best one) is something called
the Developer's Certificate of Origin, DCO. 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, either because you wrote it or because 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, very 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 this provides is protection for the project. If it turns out that you lied and
you're trying to sneak in code that you shouldn't have, that's now on you, because the project
had good reason to believe that this was code that they could use, because you said it was.
It protects maintainers both from 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 and redistribute it, instead of just implicit because they
think that you sent them that patch that they think you wrote. And as all Python developers
know, explicit is better than implicit. You can easily adopt this for projects that you maintain
You just have to ask people to agree to those very short little assertions.
Just search for "Developer's Certificate of Origin" and it comes up, and it's four paragraphs
or something like that — very small.
Now we've covered the core ideas of intellectual property law, and we've covered sharing your
code, accepting contributions from others, practical things to keep in mind, and that
is pretty much what you need to know about Free and Open Source software licensing.
So to wrap it up, I'll ask that you please pick a license, and when you do that, pick a license
that's already established, proven, and in wide use. The Open Source Initiative, the
Free Software Foundation, choosealicense.com — they all maintain really good online resources
with lists of licenses, their details, things to keep in mind. So just do some research there.
And pick a license that makes sense in 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 if you want to integrate with that community, that's the one you would
choose.
And pick a license that's appropriate to the nature of the work. Consider Creative Commons
or GFDL for things like documentation, and do use a real full license with a warranty
disclaimer for code, and if you're at risk of of patent issues, one with a patent license grant.
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 that 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 that you will now feel more comfortable navigating software licensing, and I hope
you'll care about the subject, and I hope you'll care about how licenses can be tools
that can 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, and I hope that you'll find ways
to make this work for you and that it'll actually help you accomplish what you
set out to do when you first sat down, started your project, and wrote that first creative
and copyright-protected line of code. Thank you all.
[APPLAUSE]
This is how to contact me. I'd love to chat with all of you.
I'd love to hear if I didn't cover something, or you would have liked to
hear about something in more depth. I'll be around all conference,
and afterwards this is how to get hold of me in a variety of media.
Thank you.