[okfn-discuss] Open Service Definition (revisited)

[Luis Villa]

On 8/1/07, Rufus Pollock <rufus.pollock at okfn.org> wrote:
> Luis Villa wrote:
> > On 7/27/07, Luis Villa <luis at tieguy.org> 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]
> >>> 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.
> >
> > On rereading http://opendefinition.org/1.0 I see that I may have been
> > incorrect in some of my recollections around OK. Many of the terms
> > could be interpreted to require non-discriminatory TOSs, so some of
> > this objection may not stand.
>
> That's exactly right. If a service has terms that restrict your ability
> to extract data then that data is *not* open --

I think I'm still leery of using the OKD for services because it is
not at all clear, in the service context, what 'the work' is, what
'access' is, etc. Regardless of my own plans (as below), I would
suggest that OK's proposed OSD should seek to make more explicit how
the OKD would apply to such services- it would make it stronger.

> in fact I wrote a
> substantial blog post on the subject of why the 'Open' in Open APIs is
> fairly meaningless:
>
>    http://blog.okfn.org/2006/09/04/open-apis-dont-equal-open-knowledge/

Sadly, open everywhere is fairly meaningless; the term is badly
overloaded. My own current private draft uses 'User-Centric Service
Definition' to avoid the ambiguity around 'open', but I'm not happy
with that route either. Suggestions welcome :)

> On the matter of reliability and identity lockin I have to say I remain
> sceptical about what could be done about in an OSD.

I should note that I think that an OSD probably needs to be about more
than licensing- it will probably need to encompass some governance and
possibly even architecture in order to practically empower users in
the way that FLOSS does.

> On the question of
> reliability as I have already said I don't think you can mandate this
> and I feel it is best addressed via competition (with open data and open
> code you can always go elsewhere or set up your own service).

I'm a fairly die-hard capitalist but remain skeptical about the power
of competition to spontaneously force a shift in risk from the user to
the service provider. Like the shift in software, my guess is that the
shift in services will occur only after someone says 'this is the
standard to be striven for' and then begins to strive for it, instead
of just crossing our fingers and hoping that the market generates
freedom on its own :)

> You suggested that identity lockin might prevent this:
>
> > 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.

This is only meaningfully possible where the service provider
cooperates. I could obviously set up http://tieguy.org/facebook to
redirect to my facebook page, but without cooperation from facebook,
the facebook.com page will be the URL friends and search engines see,
use, and link to. (Similarly, I could make luis at tieguy.org redirect to
luis.villa at gmail.com, but it only works in practice because the gmail
client also allows me to send from luis at tieguy.org.)

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

Would you have known that I used it had i not pointed it out? :) The
whole point of such transparency is that I can use the service without
depending on it; if you know I'm using it without my pointing it out
then it is quite possible (even likely) that it isn't actually
transparent- that there is no 'freedom to leave', in simon phipps'
term.

> but that is not up to us to solve

I don't see why not. :)

In my mind, openness was successful not because it gave people access
to source, but because it shifted *control* back to users from the
producers of proprietary software. Source access was just one part of
that shift. An open service definition, I believe, should seek to
define systems which meaningfully/practically transfer control back
from service providers to users, not merely give them access to source
and data.

Now, you can argue that the point is not to be successful, but to
protect moral considerations to the extent that they exist. This
appears to be Prof. Moglen's position on the SaaS/freedom discussion.
In this sense, the proposed OK service definition is probably
sufficient. But my sense is that in a hosted world that is
insufficient to have practical traction, and I'd like to explore that
some more before giving up on it as an impossibility. :)

[To put it another, more concrete way: GNOME is currently building
online.gnome.org, a hosted service for GNOME users. If I came to most
GNOME contributors with the OSI open source definition, they'd say it
sufficiently protected their interests. If I came to those same people
with the proposed OK service definition, they'd say, and I think
rightfully so, that it did not sufficiently protect their interests.
That is, in practice, the gap I'm trying to bridge.]

Luis