0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

パブリックドメイン画像のライセンス表記を、どうデータに落とすか

0
Posted at

パブリックドメイン画像のライセンス表記を、どうデータに落とすか

画像を扱うサービスで、素材のライセンス情報をDBに持たせる場面があります。

最初は license カラムに "CC0" と入れれば済むと思っていました。実際に運用してみると、この設計では足りないことが分かってきます。何が足りないのかを整理します。

この記事は表記の扱い方の話です。 画像をどこからどう取得するかには触れません。そこは提供側の条件によって変わる領域なので、設計として切り離しておくべき部分だと考えています。

名画の時間

→ ライセンス表記を作品ごとに載せている名画の時間

enum にすると破綻する

最初に思いつくのは、こういう定義です。

license ENUM('CC0', 'CC_BY', 'PDM', 'UNKNOWN')

3つに分類できれば扱いは楽になります。ただ、この3つは性質が違うものを同じ軸に並べています。

  • CC0 — 権利を可能なかぎり手放すという、権利者側の意思表示
  • CC BY — 使用を認めるが、出典表示を求める条件付きの許諾
  • パブリックドメイン・マーク — 権利が既に切れているという事実の表示

3つ目だけが宣言ではありません。誰かが何かを放棄したわけではなく、状態を示しています。同じ enum に入れると、この違いがコード上で消えます。

さらに、提供元によっては上の3つに当てはまらない独自条件を出してきます。出典表示を求めるもの、事前の申請を必要とするもの。UNKNOWN に落とすと、そこから先の判断ができなくなります。

分類ではなく、原文を持つ

行き着いた形はこうです。分類した結果ではなく、提供元が出した表記そのものを保持する。

CREATE TABLE artwork_rights (
  artwork_id     BIGINT      NOT NULL,
  source_name    VARCHAR(200) NOT NULL,  -- 提供元の名称
  source_url     TEXT        NOT NULL,   -- その作品のページ
  rights_text    TEXT        NOT NULL,   -- ★ 表記の原文。要約しない
  checked_at     DATETIME    NOT NULL,   -- ★ いつ確認したか
  image_kind     VARCHAR(40),            -- 取得した画像の種類
  image_size     VARCHAR(40),            -- 寸法
  PRIMARY KEY (artwork_id)
);

rights_text を要約せず原文で持つのが要点です。分類が必要ならビューや関数で導出すればよく、逆はできません。

なぜ要約してはいけないのか

理由は3つあります。

1. 分類の粒度が後から変わる。
運用を始めた時点では3分類で足りていても、独自条件を出す提供元が増えると分類軸を作り直すことになります。原文があれば再分類できますが、"CC0" としか残っていなければ、元が何だったのか復元できません。

2. 差分が取れない。
提供元が表記を変更したとき、原文同士なら差分が取れます。要約同士を比べても「何が変わったか」は出てきません。

3. 説明できなくなる。
後から問い合わせを受けたとき、「CC0でした」では根拠になりません。そのページに何と書かれていたかが必要です。

ログ設計と同じ話だと思っています。加工後の値だけを持っていると、調査ができなくなる。

checked_at が必須である理由

作品ページ

checked_at は付け忘れやすいカラムですが、これがないと記録が意味を持ちません。

権利の状態は変わりうるからです。 提供元が方針を変えることもあれば、特定の作品を対象から外すこともあります。

そのとき必要になるのは「いま何と書いてあるか」ではなく、**「利用した時点で、どう表示されていたか」**です。後者は記録していなければ復元できません。

日付のない記録は、変更が起きた瞬間にどちらが正しいのか判断できなくなります。逆に日付さえあれば「この時点ではこう表示されていた」と示せます。

提供元単位でキャッシュしない

実装で入れたくなるのが、こういう最適化です。

// やらないほうがよい
const cache = new Map();            // 提供元 -> ライセンス
function licenseOf(source) {
  if (!cache.has(source)) cache.set(source, fetchLicense(source));
  return cache.get(source);
}

提供元ごとに1回だけ確認すれば済む、という発想です。実際には同じ提供元の中でも作品によって扱いが違いえますし、時期によっても変わります。

キャッシュのキーは提供元ではなく作品にすべきで、しかも checked_at とセットで持つ必要があります。

CC0 が覆っていない範囲

もうひとつ、スキーマに入れておくとよい項目があります。

CC0 が手放しているのは、その画像についての権利だけです。 描かれている商標、写り込んだ人物の肖像に関わる権利、所有者側が別に定めている条件は範囲外です。

古い絵画では問題になりにくい部分ですが、近代以降の素材を混ぜて扱うなら、rights_text とは別に「この観点を確認したか」を持たせておくと後で助かります。ライセンスが自由であることと、素材として安全であることは別の判断です。

実例

作品をさがす

名画の時間は、作品ごとに提供元の名称・その作品ページ・権利表示の文言をそのままの形で・確認した日付・取得した画像の種類と寸法を保存していると明示しています。上で書いた形とほぼ同じ構成です。

作品ページを開くと、その作品について何がどう表示されていたのかが読める状態になっています。表記を要約せずに持つと、こういう見せ方ができます。

法解釈が定まっていない領域では、判断の材料をそのまま渡せることが信用につながるのだと思います。

本ページはプロモーションが含まれています

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?