[okfn-discuss] Open Service Definition (revisited)

Fri Jul 27 14:31:50 BST 2007

On 7/27/07, Rufus Pollock <rufus.pollock at okfn.org> wrote:
> Hi Francis,
>
> I've been meaning to write to okfn-discuss ever since I read your recent
> post on the blog 'We need an Open Service Definition':
>
> http://blog.okfn.org/2007/07/18/we-need-an-open-service-definition/
>
> It seems that parts of the Open Source community are really starting to
> get animated about this issue. As I mentioned in a comment on your post
>   we've been discussing for a while now -- in fact you yourself wrote to
> okfn-discuss back in last October in an email whose subject was
> precisely an 'Open Service Definition'[1].
>
> [1]:http://lists.okfn.org/pipermail/okfn-discuss/2006-October/000177.html
>
> Looking back over that thread, by the end  we had a draft definition
> along the lines of what I have included below. Does this look a good
> starting point? Who else should be be in contact with? (I've included
> Kragen Sitaker in cc).
>
> Regards,
>
> Rufus
>
>
> Draft of an Open Service Definition
> ===================================
>
> 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).
>    2. Whose source code is F/OSS and *is made available*.

I've been doing my own writing on this of late:
http://tieguy.org/blog/2007/07/22/evaluating-a-freeopen-service-definition-rough-draft/

and also (in very draft form):
http://live.gnome.org/FreeOpenServicesDefinition

My sense (as you'll see from reading the posts) is that mere source +
data is insufficient to constitute a meaningfully open service- that
says nothing about (for example) the licensing of the APIs used to
manipulate the data; the long-term reliability of the service (if one
wants to use it from a non-web client, or depend on it for other
services), etc. But I admit I'm only a little ways into my thinking on
the problem, and I don't see easy/reliable solutions to these
problems.

If you do want to go with the simplified definition, I'd suggest that
(2) should refer explicitly to the OSI and/or FSF's approved license
list, rather than just generic F/OSS licenses.

Luis

If you were to go with this simplified definition (which I agree