Bradley Kuhn moderated a panel discussion entitled With Software as a Service, Is Only the Network Luddite Free? on the first day of OSCON 2009, exploring the loss of freedom that accompanies the software as a service (SaaS) computing model. Kuhn was joined on the panel by Benjamin Mako Hill from the Free Software Foundation (FSF), Evan Prodromou from Control Yourself, Nathan Yergler of Creative Commons (CC), and O’Reilly Media’s Tim O’Reilly. Three topics dominated the session: the changing models of SaaS itself, the importance of building federated network services, and the challenge of building licensing models for data that preserve the user freedom that free software users have come to expect.

Software as a Service

Hill led off the discussion by explaining the background behind the Franklin Street Statement (FSS), then posed the question “whose computing is happening where?” SaaS can be divided into two types, he said: computing that could be done locally, such as email or Google Docs editing, and computing that must be networked — “group computing” for which user-to-user interaction is a core idea. The meaning of user’s “freedom” differs between the two. Computing that could happen anywhere is much like the desktop paradigm; the bigger challenge is protecting freedom in the group computing model.

O’Reilly asserted that the first case is a “vanishing class” of software anyway. SaaS as an application delivery mechanism to a single user is going away, he said, to be replaced by applications built to incorporate user contributions and collaboration.

Hill and O’Reilly elaborated on the point when an audience member asked how the GPL related to the individual-versus-collective computing demarcation. The FSF knows that “one person’s computing” as historically protected by the GPL does not cover all computing models, Hill said, including SaaS tasks like crowdsourcing and searching; the Affero GPL and FSS were created to address them, but it is important not to get sidetracked by philosophical and political discussions over the meaning of freedom. O’Reilly added that to him, transparency was the critical freedom issue in collective computing.

Federation

Kuhn asked Prodromou to speak about creating a business model around free network services, particularly in light of federation — which removes the stranglehold over the service that keeps proprietary SaaS vendors in power. Prodromou replied that the distributed, federated architecture of Laconica (the free microblogging software that runs Identi.ca) is the crux of the entire system. Open microblogging is distributed like the Internet itself, and distributed, federated designs have always become standards — email and instant messaging the most high-profile examples.

In response to the question “what would a free, federated social networking system look like?”, Prodromou speculated that it would not be a separate site at all. “Social networks are the modern Romeo and Juliet story,” he said. “If Romeo is on Facebook and Juliet is on MySpace, there’s no way that they can ever be together.” O’Reilly likened the underlying challenge to separating the “social graph” implemented in such sites from the sites themselves. “I want to see somebody reinvent the address book as an integrated social graph,” he said, so that the relationships and connections are attached to the user, not to the site.

Data licensing

Yergler added that the licensing of data was just as important as the licensing of SaaS software itself. SaaS is about users interacting around shared resources, not just publishing data one-way; using standardized data licenses is the way to grow the pool of shared resources. He described CC’s work on data licensing, including ways to make licensing information discoverable, such as machine-readable markup.

O’Reilly added that it is increasingly important to think about data that is not explicitly created by human beings — we tend to define data as “what we type,” he said, but it also includes automatically generated data like GPS logs. The answer is for coders to select a default data license, lest ambiguity about such automatically generated data creep in. Yergler commented that it is still an open question, legally speaking, whether machine-created data can even be copyrighted. He recommended using the CC0 public domain declaration as a solution, thus waiving all possible rights.

The panel addressed several other issues, from whether Google’s ChromeOS project represents a new challenge to user freedom to the privacy issues inherent in moving personal data between federated service providers. A line of audience members asked questions, but the session had to be wrapped up to make room for the rest of the day’s program. Hill encouraged those who found the discussion worthwhile to join in the ongoing discussion hosted at the Autonomo.us Web site.

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.

There is some debate on whether my comment during Jeremy Allison’s keynote at LibrePlanet 2009 was a heckle or not. (I did directly give Jeremy permission to call it such, so I don’t mind it. . However, there is no debate that Jeremy’s follow-up article clearly endorses the AGPL for Cloud Computing applications. In it, he says:

[I]f I ever work on cloud computing code, I’d like to see it under the AGPL, in order to preserve the freedoms I’ve been able to enjoy in conventional software development these many years. Without the AGPL, our freedoms will depend on the kindness of strangers donating their modifications to our code back to us, as they did in the days before the GPL license and the FSF was born.

This is great to see and I thank Jeremy for a great and open-minded response to my point (er, heckle .

James Grimmelman has a new paper out on privacy in social networks that suggests I might be wrong. In short, Prof. Grimmelman argues that data portability is not a solution to the privacy problem, because privacy is determined not just by who controls data, but by what code controls and interprets the data. Of course, the code won’t follow ‘ported’ data. For example, if a friend shares a picture with you, they aren’t deciding ‘just’ to share that picture with you, they are deciding to share it under the specific rules of the social network they are sharing it through. They may not fully understand those rules, but the rules are discoverable, choosable, and maybe even predictable. If that picture is taken elsewhere the rules may be better- but they may well be worse. Using the example of Scoble getting banned from Facebook for importing information into the notorious Plaxo, Grimmelman points out that this helped Scoble’s independence- but may well have violated the privacy expectations of anyone who had shared data with Scoble, assuming that Facebook would enforce certain rules on the use of the data. Or to put it more abstractly: “data portability may reduce vertical power imbalances between users and social network sites, it creates horizontal privacy trouble.” I think I’d known this before reading this paper, but Grimmelman laid the problem out so clearly that I will be forced to revisit the question.

(Tangentially, Grimmelman notes that this problem is in part a side-effect of the use of notions of ‘ownership’ to describe personal data, when property norms may well be the wrong metaphor for personal data. Certainly we’ve been guilty of that mistake here from time to time.)

Grimmelman does suggest a slew of other approaches that might lessen the privacy issues in modern social networks, and critiques a slew of others that he thinks won’t work – so for anyone thinking about privacy and network services the paper is well worth a read. In the meantime, I’ll be mulling what it means for free/autonomous social networks, and invite others to do the same.

A reminder about other modes of communication:

• IRC: #autonomo.us on freenode
• Blog: you’re reading it — if you have an idea for an article get in touch via IRC or the mailing list.
• Wiki: http://autonomo.us/wiki