[odc-discuss] (no subject)

[Francis Davey]

2015-03-27 22:25 GMT+00:00 Andrew Rens <andrewrens at gmail.com>:.
>
>
> But 4.2 a. states: "If You Publicly Convey... any Derivative Database
> then You must ... Do so only under the terms of this License".
>
> That reads to me as if it applies not to A's database but to B's database.
> B's database is the Derivative Database.
>
> Recall the definition of Derivative Database
> "Derivative Database" - Means a database based upon the Database, and
> includes any translation, adaptation, arrangement, modification, or any
> other alteration of the Database or of a Substantial part of the Contents.
> This includes, but is not limited to, Extracting or Re-utilising the whole
> or a Substantial part of the Contents in a new Database."
>
> That suggests a reading that if B's database  includes a modification of
> substantial part of the contents of A's database then B may only publicly
> convey it "under the terms of this licence". It seems on the wording that B
> is not free to license the derivative database under any licence that she
> likes
>

I understand your alternative interpretation.

Read literally 4.2(a) says that the action of publicly conveying (of a
Derivative Database) may only be done under a particular set of conditions.
Those conditions are to be found in the terms of "this License", i.e.
ODC-By.

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; (ii) it is clearly inspired by
CC-BY (which would be admissible as part of the interpretive background).

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.


> .
>
> Now I understand that on the reading that you've suggested the "terms of
> this licence" are that a licence to A's database is granted directly to the
> user's of B's database.  On that reading the "terms of this license"
> applicable to B's database is simply preserving the terms on which those
> aspects of A's database which are in B's database are granted.
>
> However there is the other reading - and one the one that seemed obvious
> to both Mike and myself, neither of us unfamiliar with licences. That
> uncertainty seems problematic, perhaps something that could be addressed in
> a new version.
>

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


>
> But even on the preservation of direct licence reading B cannot licence
> the Derivative Database on any terms - only terms that keep intact the
> ODC-By direct licence.
>
> One issue seems to be clearly distinguishing between the contents from A's
> database and what B has added. If they are not clearly distinguishable
> which I take to be the case in most if not all the real life examples in
> which I've worked with datasets, then although B may have a theoretical
> right to put her additions under other licences she cannot in practise do
> so, because the artifact that she is conveying includes ODC-By content so
> she cannot label the artifact that she produces with another licence.
> If she were to say 'parts of this are ODC-By and parts are CC By not then
> someone who want to use B's database would naturally ask - which parts are
> which.
>

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.

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. The derived database will note A's contributions under ODC-By and if
the third party wanted to use them it would need to comply with ODC-By as
well. But the third party wanting to use B's data would have to comply with
whatever licence B imposed.

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.


>
> So in practise on the preservation reading one can only use a different
> licence for B's additions if one can clearly distinguish between A's data
> and B's additions - otherwise one is practically constrained to use ODC-By
> for the derivative.
>
> Of course in many cases I'd advise use of PDDL or CC 0 which in my view
> have the same effect. But when I am advising others - especially those new
> to open data, they want to consider all the options, so implications of
> ODC-By amongst others become important.
>
>
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. While the CC and
ODC family are different, ODC-By really does work the right way.

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

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