This Time Self-Hosted
dark mode light mode Search

Intentionally Permissive Licensing

A few months ago, when talking about licensing preferences between permissive and copyleft, a zealot decided to argue with me that I shouldn’t use permissive licenses for my software ever. Said character got obviously blocked, because I don’t have time for that, but I thought the topic deserves a little more nuanced coverage, particularly given I care — and be warned, this is a topic that is dear enough to me that I wrote about this extensively for the past 20 years, so you will find me referencing a number of old posts.

Before I proceed, I want to make something clear here: I am a supporter of the Free Software movement, and I have dedicated my own time and resources for many years for the development and betterment of Free Software. Which is not to say I haven’t been at time labeled an “enemy of Free Software” for evaluating competition and discussing the lacklustre desktop progress. If you think that my criticism overrides my contributions, well, feel free. Where I do draw a line though, is if you think that there better be no software, than non-Free software. The staying goes “software is eating the world” but software is also how we got significant improvements in quality of life and life expectancy, COVID notwithstanding — and that’s why I have said before we need more Kind Software as well as Free.

With that out of the way, let’s introduce a bit what the problem I’m talking about here is: Free Software licenses (as well as Open Source, but I’m not going there now!) are generally divided in two big categories: permissive and copyleft — the latter being championed heavily by FSF, to balance the rights of the users with the rights of the authors. To oversimplify this (because I’m not a lawyer, and lawyers wrote better FAQs about this anyway), a permissive license generally allows you to receive the code for a piece of software and modify or integrate it into a larger piece of software to your liking, while a copyleft license put some level of limitations on what you can do with it in terms of distribution and integration — to the intended effect of requiring the integrated software to be licensed under a copyleft license, or at least releasing the modified software (particularly in case of libraries.)

Over the years, I have released or contributed to software under pretty much the whole gamut of Free Software. But more recently I decided to release everything I could under permissive licenses — going as far as relicensing some of my obsolete software under permissive licenses, where I held the sole copyright. This is a very conscious choice, and not one that you’ll find me budging from any time soon, but also a pragmatic choice for me personally — which is to say, I do not judge other people based on their preference for software licensing.

In my case, I have never really been a “software ideator” — even if you look at my very old projects, you’ll see that the only one that was an actual idea, rather than me attempting to implement something that already existed in a different form, was ATMOSphere. For more recent stuff, glucometerutils is likely the most creativity I put in a piece of software in a long time, and that, together with my ESPHome thermostat, fits in the particular niche of reverse engineered projects, which I’ll get back to later.

Since I’m not an ideator, or a creative, I guess I feel less of an attachment to my software, even for that I did indeed design and come up with. This, to be honest, is something I noted at work as well, and that appears to set me apart particularly from the more successful SWEs — I count it as a boon and a curse at the same time. So it might very well be that my reason for preferring permissive licenses is related to that more than anything, I thought it was fair to say.

The choice of copyleft licenses, in my experience and from my point of view, is usually suggested for one of three motivations: wanting to make a statement of support for Free Software (which has been my primary motivation early on), caring about the rights of users (the explicit motivation behind the Free Software movement), or wanting to restrict access to proprietary developers. While the effect of copyleft licenses is a sum of all three, I find that it’s usually more likely that some of it is a side effect rather than an explicit intention.

This is, after all, why the AGPLv3 came to be: its aim is to make it harder for Free Software to be hidden behind an “as a Service” curtain, which became an increasingly common tactic (thanks to widespread adoption of high speed Internet connections) for commercial operators trying to monetize software they often didn’t write or even contribute to.

Okay, there’s a fourth possible motivation for using copyleft licenses, but I have not included it above because it is the kind of motivation I dislike the most, and that is leveraging copyleft as a commercial advantage — and I’m not talking about the controversy around RedHat’s derivatives. This is something I covered years ago, but it still happens regularly, but it boils down to commercial operators building software that is designed to be integrated, or provided over the network, and releasing it to the public copylefted — but without accepting contributions (or only accepting contributions under a contributor-unfriendly CLA), so that they can sell a license to ignore the copyleft restrictions on the side, kind of like Catholic Indulgences.

Depending on your stance on that, this is either clever or evil – to me, the ability to pay off the copyleft restrictions make it look more like a demo version, not much different from those source-available licenses that are becoming all of the rage now that the dot-io bubble burst. This is not a new position for me, since I actually wrote a similar take about MySQL, 20 years ago, in Italian.

So, and speaking solely for myself here, I don’t have reasons to make statements with my licensing choice, because while I do believe in the ideals of Free Software, talking about the organizations involved leave me with enough of a bad taste in my mouth that I wouldn’t want to be associated with them, and I don’t see an alternative coming any time soon.

Lacking the need to make a statement, what remains is purely the practicality of which license to choose. And in practice, choosing a copyleft license like GPL-3 wouldn’t really make much of a difference in term of who would get to use my projects. On the other hand, if would make it ever so slightly harder for other projects with non-copyleft licenses, as well as commercial projects, from integrating my code. For some people, that is a good outcome — for me, it isn’t.

The vast majority of the projects I released, I did so because the marginal cost of me publishing the code is negligible: they often are personal itch-scratchers (such as pdfrename) which I would have written anyway — and it costs me nothing to let others learn, reuse, or remix my code. If someone wanted to build a proprietary web document management system able to extract basic RDF metadata from the PDF of a monthly bill of Vodafone Italy from five years ago, they’re more than welcome to take the code I have already published — I ask nothing in return, and they won’t be asking me anything for it because, well, there’s nothing to ask for it.

In two particular cases, I actually made sure to make my code open for proprietary users explicitly: the first is glucometerutils, and the second is my LG HVAC controller. In both cases, the projects implement protocols that I either reverse engineered myself or (in a couple of cases) were already reversed and documented by others. These are, very explicitly, cleanroom implementations, at least at the starting point when the license was chosen (glucometerutils received further contributions under the same license.) And my reason to explicitly choose a permissive license is that I believe there’s more good to be had for better diabetes management software and HVAC controller firmware — I know of at least one proprietary iOS DMS application that integrated support for new glucometers after I reverse engineered and described the protocol: even if it’s for a handful of people, my work there improved their quality of life, I’ll take that as a win.

Of course I would feel different if the projects I’m releasing would have more upfront costs for me, or if I was trying to make a living of my FLOSS work, but that is not the position I’m in. Which is why I think there’s no “one size fits all” in this case, like most other cases. And even for unpaper, the license of which I didn’t choose since I took over the project from the original author, I don’t think I would make the license more permissive, even if I could. For that particular project, if anything, my aim is to make it easier to integrate as a copyleft component instead.

Do I expect my use of permissive licenses to eventually lead to curtailing of access for users? Doubtful. If someone managed to make a better tool than mine, it’s probably better for the users even if it’s proprietary. And forking is always an option, as recent developments show. Could I leverage my projects as a forcing function to get more software released as copyleft? Also doubtful, as there’s very little if anything that can be built depending on my projects (with the possible exclusion of glucometerutils, but for which, as I said, more software, even proprietary, is likely going to be better for users!)

Anyway, once again, this is my personal take on how I choose licenses for my projects. If you happen to agree, and want to follow the same steps, I would recommend you make sure your licensing information is very clearly specified with something like REUSE so that whoever wants to learn from, copy, or remix your code doesn’t have to worry about making mistakes in judging how it is released.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.