[odc-discuss] An attribution-only version of the open database license

Wed Nov 18 18:10:20 UTC 2009

2009/11/18 Matt Amos <zerebubuth at gmail.com>:
> On Wed, Nov 18, 2009 at 2:26 PM, Rufus Pollock <rufus.pollock at okfn.org> wrote:
>> 2009/11/18 Matt Amos <zerebubuth at gmail.com>:
>>> On Wed, Nov 18, 2009 at 11:13 AM, Frederik Ramm <frederik at remote.org> wrote:
>>>>
> [...]
>>> sure. but there are some who would argue that "SA" licenses are a step
>>> away from open, and then we just end up having a license holy war.
>>
>> This isn't about "holy war" but something very practical: license
>> compatibility and the integrity of the "open" commons. The core of a
>> "commons" of data (or code) is that one piece of "open" material
>> contained therein can be freely intermixed with other "open" material.
>
> that's your definition of "open", though. part of the point i was

You are right that anyone can define "open" (data) how they like :) --
just as with open source (one of bunch of people can say it means X
but another bunch can say it means Y)

However, I think communities can still make efforts to get a shared
meaning and that's what we're debating here (I think!).

> trying to make is that different people and companies have different
> definitions of "open" and, while i like your definition, it's not a
> widely-used definition yet.

If so we should be working to make it more widely used :)

> [...]
>> Share-alike or attribution requirements are allowed within the
>> definition precisely because they do not break this interoperability
>> (and may even help promote the commons by ensuring material is "shared
>> back").
>
> except when it needs to be shared back to a project which is
> attribution-only or PD. in that situation, taking PD/BY data and
> releasing it under an SA/BY-SA license is allowed, but breaks

Remember that simply releasing it under the SA or BY-SA license would
be meaningless -- the original PD/BY license would still be in
operation. However, I assume you mean taking that original data,
adding to it and then releasing the results as BY-SA.

> interoperability with the original dataset.

I'm not sure I would say it breaks interoperability. Someone else
could still intermix the two. However, I take your point that it
couldn't be merged back into the original community's set of data.
(This kind of thing obviously comes up a lot in code ...)

> [...]
>> To reiterate: it is a mistake to view the set of licenses as some
>> continuous spectrum of 'openness' with PD at one end and full rights
>> reserved at the other -- with the implication that all licenses in
>> between are more or less open.
>
> there was no such implication of a one-dimensional total ordering.
> however, two similar licenses can be compared. for example, adding an
> NC clause to any license which didn't discriminate against commercial
> use means removing some freedoms, adding some restrictions, being
> "less open".

Agreed. What I was really trying to get at it here (and I hope there
was no misunderstanding of your point) was that that while SA and NC
could both be seen as adding some restrictions -- and therefore being
"less open" (than PD) -- there was a significant difference between
their impact, a difference which meant one could still term SA open
while NC was not.

>> There are significant discontinuities and in particular we can
>> meaningfully partition the set of licenses into open and not-open
>> based on a) their interoperability b) the freedom they provide to
>> *all* persons (and companies) to use, reuse and redistribute.
>
> again, for your definition of "open". dropping paragraph 8 of your
> definition (and some other wording tweaks) would lead to a partition
> no less meaningful, but which would include NC licenses.

But dropping that requirement would rapidly lead to lack of
interoperability since there are many possible restrictions on "fields
of endeavour".

That said I take your point that one could have a setup where, say,
non-commercial and attribution were the only restrictions permitted
and this would be a self-consistent interoperable set. However it
wouldn't permit access and use by everyone (key aspects of a "commons"
...)

[...]

>> There would be no desire to get a trademark here but I do think we
>> should be making an effort to have a clear meaning for "open" in
>> relation to data and content along the lines of
>> http://opendefinition.org/ -- just as the open source definition has
>> done for code.
>
> well, the thing about the trademark was supposed to be a joke. but it
> would be interesting to do a review of available geodata sources and
> see if they fit your definition.

That's what ckan.net is partly about (it's main purpose is to enable a
"debian of data" ...). I would note that just as for software one
wouldn't expect most data (as yet!) to be open source. Here are
packages tagged with 'geo' or 'geodata':

<http://www.ckan.net/tag/read/geo>
<http://www.ckan.net/tag/read/geodata>

Rufus

PS: the reason tiger didn't have a download url was that there isn't a
single point to get the dataset (which is what the download url was
supposed to point to when we first started CKAN). We've now got more
liberal on what the download url points to and I've updated the
package to reflect this: <http://www.ckan.net/package/tiger-geodata>