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

Programs and services are different kinds of entities. A program is a work that you can execute; a service is an activity that you might interact with.

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.

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. As a result, the four freedoms that define free software don't make sense for services.

To use a culinary analogy, my cooking can't be a copy of your 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 the recipe is not the same as the cooking. (And neither of those is the same as the food produced by the 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 Software as a Service (SaaS), or Service as a Software Substitute (SaaSS — this term explains more clearly what the issue is), 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, is not enough by itself to communicate with other people.

Non-SaaSS services can mistreat their users in other ways. Issues about a service can include whether it misuses the data you send it, and whether it collects other data (surveillance). The Franklin Street Statement made a stab at addressing these issues, but we don't have a firm position on 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.