About This Page and Subpages

  • This is not a GNOME-specific or OnlineDesktop specific project- the intent is to eventually provide a very broadly applicable framework for thinking about these problems. However, at this time, this wiki was the most convenient politically-neutral wiki I could find. If you have a better suggestion, I'm all ears to move it.

  • This is not yet a 'ready for the public' document; consider it a very early work in progress, not yet suitable for much blogging or news coverage. Email me if you want to chat about it.

  • This document is not yet ready for public collaboration; please don't edit without talking to me first. I have put it in a public wiki so that I can have a good changelog, and so that others can start to digest it and contact me with feedback.

  • I'm not formally using Design Thinking to put this page together, but I'm at least inspired by the approach. If you comment or edit, please keep that in mind- this is very much in the define/research/ideation phase.


Software as a Service (SaaS) has become extremely popular in the last few years, demonstrating a number of benefits to users and developers, including:

  • easy collaboration between individuals (both for private purposes like planning parties with facebook and for public purposes like creating wikipedia)
  • easy maintenance and administration
  • access to data from anywhere and from any device
  • access to large databases without needing to download/maintain the entire database

A prescient and in-depth assessment of the benefits was written by Paul Graham in 2001. Since then the web's advantages have only increased as usability and performance have risen to par with local applications for many tasks.

Unfortunately, SaaS has historically been antithetical to many of the goals advanced by free software and open source. Among the restrictions typical of many SaaS systems:

  • lack of access to source has constrained or eliminated modification of the software, and hence reduced innovation
  • lack of access to data has reduced user freedom to modify or move to other software (aka 'Freedom to Leave'), eliminating many of the benefits of competition

  • lack of publication of modifications has made building a collaborative commons more difficult, reducing the benefits of peer production.
  • restrictive terms of service and reliance on third parties have constrained use, investment and innovation.

How do we get the best of both worlds?

Problem Definition

In order to encourage the creation and use of web services which combine the best of both SaaS and Free/Open software, we'd like to create a Free/Open Services Definition. This definition would serve as a reference (and potentially a checklist) for those creating free/open services, and perhaps eventually as a certification for users as well, so that they know they are getting the same benefits from a specific web service that they've come to expect from traditional Free/Open Source software. (Q: elaborate here or elsewhere on the relationship between definitions/licensing/business models/service implementation/etc.?)

I use "Free/Open" because I expect that the Definition (like the OSI definition) will be broad enough to allow a variety of implementations- some of which might be more user-friendly (and hence closer to the FSF's Free focus) and some of which might be more developer-friendly (and hence closer to, say, the pragmatic Open/Linus camp, or Creative Commons.)

Criteria for discussion and evaluation

There are a number of axes along which these problems can be evaluated. A starting point for evaluation would include the following criteria (all of which are probably continuums or sliding scales, not binary yes/no):


The point of having open/free web services:

Evaluating these criteria differently will result in different values for the next two categories (preconditions and rights). For example, when in doubt the FSF favors user freedom, which means much stricter restrictions on redistribution than might otherwise be ideal for direct contribution; when in doubt Linus favors contribution and ecosystem participation and hence prefers GPL v2 to v3. And of course the Open Source/Free Software split was precipitated in part by an increased emphasis on ecosystem participation and decreased emphasis on user freedom.

I’m not entirely sure yet that direct contribution and ecosystem participation are really all that different in practice, but it seems they might be (particularly in an online context) so I’m keeping them separate for now.


If these preconditions are not met, then you can’t meaningfully achieve the rights listed below or the goals listed above:

  • data control: taken for granted until recently because our data has always been under our control (either on local drives or servers in our organizations.) As a result, this control is implied by the Free Software Definition and yet not protected by the GPL (even v3). DRM and privacy are discussed as part of this as well.

  • source access: this is probably a precondition for all other user rights (as per the Free Software Definition) as well as a pragmatic warrant of competition and other benefits. (see, e.g., Asay blog post.)

  • hardware access: never much discussed because, unlike everything else here, hardware actually is scarce, and so can’t be provisioned merely by good intent or good licensing.


Rights available to participants in the commons.

  • use

  • modify: as in FSF/OSI, pretty much, including sliding scale of options. May have some implications for APIs/service guarantees in an online context which are not readily comparable with the traditional model.

  • redistribute: as in FSF/OSI, pretty much, including sliding scale of options.

These are pretty much straight out of the Free Software Definition. I tend to think FSF freedoms 1, 2, and 3 have a fair amount of redundancy, so they get collapsed to modify/redistribute, with the assumption that redistribution means either modified or unmodified.

FSF calls these freedoms; I call them rights here because I personally tend to think of them as inalienable things which should be provisioned rather than optional things which can be taken or not. But neither term is completely satisfactory for this analysis, since saying that these are rights or freedoms implies taking a position on where on the sliding scale restrictions should be made.

Not clear where the question of who gets access to these things fits into the analytical model; OSI’s definition leaves that up to the license, and even FSF allows some fairly strong restrictions on who gets source access and hence gets to exercise these rights, so perhaps it is merely implied that that is part of the spectrum of options for each criteria.

Open Questions

  • what attracts developers/investment to free software that we'd want to see in a free/open service?
    • network effects? (what causes this? probably not licenses per se, maybe the business model or open standards.)
    • ability to function as a drop-in replacement for other tools (both by way of defacto standards (Unix) and real standards (HTML, ODF))? (license/business-model does not impact this, though it might be made easier or harder by licensing details- e.g., the system library exception.)
    • no barriers to innovation- anyone can take, modify, test, and then eventually propagate the innovation if it is valuable. (could be replicated with openly licensed APIs in at least some cases; see also the better gmail example.)
  • is there still substantial/meaningful openness if the source is closed but the data is available/well-licensed?
  • what makes SaaS/web 2.0 so attractive, and which of those features do we get 'for free' from being on the web, and which need to be deliberately baked in to the definition/framework?
    • the APIs? how open do they have to be? do you want to do something like the rumored flickr reciprocal API license (you can harvest mine if I can harvest yours?) what about delegation of API access to a third party? (i.e., I want gmail to be able to suck my mail out of my yahoo mail account- can I do that?)
      • what is 'good' API licensing? minimal: documented, lets you get all data out; good: freely usable, get/set all data; ideal: free and permanent.
    • social/collaboration aspects/huge amounts of aggregated individual data being worth more than the sum of its parts, and available w/out download?
    • the easy updates/low administration costs? (this is not a licensing/business model question- purely a technology question, AFAICS.)
  • Moglen challenged the SaaS-centric folks to focus on a rights-based approach to licensing, which appears to lead him to the conclusion that the GPL is sufficient. He and FSF appear to believe that the only relevant rights are user (aka deployer) rights, and as a result additional restrictions which shift the balance from deployers to developers or deployers to consumers are unacceptable. Is it possible to frame the discussion differently, such that FSF's 'user' begins to again cover both software user/consumer and software deployer? How does this look in a copyright-free (but industrial secrets-allowed?) world (if you take that as FSF's goal?) Perhaps the focus is on control of the rights once it leaves the service? You can at least get a 'no onerous TOS' out of that- if developer makes it accessible at all via any route, they can't prevent the transformation/modification into other forms. Seems hard to get an export clause out of it, though.


Brainstorming By Others

Lots of people have been thinking about this. Some of the most interesting posts of late:

Other Similar Definitions

Use Cases to Enable or Prevent


Attic/FreeOpenServicesDefinition (last edited 2013-12-03 22:45:57 by WilliamJonMcCann)