カスタム絵文字ライセンスを連合してほしい

tamaina commented 1 year ago

Summary

https://github.com/misskey-dev/misskey/issues/10822#issuecomment-1550804515

(連合仕様という意味ではRelated to https://github.com/misskey-dev/misskey/issues/6457 )

custom emoji license federate remote

CyberRex0 commented 1 year ago

・おそらくMastodon陣営は理解してくれない・絵文字はソフトで制限できても回避はおろか直接ダウンロード可能なので無駄そう

syuilo commented 1 year ago

まあ連合して損はない

fruitriin commented 1 year ago

著作権の考え方的に、見えるところでちゃんと主張してることが重要だと思われる「ここに書いてあるのにお前は無視している！」とキチンと主張できればなんらかの揉め事になった際（これは裁判沙汰になった場合も含む）強く出ることができる

技術的に防ぐことができなくても「コピーしてほしくない」などの旨を主張しているのがわかればOK 現状だと元のインスタンスの絵文字をクリックして詳細を見ないとわからないので結構厳しいと思うので是非前向きに連合に加えてほしいところ

fruitriin commented 1 year ago

蛇足一応具体的なげむすきでのライセンス設定のケースをいくつかあげると 他サーバー転載可否 改変可否 使うときは一言ほしい の組み合わせみたいなバリエーションを基本にして運用してる

ゲームが元ネタの二次創作手書き絵文字なので転載不可 みたいな事情もある

ファンキットのような公式素材なんかもあるので権利が企業にあるものもある 例）（C）SEGA、他サーバー使用：公式利用規約を要確認、改変：公式利用規約を要確認 https://pso2.jp/players/community/fankit/logo/

きちんとページつくって主張してる人もいたり https://misskey.gamelore.fun/@basilicum/pages/kiyaku

tamaina commented 1 year ago

・おそらくMastodon陣営は理解してくれない

そこまで話通じない人たちじゃないでしょ

・絵文字はソフトで制限できても回避はおろか直接ダウンロード可能なので無駄そう

著作権の考え方的に、見えるところでちゃんと主張してることが重要だと思われる

↑これ

yuriha-chan commented 1 year ago

カスタム絵文字ライセンスを連合するというのは、リモート絵文字のライセンス情報を取得できるようにするという意味ですよね。

（要約）インポート時にライセンスを確認することだけが必要。カスタム絵文字ライセンスを連合に流すことに意味はなさそう。license:null はなぁなぁでしかない。

分散型SNSにおける著作権の一般論

まず、連合しているインスタンス間の関係では、リモート絵文字の情報を送る側は、リモートユーザーのノートを表示する目的や、リモートユーザーからのリアクションを表示する目的に限って、リモート絵文字の使用を許可するという慣習が確立していると考えれらます。（これが認められないとすると連合が崩壊するので。）絵文字の情報を受け取る側は、送る側がこのような許可を行う権利を絵文字の作者からすでに取得していると期待し、送る側はこの期待に応える義務があると考えられます。

次に、インスタンス運営者と利用者の関係では、リモート絵文字を表示・引用したり、ローカル絵文字を利用したノートを作成したりリアクションしたりする権利が、インスタンス運営者から利用者に許可されていると考えられます。^{_{一部の絵文字（「しろぷよ」など）は、このような利用をする場合でも一定の要件が課される場合があります。これは法律的な要請というよりも、作者からの拘束力の無いお願いとして解釈するのが妥当に思えますが、サーバーの利用規約によってはこれを法律的な要請とすることもできるかもしれません。}}

これらの権利関係が明確ではない場合は、インスタンスの利用規約で明示することが望ましいです。（法律的に厳密な運営を希望する場合、連合しようとするインスタンス管理者のみに適用される条項を利用規約を別途加えることもできます。）

絵文字ライセンスの明示と利用法

さて、絵文字の作者は、それ以上の権利をユーザーに許可することができます。たとえば、絵文字をパブリックドメインやCCライセンス扱いとしたり、Misskeyサーバーを使う限りにおいて、他のサーバーでローカル絵文字として登録し、そのサーバーの利用者に使用させることを許可するといった場合です。このような権利をユーザーが行使しようとする場合、ユーザーは絵文字が登録されているサーバーにアカウントを作成の上、カスタム絵文字エクスポート機能を利用して、絵文字をダウンロードすることが期待されます。この場合、ライセンス条項は(JSONファイルの形式ですが) zipファイルに含まれているので、ユーザーはそこで許可を確認することができます。ただし、すでに指摘されているようにこのライセンス条項は絵文字インポート時に確認されないので、確認されるように改善する必要があります。

また、カスタム絵文字エクスポート機能は、APIを直接叩けばサーバーの利用者全員がつかうことができますが、絵文字管理者しかその機能にアクセスできるUIが表示されないという中途半端な状態になっています（ですよね？）

個別のスタンプのライセンスをカスタム絵文字一覧画面から確認し、その条件に則って、画像を直接ダウンロードして使うという方法もあります。この方法の場合、サーバーにアカウントを開設していなくても画像をダウンロードできること、絵文字が膨大になる場合でも必要な画像のみダウンロードすることができるというメリットがある一方で、一部のメタデータ(originalURLなど)が失われるというデメリットがあります。また、ライセンスの一覧性が非常に悪いです。

（リモート）絵文字を利用したいユーザーは、これらの手順を踏むことが期待されるため、カスタム絵文字ライセンスを連合に流すことは使い道がないのではないかというのが率直な意見です。さらにいうと、リモート絵文字の一覧は一般ユーザーからは見れないので、連合したところで現状ユーザーに提示する場所がありません。

このような手順が一般に周知されていないと思われる場合、misskey-hubなどで告知することが重要と思われます。

license:null について

license:null は文字通りとれば、ユーザーに追加で許可される特段のライセンスはないということを表している、すなわち他のサーバーでの利用禁止を表しているということにはなりそうですが、実際には絵文字のライセンスなんか気にしてなかった（というかそんなAPIなんてなかった）ということを表しカジュアルにコピーされているように思います。例えば、多くのサーバーでlicense:null とされている blobcat の絵文字群は blobs.ggでApache License 2.0でライセンスされているものが中心と思われます。パーミッシブなライセンスなのでコピー自体には問題はないと思うのですが、ライセンスが明示されていないのは微妙です。license:null のインポート時に表示するメッセージには頭を使いそうです。

yuriha-chan commented 1 year ago

リモート絵文字の情報を送る側は、リモートユーザーのノートを表示する目的や、リモートユーザーからのリアクションを表示する目的に限って、リモート絵文字の使用を許可するという慣習が確立している

もしかしてこれが確立してないから問題になっているのか…

tamaina commented 1 year ago

絵文字のコピー可否関連は #10822 でお願いします

tamaina commented 1 year ago

絵文字のライセンスって絵文字のサーバー間のコピーについてはあんまり主題でないと思っていて、絵文字画像自体のライセンスについて書くところだと認識している

https://github.com/misskey-dev/misskey/issues/10091

カスタム絵文字に想定される画像は、二次著作物だったり簡単な文字などの著作権が主張しにくいものだったりしかなかったと思う。
例えばSCPに関連する絵文字はCC BY-SA 3.0/4.0を明示しなければならないが、今まではそれが無理矢理だったのを簡単にできるようにするとか。

サーバー自体やその関係者がライセンス元である場合とかサーバー個別にライセンスが割り当てられている場合、当然他のサーバーへのコピーできるかというのはここに入るわけで、 #10822 と関係はある。
カスタム絵文字となる画像に一次創作物が増えてきたが、二次創作物でゆるくやることしか想定されてなかったので問題になってきた

yuriha-chan commented 1 year ago

たしかにCC BY-SA みたいに著作者やライセンス条項を表示することを条件に使用が許可されているライセンスがあるから、それを表示しておけるようにする必要があるのか。本当は絵文字が使われているすべての場所からライセンス表示への導線がないといけないのだろうけど、とりあえず誰でも見れるサーバーの絵文字一覧ページに、リモートの絵文字とそのライセンスも表示するようにすると良さげか。

noellabo commented 1 year ago

こんな感じどう？ https://fedibird.com/emojis/92354.json

関連部分抜粋

{
  @context: [
    {
      fedibird: "http://fedibird.com/ns#",
      license: "fedibird:license",
    }
  ],
  license: "@noellabo@fedibird.comが作成, Public Domain Dedication (CC0)"
}

Fedibirdで先に試してる。"https://misskey-hub.net/ns#"でいくなら合わせるよ。

acid-chicken commented 1 year ago

SPDX 識別子かなんかで機械的に判別しやすいプロパティがあった方がいい気がする（例えば商用のカテゴリに入るかもしれないサーバーは CC BY-NC を使えない、というのは識別子があれば将来的に人間が判断しなくて良いかもしれない）

noellabo commented 1 year ago

そういう識別子まで入れたら標準化できそうだね。

ライセンスについては、PeerTubeの投稿にライセンスが付与できたり

Piexlfedの投稿にライセンスが付与できたり

それぞれにいろいろ試みられているけど、まだバラバラ。

ガチに標準化を目指しているやつはこっちで議論してる。 https://socialhub.activitypub.rocks/t/fep-c118-content-licensing-support/2903

それはそれでおいといて、Misskey同士 + Fedibirdぐらいの範囲で早々に連合する仕様を採用しちゃって、Progressiveで行ってもいいんじゃないかなと思うの。

ちなみにFedibirdは、機械的判別用はとりあえずこうした。

{
  @context: [
    {
      fedibird: "http://fedibird.com/ns#",
      copyPermission: "fedibird:copyPermission"
    }
  ],
  copyPermission: "allow"
}

とりうる値はallow, deny, conditionalで、指定しないというnoneがある。

これが一つの例なんだけど、白黒はっきりしないものも扱いたいという要請もあるよ。

acid-chicken commented 1 year ago

個人的には

{
  "license": {
    "spdx": "SPDX string" | null,
    "copyright": "string" | null
    "description": "(human readable) string" | null,
  }
}

みたいなのを想像している（string が直にあると拡張性がないので）

noellabo commented 1 year ago

その後、諸々再考して、Fedibirdでは現在このような形に（抜粋） https://fedibird.com/emojis/92354.json

{
  @context: [
    {
      fedibird: "http://fedibird.com/ns#",
      copyPermission: "fedibird:copyPermission",
      schema: "http://schema.org#",
      license: "schema:license",
      keywords: "schema:keywords",
      usageInfo: "schema:usageInfo",
      isBasedOnUrl: "schema:isBasedOnUrl"
    }
  ],
  copyPermission: "allow",
  license: "Public Domain Dedication (CC0)",
  keywords: [
    "コーヒー豆",
    "こーひーまめ",
    "カフェキチ"
  ],
  usageInfo: "フリー素材として扱ってください",
  author: "@noellabo@fedibird.com",
  description: "本物のコーヒー豆の写真を撮って、カフェキチ先輩風に切り抜き加工したものです",
  isBasedOn: "https://fedibird.com/emojis/92354"
}

基本的な語彙は https://schema.org/CreativeWork から採用しています。 copyPermissionだけFedibird拡張です。

licenseはライセンスの名称や参照URLで一意に定めうるもの。SPDXとしても良いと思います。不足する内容をusageInfoで説明します。コピー時に元のオブジェクトURIを保持してisBasedOnにしてます。対応している実装が続く限りコピー経路を辿れます。

Misskeyの現在のlicenseフリーテキストはusageInfo、aliasesはkeywordsにあたります。残りは追って考えるとして、この二つあたりから動きだしてもいいのでは。

yuriha-chan commented 1 year ago

License に表記ゆれがあると面倒なのでSPDX識別子（indentifierのみ）が簡潔でいいと思います。法的に十分なのかはちょっとわかりませんが。（すくなくともSPDXが振られているライセンスに関しては。）（off-topicですが）また絵文字を申請するユーザーの方にも、(パーミッシブなライセンスを志向する人には)SPDXが振られているような定番のライセンスをできるだけ使うようにアナウンスする必要かもしれません。

tamaina commented 1 year ago

SPDXが振られているような定番のライセンスをできるだけ使うようにアナウンスする必要かも

絵に関してはなかなか厳しい気がする

fruitriin commented 1 year ago

SPDX、ソフトウェアライセンスばかりにIDがついてるから絵文字に寄せるより絵文字用のライセンス条文を作ってgistとかにあげてURL貼る+著作者　とかみたいな運用のがよくないかな

yuriha-chan commented 1 year ago

絵に関してはなかなか厳しい気がする

営利目的はいやだけど、CC-BY-NC(-ND)ならいいよっていう人は一定数いるんじゃないかなと思っているなので、こういう有名ライセンスだと使う側が安心してつかえるし、システム的に扱いやすいので、使ってもらいやすくなるよという情報提供することは一般的にはよさそう

もちろんそれで全部の需要にこたえられるとは思っていない

絵文字用のライセンス条文を作ってgistとかにあげる

無数のサーバーや絵文字作者がそれぞれ独自にライセンスを作ると実質的に機械可読でなくなる。一方で、多数のサーバー・絵文字作者が納得して共通して使ってもらえそうなライセンスを作るのは（政治的に）大変そう。

なのでSPDXだったら機械的に処理してよいが、URLだったら人間が良く読む必要があるよという意味合いで運用するのが良さそうだと思う。

noellabo commented 1 year ago

あれこれ考えた結果、ウチではcopyPermissionを設けてコピーの可否を別途指定するようにしたのね。取り得る値は、無指定、許可（allow）、拒否（deny）、条件付き（conditional）。機械可読はこれだけできてればいいように。読めないのは人間が頑張る。

で、licenseを機械可読で一意に判別できたとして、それで何をしたいか。

コピー利用（ローカル絵文字として利用可能にする）かの判定まで
ユーザーにライセンスを読ませたり、項目をあげて事前同意させるところまでしたい
モデレーションの自動化やアシストに活用したい

コピー可否以外にしたいことはあるのか。たとえばグッズを作る許諾までここでカバーしたいのか。

私の提案としては、現在のデータベース上のlicense（フリー記述のテキスト）だけでもまず連合させること。次点で、copyPermissionとりあえずつけといて、他の仕様を確定するまで時間稼ぎしつつ実効性を確保すること。

独自ライセンスは、形式の定まった許諾というより『作品○○甲×乙カプに理解がある人のみ利用可。リバ不可』『攻撃的・不快にさせる使用方法禁止』『反差別シンボルにつき差別のあるサーバ不可』などの追加の禁止事項が主体かな？こういうのはlicense的なものはなしで、usageInfo（いまのMisskeyのフリー記述）を活用する方向が収まりがいいかも。

フレームワークとしてもっと理想を目指すなら、先の https://socialhub.activitypub.rocks/t/fep-c118-content-licensing-support/2903 も踏まえた方がいいかも。SPDXでいいじゃん。いや権利の枠組みにはORDLあるんだからORDLでいこうよ、というような話をしてたりするよ。なんにしても、どこまで踏み込みたいのかは決めたらいいと思う。

権利関係は、Calckeyのさらにフォークでなんかやってるのもあるね。 https://blahaj.zone/notes/9ev0kge0aj

Mastodonサイドではこんな感じ。 https://mastodon.social/@Gargron/110418568586988003 ……これで提案すると案外通らないんだけどw、機運が高まると話がまとまることもあるよ。

KisaragiEffective commented 5 months ago

revisit: 1年以上経つが、ライセンス周りのトラブルを数件ほど聞いたのでここまでの流れを再整理

絵文字のライセンスは連合されるべきというコンセンサスがある
管理の手間を考えると機械可読にしたい
- が、スキーマについてはどれが良いかはまだコンセンサスがない
- 追記: 少ないながらもクリエイティブ・コモンズが活用されている例もあるので、機械可読にすることのメリットはある
インポート可否も設定できるようになると良い → #10822 ?
- 自分から: 現行は初めから「ローカルのみ」に設定することで暫定的な運用がされている認識
- https://github.com/misskey-dev/misskey/issues/10822#issuecomment-1555049797

KisaragiEffective commented 5 months ago

暫定的な対策として、「違法建築」をしてインポート時点のライセンスを連合するべきかもしれないのはそう

Sayamame-beans commented 5 months ago

絵文字の削除や"ローカルのみ"への変更(実質削除)が連合されていないのも若干気になるところですね。(時間が経てばキャッシュ消えたりはしそうですが)

samunohito commented 3 weeks ago

すでに仰っている方がいらっしゃいますが、まずはemoji.licenseだけでも連合したほうが良いのでは、と考えています。closeされてしまっていますが、 https://github.com/misskey-dev/misskey/pull/14109 を作成いただいていますし…

連合を確認できるe2eもあるので動作確認も容易かと思います（よく見れていない、認識間違いだったらごめんなさい）

samunohito commented 3 weeks ago

（e2eふえたらマージの機運あります？）

misskey-dev / misskey