Felix Crux

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.

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 very long time now it’s all been fully automatic. You don’t even need to stick a little bit of text like “Copyright © 2016 John Doe” on your work.

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.