Open Service Definition (revisited)

[Luis Villa-3]

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

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

While I have my own (strong) opinions on mark/brand in an open
context, I do agree with Rufus here that an open service definition is
probably not the place to handle this particular problem. To the
extent that it is a problem at all, it is probably best handled using
the integrity clauses of the data and software licenses- I've tried to
find examples that would not be covered by those two, but failed.

Luis

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

[Mike Linksvayer-2]

On Fri, 2007-08-03 at 09:17 -0400, 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?
>
> >    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?

I suspect both of these cases can be simplified and analyzed as if the
service were running on the same machine as the browser.  If the now
local service depends on non-free local program, remote services, data,
or codecs, could it ship in Debian main?  I guess 1 maybe and 2 no.
However one could expand the single-machine (or perhaps more usefully,
everything comes from a hypothetical Debian main that incorporates
everything free) such that remote dependencies are local, then 1 is also
no.

I don't know whether this is a useful analogy, but it seemed kind of
interesting to me.  Of course it leads one to be more stringent about
services than local software -- lots of free software is Windows-only,
for example.

--
  http://wiki.creativecommons.org/User:Mike_Linksvayer


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

[Mike Linksvayer-2]

On Wed, 2007-08-01 at 09:59 -0400, Luis Villa wrote:
> On 8/1/07, Rufus Pollock <rufus.pollock@...> 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. :)

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

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

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


--
  http://wiki.creativecommons.org/User:Mike_Linksvayer


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

[Luis Villa-3]

On 8/20/07, Mike Linksvayer <ml@...> wrote:

> On Fri, 2007-08-03 at 09:17 -0400, 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?
> >
> > >    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?
>
> I suspect both of these cases can be simplified and analyzed as if the
> service were running on the same machine as the browser.  If the now
> local service depends on non-free local program, remote services, data,
> or codecs, could it ship in Debian main?  I guess 1 maybe and 2 no.
> However one could expand the single-machine (or perhaps more usefully,
> everything comes from a hypothetical Debian main that incorporates
> everything free) such that remote dependencies are local, then 1 is also
> no.
>
> I don't know whether this is a useful analogy, but it seemed kind of
> interesting to me.  Of course it leads one to be more stringent about
> services than local software -- lots of free software is Windows-only,
> for example.

Not only is lots of free software currently Windows-only, at one time
*all* free software was proprietary-OS only, and my sense is that the
current service situation is a lot closer to that period historically
than it is to the modern situation (where there are multiple viable
Free/Open operating systems, like Debian.)

This doesn't necessarily mean that we should allow non-free services
in this way, but I think it means that (realistically) some of them
have to be allowed into the stack at some point until open services
become more common, which makes Debian a tough point for comparison.

Luis

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

[Luis Villa-3]

On 8/21/07, Mike Linksvayer <ml@...> wrote:
> On Wed, 2007-08-01 at 09:59 -0400, Luis Villa wrote:
> > On 8/1/07, Rufus Pollock <rufus.pollock@...> 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

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

[saulalbert]

On Tue, Aug 21, 2007 at 05:17:04PM -0400, Luis Villa wrote:

> Not only is lots of free software currently Windows-only, at one time
> *all* free software was proprietary-OS only, and my sense is that the
> current service situation is a lot closer to that period historically
> than it is to the modern situation (where there are multiple viable
> Free/Open operating systems, like Debian.)
>
> This doesn't necessarily mean that we should allow non-free services
> in this way, but I think it means that (realistically) some of them
> have to be allowed into the stack at some point until open services
> become more common, which makes Debian a tough point for comparison.

That seems to be a good analogy.

The line-drawing of open services between brand, service identity, API,
reliability, documentation, underlying systems, data licensing and other
considerations is hard but useful.

The more aspects that can be seen as infrastructural, and therefore
needing to adhere to a debian-like rigorous openness, the better in my
opinion because that would allow greater flexibility. How those
services are then monetised or achieve 'brand recognition' is not
really the problem we're seeking to address. They'll work it out :)

However, what will win out is probably what works best from a
commercially competitive standpoint once the browser dies. I hope that
happens soon.

At the moment web browsers are currently a very clunky way to handle
complex data and relationships. Pretty soon, like yesterday, I'm going
to want to be able to interact with my data and its relationships in far
more interesting ways than most services make possible. I know some
interesting people building interesting and potentially very useful
software and services that should help me do that... but having lots of
incompatible and scattered APIs with dubious attempts structuring their
data isn't going to help them make it happen.

Imho, the valuable asset that the non-open service providers are sitting
on is the ability to make cross-references and complex queries on their
data sets, which they are probably only using to do 'clever' marketing.
So that value - the means of association - is really the core of what
the OSD needs to address.  Balancing this ability against privacy
concerns between users is the real issue - and coming up with facilities
that by virtue of their openness *just work better* and make more useful
things possible. That's when a landscape of open services could start to
threaten the walled gardens of web2.0 services.

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

[Mike Linksvayer-2]

On Tue, 2007-08-21 at 17:28 -0400, Luis Villa wrote:

> On 8/21/07, Mike Linksvayer <ml@...> wrote:
> > > 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,

AFAICT the identity folks are not focused on the part that would
transfer power back to users -- delegable service addresses.  The
technology required is ancient -- owning your own domain -- and often
used to transparently and relatively costlessly move between low level
service providers (eg email).

> and it isn't undoable- openid-like systems (or more appropriately,
> email-like systems which allow forwarding and delegation of identity)

OpenID and the like are fine, but marginally relevant.  I'm far more
interested in being able to tell the world where I want them to access
"my" service (eg imagine images.mike.com, powered by flickr) than being
able to tell my service provider how to tell who I am.

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

It may have no place in a definition, but "can I transparently move,
without cooperation (apart from data access) from my service provider"
is a pretty important consideration for anyone who wants to keep control
rather than cede control to service providers.

--
 http://wiki.creativecommons.org/User:Mike_Linksvayer


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

[Luis Villa-3]

On 8/23/07, Mike Linksvayer <ml@...> wrote:

> On Tue, 2007-08-21 at 17:28 -0400, Luis Villa wrote:
> > On 8/21/07, Mike Linksvayer <ml@...> wrote:
> > > > 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,
>
> AFAICT the identity folks are not focused on the part that would
> transfer power back to users -- delegable service addresses.  The
> technology required is ancient -- owning your own domain -- and often
> used to transparently and relatively costlessly move between low level
> service providers (eg email).
>
> > and it isn't undoable- openid-like systems (or more appropriately,
> > email-like systems which allow forwarding and delegation of identity)
>
> OpenID and the like are fine, but marginally relevant.  I'm far more
> interested in being able to tell the world where I want them to access
> "my" service (eg imagine images.mike.com, powered by flickr) than being
> able to tell my service provider how to tell who I am.

OpenID allows you to specify service providers, so, for example, if
you know that I am http://tieguy.org/, you can query that to see where
my images are hosted. This allows me to do the kind of thing you're
talking about.

Luis

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

[Mike Linksvayer-2]

Luis Villa wrote:

> On 8/23/07, Mike Linksvayer <ml@...> wrote:
>> OpenID and the like are fine, but marginally relevant.  I'm far more
>> interested in being able to tell the world where I want them to access
>> "my" service (eg imagine images.mike.com, powered by flickr) than being
>> able to tell my service provider how to tell who I am.
>
> OpenID allows you to specify service providers, so, for example, if
> you know that I am http://tieguy.org/, you can query that to see where
> my images are hosted. This allows me to do the kind of thing you're
> talking about.

After useful software that understands HTTP, URLs, and DNS also
understands a layer of OpenID indirection.

Mike

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

[Luis Villa-3]

On 8/27/07, Mike Linksvayer <ml@...> wrote:

> Luis Villa wrote:
> > On 8/23/07, Mike Linksvayer <ml@...> wrote:
> >> OpenID and the like are fine, but marginally relevant.  I'm far more
> >> interested in being able to tell the world where I want them to access
> >> "my" service (eg imagine images.mike.com, powered by flickr) than being
> >> able to tell my service provider how to tell who I am.
> >
> > OpenID allows you to specify service providers, so, for example, if
> > you know that I am http://tieguy.org/, you can query that to see where
> > my images are hosted. This allows me to do the kind of thing you're
> > talking about.
>
> After useful software that understands HTTP, URLs, and DNS also
> understands a layer of OpenID indirection.

You make it sound as if the first three are rare, but sure :)

Luis

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