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

Wed Mar 4 22:06:42 UTC 2009

On Wed, Mar 4, 2009 at 9:56 PM, Jonathan Rochkind <rochkind at jhu.edu> wrote:
> Sorry, I don't mean to muddy the waters instead of trying to help, but I
> can't resist.
>
> What if the derived database is constantly changing?

my use case is very similar - the database is constantly receiving
updates from the openstreetmap database, making a "full dump" solution
impractical.

> Say they take your
> data, and put it in another database that also allows user
> contributions? And the users can not only add new data, but fix/change
> the data they got from you?  This is not an unreasonable use case, I
> don't think?

i think it is very reasonable. and you're right - i have no idea how
to practically comply with the license in this case. will this
effectively prevent anyone building useful interactive things on top
of openstreetmap data?

> What would the 'diff' they have to provide look like at any given time,
> and how the heck would they track it?
>
> I'm not sure why you guys arrived at a 'diff' solution in the first
> place, but I'm sure there's some reason I'm missing. If you instead just
> said that the entire derived database needs to be available in an easily
> machine readable format, would that get around some of the issues of the
> 'diff'? Ignore the 'diff' entirely?

the current license allows both the entire database to be provided, or
diffs. the problem that i have is that neither are practical for me to
provide.

> Or, I see, you're trying to _avoid_
> making the derived database 'sharealike' infected, but still require
> them to share certain things.  I'm not sure how workable this is in the
> general case. If it gets so complicated that it's hard to understand
> what the requirements are and how to meet them easily, then compliance
> is going to go down.

i don't think anyone is trying to complicate the license - in fact,
i'd prefer it to be much, much simpler. but we may not all be able to
agree on this ;-)

cheers,

matt