An Open Service Definition

This page is editable so if you have comments or amendments please feel free to add them. To edit click on either 'Edit (Text)' or 'Edit (GUI)' at the bottom of the page.

If you'd like to get more involved in the development of this definition we strongly recommend you join the okfn-discuss list.

Introduction

The Open Service Definition defines 'open' for to Software as a Service (SaaS):

  • "a software application delivery model where a software vendor develops a web-native software application and hosts and operates (either independently or through a third-party) the application for use by its customers over the Internet. Customers do not pay for owning the software itself but rather for using it. They use it through an API accessible over the Web and often written using Web Services or REST." (source)

The Software as a Service model has grown greatly in popularity in recent years as the cost and speed of bandwidth has dropped.

Background

This particular formulation originates from discussions taking place originally on the okfn-discuss mailing list in September and October 2006 (see in particular this post) but owes much to recent (Summer 2007) discussions precipitated by activities at GUADEC 2007 (see [1], [2], [3], [4]).

  1. We Need an Open Service Definition -- blog post on the OKFN blog by Francis Irving which references a post on Havoc Pennington's blog

  2. Evaluating a Free/Open Service Definition (rough draft) posted by Luis Villa

  3. This ongoing thread on okfn-discuss -- this includes comments from a variety of people including Luis Villa, Mike Linksvayer, Rufus Pollock, Francis Irving and Saul Albert.

  4. Free/Open Services Definition draft/discussion page -- this is a draft definition put together by Luis Villa and posted on the GNOME 'live' wiki. In addition to the definition there is also an excellent listing on existing work and writing on this issue.

The Definition

An open service is one:

  1. Whose data is open as defined by the open knowledge definition (http://opendefinition.org/1.0/) with the exception that where the data is personal in nature the data need only be made available to the user (i.e. the owner of that account).

  2. Whose source code is:
    1. Free/Open Source Software (that is available under a license in the OSI or FSF approved list -- see note 3).
    2. Made publicly available.

Notes:

  1. The Open Knowledge Definition requires technological openness. Thus, for example, the data shouldn't be restricted by technological means such as access control and should be available in an open format.
  2. The OKD also requires that data should be accessible in some machine automatable manner (e.g. through a standardized open API or via download from a standard specified location).

  3. The OSI approved list is available at: http://www.opensource.org/licenses/ and the FSF list is at: http://www.gnu.org/philosophy/license-list.html

  4. APIs: all APIs associated with the service will be assumed to be open (that is their form may be copied freely by others). This would naturally follow from the fact that the code and data underlying any of the APIs are open.

TODO

1. Discussion of reliability obligations for service providers (see [http://lists.okfn.org/pipermail/okfn-discuss/2007-July/000477.html this post and following).

2. Identity ownership (that is issues around lock-in to a service due to their control of an identify url). Some have argued that this is something to be included while others have argued this out of scope see e.g. this extract from this post: 

Rufus Pollock in response to Luis Villa:
> There are also other ways in which source + data are insufficient.
> Consider, for example, an OKFN open service linkedin. Lots of people
> have a linkedin page as the #1 search result for their name. If
> linkedin suddenly does something Bad, they could take their data and
> the code, and replicate it elsewhere, but google would still point at
> the old (now bad) linkedin URI. So yes, in theory, you've got
> independence, but the reality of identity ties you to the old URI. (A
> lot like phone number portability, if you want a real-world analogy-
> yes, you *can* switch to a new provider without it, but it is
> painful.)

But the solution to this is simply to have some level of indirection or 
to have an identity which is separate from the service. The obvious 
forms for that identity are your email address or your website or your 
openid (As you point out gmail allows you to use your own email address 
in the From: field). Of course many people fail to make this effort (I 
notice that very, very few people seem to use gmails From facility) but 
that is not up to us to solve -- though we can certainly encourage 
people strongly to avoid lockin and encourage them to invest in 
identities that they control.

3. External dependencies (on closed services/data/code)

Discussed extensively on list. For example see this post from which the following is an extract: 

Rufus Pollock in response to Luis Villa:
>> An open service is one:
>>
>>    1. Whose data is open as defined by the open knowledge definition
>> (http://opendefinition.org/) though with the exception that where the
>> data is personal in nature the data need only be made available to the
>> user (i.e. the owner of that account).
> 
> I think I know the answer to this one, but I want to double-check: is
> this intended to exclude services which depend on third-party,
> non-OKD-compliant data sources? For example, if I built a geodata
> service which was otherwise completely data and source available, but
> used google maps to display some data to users, would that be
> compliant with the definition?

This is a thorny issue. There are obviously two options here:

1. (strong) A Service X is 'open' if and only if *all* 
material/knowledge it uses in delivering the service is 'open' (i.e. 
both all data and all code).

2. (weak) A Service X is 'open' if all material/knowledge (code and 
data) provided by the runners of the service themselves is open (but any 
third party material is not).

Personally I incline towards the first definition since I feel the 
'exception' in 2 can made so wide as to render the definition valueless. 
  Sure this may then mean that a few services that are 99% open but used 
a closed data source for some small item would be excluded but that's 
the way with drawing a line -- you always have to draw it somewhere.

This also has some analogies with packaging efforts such as debian: all 
of the core has to be 'free' but they do allow users to plug in 
'non-free' components (such as video card drivers or other proprietary 
libraries). The same thing could happen here with the providers of open 
services leaving it up to users to plug in closed stuff to their 
particular installation.

>>    2. Whose source code is F/OSS and *is made available*.
> 
> Similar question: if the service uses a non-F/OSS browser plugin
> (e.g., Flash) or runs on a non-F/OSS OS or system service (e.g.,
> Windows or Oracle) does that prevent it from being an open service,
> assuming all other aspects (source, data) are open?
> 
> Luis (struggling with these line-drawing issues myself)

Well I think again this goes back to the debian analogy. If you provide 
a system that has an essential non-open component (whether in the form 
of code or data) then that system is *not* open. If the item is an 
optional add-on then I think you are ok. So, for example, firefox is 
definitely open source even though the flash plugin may be proprietary 
(though if the flash plugin became absolutely essential to using firefox 
this might start to be debatable).