[okfn-discuss] Open Service Definition (revisited)

[Francis Irving]

That's all ace Luis.

Please keep us posted as you think things through.

Rufus - perhaps when Luis has got a bit further and clarified the
language and options, we should have a meeting in Cambridge to work
out what, if anything, OKFN needs to do?

On Fri, Jul 27, 2007 at 12:21:44PM -0400, Luis Villa wrote:
> On 7/27/07, Rufus Pollock <rufus.pollock at okfn.org> wrote:
> > 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.
> 
> Sorry, hadn't seen the comment- have been swamped this week.
> 
> > > and also (in very draft form):
> > > http://live.gnome.org/FreeOpenServicesDefinition
> >
> > I hadn't seen this.
> 
> This is the first time I've posted it publicly; you'd have to have
> been watching live.gnome.org's recent changes page to have seen it
> before 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.
> 
> At this point, discussion/framework for thinking about the problem,
> leading to a more concise/simple definition in the near future. But
> not quite as concise/simple as what you're proposing here :) (In fact,
> probably multiple concise/simple definitions- one that focuses on
> rights, FSF-style, and another that is more pragmatic, OSI-style.)
> 
> > > 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 ...)
> 
> network-provided APIs have terms of service which can restrict things
> like how often they can be used, what can be done with the data
> extracted from them, etc. That licensing is completely distinct from
> the licensing of the underlying code and data.
> 
> So, for example, lets say that facebook was FLOSS, and that all
> personal data was available from facebook under OK principles. Given
> that, you could set up your own facebook with that code and your own
> personal data.
> 
> But in order to interact with the thing that makes facebook actually
> interesting - the aggregate data at facebook.com -  you'd still have
> to agree to:
> 
> http://developers.facebook.com/terms.php
> 
> Now, I haven't read all of that, but I'm guessing it isn't very
> compatible with FLOSS or OK principles :) It certainly doesn't make me
> want to make my project or my business depend on it, the way many
> projects and businesses depend on open code today and should depend on
> open services/data in the future.
> 
> 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.)
> 
> [This is why I am OK with using gmail, BTW- it lets me use
> luis at tieguy.org, so that if gmail ever goes bad for some reason, I can
> easily migrate away without any substantial service interruption. I'd
> have to use different software, of course, but since open standards
> are involved, I can do that without too much pain.]
> 
> > 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.
> 
> Of course not, but the OSI does mandate a perpetual license, so it
> assumes that once I have the code, it can't be taken away. The same is
> not the case with a service, which can go away without warning,
> perhaps even before I've taken a backup of the publicly available
> data.
> 
> > 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.
> 
> I agree that the reliability problem is tricky, and potentially
> unsolvable. But I wouldn't personally trust critical data to a service
> which did not make a serious attempt to address the issue, which
> (again, speaking personally) seems to make this proposed definition
> insufficient for my needs.
> 
> Anyway, definitely a difficult problem- sorry I missed out on it the
> first time around- hopefully this doesn't sound like post-hoc whining
> and can still be constructive.
> 
> Luis
> 
> > > If you were to go with this simplified definition (which I agree
> >
> > did something get cut off here?
> 
> Hrm, don't think so, must have mis-copied/pasted.
> 
> Luis
>