[odc-discuss] ODbL: Does publishing Produced Work from Derivative Database trigger Derivative Database ShareAlike?

Wed Mar 4 12:20:55 UTC 2009

2009/3/4 Frederik Ramm <frederik at remote.org>:
> Hi,
>
> Jordan S Hatcher wrote:
>> I've just sent through an email explaining my approach to answering
>> these questions.  In an effort to test out the licence and improve it,
>> I'm going to turn this around and ask you (Richard W), what do you
>> think? Where would you draw the arguments for applying the ShareAlike
>> clause to a Produced Work from a Derivative Database?
>
> No. That's not what we are talking about.
>
> We are not requesting the Produced Work to be ShareAlike.

I think that is understood -- I think Jordan's brevity just led to an
ellision meaning. I think what he meant was: "Where would you draw the
line for applying the SA clause in the area of Produced Works and
Derivative Databases".

> We are requesting that the interim derived database that only sits on
> your hard disk because you had to make it in the process of creating a
> Produced Work be ShareAlike.
>
> This is our major selling point for the application of ODbL in OSM: To
> those who say that freedom is reduced by not making Produced Works
> ShareAlike, we answer: True, but Produced Works are not what we're
> after, we're after the data; and here ODbL gives us something that the
> old CC-BY-SA didn't.
>
> My standard example:
>
> Guy takes OSM data for London, adds a few streets, prints nice T-Shirt,
> sells it.
>
> Under CC-BY-SA, he can keep the added streets but has to make the
> T-Shirt available under ShareAlike.

I don't think it is really clear what the situation is under CC BY-SA
if he works of off the original data (if he took the original
*rendered* map and modified it in photoshop that would be different
but he didn't).

> Under ODbL, at least that was our reading of the previous draft, the guy
> does not have to make the T-Shirt design available, but he has to share
> the added streets.
>
> The reading of the license behind this was: If you publicly use a
> derivative database then you have to share that database; and making a
> Produced Work from a derivative database constitutes using it.

I think you meant 'publicly using it'. I entirely agree with you here.
In v0.8 (2008-04-10 version) definition of Use + s4.4 would have this
effect.

> This was an idea that rung well with many in the OSM community and had
> the potential to overcome the "but Produced Works are not ShareAlike"
> criticism.
>
> I am not aware of *anyone* in OSM who did *not* read it that way. All of
> us always said "ODbL scales back on the protection of Produced Works but
> gives us more in terms of data, and this is exactly what we want." (Well
> at least those in favour of the license said this.)

There seem to be a set of basic options of where to go here re SA for
derivatives:

1. Apply SA provision only to derivative DBs which are publicly 'conveyed'
2. Option 1 + Apply SA provisions to (public) "Produced Works"
  * So SA does not apply to non-public derivative DBs
3. Option 1 + Apply SA provisions to any derivative DBs used to
produced a (public) "Produced Works"
  * So SA does not apply to
4. Combine 2+3: so SA applies to public "Produced Works" and any
derivative DBs so constructed.

BTW: All seem to agree that SA does *not* apply to non-public
derivative DBs which are not associated with Produced Works. In my
understanding:

Current v0.9 of ODbL = Option 1 (approx)
v0.8 of ODbL = Option 3

I don't think it would be that difficult to either a) revert to v0.8
(if that is what is wanted) b) have 2 distinct license versions
incorporating the different approaches.

> By changing the "Use" to "Convey" and defining that "Convey" does not
> happen during the production of a Produced Work, this very basic premise
> is simply cancelled; with the current wording, someone can take London
> data from OSM, fill in all the gaps, print and sell his very own A-Z
> from it *without* having to share the filled gaps. This would never,
> ever be accepted by the OSM community.

I am not disagreeing -- it is up to the community what it wants -- but
I would suggest that you may want to think carefully here.

1. How often are people going to be doing what you suggest *without*
publicly conveying the derivative database. (I understand the T-shirt
example but is this really a big problem -- I am doubtful how many
t-shirt producers are going to be producing derivative dbs -- they are
going to buy in the db -- and even the producers of paper maps are
likely to want to make the digital data available -- in which case the
SA provision applies).

2. What happens if I combine a ODbL licensed DB with another DB which
lists, say temperature by location, and then make some produced work
(for example I put a picture in my academic paper or even 'print it on
a T-shirt). Under this interpretation I assume the combined
'derivative' DB will need to be SA licensed.

This starts to be pretty burdensome and cause a lot of incompatibility
problems -- there's a lot of people combining data together to make
graphs, pictures etc. Under this approach every time they put that
graph on the web or in a paper they have to publish the derived
database under SA (which may be incompatible with the terms of the
others DBs they've got).

Obviously, what the community wants is up the community and it is not
difficult to make changes to reflect those wants -- that is, after
all, why there is this comments period. I would also point out that it
would be good to bear in mind that Jordan, and the other legal experts
have given a lot of pro-bono time to produce these licenses and doing
their best to produce the best open data licenses possible for use by
OSM and other communities.

> I am still astonished how such a major change could have slipped
> through, and somewhat waiting for someone to tell me this is not true!
> For the best part of the previous year I have argued for ODbL within OSM
> using examples like the above T-Shirt example, and I know others have,
> too. If it should turn out that I have been totally misreading the ODbL
> intention then I will have to say sorry to a *large* number of people.

As already stated I do not think it would be a problem to reinstate
the original approach (or to have two distinct versions).

I would also invite OSM to propose an official representative to be on
the ODC Advisory Council (this is something we have already suggested
a couple of times in our chats with the OSM board leading up to this
public comments period). This would help clarify exactly what the OSM
position is and also provide for OSM to 'officailly' involved in the
governance of ODC (see http://www.opendatacommons.org/about/).

Regards,

Rufus