[odc-discuss] (no subject)

Fri Mar 27 23:50:53 UTC 2015

Thanks again Francis

>
> But I see that there is a reading, albeit in my view a rather strained
> one, that says "under the terms of this License" means the same as "under
> this License". In other words the modifiers "only" and "the terms of" are
> unnecessary and are padding. Padding is always possible in contract
> drafting.
>
> Now in English law a court would be reluctant to select such a meaning, on
> the grounds that: (i) it makes less sense;
>
To be clear - it is not that I want the licence to read in this way.
Instead as I worked through the licence this seemed to be the obvious
reading. Of course what is "obvious" to one person may not be obvious to
another. Trad route descriptions routinely make statements such as 'ascend
the obvious crack' and then one finds oneself one pitch up the route and
find that the crack is not obvious at all.

Nevertheless I am concerned about the effects of this reading because I
don't think it can so easily be dismissed.

It may well not be an English court doing the interpreting of the licence.
10.4 of the licence stipulates "Choice of law. This License takes effect in
and will be governed by the laws of the relevant jurisdiction in which the
License terms are sought to be enforced."

>
> Your interpretation also does violence to other parts of the licence. Eg
> in 4.4 the term "You may enforce any rights that You have over a Derivative
> Database" is intended to make clear that a licensee may do what they please
> with their own rights, selecting any licence they please. If the licensee
> was required to license under ODC-By, then that term would not make sense.
>

I agree that counts against the 'use the same licence' reading. But does it
count enough?

> .
>>
>
> I like to think I am fairly familiar with licences too :-).
>

No doubt :-)

>
>
On distinguishing A's and B's:

Frances wrote:

Two points you might want to think about:

(i) There will be circumstances where a Derived Database does not contain
any of the originators IP - for example where it contains only an
insubstantial contribution of the original work. Unusual, but possible. For
example, if the original database had a very thin layer of database right -
where the independent investment was only just "substantial" - a derived
database might not have extracted sufficient data to amount to an
extraction of that investment.

Would you make this more concrete?

A more common situation might be a translation or adaptation. The two
principal ways of infringing database right (extraction and re-utilisation)
are pretty strict. Creating an adaptation may well not be a re-utilisation.

(ii) The obvious situation where this might matter is a mashup of some kind
where a third party does not have any interest in A's data but only wants
B's.

This is really quite a common situation. I have quite a few clients who
have databases of this kind. In the open data world this sort of
combination is a very useful aspect of open data.

If I understand you correctly then in both i. and ii it must be possible to
distinguish A and B's data.

People want to achieve different things with open data. PDDL and CC0 do
particular jobs that not everyone wants. Many people do care about
attribution, hence CC-BY and ODC-By. Others feel more strongly about
enclosure of the commons and choose ODC-ODbL or CC-BY-SA.

I agree that people are trying to achieve different things with open data -
as a consequence my close reading of ODC-By which raised the question.

Note that I wasn't one of the lawyers involved in drafting it (though some
clever minds did get involved). It should also go without saying that none
of this is legal advice by me - but of course for a fee I'd be happy to
offer it :-).

We need to come up with an acronym that is the equivalent of IANAL for
those of us who are lawyers. Perhaps IAALBTINLAYHTPFT:
I am a lawyer but this is not legal advise, you have to pay for that
Wordy but then we have reputation to uphold.
:-)

Andrew Rens

>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.okfn.org/pipermail/odc-discuss/attachments/20150327/04f7d609/attachment-0003.html>