<div dir="ltr">On Tue, Apr 29, 2014 at 9:39 PM, Paul Norman <span dir="ltr"><<a href="mailto:penorman@mac.com" target="_blank">penorman@mac.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">> From: Luis Villa [mailto:<a href="mailto:lvilla@wikimedia.org">lvilla@wikimedia.org</a>]<br>
> Sent: Tuesday, April 29, 2014 3:10 PM<br>
> To: Licensing and other legal discussions.<br>
> Subject: Re: [OSM-legal-talk] Guideline review: Substantial<br>
<div class="">><br>
> Reminder that Simon has pointed out here quite recently that ODBL claims<br>
> to be a binding contract that can apply when no license is necessary.<br>
<br>
</div>So, there's two cases here. One is in Europe. You might have trouble<br>
enforcing a contract which restricts you from acts permitted in the<br>
directive. I'm not sure of this interpretation, but won't further<br>
consider it because the point is moot, since 6.0 explicitly says that<br>
the ODbL doesn't restrict the rights you have under the exceptions to<br>
the database right.<br></blockquote><div><br></div><div>Without going further into the details of the many drafting shortcomings of ODBL (which, to be clear, are partially my fault!) suffice to say that I think that the interactions of 6.0 and 2.2(c) are not well-defined, especially in jurisdictions where there is no applicable statutory law, and/or where applicable caselaw says there are no database rights.<br>
</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
The other more complicated one is outside Europe, where you'd be looking<br>
at the ODbL as a copyright license or contract. In that case, we still<br>
want the guideline to be in harmony with the database directive for a<br>
few reasons [snip]<br></blockquote><br>Assuming OSM finds EU law desirable[1], then I agree that it would be good if the license was consistently interpreted in light of EU interpretation of the DD. It just isn't clear to me that the actual text of the license achieves this goal. So something to add to the list of clarifying wiki positions might be a firm statement on this position.<br>
<br></div><div class="gmail_quote">[1] Which is really, seriously, something OSM should think hard about before making a statement - if there are edge cases in EU law that could blow up OSM, they need to be looked at very seriously - the last thing you'd want to do is say "we firmly believe this should be interpreted in light of EU database directive caselaw" and then have someone say "but what about X, doesn't that make the whole enterprise look shaky"?<br>
</div><div class="gmail_quote"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">
> This strongly suggests that a European court would evaluate<br>
> "substantial" in the quantitative sense with regards to the entire 2B<br>
> records in OSM, not with regards to the database the information was put<br>
> into. It would be interesting to see what courts around Europe are<br>
> finding as "substantial" in this sense; I see one reference to a French<br>
> court that found that taking 15% was not quantitatively substantial, and<br>
> the GRADE paper linked to from the wiki suggests it would have to be >50%.<br>
> But I suspect this would vary a lot based on the facts of the case,<br>
> and that a skilled lawyer could raise or lower the number. And of course<br>
> in the case of a database as large as OSM a court might try to change<br>
> their mind.<br>
<br>
</div>OSM has ~250M features. The difference from 2B is for technical reasons<br>
to do with the data model. Seeing the percentages that are being used<br>
for substantial, I think anything that is quantatively substantial will<br>
be qualitatively substantial.<br></blockquote><div><br></div><div>Agreed that anything that is quantitatively substantial will likely also be qualitatively substantial. The reverse may not be true, so OSM (and perhaps these guidelines?) would likely be well-advised to focus on building the case for qualitative substantiality as defined in BHB. I think maybe that is what the current statement on the page is trying to get at, just not clearly?<br>
</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I also suspect that OSM has two key differences from anything else<br>
considered. One is the size and worldwide scope - Great Britain is ~2%<br>
of the planet-wide data, but anyone trying to work with all of Great<br>
Britain is hardly likely to not consider it substantial.<br></blockquote><div><br></div><div>I agree that in practice, courts are likely to find ways to work around it. But the EU CJ was quite explicit in BHB about comparing to the entire size of the dataset, so best not to rely on that as a primary tool.<br>
</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Another is applicability to database of geographic information. I'd<br>
defer to someone who's more familiar with them, but I believe the<br>
Ordinance Survey treats *much* smaller extracts of their data as<br>
substantial.<br><div class=""></div></blockquote><div><br></div><div>Lots of things that big rightsholders do are not supported by law or by ethics, so I wouldn't rely on that. <br><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="">
<br>
> For qualitative, the key passage of BHB is:<br>
> > [S]ubstantial part, evaluated qualitatively, of the contents of a<br>
> > database refers to the scale of the investment in the obtaining,<br>
> > verification or presentation of the contents of the subject of the act<br>
> > of extraction and/or re-utilisation, regardless of whether that subject<br>
> > represents a quantitatively substantial part of the general contents of<br>
> > the protected database. A quantitatively negligible part of the contents<br>
> > of a database may in fact represent, in terms of obtaining, verification<br>
> > or presentation, significant human, technical or financial investment.<br>
> (Para 71)<br>
><br>
> In other words, a small chunk of a large database can be qualitatively<br>
> substantial if the cost of "obtaining, verification, or presentation" of<br>
> that small chunk was substantial. The court goes on to say that it<br>
> doesn't matter if the small chunk is, by itself, valuable - what matter<br>
> is the work done to put it into the database. What qualifies as a<br>
> substantive "investment" is left as an exercise for the lower courts.<br>
> (One German case I've found seemed to presume that 39,000 Euro was a<br>
> substantive investment, but that was not the primary point being argued<br>
> in that case so I wouldn't rely on the number being that low.)<br>
<br>
</div>Putting BHB into an OSM context, what seems to matter is mapping effort.<br>
That makes sense - 100 detailed POIs are worth more than 100 points with<br>
only building=yes. Of course mapping effort is harder to measure...<br><div class=""></div></blockquote><br></div><div class="gmail_quote">Hard to measure, but at least likely the right framework.<br></div><div class="gmail_quote">
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">
> Some pretty decent summaries of BHB and other relevant caselaw, FYI:<br>
</div>Thanks for the links - they're on my to-read list.<br></blockquote><div><br></div><div>I'll throw them into the pages Richard linked (and probably do some other cleanup as well).<br> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
> Few other comments:<br>
> * It might be helpful to link to <a href="http://wiki.openstreetmap.org/wiki/Map_features" target="_blank">http://wiki.openstreetmap.org/wiki/Map_features</a><br>
<div class="">> when talking about Features, assuming those are the same concept,<br>
> which I admit I'm still not 100% sure about?<br>
<br>
</div>It's a data model issue. OSM's data model is designed for crowd-sourced<br>
editing, and polygons are composed of multiple elements. The definition is<br>
basically equivalent to a feature being one "thing" after conversion to<br>
more traditional GIS formats. The conversion is similar to how Wikipedia<br>
pages need to be parsed to resolve transcludes and other features before<br>
they're actually usable.<br></blockquote><div><br></div><div>Thanks for clarifying. If you draft something for the guidelines, I'd be happy to pepper you with more questions about it :)<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Bringing it back to the guideline, I'd suggest<br>
<br>
- Dropping references to villages or areas<br>
<br>
- Dropping reference to 100 features; the number doesn't seem in line<br>
with quantative<br></blockquote><div><br></div><div>While I don't like the 100 feature reference (it seems awfully arbitrary to me, and small) it could be salvaged if one explained _and justified_ that in the common case, mapping 100 features is likely to represent a substantial investment of time, effort, etc., in gathering the data. I just don't know enough to know if that is doable.<br>
</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
- Reframing in terms of mapper effort, i.e. the cost of "obtaining,<br>
verification, or presentation"<br>
<br>
- Referring to features and noting that a feature like a building<br>
may be formed with multiple OSM elements (i.e. multiple nodes) but<br>
is one feature.<br>
<br>
I could try writing some text if there's agreement on these points.<br>
</blockquote></div><br><br></div><div class="gmail_extra">I will never object to anyone trying to write anything :)<br><br>Luis<br></div><div class="gmail_extra"><br clear="all"><br>-- <br><div dir="ltr">Luis Villa<br>Deputy General Counsel<br>
Wikimedia Foundation<br>415.839.6885 ext. 6810<br><div><a value="+14158820495"></a><br><div><span style="font-size:7.5pt;font-family:Tahoma"><font style="font-family:arial,helvetica,sans-serif" size="1">NOTICE: </font></span><font style="font-family:arial,helvetica,sans-serif" size="1"><i>This message may be confidential or legally privileged. If you have received it by accident, please delete it
and let us know about the mistake. As an attorney for
the Wikimedia Foundation, for legal/ethical reasons I cannot give legal advice to, or serve
as a lawyer for, community members, volunteers, or staff members in their personal<b> </b>capacity.</i></font></div></div></div>
</div></div>