[okfn-discuss] Open Service Definition (revisited)
luis at tieguy.org
Mon Jul 30 17:26:21 UTC 2007
On 7/27/07, Luis Villa <luis at tieguy.org> wrote:
> On 7/27/07, Rufus Pollock <rufus.pollock at okfn.org> wrote:
> > Luis Villa wrote:
> > > On 7/27/07, Rufus Pollock <rufus.pollock at okfn.org> wrote:
> > [snip]
> > >> 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.
More information about the okfn-discuss