You may also add separate and distinct layers to your map made from other sources of data. This data does not have to be shared, provided there is no interaction with the OpenStreetMap derived layer. For example, you cannot have a layer of restaurant icons that only appear if the same restaurant is not in OpenStreetMap!
Could someone explain why that is? I’m not sure if I see how it follows from the terms of ODbL. The way I see it is:
(1) There’s the OSM data that needs to be shared.
(2) In a separate database / file, I have my own list of restaurants, sourced from outside OSM. This list is not “a database based upon the Database” (definition of “Derivative Database”) and hence doesn’t need to be shared.
(3) My web app displays, in a single layer, some entries from (1) and some from (2).
Is the interpretation that a “Derivative Database” is created at the moment (3) takes place? But what if at the moment (3) only a subset is displayed, e.g. within a bounding box, or limited to 10 results? Then it’d seem I don’t need to share the entirety of (2), but only each of the subsets thus created.
Sorry to be nitty-gritty, but I’d like to keep the terms of the license and at the same time not allow my data-based startup to be copied by competition in one day. With two small children, either it earns money or I don’t have the time to maintain it pro publico bono… I do have to say I am somewhat disappointed with ODbL.
The ODbL requires that the constituent members of a collective database be independent of each other, this is obviously not the case when you de-duplicate the data.
Note that if you are actually concerned about your business plans, it probably isn’t a particularly good idea to discuss them in public instead of using the contacts provided for (among others) that purpose.
It was written with express goal of creating a common good that nobody can appropriate without giving back. Does it mean you can’t profit off of it? Many companies, including Mapbox, Facebook, Microsoft would disagree.
As per your example - MAPS.ME did what you wanted but without de-duplication. They displayed accommodation POIs both from OSM and Booking.com. There were duplicates. A little bit rough around the edges, but I guess more hotels = more better (and more referral money).
Thank you for your answers. I think I figured it out, so I post the reasoning for others’ benefit.
In the example I draw, we have 2 source databases, and any number of smaller derived databases:
(1) Source DB: OSM data.
(2) Source DB: my own list of restaurants.
(3) - (n) Each of the collection composed partially from entries from (1) and partially from entries from (2).
(1) is clearly under the terms of ODbL.
Each of (3) - (n) is clearly under the terms of ODbL because it is derived from OSM data in (1).
As to (2), it does not fit the definition of a “Derivative Database” because it is not “a database based upon the Database”.
However, in the ODbL, we have the clause:
d. Share Alike and additional Contents. For the avoidance of doubt, You must not add Contents to Derivative Databases under Section 4.4 a that are incompatible with the rights granted under this License.
Therefore, to be able to create (3) - (n), the Contents of (2) must be compatible with the rights granted under ODbL. Therefore (2) must be under ODbL or similar.
As to my feelings about ODbL, I understand the motivation behind it: requiring contributions back. However, I do think that the initial message one gets from OSM is misleading, or missing an important point. My impression of it was “here’s free geographical data; if you improve it privately, share the improvements” whereas now I read it as “here’s free geographical data; anything it comes in contact with stops being your private data”. I do think this is pretty business unfriendly, and deserving the adjective “infectious”…
My understanding is that (2) doesn’t have to be ODbL-licensed. With your own data, you can achieve ODbL compatibility by just saying that this data is allowed to be integrated into ODbL-licensed derivative databases.
So you don’t have to hand your entire dataset (2) to anyone under ODbL. But datasets (3) … (n) probably do need to be ODbL, so your users/customers could reconstruct (2) by puzzling all the small datasets together… which means that this distinction may not be particularly helpful to you in practice if you expect someone is going to do that.
I’m not really a fan of the ODbL, but the line of thought is that adding missing restaurants is a form of improving the data, and that these improvements would benefit everyone if they were added directly to OSM.