That used to be my big caveat with ODBL too. Though the final version of the license differentiates between "Derivative Database" and "Collective Database". Effectively it seems that if your application uses OSM data as one layer, and non-OSM data as separate layers, it would make up a "Collective Database", and you'd only have to release changes to the OSM data itself.
That's potentially a huge improvement.
The problem there is there's a huge grey area as to what will be considered a Derivative Database vs. OSM data in a Collective Databases with other, proprietary databases.
E.g. if the data in the properitary database contains road data that augments the OSM data, will the result of combining it with OSM data in a collection create a Collective Database or a Derivative Database? How well must the separate layers stand on their own before combining them with OSM data is "derivative".
They're trying to walk a very fine line, and I suspect quite a few lawyers will make a decent amount of money interpreting that license for clients that wants to use OSM data but are worried about where the line goes.
There are some cases where it's perfectly fine to not have to release the data, like if you, as a company make a map of how much each store makes in revenue, and you want to use OSM. You should not have to release internal, confidential sales data.
Oh, I agree. A startup I've been advising is in the GIS space, and the old OSM license meant they had to use other map sources instead.
On one hand sharing modifications to base layers would not be an issue, but the business model revolves around allowing clients to upload their own layers, many of which they can't release for business reasons or in some cases legal reasons.
The old license meant a lot of effort was wasted on producing own base maps which could've gone into fixing issues with OSM instead (e.g. areas covered by customers include sparsely populated areas where both OSM and Google's maps are severely lacking, but where getting GPS traces of all the local roads that they could release would be easy).
The new license seems to be sufficient for their usage. The problem currently is just that it's vague. E.g. I think it's safe to assume that your example would be ok, but there's still a lot of grey areas. For the company mentioned above, I also think the new license is probably ok, but it'll take some time to review.
While on one hand the new license gives more opportunities for keeping data private in some instances, I think it'll actually result in more data released for the reason that it allows a lot of people that previously would never dare touch OSM data to actually use it, and so gives them a reason to contribute fixes and improvements.
That's potentially a huge improvement.
The problem there is there's a huge grey area as to what will be considered a Derivative Database vs. OSM data in a Collective Databases with other, proprietary databases.
E.g. if the data in the properitary database contains road data that augments the OSM data, will the result of combining it with OSM data in a collection create a Collective Database or a Derivative Database? How well must the separate layers stand on their own before combining them with OSM data is "derivative".
They're trying to walk a very fine line, and I suspect quite a few lawyers will make a decent amount of money interpreting that license for clients that wants to use OSM data but are worried about where the line goes.