[okfn-discuss] Open Service Definition (revisited)

Rufus Pollock rufus.pollock at okfn.org
Fri Jul 27 14:48:11 BST 2007


Luis Villa wrote:
> On 7/27/07, Rufus Pollock <rufus.pollock at okfn.org> wrote:
[snip]
>> 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/

This is great Luis -- in fact I'd already taken a look (and posted a 
comment) and I should have mentioned that in my original post.

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

I hadn't seen this. My question here, as with your blog post, is whether 
this is intended to the 'definition' or a general discussion/preamble. I 
think it would make sense to keep these pretty separate within the page 
-- the preamble can be fairly verbose but I think one would want to keep 
the definition pretty simple.

> 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.

I'm not sure what one means by 'licensing of the APIs' here. If the 
underlying code which creates those APIs (the code running the service) 
is open then one would expect to the APIs to be -- unless one is arguing 
that the APIs could somehow be patented while the code kept 'open' (and 
this problem then isn't specific to services but to software patents and 
open source generally ...)

I also think we should steer well clear of reliability questions. OSI 
does not mandate you as a software provider have to stay around to 
maintain and develop your software only that what you currently provide 
is open. Similarly an Open Services Definition (OSD) is there to ensure 
I can easily move to another service -- and if necessary duplicate the 
existing one so that if you fall over tomorrow someone else can take 
over. Thus reliability is ensured by competition not by the Definition 
itself.

> 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.

Good point. That should be fixed.

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

did something get cut off here?

~rufus




More information about the okfn-discuss mailing list