ODbL compatibility with itself

Not so recently I discovered that the municipality of Athens has an open data portal where much of the data is OSM derived, and therefore licenced under ODbL. A few of these datasets would be quite useful to put into use in OSM, but my question is about ODbL data more generally.

Both the OSMF website and the wiki are notably silent on the compatibility of importing ODbL data into OSM. Is this something the LWG hasn’t looked into at all, or is it simply seen to be implied?

1 Like

Seems as if the wiki entry was removed in December 2023 see Import/ODbL Compatibility: Difference between revisions - OpenStreetMap Wiki

In any case there are two issues:

  • as with every share alike licence without a specific compatibility determination, the licence will only be compatible with itself. In practical terms this means that any change of the licence (even just fixing some of the bloopers) would require going back to such sources and asking them to re-licence the data. Essentially this implies that they have you by the ****s.
  • the 2nd issue is due to the OSMFs board hardline literal reading of the ODbL which, if ODbL sources would take the the same position (and why shouldn’t they?), would, for example, require every use of OpenStreetMap data to provide attribution to such ODbL sources.
2 Likes

This seems to be a similar case to CC-BY then.

For point one, is there not the same risk with literally every content under licence that isn’t explicitly compatible with ODbL? CC-BY data signed away by waiver doesn’t allow OSM to change ODbL’s terms, as it explicitly mentions ODbL 1.0. Therefore any and all data under CC-BY licence currently in OSM is also under similar risk, which in some countries is quite sizeable chunks.

For point two, would a waiver form not be sufficient to allow attribution under similar terms as we currently do for CC-BY?

It seems we’ve twisted ourselves into a knot here, not allowing us to reuse data that is entirely built on our own.

2 Likes

We’re talking about degrees of friction here, from the essentially impossible (changing to a licence that doesn’t require attribution), to doable (changing to a non-sharealike licence). The key point is that the target licence needs to implements a compatible subset of terms of the input 3rd party licences.

So for example as long as a new licence required parallel distribution if you are distributing a DRMed derivative I don’t see an issue with maintaining the current waivers.

Sure (I’ve actually suggested that the board does that for the elephant in the room), but somebody has to execute on it and not give in if it isn’t forthcoming.

1 Like