Open Service Definition (revisited)

[Rufus Pollock]

Hi Francis,

I've been meaning to write to okfn-discuss ever since I read your recent
post on the blog 'We need an Open Service Definition':

http://blog.okfn.org/2007/07/18/we-need-an-open-service-definition/

It seems that parts of the Open Source community are really starting to
get animated about this issue. As I mentioned in a comment on your post
  we've been discussing for a while now -- in fact you yourself wrote to
okfn-discuss back in last October in an email whose subject was
precisely an 'Open Service Definition'[1].

[1]:http://lists.okfn.org/pipermail/okfn-discuss/2006-October/000177.html

Looking back over that thread, by the end  we had a draft definition
along the lines of what I have included below. Does this look a good
starting point? Who else should be be in contact with? (I've included
Kragen Sitaker in cc).

Regards,

Rufus


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

Remark: The OKD requires technological openness (i.e. provision in an
open format)

Remark: The OKD also requires that data should be accessible in some
machine automatable manner (e.g. through a standardized open API or via
download from a standard specified location).

_______________________________________________
okfn-discuss mailing list
okfn-discuss@...
http://lists.okfn.org/cgi-bin/mailman/listinfo/okfn-discuss

[Luis Villa-3]

On 7/27/07, Rufus Pollock <rufus.pollock@...> wrote:

> Hi Francis,
>
> I've been meaning to write to okfn-discuss ever since I read your recent
> post on the blog 'We need an Open Service Definition':
>
> http://blog.okfn.org/2007/07/18/we-need-an-open-service-definition/
>
> It seems that parts of the Open Source community are really starting to
> get animated about this issue. As I mentioned in a comment on your post
>   we've been discussing for a while now -- in fact you yourself wrote to
> okfn-discuss back in last October in an email whose subject was
> precisely an 'Open Service Definition'[1].
>
> [1]:http://lists.okfn.org/pipermail/okfn-discuss/2006-October/000177.html
>
> Looking back over that thread, by the end  we had a draft definition
> along the lines of what I have included below. Does this look a good
> starting point? Who else should be be in contact with? (I've included
> Kragen Sitaker in cc).
>
> Regards,
>
> Rufus
>
>
> 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/

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

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.

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.

Luis

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

_______________________________________________
okfn-discuss mailing list
okfn-discuss@...
http://lists.okfn.org/cgi-bin/mailman/listinfo/okfn-discuss

[Rufus Pollock]

Luis Villa wrote:
> On 7/27/07, Rufus Pollock <rufus.pollock@...> 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

_______________________________________________
okfn-discuss mailing list
okfn-discuss@...
http://lists.okfn.org/cgi-bin/mailman/listinfo/okfn-discuss

[Luis Villa-3]

On 7/27/07, Rufus Pollock <rufus.pollock@...> wrote:

> Luis Villa wrote:
> > On 7/27/07, Rufus Pollock <rufus.pollock@...> 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@..., 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

_______________________________________________
okfn-discuss mailing list
okfn-discuss@...
http://lists.okfn.org/cgi-bin/mailman/listinfo/okfn-discuss

[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@...> wrote:
> > Luis Villa wrote:
> > > On 7/27/07, Rufus Pollock <rufus.pollock@...> 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@..., 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
>

_______________________________________________
okfn-discuss mailing list
okfn-discuss@...
http://lists.okfn.org/cgi-bin/mailman/listinfo/okfn-discuss

[Luis Villa-3]

On 7/30/07, Francis Irving <francis@...> wrote:
> 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?

My sense is that sometime in the next 6-12 months someone (perhaps
OKFN, perhaps someone else) will have to convene an (private(?),
invite-only(?)) summit of the key players* to hammer something out,
much as OSI was hammered out early on, but hopefully with less
crossfire.

Luis

* both on the policy side (OKFN, CC, etc.) and on the implementation
side (anyone implementing open-ish services- wikipedia, Red Hat,
Joyent(?) etc.)

_______________________________________________
okfn-discuss mailing list
okfn-discuss@...
http://lists.okfn.org/cgi-bin/mailman/listinfo/okfn-discuss

[Francis Irving]

On Mon, Jul 30, 2007 at 10:42:44AM -0400, Luis Villa wrote:
> and on the implementation
> side (anyone implementing open-ish services- wikipedia, Red Hat,
> Joyent(?) etc.)
 
The charity mySociety (http://www.mysociety.org) that I work for makes
open-ish services.

We've been using the Affero GPL for years for lots of sites like
TheyWorkForYou, PledgeBank and FixMyStreet. Not to mention the UK
Prime Minister's E-Petitions site (http://petitions.pm.gov.uk)

Source code all here:
https://secure.mysociety.org/cvstrac/dir?d=mysociety

Francis

_______________________________________________
okfn-discuss mailing list
okfn-discuss@...
http://lists.okfn.org/cgi-bin/mailman/listinfo/okfn-discuss

[Luis Villa-3]

On 7/30/07, Francis Irving <francis@...> wrote:

> On Mon, Jul 30, 2007 at 10:42:44AM -0400, Luis Villa wrote:
> > and on the implementation
> > side (anyone implementing open-ish services- wikipedia, Red Hat,
> > Joyent(?) etc.)
>
> The charity mySociety (http://www.mysociety.org) that I work for makes
> open-ish services.
>
> We've been using the Affero GPL for years for lots of sites like
> TheyWorkForYou, PledgeBank and FixMyStreet. Not to mention the UK
> Prime Minister's E-Petitions site (http://petitions.pm.gov.uk)
>
> Source code all here:
> https://secure.mysociety.org/cvstrac/dir?d=mysociety

Cool. Definitely figured there would be a lot more, those three were
just the first that jumped to mind, as I use one weekly, work for
another, and am looking at deploying the third for personal use.

There is some challenge to doing this kind of thing in an open
environment- you want to convene only serious people who can work
together constructively, in a large enough group so as to be
representative, but small enough so as to still be capable of
constructive dialog.

I honestly haven't given much thought to it, other than to be scared
and look away; I look forward to any post-mortems SFLC does (publicly
or privately) on the GPL v3 process, which overall went fairly
smoothly.

Luis

_______________________________________________
okfn-discuss mailing list
okfn-discuss@...
http://lists.okfn.org/cgi-bin/mailman/listinfo/okfn-discuss

[Luis Villa-3]

On 7/27/07, Luis Villa <luis@...> wrote:

> On 7/27/07, Rufus Pollock <rufus.pollock@...> wrote:
> > Luis Villa wrote:
> > > On 7/27/07, Rufus Pollock <rufus.pollock@...> 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.

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.

Luis

_______________________________________________
okfn-discuss mailing list
okfn-discuss@...
http://lists.okfn.org/cgi-bin/mailman/listinfo/okfn-discuss

[Rufus Pollock]

Luis Villa wrote:

> On 7/30/07, Francis Irving <francis@...> wrote:
>> 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?
>
> My sense is that sometime in the next 6-12 months someone (perhaps
> OKFN, perhaps someone else) will have to convene an (private(?),
> invite-only(?)) summit of the key players* to hammer something out,
> much as OSI was hammered out early on, but hopefully with less
> crossfire.
>
> Luis
>
> * both on the policy side (OKFN, CC, etc.) and on the implementation
> side (anyone implementing open-ish services- wikipedia, Red Hat,
> Joyent(?) etc.)

On the idea of meeting up I think the first thing would be to put
together an OSD draft and then put that out there and solicit comments
as heavily as possible.

I also think it would be great for people to have local meetings -- as
Francis suggested we should do one here in Cambridge (UK). Whether we
could find the resources to bring people together from all over the
world is a bigger question -- perhaps it would make sense to organize
special sessions at other events (we could certainly have one at next
year's OKCON).

Regards,

Rufus

_______________________________________________
okfn-discuss mailing list
okfn-discuss@...
http://lists.okfn.org/cgi-bin/mailman/listinfo/okfn-discuss

[Rufus Pollock]

Luis Villa wrote:
> On 7/27/07, Luis Villa <luis@...> wrote:
>> On 7/27/07, Rufus Pollock <rufus.pollock@...> wrote:
>>> Luis Villa wrote:
>>>> On 7/27/07, Rufus Pollock <rufus.pollock@...> 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

_______________________________________________
okfn-discuss mailing list
okfn-discuss@...
http://lists.okfn.org/cgi-bin/mailman/listinfo/okfn-discuss

[Luis Villa-3]

On 8/1/07, Rufus Pollock <rufus.pollock@...> wrote:

> Luis Villa wrote:
> > On 7/27/07, Luis Villa <luis@...> wrote:
> >> On 7/27/07, Rufus Pollock <rufus.pollock@...> wrote:
> >>> Luis Villa wrote:
> >>>> On 7/27/07, Rufus Pollock <rufus.pollock@...> 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@... redirect to
luis.villa@..., but it only works in practice because the gmail
client also allows me to send from luis@....)

> 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

_______________________________________________
okfn-discuss mailing list
okfn-discuss@...
http://lists.okfn.org/cgi-bin/mailman/listinfo/okfn-discuss

[Francis Irving]

On Wed, Aug 01, 2007 at 09:59:00AM -0400, Luis Villa wrote:
> 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 :)

Maybe "Libre Service Definition", despite its problems in English. Or
perhaps "Freedom Service Definition".
 
> 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. :)

Worth trying definitely - I'm looking forward to seeing what you come
up with.

Francis

_______________________________________________
okfn-discuss mailing list
okfn-discuss@...
http://lists.okfn.org/cgi-bin/mailman/listinfo/okfn-discuss