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

カスタム絵文字をインポートする際に、どこからインポートしたかの情報を残すようにして欲しい #14021

Open
1 task
Sayamame-beans opened this issue Jun 16, 2024 · 31 comments
Labels
✨Feature This adds/improves/enhances a feature

Comments

@Sayamame-beans
Copy link
Member

Summary

現状、絵文字のライセンス情報は連合されていません( #10859 )
そのため、一旦の対処として、どのサーバーからインポートしたかという情報を残して欲しいと思います。

この情報は編集不可であるべきで、以下のような対応が想定されます。

  • 既存の"ライセンス"情報は編集可能なため、別途専用のプロパティを用意し、記録する。(←現時点で実装可能)
    • これにより、将来的に絵文字情報が連合されるようになったとき、どこから伝わってきたのかを一覧にして記録する余地がありそうな気もします。或いは、単純に一番最初に認識した情報を伝達していくことも出来そう…
  • 上記に加えて、絵文字にインポートしたものであるかどうかというフラグを用意する?
    • 将来的にライセンス情報が連合されるようになった際に、インポートされた絵文字のライセンス情報を編集/上書き出来ないように出来ます。
      ローカル側で付け足したい内容が存在し得るかどうかや、将来的にリモート側のライセンス情報が更新された場合(nullからの変更など)への対応は要検討です。

Purpose

絵文字のインポート関連の状況を改善
権利関係等の都合

Do you want to implement this feature yourself?

  • Yes, I will implement this by myself and send a pull request
@Sayamame-beans Sayamame-beans added the ✨Feature This adds/improves/enhances a feature label Jun 16, 2024
@syuilo
Copy link
Member

syuilo commented Jun 16, 2024

そもそも他サーバーからのインポート機能いるかしら

@KisaragiEffective
Copy link
Sponsor Member

KisaragiEffective commented Jun 16, 2024

そもそも他サーバーからのインポート機能いるかしら

コンテンツに責任を持たない消費者がフォーム経由で登録したときに出所を https://notestock.osa-p.net/custom_emoji_explorer.html で探すのが面倒なのでほしい

@Sayamame-beans
Copy link
Member Author

インポート機能がない場合は手動で再登録することになるだろうと考えると、Misskeyとして"インポート"機能をサポートしつつ、どこからインポートされたかを記録/保持してくれる方が良さそうに思います。

@tai-cha
Copy link
Member

tai-cha commented Jun 16, 2024

#10822 (comment)

@syuilo
Copy link
Member

syuilo commented Jun 16, 2024

その画像が本当にオープンかどうかは簡単には分からなそう

@tai-cha
Copy link
Member

tai-cha commented Jun 16, 2024

現状モデログに残している絵文字の登録や更新の情報を絵文字ごとに見られるようになるだけでも管理のしやすさは変わりそう(ログがあれば編集不可になっていなくても変更ログを追うことはできる)

@tai-cha
Copy link
Member

tai-cha commented Jun 16, 2024

その画像が本当にオープンかどうかは簡単には分からなそう

そのためにもライセンスの連合が望まれている認識
#10859

あとは不適切な絵文字の拒否という意味になると
#13937
もあるけどこれに関してもライセンスが連合されていると拒否の材料になりそう

@tai-cha
Copy link
Member

tai-cha commented Jun 16, 2024

インポートを廃止することがこの問題の解決になるとは思っていない(むしろ画像だけ取得されて別名で登録されると余計に手間が増える)

@noellabo
Copy link
Contributor

参照先のissueでも言及していますが、Fedibirdでは

isBasedOn: "https://fedibird.com/emojis/92354"

という形で元絵文字のURIを記録するようにしています。

@syuilo
Copy link
Member

syuilo commented Jun 17, 2024

「簡単に」インポートできてしまうことが問題として挙げられているから、インポート機能がなければ簡単に追加はできなくなるからある程度解決しそう
#10822

@KisaragiEffective
Copy link
Sponsor Member

個人的な意見: 退化させる方向よりも進化させる方向で発展的に解決した方が混乱を招かなくてすみそう

@syuilo
Copy link
Member

syuilo commented Jun 17, 2024

発展的な解決策が考えられて実装されるまで時間がかかる可能性があるからそれまでとりあえず無効化したい(ソフトウェアとして他サーバーにあるコンテンツを簡単にコピーして自分のサーバーのコンテンツとして使える機能があることに対して批判やトラブルが多いため)

@syuilo
Copy link
Member

syuilo commented Jun 17, 2024

現時点では、著作権などに配慮してくれる運営者であればインポート機能が無くても困らないはずだから、機能を維持したい積極的なモチベーションもない
(自分の管理する他のサーバーからインポートしたいとかであれば、一括zipエクスポート/インポート機能が別にあるからそれ使えば良いだけだし)

@syuilo
Copy link
Member

syuilo commented Jun 17, 2024

今までライセンス的に大丈夫だと思われていた絵文字が実はダメなやつだったとかもあるし、「この絵文字は絶対にインポートして大丈夫」というのは自分が作った絵文字以外あり得ないのではないかしらと思った

@Sayamame-beans
Copy link
Member Author

(参考までに、にりらみすきー部ではインポート元となるサーバーでのライセンス表記を確認した上でインポート機能を使用する形を取っています)

@Sayamame-beans
Copy link
Member Author

Sayamame-beans commented Jun 17, 2024

現状、Misskeyにはしばらく前から絵文字のインポート機能があるため、"ローカルのみ"を指定しておらず、ライセンス情報を登録していない絵文字はインポートや改変が可能なものとして登録されていると認識して利用されていても不思議ではないと考えています。
(インポート元のライセンス記述を確認するのは問題ありませんが、そこに記述されていない絵文字のライセンスをググったりして全て独自に調べて確認することはあまり現実的では無いため)

そのため、インポート機能が無くなると(逆に、インポートされないという前提が生まれて)後々問題になりそうな気が少しします。

@VillSnow
Copy link

「インポート元サーバーが原作者に無断で(ライセンスを得ずに)絵文字を作成しているパターン」と、「インポート元サーバーに絵文字を作成した人がインポートを許可していなかったり、認識していなかったりしていたパターン」があると思っています。

後者についてはインポート時にライセンス情報が表示されてCC表示が書かれていれば安心できます。ここだけでも解決する価値はあると思います。

@tai-cha
Copy link
Member

tai-cha commented Jun 17, 2024

「簡単に」インポートできてしまうことが問題として挙げられているから、インポート機能がなければ簡単に追加はできなくなるからある程度解決しそう #10822

#10822 (comment)
ここでも単に廃止すれば解決するという結論には至ってないように思うのだけどなんでそうなったの?

@tai-cha
Copy link
Member

tai-cha commented Jun 17, 2024

(廃止しても改善しないあるいは悪化も考えられるから現状維持されてきたものだと認識している)

@syuilo
Copy link
Member

syuilo commented Jun 17, 2024

「簡単に」インポートできてしまうことが問題として挙げられているから、インポート機能がなければ簡単に追加はできなくなるからある程度解決しそう #10822

#10822 (comment) ここでも単に廃止すれば解決するという結論には至ってないように思うのだけどなんでそうなったの?

インポート機能が無ければ今より簡単さは減りそう

@anatawa12
Copy link
Member

「簡単に」インポートできてしまうことが問題として挙げられているから

そもそもこのissueにそのような文言はない

@syuilo
Copy link
Member

syuilo commented Jun 17, 2024

あーIssue間違えてた

@syuilo
Copy link
Member

syuilo commented Jun 17, 2024

いや合ってた

@syuilo
Copy link
Member

syuilo commented Jun 17, 2024

サーバーのために作られた絵文字が、リレー先で簡単にインポート出来てしまう

@syuilo
Copy link
Member

syuilo commented Jun 17, 2024

まあそのIssueに限らずそのような意見はよく見るわね(自分もそう思う)

@tai-cha
Copy link
Member

tai-cha commented Jun 17, 2024

一時的な廃止なのか恒久的な廃止なのかによってかなり意見が異なる

  • 一時的な廃止
    • インポートの諸問題を解決できる気がしないから一時的に廃止する
    • (これはまあやるのもなしではないとは思う、でもlocalOnlyである程度は解決している認識)
    • (個人的にはlocalOnlyもある現状で廃止が解決になると思っていないので賛成ではない)
  • 恒久的な廃止
    • これはインポートのほうがむしろきちんとライセンスを作り込めるなら手軽に権利クリーンにできる可能性がある

@tai-cha
Copy link
Member

tai-cha commented Jun 17, 2024

むしろこのIssueの文脈と目的としては他の大元などのIssueでインポートの是非の議論がされた上でインポートを残す場合にはインポート元サーバーのURLを残してほしいという要望だと認識している

これをするとimportがbetterになるという提案で

@tamaina
Copy link
Member

tamaina commented Jun 17, 2024

インポート機能を封じたら画像をコピーしてインポートするサーバーが増えると思うので、カスタム絵文字のインポート機能を充実させて色々なデータを残すようにした方がむしろトラブルは少なくなると思う

@tamaina tamaina closed this as completed Jun 17, 2024
@tamaina tamaina reopened this Jun 17, 2024
@tamaina
Copy link
Member

tamaina commented Jun 17, 2024

その画像が本当にオープンかどうかは簡単には分からなそう

絵文字のインポート可否はbooleanで専用のプロパティとして持っておくべきだと思う

@Sayamame-beans

This comment was marked as duplicate.

@Sayamame-beans
Copy link
Member Author

Sayamame-beans 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: Triage
Development

No branches or pull requests

8 participants