No subject
Sun Dec 12 18:29:16 UTC 2010
<br>
1. A lot of thought (much from OSM) went into drafting the ODbL.<br>
Data(base)s are different from content (just as content was different<br>
from code) and they need specific thought (if anything 'content' is=
<br>
closer to code than data is to contentyet CC created a set of<br>
licenses even though the GPL, MIT/BSD etc all already existed).<br></blockq=
uote><div><br>I think it's fairly obvious that there's much more ov=
erlap between "content" and "data[bases]" than either a=
nd "code" -- the first two often contain each other, or are aspec=
ts 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 2=
050 copyright and related restrictions still exist there is a single domina=
nt copyleft instrument across all these domains), code and (content, data) =
rarely mix in a way that triggers need for license compatibility among them=
.<br>
<br>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.<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;">
Even if CC do address data in their upgrade they are going to need to<br>
have stuff in there looks pretty like the ODbL.<br></blockquote><div><br>I =
won't profess to know in advance. I am in general pretty confident in o=
ur (meaning the community of people who care about the commons and public l=
icenses) to learn how to do it better, for an "it" with increasin=
g scope (mostly from observing free software).<br>
=C2=A0</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;">
2. The contract issue argument about ODbL being bad ('ODbL introduces<b=
r>
contract) is, in my opinion, a) bogus b) a red-herring. CC licenses<br>
are contracts too, right ... [1]<br></blockquote><div><br>No, characterizat=
ion of CC (or GNU, or ODC, etc) licenses and licenses or contracts is irrel=
evant here (and a fairly narrow, incredibly boring topic in my experience o=
nly of interest to lawyers overly attached to whatever legal tradition they=
were schooled in ... I'm sure I misunderstand and exaggerate, apologie=
s). The issue is whether the instrument in question grants permissions whic=
h can be thought of as carve outs from copyright and related restrictions, =
or whether the instrument also attempts to create new restrictions which ar=
e not present by default. I assume the latter extremely dangerous until pro=
ven otherwise -- exceptions and limitations ought be increased, not diminis=
hed. Any public license that attempts to work around limitations had better=
have a truly massive and clear win for doing so.<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;">
3. The ODbL already supports the concept of compatible licenses. If CC<br>
licenses do reach the point that they support data then this should<br>
provide a way to interope (or even migrate) to that license if a<br>
particular organization so wishes.<br></blockquote><div><br>Credit for incl=
uding 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 t=
o in the future prove to be important mechanisms for growing the commons. F=
or 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.<br>
<br>Mike<br></div></div><br>-- <br><a style=3D"color:rgb(204, 204, 204)" hr=
ef=3D"https://creativecommons.net/ml" target=3D"_blank">https://creativecom=
mons.net/ml</a><br>
--001636499453a2df54049a7da54a--
More information about the odc-discuss
mailing list