I’ve been thinking about software licenses this month for two reasons. First, I saw this blog post from Daniel Stenberg, who created curl, about whether developers really have to update the years in their copies of software licenses. He concludes “I don’t think we risk much by” removing the years from most of curl’s license-related files, and thus, on January 3rd, Stenberg removed the years on almost all of the relevant curl project files. Interesting!

And second: for the first time ever, one of my open source Rust projects, Tidy, passed 25 stars on Github. Woohoo! Now that one of my projects was gaining a modicum of popularity, I wondered if I was satisfied with its license, which is the MIT License. I also have an at-this-point-private repo that I would make public if I was assured it wouldn’t be used for illegal hacking…

The MIT License is known as a “permissive” license, meaning that users and other would-be contributors have lots of permission about what they can do with the project’s code. This is the license I was slapping on most of my projects between 2014 and 2021-ish, mostly on recommendation from the Flatiron School instructors.

(Before I continue, for those who do not know, I am NOT a lawyer. And this post is not intended to be an overview of all open software licenses out there.)

Permissive vs. Copyleft

In my mind, the other strongest contender that I would hypothetically switch to would be GNU General Public License or GNU AGPL (probably version 3), which are known as “strong copyleft” licenses. As GitHub’s “Choose a License” project summarizes:

Permissions of this strong copyleft license are conditioned on making available complete source code of licensed works and modifications, which include larger works using a licensed work, under the same license.

During my research, I found a nonprofit called Blue Oak Council, whose website explains software licensing in the most clear language I’ve seen so far. For example, here is their comparison, broadly, of the two main categories of software licenses: permissive and copyleft:

Permissive licenses give everyone the right to do nearly anything with software, for free. That includes building new software that’s made available under different, commercial license terms, rather than open terms, or that’s kept secret within an organization.

Copyleft licenses work like permissive licenses with a catch: they require sharing and licensing the source code for new software built with copyleft-licensed software as open software, too. For this reason, copyleft licenses are sometimes called “share-alike” licenses, though “copyleft” is the term you’ll hear most in software.

(Blue Oak Council also has a long “primer” on open software licenses.)

To be more blunt, paraphrasing “Choose a License,” if you want a simple license that lets people do almost anything they want with your work, go with MIT. If you want people to be able to do whatever they want, but have those changes remain public, go with GNU GPL v3.

I still think using Copyleft is good

In general, my early free software training from books like Gabriella Coleman’s Coding Freedom and Two Bits: The Cultural Significance of Free Software by Chris Kelty tells me I should always prefer to use copyleft licenses, since they keep software free and open, a universal good thing in the eyes of some. And I’m not disagreeing with that here.

But from what I’ve seen in the world of software licenses, there seems to be more movement and innovation on the permissive side of the spectrum, as opposed to on the copyleft side, where GPL v3 and AGPL v3 and the other GPL licenses still reign. And thus I generally was exploring permissive license when writing this post.

What other licenses are out there?

The MIT License – the only permissive license I had ever used personally – is from the 1980s. While I still think the MIT License is a fine choice, I figured there must be some new licenses with interesting ideas and protections.

I’d heard of Apache 2.0 License, a permissive license, notable because the Rust programming language is dual-licensed under it and MIT; and Mozilla Public License, a “weak” copyleft license that I’ve always meant to understand better…

But I hadn’t really ever sat down and surveyed the world of software licenses. Below is a grab-bag list of licenses I was either reminded of or found in my research (by no means comprehensive!).

Stranger licenses

  • The JSON License has the fun and likely legally murky clause: “The Software shall be used for Good, not Evil.”
  • Microsoft(!) has a license called the Microsoft Public License.

Other lists of licenses

Which licenses does the Blue Oak Council like?

Ever helpful, the Blue Oak Council website has a list of permissive licenses, which they rated from Gold to Lead, including a few I listed above.

Among established licenses, they like BSD-2-Clause Plus Patent License (also known as BSD-2-Clause-Patent). I also got the sense that Apache License 2.0 was well-liked by them.

But in their survey, the Council decided to write their own license, which they named the Blue Oak Model License 1.0.0.

Let’s take a look at that one.

The Blue Oak Model License, a permissive license published in 2019

As Blue Oak Council notes:

The Council didn’t set out to write a model license. While preparing the first version of the permissive license list, members ended up trading notes about the features of a good permissive license they were using to judge existing terms. No existing license boasted all of those features. Rather than simply list them out, the Council found it easier just to write out a new, model license showing what’s possible.

What’s good about the Blue Oak Model License 1.0.0? The project creators explained their reasoning in a post. Some notes from my non-legal mind:

  • To me it seems like the authors were concerned about how, with most existing permissive licenses, “patent owners [may be able to] sue users and distributors of open software.” I think the worry that the Blue Oak Model License authors are attempting to squash here is that if software user A files a patent that involves the software, user B might be in legal trouble.
  • Their license also clearly states that “No contributor can revoke this license,” which I presume is (or may be) an issue with licenses that don’t explicitly state this.
  • And of course, there’s a “No Liability” section to protect me from the consequences, especially the projects that COULD, theoretically, be used for illegal activities.

All good, smart ideas, as far as I can tell.

Finding more new-to-me licenses

I found more licenses by the executive director of the Blue Oak Council, Kyle Mitchell, listed in one of his blog posts. As you’d expect, Blue Oak Model License is listed, but there are many other interesting ones. I made note of the Big Time Public License and the Prosperity License in particular.

Obligatory note on license compatibility

One potential issue with using a new or just less-than-popular license is that, even if the license you choose is pretty permissive, it may not legally jibe well with the licenses of other software that developers may use in tandem with your code in their project. This is a big point in favor of sticking with the older, much more common licenses like MIT or Apache. But to me that is just not as fun as finding and using the hot new thing.

For what it’s worth, the Blue Oak Model License authors address this:

The Council doesn’t see any reason why software licensed under the Blue Oak Model License 1.0.0 can’t be used, combined, and distributed with software under GPLv2, LGPLv2.1, GPLv3, LGPLv3, or AGPLv3.

Some have argued that GPLv2 and Apache 2.0 are incompatible, because if a patent claim was brought against the software, Apache 2.0’s patent grant would terminate, leaving the recipient with fewer rights than required by GPLv2. Without commenting on the accuracy of this analysis, the Council notes that the Blue Oak Model License doesn’t have patent termination, so this hypothetical conflict cannot occur between the Model License and the GPL.

which is reassuring!

Other reasonable advice: Stick with your community’s license

GitHub’s Choose a License website reminds developers to consider what licenses your related projects use when selecting a license, which seems like solid advice. For example, it notes that “Rust crates are overwhelmingly licensed under both MIT and Apache License 2.0.” This is part of the reason I initially chose MIT for Tidy and most of my other Rust projects (though in hindsight I could have dual-licensed with MIT and Apache v2). It’s also the reason I chose the BSD-3-Clause license for a project of mine that works with and depends on age file encryption.

Changing the license of an existing project

Can a developer change the license of an existing project? Mitchell addresses that question specifically in a more recent post. I won’t attempt to summarize, but it sounds like a “Yes, with these notes” on things like “license revocation.”

I think the risk one takes in straight up “revoking” an existing license and plopping a new one into your code repository is that you theoretically could be sued by past contributors to the project. Thus, I think for my projects to which I am the sole contributor (hopefully not counting GitHub’s Dependabot?!), I could just switch to Blue Oak or GPL v3 or whatever I want, whenever I want since I’d only be violating my own rights (and I won’t sue myself).

A more real-world example

What about a project that already has a number of contributors?

A Fedi friend pointed me to an open-source project that is currently in the process of changing its license from from GPL 2.0 to BSD-3-Clause. This “process” appears to be being organized as a GitHub issue, in which a contributor states the reasons for the proposed change. They then write “Since this change would affect past contributors, I need to ask for their agreement. I will ping them below in case they’d like to discuss this” and tag about two dozen fellow GitHub users (presumably all other contributors to the project).

This makes sense to me, but one question I still have about this situation is: let’s say you get all past contributors to agree to a license change. I’m assuming what they’re effectively agreeing to is something like “Are you OK with future versions of this project, which will include your past contributions, to be licensed in this new way?” My question is: Can future versions of the project be solely available under the new license (BSD-3 in this case), or will they have to be dual licensed? Or is that what this Github issue is seeking to prevent by getting buy-in from past contributors? Lastly, will older versions of the project still be available under the previous license (assuming yes)?

Slapping the Blue Oak Model License on a few of my projects that did not have an explicit license specified

I did find a few of my public Github repositories that did not have a license on them at all, which feels like a loophole when worrying about whether you can change the license of a project. These included:

Since none of these had licenses as of a few hours ago, I figured they’d be excellent candidates for me to (safely) use the Blue Oak Model License 1.0.0. So I did it! Neat!

What about Tidy’s license?

Hey, remember by 25-star project, Tidy?

After all of this research, I’ve found myself a bit slower to change the license on my most popular project, Tidy. I want to be sure I’m doing things more by-the-book with what is likely my most-used project (not counting my Vim colorscheme).

Plus, Tidy just got its first contribution by a human other than me just this past weekend, while licensed under MIT! Thankfully, I interact with this contributor on Mastodon often, so I could get in contact with him, but I’m not even sure how to get his legal permission to change the license of his contribution retroactively. I think I could add something called a contributor license agreement to the project, but I’m guessing that would only apply to future contributions?

As usual, feel free to mention or DM me on Mastodon if you know of a license you like, or spotted an error in this post.

Epilogue: Some movement on the copyleft side?

I wrote above that there doesn’t seem to be much innovation in the copyleft space. (I think this is because license compatibility between 2 different copyleft licenses is usually a gnarly mess.) It seems I may have been wrong!

Another Fediverse friend points me to a copyleft license (confusingly) called copyleft-next (GitHub repo where they take contributions). The creators describe it as “a new, post-post-modern, non-weak copyleft license inspired by, though different from, the GNU GPL.” It was apparently first published in 2012, but it seems to be on the cusp of a “re-launch”.

Here’s a recent article about one of the people behind it that provides some great and useful historical context on software and software licensing that I won’t try to quote here. Instead, the exciting news about the near future:

Kuhn has decided to help relaunch the copyleft-next project that was started by Richard Fontana a little over ten years ago. The project is going to try to write a copyleft license in an open and transparent way; “write a free-software license the way we write free software”. That is really how it should be done.

I’m rooting for the project, but I will say I don’t love the name!

Semi-relatedly, developer Drew DeVault has written a blog post criticizing the Free Software Foundation.

The GPL family of licenses are essential for our movement, but few people understand its dense and esoteric language, despite the 16,000-word FAQ which supplements it. And hip new software isn’t using copyleft: over 1 million npm packages use a permissive license while fewer than 20,000 use the GPL; cargo sports a half-million permissive packages and another 20,000 or so GPL’d.

He also explicitly calls for the creation of new copyleft licenses:

Develop new copyleft licenses. The GPL family of licenses has served us well, but we need to do better. The best copyleft license today is the MPL, whose terse form and accessible language outperforms the GPL in many respects. However, it does not provide a comprehensive answer to the needs of copyleft, and new licenses are required to fill other niches in the market…

Partially on DeVault’s recommendation, I looked a bit more into the Mozilla Public License 2.0 and it seems really intuitive. It seems like it applies copyleft restrictions by file rather than the entire project.