In his article, Stallman defines SaaS as, “a network server that does certain computing tasks … then invites users to do their computing on that server.” His basic message is simple: users should reject SaaS network services because SaaS users are inherently disempowered and out of control. Indeed, users should reject SaaS even if a service is implemented using free software!

Although some people have used the term SaaS quite broadly, Stallman means something very particular and focuses on the term “their computing.” When Stallman uses the term SaaS, he’s talking about computing that is highly individualistic and that looks like the type of computing that otherwise happens on a user’s own computer. Stallman explains SaaS does not refer to search, collaborative editing (e.g., Wikipedia), social networking, publication, or e-commerce. For each of these tasks, the computing involved can’t clearly be said to “belong” to one user or another; these examples all refer to computing that “belongs” to a dyad or a group. As a result, it follows that the computing involved need not obviously reside with any one individual. Stallman is careful to explain this doesn’t mean that network services doing these sorts of things are unproblematic. Often they are very problematic — but for reasons that have nothing to do with SaaS.

The piece is an interesting read but, judging by the questions and discussions after Stallman’s talk, the argument seems to be confusing for a number of people. Here’s my early thinking on the piece:

Part of the reason people are confused is because they are looking for a bright-line statement to evaluate particular applications and declare them free and non-free. SaaS can do that, but falls for short for many — and I think perhaps even the vast majority of — network services.

It seems to me that most network services I’ve used involve some SaaS features and some non-SaaS features. Some of the computing being done really belongs to a single user and some doesn’t. Some functionality boils down to collaborative or group-based computation and other things really are just tasks being done for one user using that user’s data; only the second class of features is SaaS. While particular features are easy to classify, most services end up being a bit muddy.

Much more problematically, and this is not something RMS addresses, it seems to me that the way that an application is used can really change the degree to which a program is SaaS. For example, Google certainly seems to be interested in having all of us replace OpenOffice.org and our  other desktop applications with Google Docs and other Google services. Using Google as an OpenOffice replacement is clearly SaaS and should clearly be rejected for the reasons Stallman explains. That said, every time I’ve seen Google Docs used, it was as a real-time collaborative document editing system for a large group of people. Used in this way, it seems that even Google Docs might not be SaaS!  SaaS or not, of course, we might still want to use federated free software alternatives like Gobby.

There are services that I have less trouble calling SaaS. Meebo, which apparently just uses the Pidgin code and creates a web-based front-end to it so that the all the computing involved happens in some data center instead of your desktop, seems like a clear example. But it’s hard to come up with tons of these pure-SaaS examples. My sense is that there are very few bright-line examples of network services that are clearly and completely SaaS. Indeed, my sense is that collaborative functionality is becoming an increasingly important part of most popular network services. SaaS seems to be a small and decreasingly important class of services.

Stallman made it clear in his talk and in the Q&A that he understands that SaaS is not a complete answer to the network services problem and, with the help of myself and the FSF staff, is working on a draft of a document influenced heavily by the Franklin Street Statement to be published by the FSF in the near future.

Stallman is right. We should reject SaaS. But even if rejecting SaaS alone leaves the most prominent, popular, and problematic network services unscathed — as I fear it might — SaaS provides a good way to think about them and keeps us focused on the key issues — control and (ahem!) autonomy. Thinking about the SaaS and non-SaaS features of applications helps us evaluate whether applications are worth their cost in freedom.

Although there has been lots of discussion about Chrome OS in the free and open source software communities (e.g. on LWN), its worth qualifying this post by saying that, beyond Google’s announcement, we don’t actually know very much about Chrome OS. But although it is probably an overstatement to suggest (as some have) that Chrome OS will simply boot into a browser, Google is being quite up front about the fact that it is being designed for, “people who live on the web” and will be an environment where, “most of the user experience takes place on the web.”

With the rise of network services, the idea of an operating system that is largely reduced to a web browser is no longer difficult to imagine. Even if one were to limit themselves entirely to Google services, one would have a word processor, spreadsheet, email client, photo management software, chat client, RSS reader, and much more — most of the applications that most people use. As Mobily points out, this means that the details of any operating system begin to matter less. It doesn’t matter if your OS doesn’t have many native programs; if the programs you want run over the web, all you need is a browser.

Mobily argues that Chrome OS will be a win for GNU/Linux on the desktop because Google’s might and market power will help free software succeed where it has struggled in the past. And he might be right. But even if Mobily is completely right and Chrome OS becomes a raging success, it is not at all clear that this will represent a victory of any meaningful sort for software freedom and for users’ autonomy.

Chrome OS is, as it is described, an explicit attempt to build a system that changes where ones computing happens. In doing so, Google is trying to create an OS built around “Software as a Service” that replaces applications a user might run on their own computer with applications that runs on servers outside user control. A Chrome OS user’s computer doesn’t need to be powerful — Google claims that Chrome OS will be ideally suited to low power netbooks — because the user’s computation is happening on Google’s servers instead of the netbook itself.

If switching to Chrome OS means giving up Thunderbird to use GMail, or giving up Openoffice.org to use Google Docs, or giving up Pidgin to use a web-based Google Talk, or giving up Evolution to use Google Calendar, we have reduced the influence and success of the free software desktop, not sealed its victory as Mobily suggests. In a SaaS world, there will be less free software being used and, much more importantly, users will be less free.

With every shift from a piece of free software to a web-based network service, we have moved from a situation where a user had control over his or her software — users’ of “traditional” free software have access to source and have control over the system on which the computer runs — to a situation where users have very little control over their software at all. Google offers no source for the applications that run their web services and, even if they did, they do not offer users the ability to change the software that runs on Google servers.

Chrome OS, or any OS designed around pushing users computation off their computers and onto servers outside of their control is regressive for software freedom. If Chrome OS is, as Mobily suggests, the key to free software’s victory on the desktop, it would be be a ironic and bitter victory indeed.

Last week, Logical Awesome — the company that makes GitHub — announced GitHub:FI (Firewall Install). The new product is designed for those that, “wish to enjoy the benefits of GitHub, but are unable to do so because of corporate restrictions or laws that prevent you from hosting your code with a third-party service.” Essentially, GitHub:FI is a version of GitHub that can be installed on a company’s own computer inside a private network.

The GitHub:FI announcement reveals a number of interesting issues around autonomy and network services. First, the product is a symbol of recognition by GitHub of the business limitations of a purely service-based business. Not everyone will be willing or able to hand their data or computation over to a third-party. GitHub:FI exists to serve a group of people that want a level of autonomy that, while far from Franklin Street Statement style autonomy, is more than the centralized version of GitHub can provide. It marks a guarded step toward increased autonomy by a cloud poster-child.

Second, it’s interesting to see this reluctance to centralized services being described as motivated by organizations under strong institutional pressures — groups like large firms and governments. Although it certainly makes sense that these groups would be reluctant to “outsource” to centralized systems, GitHub:FI shows that these groups may provide an unlikely ally in at least part of the fight for autonomy.

Third, in Logical Awesome’s words, GitHub:FI, “is well over the cost of our most-expensive hosted plan.” In this pricing structure, the distributed option presented in GitHub:FI is framed as a form of tax on autonomy. We suspect there will be much more of this going forward. Of course, as GitHub remains proprietary software, users of GitHub:FI get only buy partial autonomy.

Finally, the product’s name is interesting. Not so long ago, we treated network services as exceptional and local software as normal. The idea of calling distributed software a “firewall install” is an explicit attempt to reframe conceptions of normal and exceptional in terms of where we expect software to reside or, perhaps, a reflection of just how entrenched services have already become.

This post was written with Dafydd Harries.

We’ve come a long way and this year and we’re helping to celebrate and to plan our future by joining with the FSF to help organize a chunk of the two-day LibrePlanet conference. Unsurprisingly, our chunk will focus on issues around software freedom and network services. A good chunk of the folks that have blogged here are already confirmed their attendance.

Saturday March 21 will be more of a normal conference form and will feature a series of talks by experts on some of the key issues facing free software. Perhaps more exciting though is that on Sunday March 22 there will be an open space style conference with three tracks. One of these tracks is being organized by Autonomo.us members and will be focused on freedom for network services. We’ll raise and tackle the important questions. We’ll try to make connections, think strategically and technically, and plan next steps.

If you are interested in these issues and there is any way you can get to Boston for the conference, please consider making the trip out. There are loads of good people coming. It looks like it will be a blast and may very well be this year’s most important single event for people interested in issues of autonomy and network services.

There’s information on travel, location, hotels, and more on this web page and on this wiki page (login is required to RSVP). And please, spread the word!

Now we run a blog, of course, so, in that capacity, we’re one of the implementors our statement speaks to. We use Wordpress with a downloaded theme and a couple extra plugins — all of which are free and available online. We export our blog’s content using RSS and Atom under the Creative Commons Attribution ShareAlike License — a licensed approved for Free Cultural Works.

In the Franklin Street Statement, we ask implementors to choose free software for their services. We’ve done that. We ask them to release customizations under a free software license. Like most people who run blogs, we’ve not made any changes, so no action seems to be required. We don’t host any private data other than passwords. Public data on our blog is accessible via RSS and licensed freely.

So are we doing enough to comply with the statement’s guidelines? It seems so. But have we provided an ideal example? Perhaps not. We’ve argued that a free service is one that can be copied, changed and reimplemented by its users. With a little extra work from us, that could certainly be easier with regards to our service.

To work toward being a better example, I’ve put together a new page on our blog that links to local copies of source code for all the software running our blog. In building this list, I made several observations.

While I think many people running blogs would be happy to provide such information, perhaps they won’t be as motivated to take the time I did to put it together. Perhaps we need a plugin to generate such sets of links automatically. Perhaps such a plugin can go further than just RSS by providing database dumps that are automatically and appropriately cleaned of sensitive information like passwords and unpublished posts.

The process of building and auditing the list raised several important issues related to the software we use. The theme we’d been using had unclear and potentially problematic licensing status so I switched to one clearly released under the GNU GPL. It’s not clear to me what to make of the Akismet plugin which, while presumably free itself, uses a separate service and database to do spam checking. The freedom status of this system is much less clear. Now, the whole point of Akismet is build a centralized database resistant to spammers. Should we uninstall Akismet? Possibly. I’m not sure yet, but I hadn’t even considered it before I went through this process.

As more people try to implement the Franklin Street Statement, these types of questions, problems, reports, and shared solutions will help make it easier for others to comply in the future. Other’s who’ve gone through this process and have useful advice, tips, or code to share should contribute that to the Autonomo.us wiki or help write an article on this blog.

Although our conversation was reflective and unstructured, we left the recorder rolling. I’ve gone ahead and put that recording up, essentially unedited, for anyone that anyone who’d like to listen in on what we had to say to each other.

One concerete outcome of our conversation was a decision to do these types of podcasts more in the future. We’ll invite guests who are active and involved in thinking about and taking action on issues related to software freedom and network services, we’ll get hear from them, and we’ll talk to them about the issues as a group.

We hope our next one to be up in less than a month with a guest that’s still to be finalized. You can listen to or download the first podcast in OGG vorbis format now.

On March 16, 2008, a workgroup convened at the Free Software Foundation to discuss issues of freedom for users given the rise of network services. We considered a number of issues, among them what impacts these services have on user freedom, and how implementers of network services can help or harm users. We believe this will be an ongoing conversation, potentially spanning many years. Our hope is that free software and open source communities will embrace and adopt these values when thinking about user freedom and network services. We hope to work with organizations including the FSF to provide moral and technical leadership on this issue.

We consider network services that are Free Software and which share Free Data as a good starting-point for ensuring users’ freedom. Although we have not yet formally defined what might constitute a ‘Free Service’, we do have suggestions that developers, service providers, and users should consider:

Developers of network service software are encouraged to:

• Use the GNU Affero GPL, a license designed specifically for network service software, to ensure that users of services have the ability to examine the source or implement their own service.
• Develop freely-licensed alternatives to existing popular but non-Free network services.
• Develop software that can replace centralized services and data storage with distributed software and data deployment, giving control back to users.

• Choose Free Software for their service.
• Release customizations to their software under a Free Software license.
• Make data and works of authorship available to their service’s users under legal terms and in formats that enable the users to move and use their data outside of the service. This means:
  • Users should control their private data.
  • Data available to all users of the service should be available under terms approved for Free Cultural Works or Open Knowledge.

• Consider carefully whether to use software on someone else’s computer at all. Where it is possible, they should use Free Software equivalents that run on their own computer. Services may have substantial benefits, but they represent a loss of control for users and introduce several problems of freedom.
• When deciding whether to use a network service, look for services that follow the guidelines listed above, so that, when necessary, they still have the freedom to modify or replicate the service without losing their own data.

The last decade has witnessed a rise in the role of computing as a service, a massive increase in the use of web applications, the migration of personal computing tasks to data-centers, and the creation of new classes of service-based applications. These shifts have raised a host of important questions for the advocates of free software. For example, by separating use and distribution of software, these models have in some cases reduced the effectiveness of GNU GPL-style copyleft which treat modified web applications as if they were private software. Much more importantly, the movement of software off of personal computers has reconfigured power relationships between users and their software and complicated questions of ownership and control in ways that free software advocates do not yet know how to address.

What does freedom mean for the users and developers of web services? What is at risk? What should the free software community, and the Free Software Foundation, do to ensure that software, and its users, stay free in this new technological environment?

Many problems associated with web services were discussed as were a range of responses. Different group members offered strong and differing ideas about both. There was0 consensus within the group, however, that the impact of the rise of network services on software freedom is not yet even fully understood and that further discuss and a more public accessible venue was necessary.

The most important step for summit participants was to help advance an understanding of the problems introduced by network services and to their impact and of the means by which they can be addressed. In attempting to do so, the participants produced a large amounts of notes and examples which, over the coming months, will be refined into a set of reports and essays and published.

The group will continue to work together, and with the larger free software community, over the next months to help refine this knowledge base about issues of free network services and to publish a series of essays, histories, case studies, and position papers. With time, the group hopes that this discursive and deliberative dialog will lead to a series of positions that the FSF and other organizations can adopt in relations to network services and software freedom.

If you’d like to be more involved, please subscribe to Toward Free Network Services: a new blog where this post marks the first entry. Please check out the about page for more information on the project and how you can contact and contribute.