[okfn-discuss] Open Service Definition (revisited)

Fri Jul 27 17:21:44 BST 2007

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