Control

... in which we discuss software freedom, Open Source, Free Software, and what the actual point of these is.

Once upon a time, Android used to have the same gumdrop emojis as the rest of Google: the ones on the top.

They eventually decided to swap them out for the ones on the bottom. Of course, this had a group of people, me included, very upset; emojis, after all, are Important, and I really liked these ones. At the same time, another group was probably very happy about finally getting rid of them. Which group you belong to is fairly irrelevant though; the point is: this just happened.

I was upset enough that I did figure out that there actually was a way of swapping them back. You only had to:

• use adb to get a shell on the device
• root it if you haven't already
• switch off the file system integrity check
• remount the root file system as read only
• replace a TTF file somewhere with the one you copied from an older device, still having the preferred emojis.

I did it nevertheless. My favorite emojis were back; happiness ensued.

And then they sent out a software update. Everything was back to the uglier, newer ones. Ohh darn. Let's do this again.

Of course, you do end up writing a shell script for this eventually. Which I did. But... by the time the next update arrived, I didn't really remember where I saved it. Also, you have to have the font file, too. Along with, if I remember correctly, a device restart after the "integrity check" part, which also resulted in mildly unpleasant feelings about making the system less secure this way.

After a couple occasions, I just gave up.

What does all this have to do with software freedom?

Android is Open Source. You can download the source code (all 300 gigs when I last checked), compile it; if you're lucky enough that some people build custom images for your phone, you can have those, too.

Actually, to swap out those emojis, you don't even need to do any of this. It's just about copying a file onto a file system. Can be done in a minute if you know what you're doing.

And yet... just to recall the 1st one of the Four Freedoms:

"The freedom to study how the program works, and change it so it does your computing as you wish (freedom 1). Access to the source code is a precondition for this."

I do think that "I want to swap out emojis" is a relatively milder case of "changing how the software works". One where you don't even really need to recompile anything. Optimally, you'd have an actual configuration option for this. And yet, for practical purposes, swapping out emojis on Android is hard. In fact, you had a lot more control over emojis in MSN messenger, in the early 2000s, even though it definitely wasn't open source.

And here comes the main point of the entire article:

Openness of source is only one factor in how much control you have over what the software does.

The FSF has historically put a lot of emphasis for source code availability. All else unchanged, it's of course easier to change software if you do have access to the source. But... it's not an all-or-nothing "Open Source vs. Proprietary Evil" comparison. There are levels. (... which, incidentally, the term "Free Software" is a lot more ready to cover than "Open Source".)

Methods of control

Obviously, you can make things closed source. However, this will not prevent people from customizing your OS... for example, this is Windows:

Of course, you could go for heavier-handed methods like "secure" bootloaders. If you give users a device that they can't actually get their code onto, you might just as well make your code open source; the majority of your users won't change it, ever. (This is one of the questions that GPLv3 addressed.)

However, all of this still focuses on the theoretical changeability of the code. We should focus instead on the practical side: what does it take to actually change things?

What I'm talking about is: if you add an option to use a custom font for emojis, some users will change it. If you don't add an option, some of those users will still change it, but some of them won't. The harder the change, the more you can actually control their behavior.

If your build instructions are 30 pages long and the smallest possible compilable unit you have is "the entire operating system", users will have a lot less power over the outcome. Meanwhile, an excellent counterexample is Emacs: although there are some parts of it written in C, it basically has a builtin build environment for the Emacs Lisp code it mostly consists of, so "recompiling" part of it is trivial (there is a reason why people's ".emacs" files are growing bigger and bigger: they're essentially patching the code base).

A similarly effective method is by making the code base really large, complex and unstable, so that anyone willing to fork it would need to keep up with the work of the hundreds of software engineers you have working on it. Many companies who like "Open Source" but object to "Free Software" do this: most of the development happens in-house. Of course, as a single user or a small group, you'd have to put in a lot of work maintaining your set of patches against this moving target.

This is where closed-source software with a reasonable, well-designed plugin architecture can outperform a random-pile-of-code open source project, in terms of actual "freedom over what the software actually does". Note that being closed source is not a requirement... but... it at least forces you to have a relatively comprehensive API.

Conclusions

The common argument for source availability in terms of benefits to end users is as follows: sure, typical users won't look at the source, but someone will, and then that someone can share modifications with everyone.

However, there isn't enough appreciation of how easy or hard this is to do in practice.

(The fact that suckless projects explicitly put configuration into the source code to keep focus on experienced users is saying something about how easy it is to recompile software.)

Making things configurable helps. (Editing a text file is a lot easier than recompiling something... even though it really shouldn't be.) For open source OSes, it's also a question of packaging: switching from a binary package to a debuggable source form should really be just one command away. But all these should follow from the difference in mindset: it's not about whether someone could control what the code does, it's about whether people really will.

... comments welcome, either in email or on the (eventual) Mastodon post on Fosstodon.