<div class="gmail_quote">On Fri, Dec 4, 2009 at 1:04 AM, Matt Amos <span dir="ltr"><<a href="mailto:matt@asklater.com">matt@asklater.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
80n wrote:<div class="im"><br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
On Thu, Dec 3, 2009 at 4:05 PM, Matthias Urlichs <<a href="mailto:matthias@urlichs.de" target="_blank">matthias@urlichs.de</a> <mailto:<a href="mailto:matthias@urlichs.de" target="_blank">matthias@urlichs.de</a>>> wrote:<br>

<br>
    On Do, 2009-12-03 at 15:09 +0000, 80n wrote:<br>
     > You've tried to show that you've addressed the question of complexity<br>
     > in your proposal document by referencing a human readable version of<br>
     > the license.<br>
<br>
    That's a totally sensible thing to do when the original document cannot<br>
    be simplified.<br>
<br>
    Please tell us exactly what you think can be simplified instead of<br>
    simply calling for unspecific simplification, particularly this late.<br>
<br>
I'm not calling for simplification.  I'm calling for the LWG to properly acknowledge the risks associated with a compex legal agreement.<br>
</blockquote>
<br></div>
ok - that's something constructive i can raise at the LWG meeting... uhh... later today.<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
     > The ODbL is a complex license that is new and untried.<br>
<br>
    True. We don't know that there are risks involved with the ODbL, an we<br>
    don't know whether it's broken.<br>
<br>
    However, we DO know that the current CC license is SEVERELY broke.<br>
<br>
<br>
Maybe it's one of those things that doesn't work in theory but does work in practice.  OSM has been using it very successfully for over five years now without any serious problems.<br>
</blockquote>
<br></div>
who was it that said something like "absence of evidence is not evidence of absence"? we had the same discussion on legal-talk a while ago and there was a variety of opinion, but i stick by the basic principle; if several civil engineers (lawyers) tell you that your house (license) is likely to fall down (be legally indefensible) and suggest something better, wouldn't that be good advice to heed?<div class="im">
<br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
If it's SEVERLY broke then you'd have to say that OSM itself is SEVERLY broken and there's nobody saying that.<br>
</blockquote>
<br></div>
i don't follow your reasoning. CC BY-SA is severely broken, but no-one is saying that OSM is fundamentally broken. the license is broken, but that's just one element, and one that we can fix.<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
There are however multiple risks associated with the license change that could break the project.  In the most general terms the ones that come to mind are:<br>
</blockquote>
<br></div>
my personal feeling is that the project is as strong as its community and that our community is intelligent and strong enough to survive a license change.<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
* The assignment of rights to OSMF introduces a range of potential failure points<br>
</blockquote>
<br></div>
there is no assignment of rights to OSMF. we discussed this in the meeting which you cited earlier. the contributor terms leaves full database and copyrights (if any) with the author and OSMF is only a licensee.<div class="im">
<br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
* The lack of any coherent license and therefore protection for the database content (as opposed to the database)<br>
</blockquote>
<br></div>
a lot of jurisdictions do not recognise any rights inherent in single, factual contents. it's very difficult, if not impossible, to create a global, coherent license for things for which there are no inherent rights.<div class="im">
<br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
* The weakness of the contract elements of the license when not supported by click-through<br>
</blockquote>
<br></div>
indeed. but the alternative is putting a click-through in front of all methods of accessing OSM data, which i don't think anyone wants. it's true that the contractual elements are weaker without a click-through, but there are mitigations we can use to retain some of the strength.<br>

<br>
it's also worth noting that CC BY-SA doesn't work, regardless of the presence of a click-through or not, so this isn't really an argument that works in the context of CC BY-SA vs. ODbL. it works for ODbL vs. PD, though.<div class="im">
<br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
* The exclusion of the reverse engineering clause (which couldn't be made to work, so just got dropped)<br>
</blockquote>
<br></div>
there were several questions about whether the reverse engineering clause meant that produced works weren't compatible with the CC BY-SA license. since such compatibility was a specific use case, LWG undertook legal advice, the result of which (you'll remember, it was at that same meeting you cited earlier) was that the reverse engineering clause wasn't strictly necessary, and had been included only for the avoidance of doubt.<div class="im">
<br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
* The loss of significant contributors and their data<br>
</blockquote>
<br></div>
this is a problem with any move away from the current license. however, according all the legal opinions i've heard: CC BY-SA is broken and, if we want a license which works, we have to move. this is regrettable, and LWG is trying to do everything it can think of to reduce the loss of contributors and data.<div class="im">
<br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
* The incompatability of ODbL with itself and with OSM's contributor terms.<br>
</blockquote>
<br></div>
ODbL, as far as i know, is compatible with itself. it is incompatible with the contributor terms, but as i explained earlier, it's a choice between allowing ODbL-licensed contributions and greater relicensing flexibility to allow for an uncertain future. it's an either-or choice and your opinion of the relative benefits may be different from mine.<div class="im">
<br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
    Therefore,<br>
<br>
     >   This makes it higher risk than the existing license.<br>
<br>
    ... your assertion is questionable, if not false.<br>
<br>
The onus of proof ought to be on those proposing change.  Can the LWG demonstrate that their proposals reduce the risks or at least do not increase the risks?<br>
</blockquote>
<br></div>
i absolutely agree. here are the current risks:<br>
<br>
* CC BY-SA, according to all legal opinion i've received, is at best risky for protecting our data and, at worst, provides no protection at all. the current license, in certain jurisdictions, could result in the use of our data without compliance the attribution and share-alike conditions.<br>

<br>
here are further problems with the current license:<br>
<br>
* it protects "works" and not data. that means anyone can take the OSM data, improve it, and distribute the resulting "works" under the CC BY-SA license. note that this doesn't necessarily mean that the data can be incorporated back into OSM, as the provider may claim other rights (such as database rights) over the data which would prohibit that.<br>

<br>
* the attribution requirements aren't clear. CC BY-SA is designed for use with creative works which typically have a few authors, not 18,000 or whatever OSM has at the moment.<br>
<br>
here are the risks i can see with the new license proposal:<br>
<br>
* data loss. there will be some people who disagree with the proposal, or who can't be reached.<br>
<br>
* no perfect protection. the new license is weaker in jurisdictions which don't recognise database rights or copyrights on collective data than it is in the EU and US.<br>
<br>
* choice of law / ported license. the OSMF legal counsel and ITO's counsel have both expressed doubts about the lack of a "choice of law" clause in the ODbL.<br>
<br>
here are some comments on the previous points:<br>
<br>
* as i said earlier, any license move is likely to result in some data loss. we would *really* like to reduce this to the minimum possible, but it's my strong belief that we cannot stay with the current license.<br>
<br>
* copyrights on creative works have a much better international foundation, but OSM aims to be a representation of the real world (i.e: factual) and so can't take advantage of this rare example of international bullying^W cooperation.<br>

<br>
* the ODbL's author doesn't believe there is a problem with the lack of a "choice of law" clause. the lack of consensus is worrying, but since none of us are lawyers specialising in international IP law, i'd say it's better to let ODC sort it out in later versions of the license.<br>

<br>
the conclusion, in my opinion, is that the new license proposal isn't perfect, but protects the data and the contributors attribution and share-alike rights much better than the existing license. in my opinion the risks associated with continuing with the current license are unacceptably high.<br>

<br></blockquote><div>Matt<br>Thank you.  I appreciate your considered and balanced response.<br><br>80n<br></div></div><br>