JA:Open Data License/Trivial Transformations - Guideline

これはコミュニティガイドラインです。コメントはdiscussion page へ、またはこのページにインラインでお願いします。

何が問題か？

ODbL はEUデータベース指令に基づく言葉遣いであり、データベースはどの時点で派生となり、どの時点で派生とならないのか、という点について、完全には明らかではありません。これは法令が比較的新しく法定でのよく検証されていないことによります。そのため、何が派生であり、何が派生で無いと考えられるのかということについてガイドラインを提供できるということは重要です。もちろん、そこにはグレーな部分もあります。

その解決法は、派生データベースの状態を保証するのに面白いとか、十分役に立つとは思われないデータの改変に適用される条件（我々は"軽微な改変(trivial transform)"から始めましたが、そこからでなければならない理由はありません）を定義することだと思われます。"軽微(trivial)"という言葉は技術的に軽微なこととしてとらえるべきではなく、データへの変更や追加という意味において"軽微(trivial)"ということを意図しています。例えば、データの追加はこれまで"軽微(trivial)"とは考えられていませんでした。

[Remark Oliver: I still believe in my test criteria of "updatability". As soon as the database can be updated without "reproducing" the work as whole it cannot be a Produced Work. It is more an "exclude criteria" for Produced Work rather than a sufficient criteria for a Derived Work]

このページの終わりの方にある現在ODbL内にある言葉遣い、及びその考え得る結論についての章を参照。

例

以下はOSMの利用例であり、各ガイドラインの持つ意味はこれらによって検証することができます:

レンダリング・データベース

レンダリング・データベース、例えばOsm2pgsqlで作成されたもの、は明らかにデータベースであり、明らかにOSMデータから派生したものです。ODbLの現在の言葉遣いの下では、レンダリング・データベースそれ自身（おそらくかなりの大容量）、あるいはそれを作成するアルゴリズム（機械判読可能な形式で）のいずれかをリリースする必要があります。これは、そのソースが既にオープンであるOsm2pgsqlデータベースにとって素晴らしいことですが、プロプライエタリーなレンダリング・データベースにとっては煩雑すぎるのではないでしょうか？もしデータに何も追加されていないのであれば、このプロジェクトにとって、我々のエコシステム内でこれらの臨時のユーザを持つことの方がより有用なのでしょうか？

ルーティング・データベース

ルーティング・データベースはレンダリング・データベースと同様、OSMデータからのアウトプットであり、ODbL及びEUデータベース指令の定義によるデータベースであると思われます。ルーティング・データベースは、より興味深いものですが、はるかに小さなデータのサブセットを操作するので、必ずしもデータを改変する必要が無く、原データベースに追加された索引と考える（あるいは実装する）ことができます。

ジオコーディング・データベース

ジオコーディング・データベースは、より索引に近いもので、最もシンプルなケースでは、単に"name"タグ上に索引の付いた変更されたスキーマであることがあります。

座標変換

OSM用の本来の座標系は WGS84 lat/lonです。もしデータベースが異なる座標系で作成されていながら、一方でOSMデータベースと同一のものであれば、それに何も有益あるいは興味深いことが行われていないという意味で、"軽微"と考えられるでしょうか？

データベース・ダンプのロード

Loading a database dump is extremely unlikely to produce the exact same database (in terms of disk layout, index structures, etc...) as the original database. But very little would be gained from considering this to be non-trivial, since any common format dump (e.g: SQL or OSM-format XML) would likely be identical to the input. Is it worth considering changes database implementation (although probably covered by ODbL and EU Database Directive) to be non-trivial, given that this would put an obligation to redistribute or release the machine-readable algorithm (i.e: code) on every user of OSM data?

特殊化された (例: モバイル) 形式のデータベース

Many devices have specialised requirements or restrictions that necessitate specialised formats. In converting OSM data to these specialised formats it is likely that a database is created (it's a "collection of material arranged in a systematic or methodical way and individually accessible by electronic or other means"). ODbL already has "technical measures" clauses to ensure that the data isn't encrypted or otherwise restricted from re-use, so anyone wishing to keep their format proprietary already can as long as they also redistribute in an open format. Is it worth putting further restrictions on those open formats by requiring them to also release their code (presumably a format specification would be required in any case)?

[Remark Oliver: I think we should also make some negative examples for clarification, which are other cases than Derived Work respectively "trivial transformations" e.g. putting a POI layer on top of a map > collective data base]

ODbLの記述

現在の状況はODbL 4.6b節で直接示されているように思われます。その記述は以下の通りです（部分）:

あなたが派生データベース、又は派生データベースに基づく製作著作物を公衆利用した場合、あなたは、それに加えて、その派生データベース又は製作著作物の受領者に対して、以下の項目の複製を、機械で読み取り可能な形式で提供しなければならない。

a. 派生データベースの全体部分。

b. 本データベースに対して行ったすべての変更、又は本データベースに対して変更を行うための方法（アルゴリズムなど。）を記載したファイルであって、本データベースと派生データベースとの間のあらゆる相違をまとめたもの。あらゆる追加的コンテンツが含まれる。

This would seem to mean that any database ("collection of material arranged in a systematic or methodical way and individually accessible by electronic or other means") would require the release of the entire database, alterations or algorithm. Given that any alteration of any sort falls under the definition of a Derivative Database ("a database based upon the Database, and includes any translation, adaptation, arrangement, modification, or any other alteration of the Database"), including changes to the schema or indexing ("modifying the Database as may be technically necessary to use it in a different mode or format" counts as "Use"), it would seem that any such database is a Derivative Database.

This raises some interesting questions about how far we would like the ODbL to extend. Clearly, it already extends far enough that, because loading an OSM dump into a database will almost certainly cause it to be formatted differently, any database could be a Derivative Database. However, this seems counter-intuitive and counter-productive. The intent of the "share-alike" part of our license is to ensure any improvements or interesting modifications are shared, but not necessarily the trivial ones, as this becomes onerous and begins to put people off using it, which was the point of releasing it under an open license in the first place.

[Remark Oliver: I think it would be helpful to clarify the statement "You must also offer to recipients of the Derivative Database or Produced Work a file containing all of the alterations". How does this offering need to look like? Is it an active offering or an offering on request? I often hear in discussions that one could "encode" attributes so that the value for the recipient is almost zero.]