フォロー

Mastodonクライアントアプリを開発した場合、それはAGPLを引き継がなきゃ駄目なのかね?

他にもMastodon互換サーバ(内部コードは違うがMastodonAPIを吐く)を開発した場合はAGPLを引き継がなきゃ駄目なんだろうか

AGPLのこの辺りをよく理解してない

「私の解釈では」で良いので誰か教えて下さい

@zundan どう考えても分散SNSを活用して規模を大きく商業活動しようと思えばMastodon互換は魅力的なので、それを閉じられると分散SNSの普及速度が落ちてしまうだろうなと思っています

Mastodon互換APIが利用可能であれば、Togetterのようなまとめサービスをメインとしつつ、Mastodonクライアント機能を備えたアプリとかも作れるわけですよ

間違いなく営利企業としては商機なので営利企業の資本力を持って分散SNSが盛り上がるだろうなと

@keizou Mastodonのソースコードをコピーしてきて利用していないならAGPL以外のライセンスで配布することができると思います。

僕の理解では、(A)GPLは著作権を根拠としたライセンスで、APIのみを利用してソースコードを利用していない場合には効力が及びません。ただ、(A)GPLのライブラリにリンクしていて、そのライブラリがないと動作できないようなプログラムについては、(A)GPL的にソースコードを利用していると見なされていて、(A)GPLで配布する必要があります。蛇足ですが、LGPLで配布されているライブラリを利用するプログラムは、LGPLと非互換なライセンスで配布することができます。

識者の方ツッコミをよろしくお願いしますう!

@zundan ソースコードさえ違えば動作の振る舞いが同じでもAGPLには抵触しないと解釈するのが正しい・・・のかな?

その場合はどうやって著作権を侵害していないことを証明したら良いのか・・・ってアレか、センシティブな部分へ影響しないようにMastodon互換コードを書けば良いのか

そして開示を求められた際に著作権を侵害していないとしつ一部Mastodon互換コードを公開したら良いのか

・・・たぶん?w

@keizou リスク管理をちゃんとするとすれば、AGPLなコードの著者に訴訟を起こされたときに、負けないくらい、コードを利用していないという証拠を残しながら書いてくのかな、と想像します。すっごく厳密にやるとすれば、AGPLなコードを見たことのない人だけが振る舞いだけを頼りにゼロからコードを書くんだろうと思います。プロプラなハードウェアのオープンソースなドライバもたぶん似たようなやり方です書かれてたんじゃないかと思います。しかし実際問題どうなんだろう…

@keizou はい。あまり深く考えたことはないのですが、Mastodonのライセンス的には、Mastodon互換のフロントエンドやサーバのサービスを運用することに問題はないんじゃないかと想像します。(現実的に裁判を起こされる可能性がなさそうという点で)

どちらかというとMastodonがフロントエンド側のAPIが変更されたときにどうするか、とか考えておきたくなっちゃう。裏側のActivityPubとは違い、MastodonのRailsとReactで整合性がとれてればどんどん変えていけちゃうものなので。携帯アプリの作者の方々には対応の素早い方もいらっしゃって、すごいです(語彙)。

@keizou それらはGPLの「リンク」の概念に抵触しないのでライセンス汚染はないはずだよ。通信だけでライセンス汚染するのならWebブラウザまでダメになっちゃう

ログインして会話に参加
グルドン

Mastodon は、オープンなウェブプロトコルを採用した、自由でオープンソースなソーシャルネットワークです。電子メールのような分散型の仕組みを採っています。