No subject

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

Mike

-- 
https://creativecommons.net/ml

--001636499453a2df54049a7da54a
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div class=3D"gmail_quote">On Fri, Jan 21, 2011 at 5:09 AM, Rufus Pollock <=
span dir=3D"ltr">&lt;<a href=3D"mailto:rufus.pollock at okfn.org">rufus.polloc=
k at okfn.org</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

I think the change of position at CC (there clearly has been one) is<br>
almost certainly due to groups like OSM and their concerns and the<br>
work in this area by ODC, OSM and others.<br></blockquote><div><br>It&#39;s=
 due to many things:<br>- consolidation of CC education and science &quot;d=
ivisions&quot; facilitated examination of domain-specific policies, increas=
ed policy coherence;<br>
- discussions with CC affiliates, many very involved in promoting open publ=
ic sector information, including data;<br>- existence many projects using C=
C licenses for data, eg in various governments, Freebase ... and OSM;<br>
- sense of massive competitive threat from non-open data; the main alternat=
ive to public domain is not sharing at all -- absence of a strong CC presen=
ce, except for a normative one in science, is a correspondingly massive opp=
ortunity cost for society;<br>
- high point (well, so far ... long way since launching, then retiring devn=
ations) 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, inter=
operability and standards before any single tool or policy idea that sounds=
 good on its own.<br>
<br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0.=
8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">