[OSM-legal-talk] CT clarification: third-party sources

[Frederik Ramm]

Peter,

pecisk at gmail.com wrote:
> 1) I'm not against ODbL. It is nice idea and I wholeheartedly support it;
> 2) I'm not against general idea of CT, I understand why it is needed;
> 
> My confusion and problem lies within fact, that while I can accept CT
> if I add only my own data to OSM, I can't to do that due of
> third-party sources because some of them requires attribution and
> share alike.

Do you have a concrete example of a third-party source that does not 
specify a concrete license, but requests a general "attribution and 
share alike"? Or is this only theoretical?

> While ODbL is good enough for both of these things
> (theoretically), then CT blocks, because it says that nature of the
> license of imported data can change. As I'm not author of those data,
> I don't have permission to change nature of the license.

In the original setup, data that is not compatible with the CT would not 
be accepted, so if someone required attribution and share-alike, that 
data would not be compatible.

The current mood in LWG (as per the latest CT draft) seems to be to 
allow such data in provisionally, i.e. you may contribute the data with 
some sort of flag (no idea about technicalities) that says "if the 
license is ever changed then this data must be removed" or so.

> About three or four months ago there was discussion about adding
> clarification about "free and open license", to add both share alike
> and attribution clauses. I have two questions - can it still be done,
> what was working group answer to this, or if not, then why not.

I don't think there's a plan to change the "free and open". You are not 
asking for a clarification, you are asking for additional restrictions 
(as there are many free and open licenses that are not attribution or 
share-alike); such additional restrictions would constitute an undue 
liability for the people who are OSM in the future. (I think it is 
possible that a reference to a widely accepted definition of the terms 
"free" and "open" might be included, as a clarification, but as I said, 
you are not asking for clarification.)

On the whole, if one wants to accept imports that are ODbL comaptible 
but not CT compatible, I think the opt-out version causes less damage 
than trying to toughen up the CT which might cause all kinds of problems 
in the future, but I don't like either.

Imagine our current data came under some sort of CT that said "the 
license may be changed but the new license must be attribution and share 
alike". Now *you* say that ODbL is ok for you, but ODbL does make 
exemptions from share-alike (namely, for non-substantial extracts for 
which attribution and share-alike are dropped, and for produced works, 
for which at leas the share-alike is dropped). I am pretty sure that 
under such hypothetical CTs, a license change to ODbL would not be 
possible.

I think that, even more than "free and open", share-alike is a term that 
is very difficult to define, and if one tries to define it, one will 
already have written half a new license. Licenses interact with their 
legal surroundings; some things we see in ODbL (the non-substantial 
extracts e.g.) are a direct refelction of the database directive. The 
legal surroundings can change, and if we have to change the license in 
the future then a new license might have to reflect the new situation. 
Any sort of cast-in-stone share-alike requirement will be an unnecessary 
burden.

In another post, I have tried to make the point that it would also be 
morally wrong (unfair) against our future colleagues in this project to 
limit their choices.

Since your argument in this posting was not that you personally require 
share-alike but you were concerned only about entering third-party data, 
I would much rather have *less* third-party data and *more* liberty for 
the project in the future, than *more data for the price of reduced 
liberty later. This would be like taking out a mortgage on what OSM is 
in 10 years. We would risk long-term problems for a short-term effect.

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frederik at remote.org  ##  N49°00'09" E008°23'33"