Your code won't break. And you probably won't even have any difficulty populating the database on new installs, since your OS provider is probably mirroring the current database.
But there are "between 20 and 100" changes to the worldwide timezone-set per year. So three weeks from now, someone's gonna change their timezone rules, effective perhaps 2013. Maybe it'll be Bolivia. And then three weeks later, someone else, maybe some part of Indiana. Then three weeks later, maybe a civil war in some ex-SSR or something finally resolves, and the two different halves end up using different time zone plans (one of them uses DST, the other doesn't, and neither of them use the USSR regime they had last year).
So now a year passes, it's 2012, what're you doing? Is your software using a database that's a year (and maybe 50 events) out of date? Or did you hand-maintain it, because you care about Indiana, and you got 10 of the 50 events? Or maybe you used the Debian fork of tzdata?
And what am _I_ doing? Probably not the same thing as you. And now when my software and your software try to interoperate (maybe our iCal calendaring, maybe our enterprise order management integration bus service routing frameworks, maybe we just want to agree when your mother's flight will land), guess what. Sooner or later a relevant event happens in one of the altered timezones, and someone misses a flight, and we get a very very difficult-to-track-down bug.
Actually, it's not that terrible, as long as every time event you care about takes place in a big important time-jurisdiction that'll be maintained by every tzdata fork that every software you care about will use. Which I guess could theoretically apply to me or you. I don't actually care about Indiana, so I don't care if time events that take place there don't synchronize.
If we agree that most OS vendors will probably ignore the copyright claim and keep using the current database, then one could put any newer updates into a "patch database", which clearly would not be under any prior copyright (and could be easily made available to everyone as the old database was).
So, I don't really buy your parable about how this will only affect future changes. If tzdata "forks", it will be between what old (possibly copyrighted) data is included.
Well, on the one hand, I agree with you about one source of forks being old data, although at least this is a relatively simple fork: those who excise the allegedly-infringing parts of the database, and those who do not.
On the other hand, I think you are completely groundless in your assertion that it can't fork over future changes. There could be multiple patch databases with disjoint changesets in them, with different software using different databases.
And it's not _my_ parable. It's my rephrasing of the FA, and the comments by the FA's author in his own comments thread.
But there are "between 20 and 100" changes to the worldwide timezone-set per year. So three weeks from now, someone's gonna change their timezone rules, effective perhaps 2013. Maybe it'll be Bolivia. And then three weeks later, someone else, maybe some part of Indiana. Then three weeks later, maybe a civil war in some ex-SSR or something finally resolves, and the two different halves end up using different time zone plans (one of them uses DST, the other doesn't, and neither of them use the USSR regime they had last year).
So now a year passes, it's 2012, what're you doing? Is your software using a database that's a year (and maybe 50 events) out of date? Or did you hand-maintain it, because you care about Indiana, and you got 10 of the 50 events? Or maybe you used the Debian fork of tzdata?
And what am _I_ doing? Probably not the same thing as you. And now when my software and your software try to interoperate (maybe our iCal calendaring, maybe our enterprise order management integration bus service routing frameworks, maybe we just want to agree when your mother's flight will land), guess what. Sooner or later a relevant event happens in one of the altered timezones, and someone misses a flight, and we get a very very difficult-to-track-down bug.
Actually, it's not that terrible, as long as every time event you care about takes place in a big important time-jurisdiction that'll be maintained by every tzdata fork that every software you care about will use. Which I guess could theoretically apply to me or you. I don't actually care about Indiana, so I don't care if time events that take place there don't synchronize.