[okfn-discuss] Re: Open Service Definition

[Rufus Pollock]

Francis Irving wrote:
> On Tue, Oct 31, 2006 at 09:55:50AM +0000, Rufus Pollock wrote:
> 
>>  * Its data is open as defined by the open knowledge definition 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 like that.
>  
> 
>>>The latter isn't strong enough, I don't think. At least if that means
>>>"the code is licensed under an open source license". It has to be
>>>that the running code on the server is publically downloadable and
>>>that that download is licensed under an open source license.
>>
>>Again I agree the source code should be F/OSS and must be made available 
>> (this ties into the open knowledge definition's social access 
>>requirement: not only should be allowed to get the information but you 
>>should actually be able to do so).
> 
> 
> Oh, this is interesting! I think what I might be trying to say is that
> the source code to the service's server software must be open
> knowledge, under the Open Knowledge Definition.

Or that the software must be open-source (see section below for 
extensive discussion of whether the OKD is more extensive than the OSD).

> In this case the Open Knowledge Definition has stronger requirements
> upon redistributors than the GPL does. The GPL only requires that
> you get the source if you get the binary (even version 3, alas).
> Whereas the OKD "The work shall be available as a whole and at no more
> than a reasonable reproduction cost, preferably downloading via the
> Internet without charge"

It is kind of odd to say "My software is GPL'd but I don't give it out" 
since it renders the licensing (or not) completely meaningless -- but as 
you point out that does seem to be the case with services.

In that sense it is true that there is an explicit **access** 
requirement in the OKD: if you want to call your data open you have 
actually got to make it available. I suppose there was some concern with 
the F/OSS licenses that you didn't want to obligate people to publish: 
if I get GPL code and then just write a little script that I use on my 
computer derived from that code should I be forced to publish it?

With the OKD this question doesn't arise since we are defining a set of 
principles that define whether a piece of knowledge is open or not (so 
we don't have to worry about the recursion on derivative works). However 
when designing a license that incorporated a 'viral' clause you'd need 
to think harder about including a requirement to make available.

	*	*	*

Your point about the binary vs. source is interesting. In software this 
is such a central disctinction that it actuall results in the naming: 
'open source'. For the OKD we've tried to address this issue under:

<quote>
4. Absence of Technological Restriction

The work must be provided in such a form that there are no technological 
obstacles to the performance of the above activities. This can be 
achieved by the provision of the work in an open data format, i.e. one 
whose specification is publicly and freely available and which places no 
restrictions monetary or otherwise upon its use.
</quote>

This is supposed to catch cases where you provide your data (e.g. the 
database dump) in some weird binary format that can only be run in a 
restrictive viewer.

> So, although the OKD explicitly excludes software "because it is
> already adequately addressed by previous work", in this case I want to
> use it for software. I think that means that I disagree with the OKD
> in that one regard - the previous work (i.e. that of the Free Software
> Foundation, mainly) does NOT adequately address software being open
> knowledge.

## Is the OKD more extensive than the OSD

This is a good point though I have some reservations.

First, we should be careful here about distinguishing between principles 
and licenses. The OKD defines a set of general principles which define 
the 'open' in open knowledge, i.e. as we state at the top of the OKD: "A 
work is open if its manner of distribution satisfies the following 
conditions: ..."

Second, I do think the access requirement is implicit in the OSD (open 
source definition) which starts: "Open source doesn't just mean access 
to the source code. The distribution terms of open-source software must 
comply with the following criteria: ...". This seems to me to clearly 
imply that a work is not 'open source' if I don't actually have access 
to the source code.

This is the nub of the problem: person A writes some software and 
licenses it under the GPL and then person B takes it and modifies and 
runs it on his webserver and does **not** redistribute the code. Here 
there is no violation of the GPL -- and note that no-one (including 
person B) considers their software to be F/OSS. But the whole point of 
GPLing was to ensure that people making derivative works also had to 
make their software F/OSS.

The OKD suffers from the same problem in that respect: if I take a work 
licensed, say, under CC by-sa and I modify it I don't have to make it 
available.

> So what I think I want to say is that "The software running on
> the computers which provide the service must be available 
> under an open source software license (as defined by the
> Open Source Initiative), AND the source code of that software must
> satisfy requirement 1. Access of the Open Knowledge Definition".

Yes although, as stated, I think the OSD also covers this.

> Which leads me to wonder if it would be simpler to just say the
> software must meet the OKD, although there is the question of
> compatibility with existing open source licenses.

Well, as explained above you could just say the software must be 
open-source as that does require access. The confusion arises here, as 
explained above, from the fact that I can make derivatives even of GPL 
works and use them to provide services while not making them F/OSS.

>>though I'm not sure that calls to non-open web services would be a
>>problem. Sure it would render the service pretty useless without
>>access to them but one allows F/OSS software to use non F/OSS
>>libraries (e.g. Windows APIs ...)
> 
> 
> Oh, I think calls to non-open web services are an enormous problem.
> They could create an indirect dependency by you upon any closed
> knowledge and closed source software. They may make it impossible for
> anybody else to implement a similar service using commonly available
> data and software. They potentially remove the possibility of
> competition, and the ability of you to migrate to a new service.
> 
> The difference with F/OSS software was that /all/ it could depend on
> is the core of Windows, or whatever. Nowdays you could create a
> proprietary service which depended on all sorts of things.
> 
> Hmmm, I'm going to get myself into a mess here. Because as soon as you
> go along this route, you exclude yourself from using any external API
> calls. e.g. Taking credit card transactions, or calling out to a
> travel agency API to buy tickets. Which would make much of the open
> service software useless, only allowing self contained stuff like
> office suites. Which would be bad.
> 
> This needs quite some careful though, starting from goals again.

I'd agree.

> Did you have some sort of drafting process for the Open Knowledge
> Definition?

Yes -- and this (i.e. discussion on list) is a big part of it. There is 
also a 'development' version of the definition which anyone can edit at:

   http://okd.okfn.org/dev/

Regards,

Rufus