The Free Software Foundation has defined Four Freedoms related to software. These freedoms apply to users of software, not necessarily developers. In the view of the FSF, these freedoms are ethical in nature, so much so that they argue that software which violates these freedoms is unethical.
Like many other rights, the four freedoms are specific expressions of abstract freedoms in the context of software. They represent concrete examples of underlying notions of freedom. You can see this principle if you ask “Why should I be able to run my own printing press or weblog?”
I’ve argued before that I don’t care about Google’s source code, for example, but if those underlying principles exist, then it should be possible to identify them. It should also be possible to extrapolate concrete expressions of those principles in new contexts… such as software run by vendors to provide a service to users.
The Freedom to Use
Freedom zero is The freedom to run the program, for any purpose (freedom 0).
This is the fundamental enabling freedom for the other three. The right of unrestricted use allows you to use the software as you see fit, even if the creator or copyright holder does not support that use. The underlying principle seems to be that, once you have taken possession of a work in a legal fashion, the creator of that work has no moral right to govern how you use that work.
In the case of a service, you don’t take possession of the work. You may possess the information used as input to that service (your personal information, for example), but there are likely licensing arrangements regarding your access to the service, and the output.
Apart from contractual arrangements guaranteeing access, the party providing access to the service may choose to deny your use of the service for various reasons. The service may be for paying customers only, for example, or for users known to the operators. The operators may in fact cancel your use of the service at their leisure, as well–again, according to any specific contractual terms.
Though this freedom does not apply specifically to software as a service, it is useful to consider when demarcating the ownership of data related to the service.
The Freedom to Modify
The second freedom is The freedom to study how the program works, and adapt it to your needs (freedom 1). Access to the source code is a precondition for this.
This freedom is somewhat specific to software. The fact that software as a service includes software is mostly immaterial to the function of the service. The difference between a human-edited directory of hyperlinks and an algorithmically-generated directory–apart from issues of quality of service–is irrelevant to users of the service. They make a request for information and receive information in return.
Further, even if users had access to the source code of the service under terms which allowed use and modification, there’s no reason the operators of the service must allow deployment of such modified software on their own systems. The four freedoms seem to apply most directly to systems under the direct control of the user.
However, none of this precludes a fundamental freedom: the freedom to study how a work operates. In the absence of legally-enforceable contractual conditions which govern trade secrets or other information, studying the operation of a service from the point of view of a user is an important freedom. Building on the idea of demarcation introduced in the discussion of freedom zero, users of a service should be able to access the service through his or her preferred means, not only the single blessed client provided by the operators of the service.
The freedom to study a service does not remove the right of the operators of that service to deny access to the service, if they believe that users are accessing it inappropriately. It’s difficult to generalize one single rule in this case; game server operators probably should be able to ban misbehaving client software, whereas web site operators should not ban clients which do not display their pages perfectly. Both groups of operators do have that right, however.
The Freedom to Copy
The third freedom is The freedom to redistribute copies so you can help your neighbor (freedom 2).
The underlying principle again relies on the idea of unrestricted use. With regard to a service, this is again contrary to the idea of using someone else’s physical resources without permission. Where the cost of duplicating software is nearly zero, the cost of duplicating a service is much higher.
Even still, you should have the freedom to create a competing service. As there is no requirement for you to receive any source code employed to produce the service or other resources used to deliver the service, this freedom may be less practical than in redistributing software. However, there is a parallel in that the freedom to redistribute software does not require that you distribute hardware with which to run the software.
Allowing other users to access the service without the knowledge or consent of its operators is probably not ethical even under this freedom. (The principle that the owner and operator of a piece of hardware has the responsibility for the use of that hardware and the right to govern its uses holds true. Note that the same property right is often a solid argument against the use of DRM on behalf of copyright holders and distributors.)
Perhaps the best reframing of this right in the context of software as a service is the right to reimplement the service.
The Freedom to Redistribute Changes
The fourth freedom is The freedom to improve the program, and release your improvements to the public, so that the whole community benefits (freedom 3). Access to the source code is a precondition for this.
This principle builds fully upon the three previous freedoms. On its surface, it may seem the least applicable to software as a service, especially with its explicit mention of source code. In practice, it may be the most important.
If the line I’ve drawn in analyzing these freedoms is correct, then so is the idea of a strict interface between the users of a service and its implementation. In the absence of specific contractual terms governing the uses of the service, the interface is a promise to provide service for any client accessing the service through the interface on behalf of a valid user.
Combined with freedom one, this freedom allows the use of custom clients, provided they meet the contractual obligations of the service. (Prohibiting denial of service attacks, cheating in multi-user situations, and other malicious use is acceptable on the part of operators.) This is even more applicable for purposes of interoperability, data retention, migration, and compatibility.
There is a fuzzy line in ethics here, however. A free service supported only by advertising may be within its rights to block clients which refuse to display the advertising, for example. Even so, the right to access your own data is more important than the right to make an attractive profit by limiting access to someone else’s data.
Analyzing the Freedoms
I’ve defined here the user of the sofware as the operator of the service, which uses the software on the behalf of the users of the service. This degree of separation is important.
One of the major difficulties in applying the four freedoms of software to software used primarily as a service is that the only distribution is of data, not software. This is well outside the realm of what a conservative view of copyright might cover. Even so, the unstated principle behind both sets of freedoms is that the user of a piece of software should retain ultimate control over the behavior of that software.
None of these four freedoms completely address the most interesting questions of software as a service. Those questions relate to access to your own data, whether directly (for the purpose of backups or migration to other services) or on your behalf (as in privacy concerns). As such, it’s definitely within the interest of freedom to enumerate and explain specific freedoms directly targeted at the use of data, not code.