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

[Luis Villa-3]

On 8/1/07, Francis Irving <francis@...> wrote:
> 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".

User Freedom Service Definition?

[Tangentially, from reading everything I can find about Prof. Moglen's
comments at OSCON, I think some of the problems we're all having in
coming to grips with this may be that 'user' used to be nearly
synonymous with (or at least deeply aligned with) 'deployer', whereas
now there is a vast gap between the identities and interests of
user-deployers and user-consumers. At OSCON, when Prof. Moglen spoke
of user freedom, he seemed focused mostly on user-deployers rather
than user-consumers, and if so, that explains a lot of the gap between
he and the SaaS crowd.]

Luis

_______________________________________________
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:
> 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).

I think I know the answer to this one, but I want to double-check: is
this intended to exclude services which depend on third-party,
non-OKD-compliant data sources? For example, if I built a geodata
service which was otherwise completely data and source available, but
used google maps to display some data to users, would that be
compliant with the definition?

>    2. Whose source code is F/OSS and *is made available*.

Similar question: if the service uses a non-F/OSS browser plugin
(e.g., Flash) or runs on a non-F/OSS OS or system service (e.g.,
Windows or Oracle) does that prevent it from being an open service,
assuming all other aspects (source, data) are open?

Luis (struggling with these line-drawing issues myself)

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

[saulalbert]

On Mon, Jul 30, 2007 at 12:28:25PM +0100, Francis Irving 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?

I'm following this thread with interest, and would be very interested
in meeting up to talk about it either in Cambridge or London.

Thanks Rufus, Francis, Luis for keeping the thread going. My feeling is
(as with many OK projects) that practice will have to lead in the end -
and the definition that works will be one that makes the services that
use it more operationally functional and profitable.

I know I'm not helping with the line-drawing issues, but services like
http://freebase.com are interesting in the sense that they're doing
exactly what an OSD would set out to prevent: relegating freely licensed
content to an abstract mess of stuff that only makes sense if you can
get to the service, their metadata, and their APIs etc.

In some ways - these counter examples might be very useful for
informing the terms of the OSD.

Cheers,

Saul.
--
The People Speak   | 17-25 Cremer St.  London E2 8HD | http://theps.net
studio [phone] | saul: [phone] | ms@...

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

[Luis Villa-3]

On 8/3/07, Saul Albert <saul@...> wrote:

> On Mon, Jul 30, 2007 at 12:28:25PM +0100, Francis Irving 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?
>
> I'm following this thread with interest, and would be very interested
> in meeting up to talk about it either in Cambridge or London.
>
> Thanks Rufus, Francis, Luis for keeping the thread going. My feeling is
> (as with many OK projects) that practice will have to lead in the end -
> and the definition that works will be one that makes the services that
> use it more operationally functional and profitable.
>
> I know I'm not helping with the line-drawing issues, but services like
> http://freebase.com are interesting in the sense that they're doing
> exactly what an OSD would set out to prevent: relegating freely licensed
> content to an abstract mess of stuff that only makes sense if you can
> get to the service, their metadata, and their APIs etc.
>
> In some ways - these counter examples might be very useful for
> informing the terms of the OSD.

They absolutely are. I've collected some examples (see the bottom of
http://live.gnome.org/FreeOpenServicesDefinition ) already, but those
are mostly positive ones- any other negative ones you've got I'm more
than happy to discuss/look at.

Note that I do agree with the proposed OKFN draft that the goal should
not be to dictate means, but merely to guarantee ends (i.e., crappy
APIs are probably OK as long as they work, privacy policies are
completely not my problem, etc.) so I may not react to freebase as
badly as you do (haven't looked at it yet. :)

Luis

_______________________________________________
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:
>> 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).
>
> I think I know the answer to this one, but I want to double-check: is
> this intended to exclude services which depend on third-party,
> non-OKD-compliant data sources? For example, if I built a geodata
> service which was otherwise completely data and source available, but
> used google maps to display some data to users, would that be
> compliant with the definition?

This is a thorny issue. There are obviously two options here:

1. (strong) A Service X is 'open' if and only if *all*
material/knowledge it uses in delivering the service is 'open' (i.e.
both all data and all code).

2. (weak) A Service X is 'open' if all material/knowledge (code and
data) provided by the runners of the service themselves is open (but any
third party material is not).

Personally I incline towards the first definition since I feel the
'exception' in 2 can made so wide as to render the definition valueless.
  Sure this may then mean that a few services that are 99% open but used
a closed data source for some small item would be excluded but that's
the way with drawing a line -- you always have to draw it somewhere.

This also has some analogies with packaging efforts such as debian: all
of the core has to be 'free' but they do allow users to plug in
'non-free' components (such as video card drivers or other proprietary
libraries). The same thing could happen here with the providers of open
services leaving it up to users to plug in closed stuff to their
particular installation.

>>    2. Whose source code is F/OSS and *is made available*.
>
> Similar question: if the service uses a non-F/OSS browser plugin
> (e.g., Flash) or runs on a non-F/OSS OS or system service (e.g.,
> Windows or Oracle) does that prevent it from being an open service,
> assuming all other aspects (source, data) are open?
>
> Luis (struggling with these line-drawing issues myself)

Well I think again this goes back to the debian analogy. If you provide
a system that has an essential non-open component (whether in the form
of code or data) then that system is *not* open. If the item is an
optional add-on then I think you are ok. So, for example, firefox is
definitely open source even though the flash plugin may be proprietary
(though if the flash plugin became absolutely essential to using firefox
this might start to be debatable).

Regards,

Rufus

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

[Julian Priest]

Rufus Pollock wrote:

> Well I think again this goes back to the debian analogy. If you provide
> a system that has an essential non-open component (whether in the form
> of code or data) then that system is *not* open. If the item is an
> optional add-on then I think you are ok. So, for example, firefox is
> definitely open source even though the flash plugin may be proprietary
> (though if the flash plugin became absolutely essential to using firefox
> this might start to be debatable).

:) bit of a tangent but last week installing Debian I found..

Yes - Firefox is definitely open source, but Firefox's trademarked logo
conflicts with the Debian Free Software Guidelines so Debian won't ship
it any longer!

They instead ship the Firefox code base with an open logo under the name
'Ice Weasel'

http://en.wikipedia.org/wiki/Naming_conflict_between_Debian_and_Mozillao#Iceweasel

This discussion maybe has some relevance for Open Services.

In popular web services the name, domain name and logo become publicly
recognised as people use the service and recommend it to others. This
process self reinforces as participation increases -  public awareness
of 'the brand' increases until it has common currency.

In a sense use value ends up accruing in the public recognition of the
name and the brand.

In proprietary services this recognition is a large part of what is
packaged up for sale or investment often for millions of dollars at IPO
time.

In the Firefox case the Mozilla Corporation say they are protecting the
brand against dilution or appropriation by trademarking it- maintaining
public faith in F/OSS.

How should these branding issues be handled in Open Services?

cheers

/julian


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

[Rufus Pollock]

Julian Priest wrote:

> Rufus Pollock wrote:
>
>> Well I think again this goes back to the debian analogy. If you provide
>> a system that has an essential non-open component (whether in the form
>> of code or data) then that system is *not* open. If the item is an
>> optional add-on then I think you are ok. So, for example, firefox is
>> definitely open source even though the flash plugin may be proprietary
>> (though if the flash plugin became absolutely essential to using firefox
>> this might start to be debatable).
>
> :) bit of a tangent but last week installing Debian I found..
>
> Yes - Firefox is definitely open source, but Firefox's trademarked logo
> conflicts with the Debian Free Software Guidelines so Debian won't ship
> it any longer!
>
> They instead ship the Firefox code base with an open logo under the name
> 'Ice Weasel'

Yes I'd noticed this on a machine recently and wondered about it ...

> http://en.wikipedia.org/wiki/Naming_conflict_between_Debian_and_Mozillao#Iceweasel

Very interesting though you might want to drop that trailing o on
Mozillao :)

http://en.wikipedia.org/wiki/Naming_conflict_between_Debian_and_Mozilla#Iceweasel

> This discussion maybe has some relevance for Open Services.

It certainly does. Thanks for bringing it up.

> In popular web services the name, domain name and logo become publicly
> recognised as people use the service and recommend it to others. This
> process self reinforces as participation increases -  public awareness
> of 'the brand' increases until it has common currency.
>
> In a sense use value ends up accruing in the public recognition of the
> name and the brand.

Though only so much. Look how effectively supermarkets have been able to
sell their lower-priced substitutes for big-brand products ...

> In proprietary services this recognition is a large part of what is
> packaged up for sale or investment often for millions of dollars at IPO
> time.
>
> In the Firefox case the Mozilla Corporation say they are protecting the
> brand against dilution or appropriation by trademarking it- maintaining
> public faith in F/OSS.
>
> How should these branding issues be handled in Open Services?

As I've earlier stated in relation to the 'identity' issue (i.e. the
problem of becoming identified with a url controlled by the service
provider a la gmail/myspace ...) I think this *is* a problem but *not* a
problem an open service definition should address. In my view this is up
to the user not the service, and if the service manages to build a big
brand for itself while remaining open well bully for the
service-provider :) -- just as I don't mind Firefox getting all
protective about their 'brand' as long as the code stays open).

~rufus

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