Network Services Aren't Free or Nonfree; They Raise Other Issues

by Richard Stallman

For programs, we make a distinction between free and nonfree (proprietary). More precisely, this distinction applies to a program that you have a copy of: either you have the four freedoms for your copy or you don't. If you don't, that program does a specific kind of injustice to you, simply because it is nonfree.

The copyright holders of a nonfree program can cure that injustice in a simple, clear way: release the same source code under a free software license. Convincing them to do this may be difficult, but the action itself is straightforward.

An activity (such as a service) doesn't exist in the form of copies, so it's not possible for a user to have a copy of it, let alone make more copies. Lacking a copy to modify, the user can't modify it either. As a result, the four freedoms that define free software don't make sense for services. It is meaningless to say that the service is “nonfree,” or that it is “free.” That distinction makes no sense, for services.

That does not mean that the service treats users justly. Quite the contrary—many services do wrong to their users, in various ways, and we call them “dis-services”—but there is no simple universal fix for this, comparable to that for a nonfree program (to release it as free software so users can run and control their copies and their versions).

To use a culinary analogy, my way of cooking can't be a copy of your way of cooking, not even if I learned to cook by watching you. I might have and use a copy of the recipe you use to do your cooking, because a recipe, like a program, is a work and exists in copies, but your recipe is not the same as your way of cooking. (And neither of those is the same as the food produced by your cooking.)

With today's technology, services are often implemented by running programs on computers, but that is not the only way to implement them. (In fact, there are network services that are implemented by asking human beings to enter responses to questions.) In any case, the implementation is not visible to users of the service, so it has no direct effect on them.

A network service can raise issues of free vs nonfree software for its users through the client software needed to use it. If the service requires using a nonfree client program, use of the service requires ceding your freedom to that program. With many web services, the nonfree software is JavaScript code silently installed in the user's browser. The GNU LibreJS program makes it easier to refuse to run this nonfree JavaScript code. But the issue of the client software is logically separate from the service as such.

There is one case where a service is directly comparable to a program: when using the service is equivalent to having a copy of a hypothetical program and running it yourself. In this case, we call it Service as a Software Substitute, or SaaSS (we coined that to be less vague and general than “Software as a Service”), and such a service is always a bad thing. The job it does is the users' own computing, and the users ought to have full control over that. The way for users to have control over their own computing is to do it by running their own copies of a free program. Using someone else's server to do that computing implies losing control of it.

SaaSS is equivalent to using a nonfree program with surveillance features and a universal back door, so you should reject it and replace it with a free program that does the same job.

However, most services' principal functions are communicating or publishing information; they are nothing like running any program yourself, so they are not SaaSS. They could not be replaced by your copy of a program, either; a program running in your own computers, used solely by you and isolated from others, is not communicating with anyone else.

A non-SaaSS service can mistreat users by doing something specific and unjust to the user. For instance, it could misuse the data users send it, or collect too much data (surveillance). It could be designed to mislead or cheat users (for instance, with “dark patterns”). It could impose antisocial or unjust usage conditions. The Franklin Street Statement made a stab at addressing these issues, but we don't have full understanding of them as yet. What's clear is that the issues about a service are different from the issues about a program. Thus, for clarity's sake, it is better not to apply the terms “free” and “nonfree” to a service.

Let's suppose a service is implemented using software: the server operator has copies of many programs, and runs them to implement the service. These copies may be free software or not. If the operator developed them and uses them without distributing copies, they are free in a trivial sense since every user (there's only one) has the four freedoms.

If some of them are nonfree, that usually doesn't directly affect users of the service. They are not running those programs; the service operator is running them. In a special situation, these programs can indirectly affect the users of the service: if the service holds private information, users might be concerned that nonfree programs on the server might have back doors allowing someone else to see their data. In effect, nonfree programs on the server require users to trust those programs' developers as well as the service operator. How significant this is in practice depends on the details, including what jobs the nonfree programs do.

However, the one party that is certainly mistreated by the nonfree programs implementing the service is the server operator herself. We don't condemn the server operator for being at the mercy of nonfree software, and we certainly don't boycott her for this. Rather, we are concerned for her freedom, as with any user of nonfree software. Given an opportunity, we try to explain how it curtails her freedom, hoping she will switch to free software.

Conversely, if the service operator runs GNU/Linux or other free software, that's not a virtue that affects you, but rather a benefit for her. We don't praise or thank her for this; rather we felicitate her for making the wise choice.

If she has developed some software for the service, and released it as free software, that's the point at which we have a reason to thank her. We suggest releasing these programs under the GNU Affero GPL, since evidently they are useful on servers.

Why the Affero GPL?

Thus, we don't have a rule that free systems shouldn't use (or shouldn't depend on) services (or sites) implemented with nonfree software. However, they should not depend on, suggest or encourage use of services which are SaaSS; use of SaaSS needs to be replaced by use of free software. All else being equal, it is good to favor those service providers who contribute to the community by releasing useful free software, and good to favor peer-to-peer communication over server-based centralized communication, for activities that don't inherently require a central hub.