[okfn-discuss] Open Service Definition (revisited)

Wed Aug 1 11:11:56 UTC 2007

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

On the matter of reliability and identity lockin I have to say I remain 
sceptical about what could be done about in an OSD. 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).

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. 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) but 
that is not up to us to solve -- though we can certainly encourage 
people strongly to avoid lockin and encourage them to invest in 
identities that they control.

~rufus