[odc-discuss] Fwd: [OSM-legal-talk] LWN article on license change and Creative Commons

Mike Linksvayer ml at creativecommons.org
Sun Jan 23 06:32:27 UTC 2011

On Fri, Jan 21, 2011 at 5:09 AM, Rufus Pollock <rufus.pollock at okfn.org>wrote:

> I think the change of position at CC (there clearly has been one) is
> almost certainly due to groups like OSM and their concerns and the
> work in this area by ODC, OSM and others.

It's due to many things:
- consolidation of CC education and science "divisions" facilitated
examination of domain-specific policies, increased policy coherence;
- discussions with CC affiliates, many very involved in promoting open
public sector information, including data;
- existence many projects using CC licenses for data, eg in various
governments, Freebase ... and OSM;
- sense of massive competitive threat from non-open data; the main
alternative to public domain is not sharing at all -- absence of a strong CC
presence, except for a normative one in science, is a correspondingly
massive opportunity cost for society;
- high point (well, so far ... long way since launching, then retiring
devnations) of shift of CC as purveyor of a variety of tools and policies to
CC as steward of the commons, and thus need to put global maximization,
interoperability and standards before any single tool or policy idea that
sounds good on its own.

>From ODC perspective, looking at that discussion, I think the main
> things to emphasize are:
> 1. A lot of thought (much from OSM) went into drafting the ODbL.
> Data(base)s are different from content (just as content was different
> from code) and they need specific thought (if anything 'content' is
> closer to code than data is to contentyet CC created a set of
> licenses even though the GPL, MIT/BSD etc all already existed).

I think it's fairly obvious that there's much more overlap between "content"
and "data[bases]" than either and "code" -- the first two often contain each
other, or are aspects of the same thing, while code usually accesses content
and data by some sort of reference. This is extremely important for license
interoperability -- although I occasionally have nightmares about it (and
hope that if in 2050 copyright and related restrictions still exist there is
a single dominant copyleft instrument across all these domains), code and
(content, data) rarely mix in a way that triggers need for license
compatibility among them.

Clearly a whole lot of thought has gone into the ODbL, including some I know
intended to mitigate need for the usual sort of license compatibility, as I
noted in at least one reply on LWN.

Even if CC do address data in their upgrade they are going to need to
> have stuff in there looks pretty like the ODbL.

I won't profess to know in advance. I am in general pretty confident in our
(meaning the community of people who care about the commons and public
licenses) to learn how to do it better, for an "it" with increasing scope
(mostly from observing free software).

> 2. The contract issue argument about ODbL being bad ('ODbL introduces
> contract) is, in my opinion, a) bogus b) a red-herring. CC licenses
> are contracts too, right ... [1]

No, characterization of CC (or GNU, or ODC, etc) licenses and licenses or
contracts is irrelevant here (and a fairly narrow, incredibly boring topic
in my experience only of interest to lawyers overly attached to whatever
legal tradition they were schooled in ... I'm sure I misunderstand and
exaggerate, apologies). The issue is whether the instrument in question
grants permissions which can be thought of as carve outs from copyright and
related restrictions, or whether the instrument also attempts to create new
restrictions which are not present by default. I assume the latter extremely
dangerous until proven otherwise -- exceptions and limitations ought be
increased, not diminished. Any public license that attempts to work around
limitations had better have a truly massive and clear win for doing so.

3. The ODbL already supports the concept of compatible licenses. If CC
> licenses do reach the point that they support data then this should
> provide a way to interope (or even migrate) to that license if a
> particular organization so wishes.

Credit for including a compatibility clause. This is of course a pretty
heavyweight thing, requiring one or both license stewards to decide they can
credibly assert compatibility between two instruments, and a project to
avail itself of the option. Time will tell whether compatibility hooks that
stewards may add to in the future prove to be important mechanisms for
growing the commons. For better or worse, the most pertinent experience so
far (FDL 1.3/CC-BY-SA 3.0) involved a narrow, time-limited, specific
mechanism than a general one. Still a good mechanism to include, so long as
stewards act well.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.okfn.org/pipermail/odc-discuss/attachments/20110122/c4d3a7e6/attachment-0001.html>

More information about the odc-discuss mailing list