[okfn-discuss] OSSD and Service Orientation

Rufus Pollock rufus.pollock at okfn.org
Thu May 21 09:29:20 UTC 2009

2009/5/21 John Bywater <john.bywater at appropriatesoftware.net>:
> Mike Linksvayer wrote:
>> I prefer the current version.  There is no point defining "web
>> service" here.  "web-API" covers that case.
> I agree about that. But I do feel that both "service" and "software
> service" could have explicit definitions. Neither currently do. (Anyway,
> how about "Web API" instead of "web-API"?)
> Also, whilst I remember, there appears to be an aspect that is entirely
> missing: requiring that all open software service dependencies are also
> open software services. Dependency services appear not to be mentioned.

No this is not mentioned because there never seemed to be a consensus
position on this! It was discussed extensively, see e.g.:


Whose summary on this I quote below.

I'd be open to a clarification on this, perhaps by the introduction of
an additional note item. What do people think?


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.

More information about the okfn-discuss mailing list