[OSM-legal-talk] ZIP codes from OSM in non-compatible licensed dataset
tom at bluespice.org
Tue Oct 8 15:33:47 UTC 2019
Hi, please excuse the TOFU.
let’s not jump to conclusions that fast.
First, I consider the zip code (as in addr:postcode=/feature/) a primary
feature, although it is generally considered an “additional property”,
as in ¹. My reason would be that I don’t see any meaningful distinction
for the purposes of identifying wether a database can be called
collective or not. A feature being called primary or additional doesn’t
seem to bear any meaning towards being substantial or non-substantial
A 2nd reason would be that the definition of “Collective Database” in
section 1.0 “Definitions”² of the license doesn’t seem to rely on that
as well. It merely asks the part to be in unmodified form. Thus the
part has to be unmodified in content as well as in form within the new
Obviously your parts somehow reference each other, the POI identifier
somehow needs some reference to the corresponding postal code. Therefor
#1 of the “when-clause ” does not apply.
Although I claim clause #4 applies. Your proprietary database /adds/ a
property of a feature (postal codes) and uses all of its data. You
don’t seem to mix or complement, but instead keep all records of both
collections intact and discrete. Therefor the parts are unmodified as
to content as well as form. Complementing both by each other would mean
you would change their respective content, by not not copying some zip
codes; complementing would also mean changing their arrangement. From
what you are telling us, I understand, you don’t plan to do this at all.
The last example on the guideline page explicitly states that removing
duplicate objects is one crucial step towards a derivative database.
The example probably wants to demonstrate how two datasets cease to be
complete and separate and thus become indiscernable and therefor
something different and new. Referencing the contents of two collections
by means of mixing, complementing and rearranging obviously changes the
parts with the result that the former parts are not easily discernible
Because of this, I believe you would benefit from the collective
database clause, excluding the proprietary data from being subject to
the ODbL share-alike terms. Perhaps you should find scheme that makes
it easy for you to adhere to the demands of the ODbL.
Of course you also would have to develop some means of attribution
to the OSM-derived-works of your database. But that is another process
not concerning the database. If your work may be considered commercial
I strongly suggest some legal consultation. Mixing databases is
obviously no trivial business at all.
I sincerely hope I’m not too far out with this one.
> From: "Martin Koppenhoefer" <dieterdreist at gmail.com>
> > As I read the collective db guideline, you cannot have both, the ZIP
> > codes from your proprietary database and those from OpenStreetMap,
> > in the same database matched to the same objects. It says “add or
> > replace” a property (we do agree the ZIP codes are a property and
> > not a primary feature?). If you keep both ZIP codes in your db, it
> > implies you need both columns, which implies you are somehow mixing
> > them at some point (or you could drop the proprietary ZIP codes, as
> > you won’t need them)
> Wow, that's way more strict than all proprietary license I know of.
> All those details should be make much more prominent to users. I know
> users mixing data like this all the time, by attributing the OSM
> column for internal and external use. They don't know that they're
> doing an illegal thing :-(
> I think, I'll not use OSM data for this dataset, even if it's more
> complete than the proprietary one.
More information about the legal-talk