New diffs can still be published in the CLDR database. I know no other better place for such info. But once again we have to be careful about submissions and must track the authors of each submission (so: no anonymous contributors allowed, there's a need for a strong policy, and the need to track authors for the very long term, i.e. more than 20 years, probably up to more than one century, due to copyright laws).
2011/10/7 "Martin J. Dürst" <[email protected]>: > First, to ask the judge for a temporary permission (there's a better legal > term, but IANAL) to keep the database up until the law suit is settled > (because the database is probably down now due to a temporary order from the > judge to that effect) because of its high practical importance. If a judge ordered to make the database down, there's little incentive to have him change his mind before the trial or an agreement is found between the parties. All this looks like there will be no trial, but Astrolab will want to be paid, and some parties may help Olson pay the claimed fee. Let's hope however that Astrolab will not immediately make identical claims against Unicode for its CLDR database, and against all major Unix/Linux OS distributions (notably those selling server solutions). Once again, the new data no longer comes since long from the old book now owned by Astrolab. Note also that the individual data may be copyright-free, but unfortunately there's a copyright law that recognizes a specific right for the aggregation of the data in a comprehensive collection or database. The only way we can protect the CLDR databse is to maintain it as open as possible to many contributors so that no one can claim ownership on a significant part of the CLDR database. But we still have the risk of someone sending data for which he has no right, copied from another source (including from sources that he sincerely think is "public domain", something that is much more risky than getting a formal permission, or than creating the data ourselves and publishing it with a author name while being bound to a strong usage policy). We should not expedite updates with lots of new data coming from a single source without a thorough vetting process, with discussions, and contradictory submissions or corrections and improvements suggested by others. Once again, we need now an ISO standard for such sensitive data, supported officially by governments and not just by informal recognition (apparently the Olson database authors are left alone to defend their case, despite of their incredible work for many years on the subject). Imagine that Olson database authors loose, hat will happen next ? Astrolbal will start wanting to get say 1 dollar per CPU on almot all server installations. It would mean several millions dollars for Google, Apple, Microsoft, ... but also for many western governments, and all servers used by major ISPs worldwide, or service providers such as the Internet Archive. It's time to forget the local timezones for computing and interchange on the Internet: we should use UTC-based timezones, or only timezones for which there's a stable and open documentation and policy (leaving aside the local timezones of Indiana, Israel... that will not be interchanged or will be converted immediately to a stable timezone, even if the source of the effective local timezone is lost : Israel and US should now pass a national law forcing their local timezones to be published to some international standard body; it's essential for IATA use in air navigation, and for Internet use and in the interest of the public at large to be informed correctly). > Second, what seems to be in dispute is data about old history. While this is > important for some applications, in most applications, present and new data > is much more important, so one way to avoid problems would be to publish > only new data at some new place until the case is settled. That would mean > that applications would have to be checked for whether they need the old > data or not. Or to only publish diffs (which would be about new, present-day > data not from the source under litigation).
