I'm the kind of nerd that has a favorite software license. For a while that favorite license was the Mozilla Public License (MPL). Right now, it's the GNU Affero General Public License (AGPL). Licenses are really important on all code, and they're critical to the open source movement. They reflect the values of the people writing the software. Let's talk about software licenses and why they matter, then how they reflect our values. (And of course: I'm not a lawyer, and there may be errors in this!)

The importance of licenses

The first question is: Why do licenses exist and why do they matter? I'll take a US-centric view here, because that's what I'm most familiar with.

In the US, all code is by default protected by copyright, both as the source code and in compiled form¹. This means that other people don't have the right to use your code (with some possible exceptions) without permission. Software is less useful without users (as are books without readers, etc.) so we want some way to let people use our software. That's where copyright assignment and licenses come in.

If you develop code for your employer, they probably require you to assign copyright to them for the code you write. There are some notable exceptions, but this is common in US employment contracts so that your employer owns the rights to the code. This lets them choose the license for the code, sublicense it, sell it—all the things a business typically wants to be able to do.

If you're developing code outside of employment, and you retain the copyright on that code, then you get into license territory. When you put up code for other people to see, if you don't include a license, they have no rights to use that code. You have to include a license for people to be able to lawfully use, copy, modify, or distribute the code. So if you are publishing code on the Internet, it's best to put a license on it! Otherwise, it might solve someone's problem now or in a decade, but they could be out of luck, unable to actually use it.

Open source and licenses

Licenses are especially important if you're writing open source code. Open source requires more than making the source code available to view. The full definition by the OSI specifies ten requirements for being considered open source. There are many licenses which satisfy these requirements, and they include the ability to freely redistribute and modify the code and derived works.

Some of the common licenses are: MIT, BSD, GPL (LGPL, AGPL), Apache, and MPL. You'll also see some licenses like the Server Side Public License floating around which capture some but not all of the definition of open source; notably, they restrict commercial activity to try to prevent companies like Amazon from squashing other companies like Elastic and MongoDB (which are themselves quite large now: Elastic and MongoDB have market caps of $6 billion and $12 billion respectively).

With the myriad licenses out there, it's helpful to classify them. There are a lot of little subtle differences (trademark use, patent rights, etc.) but the biggest differentiation is permissive vs. copyleft licenses.

A permissive open source license is one where almost all rights are granted on the software, including the right to relicense it and even make a closed-source fork of the software. This category includes the Apache, MIT, and BSD licenses. It's common to see libraries licensed under this, because then almost any developer can use your library: There won't be license concerns (maybe patent or trademark concerns). Among these, the MIT license is the most common. Many Rust crates are dual-licensed under MIT and Apache.

In contrast, a copyleft open source license restricts more rights on the downstream recipient of the software because it requires that any modifications or redistribution of the software are released under the same terms as the original software. That is, if you distribute a modified copy of a copyleft program, you must make that modified copy available under the same license as the original program. This category includes the GPL and its derivatives and the MPL. The most widely used piece of software in this category is probably the Linux kernel, a little project a few people have used. Many open-source applications and libraries use this license to ensure that contributors contribute their patches back to the community.

The main differences between the copyleft licenses boil down to a few points. GPL is the base case copyleft license to start from. If you use GPL-licensed in your program, your program is now a derivative work and must also be released under the GPL. This was written before web applications were the main form of distribution, so notably if you run GPL software on a web server it's not clear that that does constitute distribution. Comparing to GPL, the other common copyleft licenses have these differences:

• AGPL explicitly states that use over a network is distribution, so if a web application uses AGPL code, then it must also be released under AGPL
• MPL is licensed on a per-file basis, so it doesn't spread to the rest of your program; only changes to MPL-licensed files have to be released
• LGPL allows dynamic linking without the rest of the program being LGPL licensed, but there's nuance here

Reflections of values

Why are there two different major camps of open-source licenses? If we all have this shared belief that open-sourcing code is a positive thing, why isn't there a standard single license?

Because each of these licenses reflects subtly different values. Yes, we value other people being able to use and modify our source code. That's the base common value for the open source movement.

But beyond that, there are disagreements. Permissive licenses put high value on full freedom and there's higher value placed on people being able to create anything they want from the software, including proprietary forks, than on the open-source aspect itself. In contrast, copyleft licenses put high value on preserving open-source, and place higher value on keeping derivative works open than on fully free derivative use.

Other licenses also reflect values. "Source-available" licenses, like the SSPL, are increasingly prevalent. One pattern that we're seeing (at MongoDB, Elastic, and LightBend / Akka, among others) is the relicensing of open-source code from a copyleft license to a source-available license. In my opinion, this is theft from the community. (This is only possible if contributors assign copyright to the entity behind the project.) This relicensing explicitly says that building a massive business is more valuable than the community benefiting from their (volunteer!) contributions.

How I learned to love the AGPL

When I started in the software industry, I did not develop any open source code. I had some config files up on GitHub which were largely not copyrightable, and people could draw inspiration from them. Everything else I did, I kept private and did not publish the source code, let alone license it for others to use. This was in large part driven by two things:

• a fear of publishing "bad" code, and
• a delusion that I could become rich by keeping my software closed.

The first point is somewhat self-explanatory. I was afraid, and it felt like all the eyeballs of the world could be on me if I put my code out there. Would someone think I'm dumb if I publish my code??? (Probably not, and if they do: their problem, not mine.)

The second one is a little more subtle. I entered college right after the 2009 financial crisis, so as I entered college everything had hit rock bottom. Some of my friends had to change where they were going to school when their first choice colleges had to rescind scholarships due to collapsing values of endowments. It was a wild time, but hitting bottom meant that the market was only going up from there. So during college, I saw startups being formed, hitting huge valuations, growing massively. The companies that were founded before 2009 and survived became incredibly valuable. Why not go for that? Money seems nice.

So with that approach, I published almost no open source code. A few things were open, like my config files and some code from my college classes. The rest I kept private. I felt that the main value I was creating with code was potential economic value.

Eventually, I started to open-source more things. It took a long, long time to get comfortable putting anything out there. Once I did start putting things out there, I had two licenses I tended to use:

• GPL for things that were just for sharing, like my Advent of Code solutions
• MPL for things that I thought could someday be a Big Deal and wanted to have rights over

I chose GPL for the things that were just for sharing because I felt vaguely uncomfortable with other people having the potential of using my not-quite-throwaway but not-quite-good code for something profitable. On the other hand, I used MPL for things where I thought they could become big. I picked it because it lets you use an open-core model: Since the license applies on a per-file basis, it's feasible to combine an MPL core with proprietary extensions. This was driven by a desire for me to be able to profit from the work I was doing if it became a big deal.

That's delusional thinking, though. Unless you put in a lot of effort to getting something to be big, it's exceedingly unlikely that a community will just *poof* into existence around it. And it's very unlikely that it'll become something valuable to commercialize without that effort, as well. Commercializing isn't something that happens by chance. It takes deliberate effort and planning, and that can distract from the goal.

I didn't start any of those projects in order to get rich or to make a commercial project, but that thought in the back of my mind limited my license choice. Joining Recurse Center gave me the space to remember again why I start projects and why I write code in the first place. Yes, I enjoy making a great living and having a great paycheck. No question. But I got into this field because while I love the creative aspect of writing programs.

Something clicked over the past 7 weeks at RC, and I remembered why I'm doing all this. Or rather, I remembered the reasons that don't motivate me. Building a billion dollar business is definitively not the motivation. And making my code available so that other people can make billion dollar businesses on top of it? Nah. Fuck that.

From here on out, if I release open source software written on my own time, it's very likely going to be under the AGPL. I don't want people to be able to use my code in proprietary software unless they paid me to write that code. I don't want to make a proprietary version of my own software, either! If I write a useful library, I would love if other copyleft projects can use it. And I rather do not want it to contribute to the value of a big business without them giving back to the community. I just want it to be open and free.

"But what if it's something really valuable, and now a company can't use my library?" That's great! That's the idea!

For me, this clarifies why I'm writing code: The value is the software itself. The community, if one arises, owns the code.

Copyleft all the way!

What's the right license for your project?

To pick a license you have to first figure out what you value and what the goals for the project are. Only you can answer what your primary values are and why you're writing the software. Ultimately, the license is a reflection of your values, so think about what you value before you pick what license to use.

If your primary value is open-source itself and you want community ownership, copyleft is a clear choice. There are very few downsides to using a copyleft license like the AGPL for your code. The downside is simply that you cannot make a proprietary work from your code. The upside is that no one cannot make a proprietary work from your code² (but businesses can be made³).

By using AGPL for your libraries, you can use almost any other library in your own. You have few limitations on what you can pull in, so you can make full use of the open source ecosystem.

That said, there are plenty of situations where you would want to use a non-copyleft license.

Here are a few examples:

• You simply want anyone to be able to use it however they want, and you don't care if derivatives are open-source. This is saying "I have this cool thing, use it however you like!" People may learn from it, they may make a product from it, they may contribute back to it! It's all cool!
• You're working on something that is to be consumed by other businesses. If you're working on a developer tool, for example, and you want widespread adoption of it in businesses, copyleft licenses can pose serious problems. Even if it would pass legal muster, businesses are cautious with licenses. Using a permissive license can make it easier to get widespread adoption since people can use it to achieve their day jobs and to write other non-copyleft software.
• You're working on something where you explicitly do want to empower proprietary software creation. We live in a capitalist society, and you may want to empower business creation. Using a permissive license can remove a lot of friction from this, if your goal is creating economic value.

When I chose licenses that permitted proprietary software creation, that was a reflection of my values. My shift to using AGPL for all the things is a reflection in a realignment of my values.

So what do you value? Pick a license that displays that. And please consider valuing open source and community by choosing copyleft licenses.

Huge thanks to Julia, Joe, and Ed for giving me feedback on this post before publication!