Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

自サーバーで作成した絵文字について、他サーバーでのインポート可否を設定したい #10822

Open
nakajima0528 opened this issue May 10, 2023 · 46 comments
Labels
✨Feature This adds/improves/enhances a feature

Comments

@nakajima0528
Copy link

現状

サーバーのために作られた絵文字が、リレー先で簡単にインポート出来てしまう
引用ではなくインポート先に新たに登録される形式のため、ライセンス表記はインポート先で消す事ができ、作成したサーバー側が該当の絵文字を削除してもインポートした側には残り続ける

問題点

・創作物を第三者が二次配布し放題という環境は権利問題として危険度が高い
・現状インポートするか否かの選択肢が他サーバー側にしかなく、本来権利を持っているはずの作成側に不利である
・絵文字は間違いなくMisskeyの大きな売りポイントなのに、それに寄与するクリエイターの権利が守られていない

どうなって欲しいか

絵文字を登録する際に、「この絵文字を他サーバーでのインポート可とするか否か」という設定項目が欲しい

検索用ワード

カスタム絵文字
権利
著作権
emoji
custom emoji
copyright
license

@nakajima0528 nakajima0528 added the ✨Feature This adds/improves/enhances a feature label May 10, 2023
@mendakon
Copy link

これがないせいで頻繁にトラブってるのを見ます
by すしすきー管理者

@fruitriin
Copy link
Contributor

げーむすきーで丁寧にライセンス表記を設定してるんだけど、
リモートから見た時にライセンス表記がみれないのも最低限なんとか……

@noellabo
Copy link
Contributor

  • ライセンス設定されている絵文字を一覧表示するページをMisskeyで自動生成するようにする。
    • ひとまず人間用の情報を表示するところから始める。すぐできるはず。
    • /emoji_license, /emoji_license.json のようなパスを定着させると良い。実装を待たずにhtmlやjsonを置くだけで開始できる。nodeinfoや.well-knownも活用する。
    • 機械可読な情報を提供する(json)。最低限必要なフィールド定義を1.0仕様として早期に確定させておく。自動化を促そう。
  • 絵文字を登録するオペレーター(サーバ管理者やロールを与えられている人)が、ライセンス一覧ページを参照してから登録する、というフローを定着させる。リモートサーバにクレームする際も『Misskeyには絵文字のライセンスページあるから必ず見て』と言えるようにする。(ここがキモ)
  • 機械可読な情報になっていれば、連合先から、ライセンス不明な絵文字の探索をかける仕組みを構築可能になる。登録型のリポジトリより、クロール型の方が好まれるのでは。一括インポート等でライセンス情報が失われているデータは、探索できないとオリジナルがわからない。初出が重要になるので、権利者情報と合わせて日時や作成経緯が参照できるとよい。
  • 同様の習慣をFediverseに定着させる。定着すれば、ライセンス一覧ページをMastodonやPleromaも生成するようになる。

既に困っていて早期に実効性を確保したいなら、こういう仕組みの構築を始めたらいいんじゃないかな。
その上で、絵文字仕様の拡張やその連合なども平行して進める。

プロダクトやサーバ運営側でここまでやっておけば、あとは人間同士で解決できる。

@yuriha-chan
Copy link
Contributor

一応現状でも /api/emoji?name={絵文字名} (GET)でJSONが返ってくるという仕様はありますが、ライセンスは文章なので他のサーバーで利用可能かどうかなどの情報は機械可読ではありません。

@tamaina
Copy link
Member

tamaina commented May 17, 2023

ライセンスとかよりコピーする際にオリジナルがどこであるかが全く残らないのが問題な気がしてきた

@tamaina
Copy link
Member

tamaina commented May 17, 2023

「リモートのカスタム絵文字は自分のインスタンスに取り入れてからでないと使えない」という仕様がややこしくしているのはそうかもしれないけど、ActivityPubの現状の仕様的には第三者のインスタンスの絵文字を使うのは難しかった気がする

#3612

@tamaina
Copy link
Member

tamaina commented May 17, 2023

絵文字のコピーはそもそも著作権的にグレーな状態で行われている

@tamaina
Copy link
Member

tamaina commented May 17, 2023

(Misskeyのゆったりした開発スタンス的には、そういうところで白黒はっきりさせたい人たちが出てきてしまったのが厄介だなという認識)

@tamaina
Copy link
Member

tamaina commented May 17, 2023

カスタム絵文字に想定される画像は、二次著作物だったり簡単な文字などの著作権が主張しにくいものだったりしかなかったと思う。

カスタム絵文字となる画像に一次創作物が増えてきたが、二次創作物でゆるくやることしか想定されてなかったので問題になってきた。

@naskya
Copy link

naskya commented May 18, 2023

二次的著作物は著作権が主張しにくい、ということは無いと思いますが……

@nakajima0528
Copy link
Author

大変恐縮ですが、二次創作こそ誰が作成していて誰が責任をもつのかはっきりしないと問題が深刻になりがちで、ゆるく考えられないものであると認識しております。

二次創作物の再配布や無断転載が禁じられている理由の多くは作り手の著作権の主張ではなく、
「何かあった時に自分の手で畳めなくなると困る」
「権利元に迷惑をかけたら二次創作が出来なくなるので自身の管理下から離れるのは困る」
からです。
二次創作系サーバーの多くが権利元のガイドラインを守りコンテンツを潰してしまわないよう努めている中で、自サーバーで生まれたものが管理の手が届かないところで問題となる可能性のある現状はとても危険ですし不安です。

一次創作の権利が守られて欲しい、二次創作のコンテンツを潰したくないという両面から、
・作成者が明示されること
・二次配布できない状況を作れること
の二点が叶うことを切に願います。

@syuilo
Copy link
Member

syuilo commented May 18, 2023

絵文字のインポート機能を無効化するのが手っ取り早いかも

@fruitriin
Copy link
Contributor

リモート絵文字のインポート機能がなくなると、正規の手段が画像を手元に保存してアップロードになるので、
ライセンス未確認問題を助長するのではないかと

@sasagar
Copy link
Contributor

sasagar commented May 18, 2023

Misskey本体を守るという意味合いでも遅かれ速かれこのあたりの対策は必要になるのではないか?という感覚があります。

@syuilo
Copy link
Member

syuilo commented May 18, 2023

インポート機能がある場合ライセンス未確認問題が軽減されることになる理由がよく理解できてない

@nexryai
Copy link
Contributor

nexryai commented May 18, 2023

絵文字のインポート機能を無効化

blob系とかオープンな絵文字を集めるのに便利なのでインポート廃止は普通に困る

@fruitriin
Copy link
Contributor

fruitriin commented May 18, 2023

インポート機能がある場合ライセンス未確認問題が軽減されることになる理由

連合情報にライセンスを含めることができる余地がある

今の所はなんの抑止力もないけど

@syuilo
Copy link
Member

syuilo commented May 18, 2023

廃止というか、このIssueの要望である「絵文字を登録する際に、「この絵文字を他サーバーでのインポート可とするか否か」という設定項目が欲しい」を実装するまでには時間がかかる可能性もあるから、それまでは現状維持 or インポート無効化のどちらかだと思った

@syuilo
Copy link
Member

syuilo commented May 18, 2023

連合情報にライセンスを含めることができる余地がある

現状そうなってないはず

@EbiseLutica
Copy link
Member

一度機能として廃止して、ライセンス問題いい感じにして再実装したらどうかな

@atsu1125
Copy link
Contributor

・カスタム絵文字インポート機能自体がActivityPubの標準ではない
・MastodonとMisskey(めいすきーとv12以降にある、v11以前を除く)に独自実装しただけ(Misskey v11以前とPleromaや他の実装系にはなかったりそもそもカスタム絵文字非対応だったりする)
・カスタム絵文字ライセンス表記に関してはmisskey v13でローカルのみで実装されたもの
・のえるが言うように"カスタム絵文字複製許可"を連合APIとして実装してもいいけど、他のAPのSNS系に対応されるのは、年単位かかりそう
だからしゅいろが言うようにカスタム絵文字インポート機能を一時的に廃止してみることは、ActivityPub全体としての影響を考慮する上ではアリではある
ソフトウェア開発として望ましいかって言うと微妙だけど

@fruitriin
Copy link
Contributor

廃止というか、このIssueの要望である「絵文字を登録する際に、「この絵文字を他サーバーでのインポート可とするか否か」という設定項目が欲しい」を実装するまでには時間がかかる可能性もあるから、それまでは現状維持 or インポート無効化のどちらかだと思った

よさそう

@nexryai
Copy link
Contributor

nexryai commented May 18, 2023

それまでは現状維持 or インポート無効化のどちらかだと思った

期間がどれくらいかにもよるけどインポート無効化は副作用として大きすぎると思う

@EbiseLutica
Copy link
Member

影響は大きいけれど、問題を野放しにするほうが良くないと考えます

@syuilo
Copy link
Member

syuilo commented May 18, 2023

自分でアップロードすれば済む話なので他のサーバーからカスタム絵文字をコピーすることができなくなってもそこまでの影響はないと考えてる

@nexryai
Copy link
Contributor

nexryai commented May 18, 2023

せめて(ライセンスを示した上で)インスタンス情報のカスタム絵文字一覧からのダウンロードを楽にするとか何かの救済策があったほうがいいと思う
どれくらいの期間廃止されるのかにもよるかもだけど

@syuilo
Copy link
Member

syuilo commented May 18, 2023

せめて(ライセンスを示した上で)インスタンス情報のカスタム絵文字一覧からのダウンロードを楽にするとか何かの救済策があったほうがいいと思う

開発リソースには限りがあるからそういった追加機能を実装する=しばらくは問題を野放しという選択になりそう

一方応急処置としてコピー機能を無効化するだけなら数十秒で対応できる

@syuilo
Copy link
Member

syuilo commented May 18, 2023

この問題の緊急性がどれくらいかによっても変わってきそう

@tamaina
Copy link
Member

tamaina commented May 18, 2023

年単位でかかるーとか言ってないですぐさま標準化することを考えたほうが良さそう
(仮に標準化に失敗したとしても「これだけ言ったのになんで対応しなかったん?」みたいに主張できるし)

緊急性はそこそこ高めだと思っているのでMisskeyどうしでだけでもライセンスぐらいは連合するようにしたほうがいいと思う

@takaion
Copy link

takaion commented May 18, 2023

私の観測する範囲でもMisskeyサーバー間でカスタム絵文字にまつわるトラブルがすでに複数件発生しています。
まずはMisskey独自の実装となると思いますが、今後もいつ同様のトラブルが発生するかわからない状況なので早めに対応いただけると嬉しいです。

@yuriha-chan
Copy link
Contributor

作者が二次配布を禁止した絵文字が「二次配布できない」ようにするのは技術的に無理だけど、「もっとも簡単な方法では二次配布できない」ことは可能でそれを目指す必要がある

@tamaina
Copy link
Member

tamaina commented May 18, 2023

絵文字のインポート機能を無効化するのが手っ取り早いかも

無効化はちょっと待って欲しいという意見が多い
(「ちゃんと許可とった?」って警告文を入れるとかがいいかも)

@KawaneRio
Copy link

KawaneRio commented May 18, 2023

(「ちゃんと許可とった?」って警告文を入れるとかがいいかも)

「ちゃんと許可とった?」じゃなくて普通にライセンスをポップアップできればそれで十分かも。

@tamaina
Copy link
Member

tamaina commented May 18, 2023

ライセンス連合の実装すら面倒であればという話

@nakajima0528
Copy link
Author

そもそも許可が必要かどうかということが周知できない、その必要性があるかもしれないという意識が共有できていないのがトラブルのもとになってるのでは?と思うので、「許可取った?」系の文言はあった方が良いんじゃないかなぁと個人的には思います。

@nakajima0528
Copy link
Author

実装まで一時的にインポート機能を停めるか否かは機能実装にかかる時間を踏まえ開発の皆様のご判断にお任せするとして、とりあえず「今のこれがよくない」ことは早めに広まってほしいきもちです。

@yuriha-chan
Copy link
Contributor

サーバー管理者に伝えたい情報は以下のようにまとめられるかな

  • 絵文字の登録・インポートは基本的に作者の許可をとる必要がある
  • ライセンス情報はリモートサーバーの絵文字一覧ページ/about#emojisで確認できる(場合がある)
  • 二次創作物など第三者権利を持っている絵文字がある
  • blobs.gg などに由来するフリー(Apache Licenseなど)な絵文字もある
  • ありふれた言葉をありふれたフォントで表示した絵文字、単純な幾何学模様は著作権が無い可能性があるが登録は自己責任

@syuilo
Copy link
Member

syuilo commented May 18, 2023

カスタム絵文字ごとに連合するかどうか設定できるようにしてみた
他のサーバーにインポートされたくない場合はこのオプションを使う選択肢ができた

@mei23
Copy link
Contributor

mei23 commented May 18, 2023

カスタム絵文字のインポートと呼べそうな機能は2つあるけど

  1. 他サーバーから受信した絵文字を1つづつ自分のサーバーにコピーする機能
  2. ZIPエクスポートされた特定サーバーの全絵文字をまとめてインポートする機能

他のサーバーにインポートされたくない場合はこのオプションを使う選択肢ができた

でやったことは、連合送信しないようにして1を封じたって認識でいいのかしら?
2はエクスポートでもインポートでもまだ封じてなさそうだから封じた方が良さそう。

@fruitriin
Copy link
Contributor

fruitriin commented May 18, 2023

目の付け所がシャープ
他のサーバーの絵文字を一括してzipでエクスポートする方法ってあまり知られてなさそう
(だから対策が不要というわけではないけど、緊急度は落ちるかも)

@haborite
Copy link

話題が2つ混在していますが、「①カスタム絵文字ライセンスを連合したい」については、間違いなくユーザーとして有難い機能だと思いますし、
#10859
で前向きに検討頂いている通りかと思います。

一方、issueタイトルでもある「②絵文字の登録時に他サーバーでのインポート可否を設定したい」という要望については、本質的な難しさを感じます。クリエイターの権利の保護という観点で考えた場合、この設定項目自体が中途半端だと感じるからです。

「インポートの可否を設定したい」という要望があるのなら、「インポート可能なサーバーを選びたい」という要望も出てくると思いますし、インポートの可否について後で気が変わるかもしれません(そして気が変わる権利がある)。クリエイターがサーバーを引っ越した場合、カスタム絵文字についても引っ越し元から削除したいと思うかもしれません。結局、権利者と管理者が分離している限り、「自分の創作物の使用範囲をコントロールしたい」というクリエイターの要望に応えることに本質的な限界があるのではないでしょうか。

なので、

  • サーバーが管理するカスタム絵文字は一貫して簡素な配布制約(ライセンスはきちんと表記するが、配布・使途は自由)とする。
  • クリエイターが細やかな使用範囲の制御を望む場合、クリエイター自身で管理する

という2段階の仕組みがあると有難いです。カスタム絵文字をユーザードライブ内に置いて、参照可能なサーバーをユーザー自身が選ぶという仕組みや、Misskey外部のサービスで管理してMisskeyから参照するといった仕組みは実現が難しいでしょうか?

そして、上記の仕組みの実現が難しい or 時間がかかるのであれば、「サーバーにカスタム絵文字を登録すれば、使用範囲の制御は難しい」ことをサーバー管理者の方からクリエイターの方に周知していただくことが、さらなるトラブルの抑止に対して最も即効性があるのではないかと思います。

@nakajima0528
Copy link
Author

nakajima0528 commented May 19, 2023

理想的で言えばhaboriteさんの仰る通りですが、クリエイター個人が管理するというところまでいってしまうと、そもそも絵文字登録することが間違っているのではないかという話になりかねない気がします。
絵文字に限ったことではなく、自分で全て管理したいのであれば自分でサーバーを建てるしかないと個人的には感じます。

サーバーに所属し、サーバーのために作品を提供してくれているクリエイターが意図しないところでトラブルに巻き込まれる、権利が侵害されることを防ぎたい(管理側がそれを防ぐ手立てがない現状をどうにかしたい)というのが当issueの目的です。
無断転載を除いて、サーバーに登録すること、サーバー管理者が管理しているドライブ上に預けること自体はクリエイター自身が同意した上でなければ発生しない認識でおります。
なので、引っ越すから使用をやめて欲しい、自分の作品を削除したいという要望は、登録時と同様に、サーバー管理者に対しクリエイターが声がけをする→管理者が削除するというステップがあっても問題ないと個人的には考えます。

しかしこれはサーバー内で完結させる事が出来るのであれば、という話で、現状は二次配布し放題なので各サーバーに飛び散ってしまったものについてはそれが叶いません。
よって、このissueを書いた次第です。

もちろん管理者側が一度登録された絵文字の削除要望自体を良しとしないのであれば、haboriteさんが仰るように利用規約上などに投稿画像や登録された絵文字の権利について表記すべきですし、絵文字登録に限らず「これに同意した上で利用してるよね」と言える環境作りは大前提として必要であると考えています。
(僕自身はもちろんクリエイターから削除要望があれば迅速に応えるつもりですし、限られた時間であっても作品を使わせてくれてありがとうという気持ちしかありませんが…)

@syuilo
Copy link
Member

syuilo commented May 19, 2023

話が発散してきた感じがするので現状「ソフトウェアとして」何が問題なのか今一度明らかにしたい
「絵文字が他のサーバーに 簡単に コピーできる」というのが問題なのであれば、連合しないオプションが出来たので解決したと言えそう
「絵文字が他のサーバーにコピーできる」というのが問題だとしたらインターネットにアップロードする以上それは防げないからMisskeyのソフトウェアとしての問題ではなさそう

@nakajima0528
Copy link
Author

迅速な対応ありがとうございます!
僕としては前者
絵文字が他のサーバーに簡単にコピーできる
という機能に大きな問題があると感じていたので、連合可否設定で大部分要望を通していただいたと認識しております

@nakajima0528
Copy link
Author

コピー出来る事自体が問題となるとソフトウェアどころかインターネット全体の問題なので…

@syuilo
Copy link
Member

syuilo commented Jun 17, 2024

とりあえずインポート機能無効化または廃止すれば解決しそう

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
✨Feature This adds/improves/enhances a feature
Projects
Status: No status
Development

No branches or pull requests