[okfn-discuss] Open Service Definition (revisited)

Tue Aug 21 21:28:51 UTC 2007

On 8/21/07, Mike Linksvayer <ml at creativecommons.org> wrote:
> On Wed, 2007-08-01 at 09:59 -0400, Luis Villa wrote:
> > On 8/1/07, Rufus Pollock <rufus.pollock at okfn.org> 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 :)
>
> Yikes.  OTOH UCSD rolls off the tongue and UC San Diego needs to stop
> dominating the top search results for UCSD. :)

Yeah, I didn't say I liked it, just that 'open' is (sadly) brutally
abused at this point.

> > > 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 are part of the market.  Even if one considers the market to consist
> only of publicly listed companies or some such silly thing, some of your
> work on this was in the employ of just such an entity. :)  But this is
> all beside the point.

> I may have missed a cogent argument, but mandating a level of
> reliability seems silly to me.  GPL doesn't regarding source
> availability -- just "equivalent copying facilities" to and directions
> from the location of the object code.  Similarly, I conjecture that a
> service can be free when it is up, and not a service when it is down.

Sure, but one of the freedoms is (for lack of a better term) a
'freedom to leave', and you can't well do that if your data has been
locked up or otherwise gone away.

That said, I'm now coming around to the idea that perhaps a better
formulation is to require appropriate notification in the case of
*intentional* cessation of service/data lockup- that is much less
burdensome for the service provider, while still providing a
reasonable opportunity for users to protect themselves.

> > 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.
>
> "Openness" is pretty vague, success seems very partial,

Sure; this is all pretty high-level discussion ATM, so I was
deliberately a little vague. By 'openness' I mean 'open source', and
by success I mean 'increased user freedom'. YMMV.

(Again, sad I'll be missing you in SF later this week; would love to
talk about this more in person.)

> and source
> (right to modify and share modifications, not just access) seems to be
> the linchpin.  What were the other critical parts?  I suspect I'm just
> being ignorant here, but I mean the question seriously.

Mostly data and operating system/hardware control. If I've got source,
but someone else has the data (and can technically and/or legally
prevent me from making my own copy) that other party still has me by
the balls- 'openness' of the source means very little then. If I've
got source, but I can't actually run the thing (either because I lack
the hardware or the OS) then, again, openness has very little value.
I'd say the first (data) is more problematic and more tractable, esp.
since no license can force the provision of hardware, but both are
things we take for granted in open source right now.

> > 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.
>
> Presumably that means user controlled/transferable names.

names->identity, really.

Which is hard, but I've started talking a bit to some identity folks,
and it isn't undoable- openid-like systems (or more appropriately,
email-like systems which allow forwarding and delegation of identity)
are still rare but are becoming more common and could be baked in from
day one if people were very serious about it. (Unlikely that you'd
want to bake that into the license or definition, but it bears
thinking about.)

Luis