SMPDのグローバル展開(SMPD's overseas expansion)

Pass

@sunatomo さん

リプライありがとうございます。
これは、マニュアルの検討項目ですね。

hiroget9

@sunatomo さん
ありがとうございます。
先ほど、再起動したらsmpd.localで名前解決できました。
Avahi Daemonがハングアップしていたようです。
こういうことが、あるんですね。全く気付いていませんでした。

webuiで接続できない事例の対処の一例になると思われますが、私のようにipアドレスを把握していないと、シャットダウンさせずに電源ブチ切りということになります。

話題が変わってしまうのですが、sdカードをリードオンリー化させるのが安全策として有効になりそうですね。

hiroget9

グローバル展開を進めていく上で、少し気になった点を少々。
考えすぎでしょうか？

重大な規約違反の対処について、管轄裁判を明記した方が良いのかなとふと思いました。
その前に、クラブのメンバーに加わる際に、ソフトウェア利用許諾契約に同意するなどの処置を施してはいかがでしょうか？
国内での利用が主であったこれまでよりシビアにならないかと気になりまして。

Pass

@hiroget9 さん

その点は私も懸念しています。

今までは純粋にsmpdを利用したい人達の集まりでした。海外の利用者、特にスキルの高い人達となるとどのような考えの人が興味を持つのかが分かりません。ソース目的で近づいてくる人も居るかもしれません。
また、我々のサポートとうまくコミュニケーションが取れず、利用できない腹いせでソースを要求してくるなども考えられます。

そのあたりは、パパリウスさんがどのようにお考えになるかになりますね。

sunatomo

@hiroget9 さま
@Pass さま
GPLに関する著作権の考え方についてはここに記載されている通りの解釈だと思います。
「smpd Research and Development Club」に上記の記載を解釈として記載してもよいのではと。

ただし、世の中理屈の通じない人間はいるもので、そういう人間と接することで対応者が精神的に疲弊し進化を止めてしまったプロジェクトはいくつもあるのも事実です。
最終的には主宰のパパリウスさまが「必要に応じて」対応することが生じるかもしれませんね。

hiroget9

@sunatomo さん
@Passさん

最終的にはパパリウスさんのお考えによると思いますが、今のうちに整理が必要かと危惧しています。
少し前のソース開示要求のような事が、狡猾な輩から「明記していない」「契約していない」」「こう解釈した」」とか出てこないか心配ではあります。退会した後の縛りも必要ではないでしょうか。
また、重大な規約違反に関しては、管轄裁判は日本国内のどこかにしておかないと不利益を被るのではないでしょうか。
形式的かもしれませんが、利用にあたって「利用条件を承諾」させることで、無駄なトラブルを防げるのではと思います。

私は、法律に疎いので散漫で申し訳ありません。

ジャイアン

SMPDのグローバル展開において「ソフトウェア利用許諾契約に同意するなどの処置」は非常に重要なプロセスだと考えます。
ここで議論されているように、どんな難癖をどんな方向からつけてくる輩がいるか分かったものではありません。この点については、打てるべき手は全てうっておくべきと考えます。

実は私は、このGPLに関して惹起するかもしれない諸問題を考えると、SMPDの展開はドメスティックなもので十分だと考えてきた人間です。仮に問題が惹起し、そのために開発者さまの心労が過多になれば、SMPDプロジェクト自体がなくなってしまうかもしれない。それだけは嫌だと考えてきました。
しかし、一旦グローバル展開をすると方向性が示された以上、やるなら徹底してやるべきと今は考えています。

この辺のスキル、経験をお持ちの方がいらっしゃったら、ぜひメンバーに加わっていただきたいですね。

パパリウス

@ジャイアンさん、 @hiroget9 さん、 @sunatomo さん、 @Pass さん

問題提起していただきありがとうございます。

本ソフトウェアは会員の権利として利用いただいています。
会員契約 を文書等で残るようにして、外部流出などの規約違反への措置を明かにするとよいのでしょうかね。

将来的にはソース開示要求にお応えできるように、環境を整えていきたいと思っています。

そのためには、開発プロセスの整備、ソース管理手順の整備に加えて、依頼があったときの対応手順など、諸々を準備する必要があります。

仕事であれば必須のプロセスですが、ソフトウェア構成・実装方式も流動的なため、作業の自動化がバージョンアップになかなか追いつきません。

手作業でやるとなれば数時間がかりの作業になるため、個人の趣味として続けるには少々負担が大きいところがネックです。

（改変対象のソフトウェアを数本に絞り込んでしまえば、管理作業もシンプルになりそうですが。。。）

メンバーの方に事務的な作業のご支援をいただくなど、やりかたの工夫が必要かもしれません。

sunatomo

分かっている範囲でソースコードを改良（していると思われる）各ソフトウェア名・ライセンス・ライセンス条項のURLを速報で記載しましたので参考にして下さい（17:40 一部追加）。

BSDについては宣伝条項がない場合には勝手に使用しても問題ないと思います。
GPLは1つ前の私のリンクで当面の要求には対応できるのではないでしょうか。

・linux-kernel
　GPL v2
　https://www.kernel.org/doc/html/v4.18/process/license-rules.html
・Xenomai
　GPL v2
　https://gitlab.denx.de/Xenomai/xenomai/blob/master/include/COPYING
・alsa-lib
　GPL v2.1
　https://git.alsa-project.org/?p=alsa-lib.git;a=blob_plain;f=COPYING;hb=HEAD
・tcmalloc
　BSD 修正もしくは3条項ライセンス
　https://github.com/gperftools/gperftools/blob/master/COPYING
・ffmpeg
　大部分は LGPL v2.1
　https://git.ffmpeg.org/gitweb/ffmpeg.git/blob_plain/HEAD:/LICENSE.md
・mpd
　GPL v2
　https://www.musicpd.org/commercial.html
・libmpdclient
　revised BSD License
　https://github.com/MusicPlayerDaemon/libmpdclient/blob/master/COPYING
・ympd
　GPL v2
　https://github.com/notandy/ympd/blob/master/LICENSE
・shairport-sync
　bsd相当？
　https://github.com/mikebrady/shairport-sync/blob/master/LICENSES
・spotifyd
　GPL v3
　https://github.com/Spotifyd/spotifyd/blob/master/LICENCE

@パパリウスさま

将来的にはソース開示要求にお応えできるように、環境を整えていきたいと思っています。

とのお考え、ご提示有難うございます。
とはいえ、まずはパパリウス様が「今一番やりたことをする」のが一番だと思います。
私としては当面は「開発に支障となる可能性について事前調査する」位は協力出来ると思いますので、必要に応じお声がけ下さい。

パパリウス

@sunatomo さん

調査いただきありがとうございます。
リストアップしていただけると把握しやすくて助かります。

あと主要なものは、Xenomai、alsa-lib、tcmalloc、各種コーデックライブラリを改変して使っています。

コーデックをオリジナルのまま使うようにすれば管理が楽になりそうです。