Network Services Aren't Free or Nonfree; They Raise Other Issues
by Richard Stallman
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
browser. The GNU LibreJS program makes
of the client software is logically separate from the service as
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
— 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
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
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.