Thoughts on Software Licenses

25 October 2024 · Adam Fontenot

---

I’ve been thinking about software licensing (again). I propose that we can fruitfully view the diversity of free licenses as trying to negotiate the complex relationship between the public domain (shared culture) and the private domain (profit-driven intellectual property under capitalism). Let me explain what that looks like and offer some remarks on how successful existing licenses have been at solving the problems that arise.

Traditionally, newly created works exist entirely in the private domain, meaning that only the author has the right to use, distribute, or commercially exploit them. Many creators want their works to exist in the public domain. You can do this (in many jurisdictions) with a public domain declaration, or a “license” that does the same like the Unlicense.

Permissive (or “lax”) licenses try to do something similar, while retaining the author’s copyright over the work. People who choose permissive licenses often want to provide their users with unlimited freedom to use the work as they see fit — but lax licenses already impose some restrictions on what you can do with the software.

Take the BSD 3-Clause license. Any redistribution of the software has to be accompanied by a copy of the license. You don’t have to do that with works in the public domain!

The Apache 2.0 license, despite being “permissive”, contains additional limitations on what you can do as a licensee of the software. In particular, if you file a lawsuit and claim that some part of the software uses your patented technology, your right to use the software automatically terminates. This provision is clearly punitive, and it limits who is allowed to use the software.

I highlight this because traditional breakdowns of software licenses like that promoted by the Free Software Foundation have attempted to enshrine certain user freedoms as “essential” and others as “inessential”. For example, it’s supposed to be essential to have access to the source code and permission to modify it. It’s not considered essential to receive these rights for free (gratis). So while your right to use and modify the software is guaranteed, you might in practice only be able to exercise that right if you are wealthy and can afford to pay for the software. If you suspect that this way of thinking about freedom is closely tied to a classical liberal conception of natural rights, you would be correct.

The most essential freedom, on this conception, is the freedom to run the software. This is widely understood to bar prohibitions on who is allowed to use the software. For example, your license can’t prohibit felons from using the software, nor can it prohibit its use by police and military. I would argue that the anti-patent provisions of the Apache 2.0 license do constitute a restriction on who may use the software. Now, one can certainly argue that this restriction is justified; after all, the would-be licensee is attempting to limit the rights of other people to use the program, but a justified restriction is still a restriction!

Consider Signal as an example. Suppose that Signal’s software license prohibited users of the software from promoting, enacting, or enforcing legislation that disallows any member of the public from using uninterceptable encrypted communications. In this case the limitation on who can use the software would be precisely keyed to ensuring that all users of the software have their right to use the software protected. Yet I think the Free Software Foundation, as well as many advocates of free software, would call this an unacceptable abridgment of an “essential freedom”. Similarly, I think the authors of the Anti-Capitalist Software License would argue that police impinge on the rights of others — including their rights to use the software.

This is ultimately why I think a new lens on software licenses is needed. Traditional views have relied on an unprincipled division of user freedoms into essential and inessential categories, and require subjective judgments to be made about when abridgments of these freedoms can be instrumentally justified, all while these decisions are usually framed as logical consequences of certain core principles. These principles exist within an ideological context that makes their judgments appear to pick out natural categories of “rights”, even though any such determination is ultimately subjective.

Let us consider, then, the relationship that software placed under the Apache 2.0 license (versus the Unlicense) has to both public and private domains.

As I have said, the natural state of software under a liberal system of private property is for all rights to be reserved to the author. The public domain exists for the private as a sphere of natural resources it may exploit. For example, the Winnie-the-Pooh book entered the public domain in 2022, and as a result you can now make a feature film containing the character without the permission of the author or his heirs.

Notice that in 2022, new Winnie-the-Pooh content did not start automatically becoming free culture. New works containing the character are once again the exclusive property of an individual or profit-seeking entity, until the term of copyright ends. This typifies the relationship of public and private; the private can use the public however it likes, while the public has no rights whatsoever over the private.

People who choose to license their software with permissive terms under the BSD 3-Clause or MIT / Expat licenses may have no objection to the status quo, or they may on the other hand have principled objections to using copyright provisions as a means to undermining the copyright system.

The Apache 2.0 license’s additional provisions are more complicated, as I’ve said. It recognizes a concrete practical problem for authors of free software: resources flow from the public domain to the private, but what flows in the other direction is not nothing, but threats of, and actual, litigation.¹ The punitive termination of the license when a patent lawsuit is filed disincentivizes behavior by private actors that tends to imperil the creators of free cultural works.

So we might view the Apache 2.0 license as partially stemming the flow of harm from the private domain to the public. Another way this can happen, common even to “non-licenses” like the Unlicense, is by providing a disclaimer of warranty. In some jurisdictions, if you distribute software for others to use, and say that the software can do X, Y, and Z, you have thereby given an implied warranty for the software to do X, Y, and Z, opening yourself up to lawsuits if the software doesn’t function as intended or has some unexpected harmful side effect. For this reason, virtually every free software license or public domain declaration explicitly disclaims the provision of a warranty. The GPL 3.0 reads, for instance:

This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

For software to have the value it does as a free cultural work, its creator needs to avoid being liable for its performance, unless of course they opt to be.

The primary distinction between permissive and copyleft licenses, on this view, is in how they treat the other direction: the flow of resources from the public sphere to the private. Permissive licenses accept the existing status of the public domain in capitalist modes of production (even though some people who use the license oppose it). A copyleft license is one that attempts to limit - to varying extents - the unidirectional appropriation of public assets, while retaining - as far as possible - the freedoms associated with work in the public domain.

The first important shift involved in this reconceptualization is that it sees permissive and copyleft licenses as different approaches to the same problem, rather than opposed philosophies on what users ought to be allowed to do. Permissive licenses, like copyleft licenses, are responses to the difficulties of creating work on behalf of the public under conditions of (intellectual) private property. Some of these licenses only disclaim liability that otherwise would fall to their creators. Others, like the Apache 2.0 license, attempt to limit the damage that intellectual property regimes can do.

From this perspective, the feature that unites copyleft licenses is that they attempt to use the legal rights granted to authors under the copyright system to enforce reciprocity after the work is given to the public. The world of private enterprise can make use of the work as before, but modified versions of copyleft work must be placed under the same license, ensuring that it remains “free”. In this way, it tackles an issue with the relationship between public and private that permissive licenses do not: the unidirectional flow of resources from public to private becomes, ideally, bidirectional.

One major difference between copyleft licenses is the question of virality. The Mozilla Public License 2.0 is a non-viral copyleft license; any changes you make to a work covered by the license must also be licensed by you to others under the same terms, but other derived (or “combined”) works do not have to be released under those terms. As I read the license, you could take the browser engine from Firefox and embed it in your e-reader software. You could then sell the e-reader software as a closed source product, and only changes you made to the browser engine would need to be released under the MPL 2.0.

The famously viral GNU General Public License (GPL) would not allow this, because the terms of the license must be applied to any derived work. The approaches differ in terms of what forms of non-reciprocity they intend to prohibit. The MPL 2.0 protects the work itself from non-reciprocal licensing, while the GPL is much more aggressive in that it attempts to keep anything it touches available as free culture.

The GPL license² is not automatically better just because it defends the public domain in a more assertive fashion. The extreme form of such a license would be a non-commercial copyleft license, but most people think this is a bad idea. Even if you believe that any commercial exploitation of software is a bad thing (maybe because you’re a communist, but you could also just have a strong aversion to intellectual property), a non-commercial license is not necessarily the best way to achieve your goals. For one thing, your license’s overenthusiastic effort to protect free culture would eliminate many of the important freedoms we associate with it. If you have written a word processor, for example, prohibiting commercial use of the software would hinder others in their efforts to thrive by earning a living.

Even prohibiting sale (as opposed to use) of the software would likely do more harm than good. This would prevent people selling hardware from including your software on the device, even if they derive no direct benefit from using your software as opposed to some other software; as there is no plausible way to make hardware free in the near future, this could detrimentally impact the value your software has to users. In general, as Christine Lemmer-Webber points out, the point of a free software license should be to solve problems with the licensing of software, not to solve every other problem in the world.

In my view, questions like “should a free software license require derived works to use reciprocal licensing?” cannot be answered with a suite of ideological principles, but instead must be considered in the pragmatic light of balancing the freedom provided to users with the need for enforcing reciprocity.

How effective have copyleft licenses been at creating a protected domain of works available for use and modification by the public? Here it’s important to point out that you can’t measure the effectiveness of a license purely by the success of the projects using that license. There are countless open source projects using permissive licenses that aren’t being heavily exploited in a unilateral way by industry, and have a diverse set of active contributors, but this doesn’t mean that the problems that copyleft licenses solve aren’t real. Likewise, the success of projects using the GPL doesn’t show that there are not software licensing problems that the GPL doesn’t solve.

Take the “System as a Service” (SaaS) problem. You can take a GPLv3 licensed project, make substantial changes to it like adding a new feature, but then gate access to the project behind a web based service that you offer on a subscription basis. The terms of the GPLv3 say that you are not obligated to share your modified copy of the software with anyone, even the paying users.

Or consider Tivoization. DVR company TiVo distributed software derived from copyleft works along with their hardware devices; they provided users with the corresponding source to this software as required by the license, but the devices themselves had hardware restrictions applied to them which prevented users from actually running modified software, meaning their right to modification under version 2 of the GPL was obstructed by the hardware.

In both cases, the FSF promoted new licenses intended to fix the problems. Version 3 of the GPL prohibits Tivoization in most cases. The “Affero” GPL requires anyone running the software over a network to provide a copy of the source code to any client using the software.³

There are other problems, however, that no FSF-approved license has solved. Take the issue I give the unwieldy name Red-Hat-ification. This is when you sell copies of copyleft software, and provide the source under the required license to purchasers, but threaten reprisals to any customer who exercises their rights under the license, such as sharing the source with others. In theory these threats could be of any nature; Red Hat’s usual approach is to predicate the continuation of the customer’s contract on their non-assertion of their rights. This is an effective threat because most businesses rely on ongoing support and updates for the programs they use.

In an extremely thorough and insightful analysis of the issue at the Software Freedom Conservancy blog, Bradley Kuhn writes this:

Red Hat’s lawyers clearly take the position that this business model complies with the GPL (though we aren’t so sure), on grounds that that nothing in the GPL agreements requires an entity keep a business relationship with any other entity. They have further argued that such business relationships can be terminated based on any behaviors — including exercising rights guaranteed by the GPL agreements. Whether that analysis is correct is a matter of intense debate, and likely only a court case that disputed this particular issue would yield a definitive answer on whether that disagreeable behavior is permitted (or not) under the GPL agreements. Debates continue, even today, in copyleft expert circles, whether this model itself violates GPL. There is, however, no doubt that this provision is not in the spirit of the GPL agreements. The RHEL business model is unfriendly, captious, capricious, and cringe-worthy.

Furthermore, this RHEL business model remains, to our knowledge, rather unique in the software industry. IBM’s Red Hat definitely deserves credit for so carefully constructing their business model such that it has spent most of the last two decades in murky territory of “probably not violating the GPL”.

So Kuhn’s view is that Red Hat may be within the letter of the law, but they’re not in the spirit. My reaction is “aren’t they?” It’s a very libertarian position. The GPL provides the right to sell modified copies of the program to whomever you like. It also deliberately and specifically refrains from requiring you to give copies of the source code to anyone you did not distribute the software to. Doesn’t that sound intentionally set up to give you broad discretion on who you provide with the source code? What’s the problem with only selling your changes to users who have adhered by your previous requests to not share copies with people who haven’t paid?

However, I do feel what Kuhn feels here. He calls Red Hat’s behavior “cringe-worthy”, and I agree that something seems amiss. Thinking about this issue was another cause of my reconsideration of the “four freedoms” approach. On that view it’s not just hard to understand Red-Hat-ification, it even seems like it would be wrong to prohibit it!

I think that if you’ve digested my analysis of the public-private dichotomy to this point, you will already anticipate how this approach will make sense of the problem. On this view, the primary motivation of a developer for choosing a copyleft license over a permissive one is the protection it provides against their work being sucked into, and becoming stuck in, the private domain, by resisting the unidirectional flow of assets from public to private. Yet this is exactly what has happened when Red Hat uses contract law to prohibit the sharing of derived works.

Red-Hat-ification feels bad because it’s a company complying by the terms of a license in a way that avoids doing what most of us using the license want it to do. We want a vibrant domain of public works unconstrained by intellectual property law, and we choose copyleft licenses because those seem like the licenses most likely to ensure this happens. That’s the culture of free software development. When everyone involved wants to use, promote, and collaboratively build free software, we understandably tend to view legal documents like the GPL as incorporating those cultural norms. So when a company like Red Hat abides by the GPL while violating the norms, we feel that their actions are not in the spirit of the GPL.

So that’s the problem with the GPL, as I see it. It was constructed on the basis of a flawed philosophical model, and as a result it often fails to do what we want it to do. I think that if we start in the right place, then coming up with license provisions that make sense and protect free culture in the way we want is possible, even if in doing so we have to depart from “free software” as the FSF defines it.

Consider the following hypothetical license provision:

If you modify the work, and sell modified copies or sell access to modified copies as a service, you must make the corresponding source available, (a) by distributing a copy of the source or an offer to receive a copy with the work, (b) by honoring a written request for the source from any holder of copyright in the work, and (c) additionally, if the modified work is sold or promoted for sale on a publicly accessible web site, by prominently displaying the option to download the corresponding source from a network server to all members of the public.

Are these reasonable terms? Would they solve the issues I’ve identified with the GPL? Would they survive legal scrutiny?

I’m no lawyer and make no claim to answer these questions. My point isn’t that someone should write a license and include exactly these terms in it, it’s that by starting out with a clear vision for what we want the license to accomplish we’re more likely to write terms that achieve it.

Let’s consider whether a license with these terms included would be free software, under the definition promoted by the FSF. Their second “essential” freedom is “the freedom to redistribute copies so you can help others”. They further clarify:

Certain kinds of rules about the manner of distributing free software are acceptable, when they don’t conflict with the central freedoms. For example, copyleft (very simply stated) is the rule that when redistributing the program, you cannot add restrictions to deny other people the central freedoms. This rule does not conflict with the central freedoms; rather it protects them.

“Protects” does too much heavy lifting here. One might argue that charging for a copy of software that you received for free is an added restriction that denies (some) other people the right to exercise freedom 0, running the software. On the contrary, the FSF says that if you prohibit others from selling your software, you are violating their rights rather than protecting a central freedom.

One might also go the opposite direction, and argue that a requirement to share derived works under the same license denies users the central freedom of redistributing the work as they see fit, but the FSF promotes using licenses that do exactly this.

Similarly, you might argue that freedom 0, “the freedom to run the program as you wish, for any purpose”, includes the freedom to provide services over a network to others. In that case, the AGPL would be a non-free license because it requires you to make the source of the program available to networked users. On the other hand, you could argue that prohibiting this is justified in the interest of ensuring the program’s users have access to the code, and the FSF takes this side.

Take my proposal, then. You might argue that requiring anyone who offers your work for sale to make a copy of the source publicly available (with some caveats) protects the central freedoms by ensuring that everyone benefits from the right to run, study, modify, and redistribute the software. Or you might argue that this requirement impinges on the (implied) freedom to commercially exploit the software, and this is the side that the FSF itself in fact takes.

My point is not that the terms are or are not compatible with the definition; it’s that the meaning of free software on this definition is indeterminate. The actual rules which determine whether a license is “free” are a combination of tradition and the unstated ideological assumptions of the Free Software Foundation. This problem bleeds into similar efforts to define free and open source software. I believe software licensed with the terms I suggested is clearly “open source software” by the OSI’s definition, but Debian disagrees.⁴

We can escape these dilemmas by starting from a clean slate and reasoning about what a license for free software ought to try to achieve. Lemmer-Webber offers a pithy take on what this is:

the role of FOSS licenses is to undo the damage that copyright, patents, and related intellectual-restriction laws have done when applied to software

I think this is basically right, although I think my framing of public and private domains gets at something important: the “damage” that intellectual property has done is the creation of an asymmetric relationship between the two. Without free software, and therefore without free software licenses, we would lack a commons. We write licenses for the purpose of establishing and protecting one. As I see it, the point of copyleft is to place a work in the commons in such a way that it cannot be plucked out again and reprivatized. We ought to be unabashed in cashing out this goal in the terms of our licenses.

It’s crucial to emphasize that there are lots of good reasons not to insert the terms I propose into a license and start using it today. The primary one is compatibility: any new copyleft license incompatible with the GPL creates a division in the free cultural pools, limiting the ways that works can be combined.

The second is that acceptance by the community is extremely doubtful, due largely to the traditions I’ve talked about. Many people won’t contribute to your project if they don’t accept it as F/LOSS. Others will refuse to include it in software distributions like Debian. This could perhaps be changed, but it would take a lot of time and public discussion before finalizing a license text.

Last, there are perhaps not that many cases where additional restrictions would be useful. If you write system software and don’t want your code sucked into Red Hat to never be seen again, maybe it matters, but even that (if it happens) probably has little impact on you. In reality, a bunch of projects get by fine without even copyleft. So long as you have a healthy pattern of contributions, it may not be worth worrying about corporations embedding your code in their products. Permissive licensed software also has the broadest compatibility with other projects; if I introduce a new license with additional requirements on top of the GPL or MPL, I lose the ability to combine works distributed with those licenses with mine. Any permissively licensed work would remain compatible, and this is a strong point in its favor.

More generally, I’d like to hear from readers as to what they think of the proposal, and whether they’d consider using software released under such a license. Please feel free to contact me by email or on Mastodon.