In open source development, it’s common for the maintainers of software to adopt a conventional license for the community. In Node.js, MIT License and Apache License 2.0 (“Apache License”) are popular; in Clojure, Eclipse Public License 1.0 (“EPLv1”) is popular; in Rust, dual licensing is popular, so it’s common for MIT License and Apache License to be options. This process makes sense because it’s often in the community’s interests to maximize compatibility. I used to license my software like this, but have since adopted copyleft licenses like GNU Lesser General Public License v3.0 (“LGPLv3”) and GNU General Public License v3.0 (“GPLv3”).

A lot has been said on this topic¹², but I specifically want to cover it in the context of self-discipline. The MIT License and Apache License are considered permissive because they impose minimal conditions. This is great for users because almost anyone can use it, but can cause issues from it enabling people to subvert the open source process. For example, it’s legal for maintainers to switch from such a license to a non-open source one, against the will of other contributors and users. The most notable incident I’m aware of this happening is the Redis database switching from BSD 3-Clause “New” or “Revised” License (“BSD License”) to dual licensed under Redis Source Available License 2.0 (“RSALv2”) and Server Side Public License (“SSPL”). While the SSPL is considered copyleft, it’s not considered open source.

I consider this a reflection of the state of open source. The benefits are primarily one-way and directed at users, while maintainers are expected to foot the bill in return for an acknowledgment. I think it’s due to this disconnect in how open source works that incidents like Redis could’ve occurred. If the benefits were instead two-way, developers could expect a stronger open source process, even in the event of people being evil.

There are organizations like the Free Software Foundation that have debated open source and arrived at free software, but I think the answer is specifically copyleft as an alternative to permissive licensing. Unlike the latter, the former imposes conditions on sharing the software that affect both users and maintainers. For example, a user modifying copyleft software is required to use the same license, if not a stronger variant, while a user distributing it as part of a wider work is required to use a compatible license. The most common copyleft licenses I’m aware of are Mozilla Public License 2.0 (“MPLv2”), LGPLv3, GPLv3 and GNU Affero General Public License v3.0 (“AGPLv3”).

This solves the issue of someone creating a non-open source fork, which is what Redis eventually did by triple licensing under RSALv2, SSPL and AGPLv3, but still allows maintainers to switch to a non-open source license in the event that they relicense with permission from the copyright holders (i.e., the contributors). For projects like mpv with hundreds of contributors, this is impractical. For software developed with next to no external contributors, or whose contributors have signed a contributor license agreement (CLA), this is a real possibility. The most that can realistically be done is to pick up stewardship, which is what the Linux Foundation did with Valkey as an alternative to Redis, since previous versions continue to be available under the original license. I will note, relicensing to another open source license is not always impractical, as mpv partially relicensed from GNU General Public License v2.0 (“GPLv2”) to GNU Lesser General Public License v2.1 (“LGPLv2.1”).³⁴

Now, I won’t sit here and act like I know what it’s like to maintain a large, open source project, but what I do believe is that open source as a process requires a lot of self-discipline to be sustainable in the long run. I’ve mentioned Redis several times here, but obviously not every user base experiences such a rug-pull. In my opinion, the value of copyleft comes from balancing expectations. For users, it ensures that the project is unlikely to be compromised. For maintainers, it ensures that contributions remain open. A lot of developers will insist that licenses like GPLv3 and AGPLv3 are harmful and reduce maintainers’ prospects of mass adoption, but software is typically written for a certain audience, and open source is not about any one of us.

To close, I think it’s important to note that copyleft exists on a spectrum ranging from weak, which is limited to the licensed code itself, to strong, which extends to the work that uses it. The former permits surrounding code to keep its own license, while the latter doesn’t. Because of this, it’s generally safe for open source software to depend on other open source software, up until the point non-open source software wants to be a dependent, at which point you have to consult the license. LGPLv3, for example, has requirements on the end user being able to replace the library, which may not be practical in every environment (say, Apple platforms with code signing). You could use a weak copyleft license like MPLv2 without such a requirement, but it’s oftentimes simpler to use a permissive license as an exception to the standard. There is also the consideration that the work may be in vain due to users adopting a permissive alternative, but responding to that bleeds into free software, which is not my domain. Except for such risks, I see very few reasons for maintainers not to adopt weak copyleft licenses as a baseline.