autonomo.us cloud computing

open source

The launch of Autonomo.us promotes debate on these issues.

One line of reasoning is, to promote the GNU Affero General Public License (AGPL) for licensing free software.

The AGPL promotes freedom by extending the GPLv3 with a clause (art. 13) that makes it impossible to take a free software network application and turn it into a proprietary web service. This applies not only to web services but to any kind of network interaction.

If the program is expressly designed to accept user requests and send responses over a network, then it meets these criteria. Common examples of programs that would fall into this category include web and mail servers, interactive web-based applications, and servers for games that are played online. GPL FAQ

That's an upgrade to the GPL that makes it enforceable for cloud computing deployments.

open service

However, it's of no use to have the source of a web application, if your data is still locked in some corporate server. You need to be able to move your data somewhere else.

The launch of the open software service definition clearly links together open source software with open access to the data managed by that software. open source + open data = open service.

So that's the second line of thought: make sure data can be moved.

I move that this line of thought can be strengthened by integrating it into the AGPL. Earlier thinking about the AGPL centered around a software program that prints its own source code, with a license that forbids you to remove that functionality. This idea can be applied to data import/export functionality as well: create a program that is able to do a full data export/import round trip via a portable file format. Then incorporate into the license, a add-on clause that requires this functionality be preserved.

Combining these two lines of thought gives you web applications, that provide you with full access to both the source code and your data. The free software community can then aim to provide free software alternatives for many web applications, creating an open software services ecology.

Problem solved? Not quite.

open protocol

There's a third aspect, besides open source and open data, that is crucial to open software services. This pops up in the discussion as the keyword distributed.

But what is "distributed"? I'm sure Flickr is a distributed service, as are all the other big web applications. They are spread out over many computing resources in diverse data centers on different locations. Being distributed is part of being cloudy. This does not provide a meaningful distinction for free software applications.

It's not enough to have open source + open data, because these two aspects do not cover the social function of a web application. Even if Flickr open sourced their application code and provided me with a perfect download of my profile data, what could I do? I could set up a Flickr clone for me and myself. I would have to sever all the connections I maintain with other Flickr users. These connections are integral to the Flickr experience, they're what makes Flickr Flickr. And they cannot be exported. Or can they?

For me to be able to set up my own Flickr clone, and still be able to participate in the larger Flickr community, requires protocol. If people are proposing distributed open software services, implicit in the discussion is a concept of an inter-operating protocol for that specific application domain. A protocol that allows messages to be exchanged, and people to be connected, across installation boundaries.

An ecology of open microblogging services is only viable if they're able to talk to eachother through an agreed-upon protocol. Likewise for distributed photo sharing or any other social web application: separate installations need a protocol that facilitates distributing this type of application and enables the creation of an illusion of a single, integrated whole.

Each node in a distributed network may establish direct communication with another node, without having to appeal to a hierarchical intermediary. Yet in order to initiate communication, the two nodes must speak the same language. This is why protocol is important. Shared protocols are what defines the landscape of the network -- who is connected to whom. Alexander R. Galloway, Protocol, MIT Press 2004, 1st ed. p. 12

The concept of protocol is central to the internet. A well-known set of core protocols is what defines the internet: TCP/IP, DNS, HTTP, SMTP, FTP, and so on.

the a-social web

The emergent application of HTTP/HTML as a generic carrier protocol, over which proprietary ad-hoc interchanges can easily be facilitated, is a bit of an anomaly.

The power of the browser was its flexibility (or, in law professor Jonathan Zittrain's phrase, its "generative nature"). Just as a general-purpose computer allowed you to run any program, from a music player to a graphing calculator, the web browser let you view any kind of document. A book, a physics paper, or photos of cats with funny captions -- the web browser doesn't care; it displays whatever the server provides it with.

This seems like a trivial point now, but it was a vast change from other networked software at the time. Email programs, for example, are designed simply to display email -- they have an enormously specialized interface for composing emails, finding emails, seeing who an email is from and to, and placing emails in different folders. The same was true for discussion software, chat software, and other pieces of software that communicated over the network.

The Web was different: it did not specialize in any particular type of content, but let you share whatever you like.

This lack of specialization in the Web browser allowed people to move this specialization to the Web server.

Aaron Schwartz, Software Freedom and Web Applications

The dangers inherent in moving the web away from it's structured markup paradigm, reducing it to merely a thin GUI delivery mechanism, have been recognized by Tim Berners-Lee and the W3C early on. The Semantic Web aims to penetrate the veil of opaque GUI HTML and expose the underlying application data.

The Semantic Web provides a common framework that allows data to be shared and reused across application, enterprise, and community boundaries. It is a collaborative effort led by W3C with participation from a large number of researchers and industrial partners. W3C Semantic Web

This is a topic in its own right, currently heading towards a hypecycle upswing as "web 3.0". Whatever. But the concerns addressed mesh well with the dataportability effort, and both are fundamentally aligned with free software interests in creating a more open, more free as in freedom web.

Please note that we don't have the kind of centralization issues discussed here with email. There's a well-defined set of email protocols and plenty of choice in email server software and email clients. Anyone can set up their own email server and let it participate in the global email internetwork. My servers talk with Hotmail and Gmail without problems, because all respect the SMTP protocol.

Compare this with Flickr, Twitter, LinkedIn or what have you. These applications are unable to talk to the wider world beyond simple hyperlinking. They may enable social behaviour for the people using these services, but the services themselves are completely a-social, even autistic; they only talk to themselves. They're walled gardens, and we all know how effectively the internet is in demolishing walled gardens.

It's a logical progression to treat the current crop of proprietary web 2.0 applications as initial prototypes, that can be used as reference designs in creating protocol-driven open software services.

Open services that are interconnected have a huge advantage over their proprietary predecessors: they can be integrated. I'm not talking mere mashups here, I'm talking about the kind of integration that makes apt so vastly superior to the sofware management you'll find on Windows or Mac. I'm talking about a level of service integration that can easily be done bottom-up with free software, whereas in a proprietary setting you need Microsoft buying Yahoo buying Flickr to archieve some level of integration.

conclusion

We can realize an open service paradigm that is legally enforceable, technically executable, and creates unique sharing and integration benefits.

Doing so requires smart programming, smart licensing, and smart cooperation by establishing common open protocols. This is the exact same combination that the free software community has excelled in, time and again in the past. We just have to apply proven expertise and mechanisms to a new challenge.

We can apply the ideals embodied in the GPL to a cloud computing context. We can combine software freedom, open data access and open protocols into a truly free, open software service eco system.