Freely giving software vs perpetuating an ideology

Hopefully I don't have to convince you how free and open-source software (FOSS) is the best kind of software. The developer benefits from potential community contribution and a low barrier to usage and adoption, while the user benefits from transparent software that can be publicly vetted. It's awesome. You can go read about it more in depth in many different corners of the internet.

All software, both proprietary or FOSS, requires a license. This is a document that spells out the terms of use, including rules the user or developer must abide by and potential protections for either. Unlicensed, public software is kind of no man's land, and in my experience generally treated as copyrighted by default and avoided for serious work.

Historically, I've used mainly two specific licenses, the MIT License (also known as the Expat License) and the GNU General Public License (GPLv3). In my mind, there is a kind of philosophical tension between the two that I want to talk about here.

Obviously, none of this is legal advice. Go read the licenses yourself and talk to a lawyer.

Look. Listen. I'm a FOSS guy. I will roll my eyes at proprietary (closed-source) software at every chance I get. While I do use it when necessary¹, it is in practice, and at a pretty fundamental level, a tool of those in power to control and manipulate the less powerful. I don't think this can really be argued against. Corporations (Google, Amazon, Tiktok, most of the rest) and governments (American, Russian, Chinese, most of the rest) do collect your data and do use it to manipulate you towards their financial or political benefit. Software being proprietary does tangibly make this easier to do and conceal.

But okay, this is not all that proprietary software is. When I sit down to really think about it, I'm not sure I can really say that it must be inherently evil or immoral. I don't think I can in good conscience fault an independent developer for trying to protect themselves and not wanting the fruits of their time and labor to be easy for just anyone to reproduce. I can respect that, but I can also disagree with the approach, and I can reserve the right not to use their software. Or, maybe it's actually just good software, and I will give it a shot. There actually are examples of beloved software that is not FOSS; e.g. recently everyone seems to love Obsidian². But a) it is by nature pretty hard to verify that this kind of software isn't doing you harm, and b) often with popularity comes power, and then… see previous paragraph.

Proprietary software as it exists today is a fairly unregulated hellscape offering very few guaranteed protections to the general population of end-users. There might exist a parallel universe where proprietary software is both regulated by stronger laws³, and regularly audited by non-partisan, democratic third parties in order to prohibit things like unwanted spyware and advertisement. Unfortunately this is not the universe we live in, nor do I have much hope that it will be any time soon. As things stand now, free and open-source software and licenses can be a pretty solid tool for fighting against the proprietary status quo that does not respect user's privacy and rights.

In theory, the most unfettered way to release software is to release it into the public domain. By doing this you say something like: "I relinquish any rights I had to this software; anyone can do with this as they wish with no restriction." There are actually some licenses that aim to facilitate just that, such as the WTFPL and the Unlicense. These are not that popular, in part because they may not be considered particularly legally rigorous, or because some domains may have no legal way of dedicating something to the public domain. I really don't know anything about this. Go talk to a lawyer.

The next best thing might be the MIT license (or something similar like BSD-3-clause). It essentially says "You have my permission to do whatever you want, as long as you include this notice and license in copies or redistribution of this software." This effectively works as an attribution clause. I think this is the most popular open-source license by quite a bit.

I really like the idea of dedicating my works to the public domain. It feels like a selfless act of giving for the common good, with no ulterior motive. Because of the possible ambiguity with public domain proper, I pretty often use the MIT license instead; it is popular, well-understood, and at least in my view has quite a similar effect. The actual license text is extremely easy to understand with little experience, so it's quite newbie friendly, and the terms are also very easy for users and other developers to accept, regardless of the intended use for the software.

The other side of that coin is that it's also very easy for big companies and governments producing proprietary software to accept. For me this is a source of uneasiness with this kind of license. Basically, "Oh no! I'm making it easier for [Big Proprietary] to take without repercussion, and without giving back.

If, like me, you believe that transparency fundamentally improves society, and that it must not only promoted but also perpetuated, you might consider a different kind of license. Copyleft or "strong" copyleft licenses aim to do exactly that. The very basic gist is something like "if you use this license in your software (that you distribute to others), your software must also use this same license." This can be a powerful tool to ensure that software is and remains free and open-source.

The GNU General Public License (GPL) is probably the most popular copyleft license. It's a slightly longer and more complicated document, so I would really recommend reading through it, especially if you use or intend to use it. Here are some of the key points around GPL-licensed software, at least in the popular interpretation of the license:

• You are free to use and modify the software locally pretty much however you want if you don't redistribute it.
• The software cannot really be used to implement DRM or restricted by it.
• You are allowed to redistribute the software or derivative works of the software, as long as the redistributed software or derivative works are also licensed under the GPL.
  • The popular understanding assumes that derivative works are not just modified versions of the software itself, but also programs that use the software as a library.
• You may distribute the software for free or for a fee, but the source code must be made easily available alongside the software at no additional charge.

The GNU Affero General Public License (AGPL) is a slightly stronger license that contains one additional clause: interaction with AGPL-licensed software or derivative work over a network also mandates that the software be licensed and redistributed under the AGPL and subject to the terms above. This covers, for example, hosted software like an email provider or a streaming service where the user doesn't run the program locally.

The (A)GPL is not as popular as more permissive licenses, but is used by large, well known projects like Linux (which uses the GPLv2, a previous version with perhaps slightly more relaxed terms) and Signal (AGPL). It has been tested in court to varying degrees. It is, in my opinion, one of the most effective ways to keep software truly free from the whims of monopolistic greed and oppressive practices. You don't have to take my word for it:

• Google says: WARNING: Code licensed under the GNU Affero General Public License (AGPL) MUST NOT be used at Google. because "The license places restrictions on software used over a network which are extremely difficult for Google to comply with."
• Apple reportedly stopped updating Bash and made the MIT-licensed Zsh the default user shell because Bash switched to version 3 of the GPL. The license is also allegedly incompatible with Apple's App Store (of course, there are other ways to distribute free and open-source software for macOS).

This is… quite remarkable. The idea that I could keep such huge players like Google or Apple away from my software with nothing more than a small piece of text is kind of mind-boggling, and makes me giddy with hope.

Now, the other side of that coin is that the license can also be harder for independent developers to accept. Some devs might not yet or at all be comfortable with the restrictions the (A)GPL imposes on their code, or they might feel more strongly about permissively licensing their software. Or they might want [Big Proprietary] to be able to use and adapt their code, for instance because wider adoption is more important to them than preserving the ideology of free software.

I don't know. Copyleft licenses like the GPL seem more "right" or perhaps "righteous" to me. They say "I release this software in a way that perpetuates and fosters a more open world." On the other hand, permissive licenses like MIT seem more "noble" or "selfless" to me. They say "I release this software to the world with truly no ulterior motive."

Keep in mind there are also licenses that are in the middle, e.g. so-called "weak" copyleft licenses like the LGPL. Or you could write your own; I can't recommend that, since people might be much more wary of custom licenses.

Recently it has been quite easy for me to fall back to the MIT license. Independently developed software is not currently my main vocation or source of income, and most of my software isn't and will never be a killer app or revolutionary program. It usually consists of small utility libraries that I just want to make as easy to use as possible.

Still, it does not escape me that I could or should be doing more to stick it to the man⁴, and the APGL is looking pretty tasty…

Okay but I'm basically done. This section and the next are just sort of exploratory. Feel free to dip out if you're not interested.

I will preface this by restating that I do not make my living, or any money at all, from open-source software. I am currently paid to develop mostly closed-source software (despite my efforts to push towards more open-source in my workplace). I'm also generally inclined to release my open-source software for free, which I acknowledge could in part come from a place of privilege (i.e. I'm comfortable enough to not need to consider it). This might make me fairly unqualified to talk about this subject.

One common question that software developers have is: "I want to release my code as open-source, but I want to make money from it! How is this possible?"

If your intent is to create software that must always be paid to use, that nobody could ever possibly make more money from than you, or that always brings back royalties, you probably don't actually want an open-source license. I don't think there's a silver bullet for this. This is generally just not how these licenses are designed. BUT WAIT PLEASE DON'T GO- You might consider some options.

So, you want to develop open-source software that someone can't just yoink from under you for profit. A very permissive license like the MIT license will probably not really help you here. For simple programs distributed to end users, the AGPL isn't a bad bet. You can still sell your pre-built program. The APGL does not forbid this. What??? I thought you said FREE software? Right. It's "free as in free speech, not free beer."

In fact, even though it's popular to do so, technically you don't even need to provide the source code for free, though you may not make additional charges for the source code on top of the charge for the built program. With the GPLv2, you can even just release a written offer to provide the source code⁵, which of course you must provide on request. You could probably even charge for each update, or you could also sell a service, like providing technical support for the software. All of this might raise some questions:

• What's to stop someone from just building and running it for themselves for free from the sources? Okay, your mom and dad and average Joe are not going to do that. If it's good software that they have a use for and it's reasonably priced, most likely they will just pay for it. You do not need to extract money from every last user.
• What if someone improves or modifies my program and re-releases it for a fee? Well, their changes would be APGL-licensed too, so you could just integrate them back in to your program.
• What's to stop a power user from buying my program, then re-releasing an identical build from my sources, for free? So yeah, they could do that I guess. I kinda got nothin' here. For popular enough software, it's entirely possible that someone might.
• What's to stop someone else from selling a service such as support for my program? Right. They could do that too. But this kind of happens already even for proprietary software, so eh.

For hosted software, it gets kind of interesting, because in theory someone with far better resources than you might be able host your software "better" (e.g. more disk space or compute power on their servers for users), modified or not, as long as they're okay with continuing to distribute the sources in accordance with the AGPL.

A few things to think about, no guarantees:

• The reason I mention the AGPL specifically is that large for-profit companies will tend to avoid it. That already reduces the surface area of "people who might mooch in bad faith" by quite a bit.
• In general, it probably helps to be the person that wrote and maintains the software. People might trust you with the software more than whoever else might distribute it downstream. Plus, maintenance can be a lot of work, so it might not be desirable for random people to do downstream. Also, if you do really good work, companies or individuals might consider sponsoring you to continue doing it, though I wouldn't hold my breath for that to happen.
• There's nothing stopping you from dual-licensing your project under the AGPL or a commercial license. That means that if your software was so awesome that [Big Proprietary] or anyone else really wanted to use it without being beholden to the terms of the AGPL, they could opt for the commercial license instead.

I don't know that I have anything else to say about this. Again, I have no experience with it, I just wanted to think it through.

First, an aside about the LGPL, briefly mentioned above. It is pretty specifically designed to not require licensing programs that use your code as a library under the same license. So the "copyleft" aspect only applies more tightly to derivative works of the library itself. This seems like a nice middle ground. The only problem is that the language of the LGPL is specifically geared to the C or C-like programming languages, which might lead to ambiguity in other contexts. I just find this kind of annoying.

My main doubt, and not-so-hot take⁶, is that the (A)GPLv3 and the LGPL may not legally be very different in the case of dynamic linking libraries, or the use of libraries that are distributed by others and loaded into memory by the user, despite the FSF's assertions to the contrary⁷. I think this applies to a large amount of external library use in software today (e.g. Python library imports), with the possible exception of static linking, where the original library object code is actually copied into the final running program.

Here's the basic argument. I believe the relevant section is 5.d) of the GPLv3, which says (ellipses my own, indicating sections cut for brevity):

You may convey a work based on the Program, or the modifications to produce it from the Program, in the form of source code under the terms of section 4, provided that you also meet all of these conditions:

…

 c) You must license the entire work, as a whole, under this License to anyone who comes into possession of a copy. This License will therefore apply, along with any applicable section 7 additional terms, to the whole of the work, and all its parts, regardless of how they are packaged. This License gives no permission to license the work in any other way, but it does not invalidate such permission if you have separately received it.

…

A work "based on" the Program was defined in an earlier section of the license text:

To “modify” a work means to copy from or adapt all or part of the work in a fashion requiring copyright permission, other than the making of an exact copy. The resulting work is called a “modified version” of the earlier work or a work “based on” the earlier work.

So, a work "based on" the Program is a work that has copied from or adapted all or part of the program. "Copied from" is fairly unambiguous, and is why I think the static linking case might be intact. "Adapt", however, is not at all defined in the document. Unless I'm missing some other text in the license, the FSF interpretation (which is probably the most widely accepted) is then claiming that using a dynamically linked library (or doing "import" from Python and using function names) is "adapting" a work. This doesn't make intuitive sense to me; I don't think the mere fact that I use a library in my program makes my program a derivative work of that library, though I might be willing to concede the point for some specific cases.

A stronger way of putting it starts by asserting that using a library dynamically is equivalent to using a programming interface or API. Basically, the program using the library is merely stating that "there exists some library that exposes an API with these functions, which I use here". It does not directly use or copy the actual implementation of that API⁸. The next question becomes: can an API be copyrighted, or subject to the terms and conditions of a license, regardless of the text?

I don't really think it should, even if it could. In my view this is pretty strongly related to the Supreme Court case Google LLC v. Oracle America, Inc., where Google copied (some of) Oracle's Java API, but with their own cleanroom implementation of the Java back end. The Supreme Court ruled in Google's favor. This case did not state that APIs cannot be copyrighted, and some of the decision was due to the specifics of the situation at hand, but in my view it did push the needle somewhat in that direction. In particular, the dissent's opinion is telling, with Justice Thomas saying:

The result of this distorting analysis is an opinion that makes it difficult to imagine any circumstance in which declaring code will remain protected by copyright.

(Here, "declaring code" is effectively referring to the API). Well, maybe so Justice Thomas. But this is a good thing. To elaborate on why I think this is a good thing, the linked Wikipedia article for this case puts it quite nicely:

If APIs became subject to copyright protection, it is believed that companies would need to implement deliberately incompatible standards to protect themselves from the risk of complex litigation. This scenario would mean moving away from the current trends in software development which have focused on improving interoperability between different services, allowing apps to communicate with one another, and creating more integrated platforms for end users.

I suppose this is not unlike some software/hardware in earlier days of computing, where the entire stack you work on may have been made up of proprietary software and interfaces, and different hardware and software was wildly incompatible at the whims of the maker. I won't lie though, that seems kinda gross.

And also:

One example identified by Wired is the Linux operating system. While Linux is fully open source, it is based on POSIX, a set of APIs that mimic those of the commercial Unix operating system that enable high levels of interoperability for developers; a programmer would only need to write one set of code which then can be compiled on any system that has the same API, even if the computing architecture of the systems are different. If case law favored Oracle, the owners of earlier versions of Unix, Micro Focus, could have sought damages from any POSIX-based operating system developer intending to use the operating system for commercial use.

Oof. That would be rough.

To further support this point, merely using a library's API is not a definitive assertion that you're using a particular implementation. In practice, there can be multiple different implementations that are linked in by the person distributing the code (e.g. package maintainers on Linux). This is a real thing: musl (MIT license) and glibc (LGPL) both provide implementations of the standard C library API, but use different licenses; unixODBC (GPL/LGPL) and iODBC (LGPL, BSD) both provide implementations of the Open Database Connectivity (ODBC) API; etc. Although, the existence of multiple, differently licensed libraries providing different implementations with the same API may kind of presuppose that APIs can't be copyrighted, which might make this a useless addition to the argument.

So, I have my doubts as to whether this use-case can be restricted by a license at all. Perhaps luckily, and to our benefit, [Big Proprietary] and many others tend to interpret the license that way anyway, so effectively the (A)GPL does offer this protection against a more proprietary world, regardless of my nitpicking.