あんまり自分がしたかった投稿じゃないけど、やってみる。
CachyOSを日常的に使ってるけど、使ったことのないディストリビューションをちょっと試してみたくてさ。実際、楽しんでるから、このプロジェクトに対して嫌悪感とか悪意は全然ない。
それでも、今日はドキュメントを読んでたら、[このページ]([https://wiki.cachyos.org/policy/repository_policy/)](https://wiki.cachyos.org/policy/repository_policy/)にたどり着いて、リポジトリの利用規約を見たんだけど、ちょっと問題だと思った。
基本的に、彼らはパッケージの再配布を防いでるんだよね。[
5. リポジトリの再配布
このポリシーでは「再配布」を、 CachyOSリポジトリ（およびそのミラー）を含む行為、またはCachyOSリポジトリから取得したパッケージをオペレーティングシステムまたはシスルートの配布イメージの一部として含める行為と定義します。 再配布には、ユーザーの選択によってCachyOSリポジトリを有効にするユーティリティを提供するLinuxディストリビューションの行為や、ユーザーがCachyOSリポジトリ（およびそのミラー）を有効にするための公式文書を提供する行為も含まれます。エンドユーザーとサードパーティのミラーは再配布ポリシーの対象外です。
CachyOSリポジトリの再配布は、CachyOSチームのみに独占的に許可されています。
6. 禁止された再配布
他のArchベースのディストリビューションを含む、無許可のLinuxディストリビューションでのCachyOSリポジトリ（およびそのミラー）の再配布は厳格に禁止されています。これには、以下が含まれますが、これに限定されません：
Manjaro
EndeavourOS
ArcoLinux
Parabola
「リポジトリの再配布」セクションに明示的に記載されていないその他のLinuxディストリビューション。
俺の理解では、これらの条項はGPL3.0などのいくつかのアップストリームライセンスに重大な違反をしてると思う。なぜなら、第三者が派生物（パッケージがそうだ）を自由に配布するのを防ぐことはできないから。
俺が間違ってるのか、それともこのポリシーの言葉は実行不可能でおそらく違法なのか？
コメント (82)
_________________________________________________
それはGPLを破ってるわけじゃない。GPLは特にソースコードに焦点を当ててるから。彼らは（仮に）ソースコードへのアクセスを遮断してるわけじゃなくて、バイナリパッケージを遮断してるだけ。バイナリパッケージをコンパイルするために使われたソースリポジトリをダウンロードして、自分でやることはできる。これはGPLの文脈ではあまり考えられない珍しい状況だよ。通常はバイナリがあってソースコードがない、逆はないから。
要するに、「他のディストロのための『ベース』になりたくないから、自分でリポジトリを用意して、アップストリームのサポートは期待しないで、CachyパッケージをManjaroでうまく動かすためにハックするのを手伝いたくない」っていう怖い言葉だと思う。法的には何の根拠もないし、ただ「これをやるなって言っただろ」って言うためのもの。
これだ。俺には「サポート担当者は他のディストロの人とやり取りしない」って聞こえる。
それはOBSが対処しなきゃいけないことを見てると、完全に理解できる。
これは法的に執行不可能な声明で、もしかしたらナイーブで簡単に怯える人たちが気にするかもしれない。ただ、ビッグテック企業のように振る舞いたいLinuxディストリビューションは避けた方がいい。彼らは間違った態度を持ってる。彼らのディストリビューションよりMacOSを使いたい。
これは非常に間違ってる。GPLソースのコンパイルは常に派生物であり、GPLでなければならない。
君は彼らが言ったことに矛盾することを言ってない。
君のポイントは何？誰かがバイナリを渡してきたら、ソースも渡さなきゃいけないってこと？この議論には関係ない。
それとも、誰かが作品を渡してきたら、すべての派生物も渡さなきゃいけないってこと？それは真実じゃないし、ちょっとおかしい。
引用して。
GPLにおいてコンパイルされたバイナリが派生物であるという言及を見つけられない。ちょっとスクロールして、‘compile’や’binary’でCTRL+Fしたけど、GPLv3では確認できなかった。
バイナリは一般的に著作権法における派生物であり、GPLに特有のものではない。誰かのソースコードを無断で取って、ライセンスなしでコンパイルして配布を始めることはできない。例えば、Microsoftのような企業がBSD派生のツールを提供し、GPLソフトウェアを避けていた理由がある。
FSFの解釈からだけど、ライセンスの根本的な文言を直接参照してる：
自分が間違ってると権威的に言うのは面白いね。
これはGPLを破ってる。彼らがバイナリをダウンロードさせるなら、ソースコードもダウンロードさせなきゃいけないし、バイナリとソースコードを一緒に配布することも許可されてる（またはソースコードだけ、バイナリだけはダメ）。
それは全く真実じゃないと思う。CachyOSはプログラムを再配布していて、元のものからそれを取得できる。CachyOSは、彼らからバイナリを受け取った誰にでも、変更がマークされたソースコードを提供する必要がある。でも、彼らは誰にでもバイナリを配布する必要はなくて、バイナリに対して料金を要求することもできるし、ソースコードを一般に公開しなくてもいい（バイナリを取得した人には提供する限り）。
彼らはバイナリを配布する必要はないけど、もし配布するなら、ソースコードなしや別のライセンスのもとで再配布するのを防ぐことはできない。
アップストリームのソースコードを指摘するだけでは、NO、それは不十分だ。例えば、
君が言及してるテキストが俺の書いたことと矛盾してるとは思えない。
でもGPLの文言自体は、バイナリを配布する場合、受取人がそれを再配布するのを防ぐことはできないと言ってる。
_________________________________________________
俺はGPL3がソースコードへのアクセスを提供しなければならないと言ってると思ってるけど、コンパイルされたコードへのアクセスを提供する必要はない。
だから、CachyOSがソースコードの公開リポジトリを持っている限り、他のディストロがそのリポジトリをインストールオプションとしてアクセスするのを止めることができる。
君がリンクしたCachyOSの利用規約も、ミラーやエンドユーザーはこの特定のポリシーの対象外だと言ってる。これは他のディストロのためだけだ。CachyOSパッケージを使いたいなら、自分でコンパイルして、自分のミラーを通じて共有しなきゃいけない。
君はほぼ正しいと思う。俺にとっての問題は、彼らのリポジトリへのアクセスを与えることではなく、俺がすでに持っているリポジトリから取得したパッケージに対する彼らの主張で、彼らの規約によると制限がある。
その部分が俺の頭の中でGPL3に違反してると思う。バイナリへのアクセスを制限する一般的なアイデアではなく、すでに手元にあるファイルをどう使うかを言おうとしていることだ。
彼らは他のディストロのためのリポジトリとして使われることを望んでない。 彼らは君がすでに持っているものを気にしてない。
俺の最後のポイントをもう一度繰り返すよ。君がリンクした引用を使って：「エンドユーザーとサードパーティのミラーは再配布ポリシーの対象外です。」
だからポリシーはバイナリよりも、実際のリポジトリのURLを制限情報として扱ってるってこと？
彼らは他のディストロの問題に関わりたくない。
OBSが対処しなきゃいけないようなことを避けたいって感じだ。
もし俺がエンドユーザーじゃなかったら？もし俺がカスタムLinuxイメージの供給者で、それをオンラインで公開してるなら？この差別はGPLの条項に反する。
今、君は過度に鈍感になって、GPL3ライセンスや法的合意、当事者の概念、善意で行動するという概念を理解してない気がする…
君はGPL3が「俺はソフトウェアで好きなことができる」って意味だと思ってるけど、そうじゃない。
GPL3を読んだことある？俺は君に答えるために特に読んだ。他の人もこのスレッドで同じことを言ってる。
ソースコードが自由に提供されている限り、エンティティはコンパイルされたコードに関して何を望んでも規定できる。
君は君のOSを配布するために彼らのサーバーを無料で使う権利があると言ってるの？GPLはそれを要求してない。
君がソフトウェアを配布するなら、君はそのソフトウェアのライセンスを読み、遵守する責任がある。
ええ、そうじゃない。でも、ほとんどの人が俺の不満をそう理解したみたいだ。おそらく、俺がメインの投稿で自分をうまく説明できなかったから。
彼らは自分たちのリポジトリを好きなように扱うことができる、疑問はない（明示的にそれに反するライセンスがない限り、でもそれはおそらくFOSSとしても資格を持たないだろう）。
だから、はい、彼らはバイナリへのアクセスを有料にしたり、IPに基づいてレート制限をかけたりできる。
俺の不満は、カスタムイメージやシスルートにおけるパッケージの配布に関する彼らの特定の言い回しについてで、彼らはその起源のために、すでにそのファイルを持っている場合でも明示的に禁止している。これが俺の意見ではGPLに反してる。狭い文脈においてだけど。
オブジェクトファイル、ライブラリ、実行可能ファイルは派生物であり、パッケージはそれの派生物だから、パッケージはGPLであり、手に入れた後にその配布に追加の制限を受け入れることはできない。基本的に、ファイルを手に入れたら、彼らはGPLの条項以外での使い方を指示することはできない。
でも、彼らはリポジトリへのアクセスを制限することはできるし、その背後にある動機には一般的に同意できる。
君はどうやってその文を構築することを期待してるの？
アイデアはシンプルだ。「俺たちは君のユーザーのサポートリクエストには対応しない」
それを得るための唯一の効果的な方法は、他の誰かがそれを言及するのを防ぐことだ。
Curlは多くのGPSサポートリクエストを受ける。なぜなら、「about」セクションで言及されているから。
OBSは、AURパッケージがその機能を壊したために、機能が動かないと不満を言うユーザーに対処しなければならない。
ああ、なるほど。99%のそのページは明らかに「CachyOSだけが俺たちのサーバーにアクセスするべきだ」と言おうとしてる。
君が引用した部分には2つの部分がある：
このポリシーでは「再配布」を定義します
1. CachyOSリポジトリ（およびそのミラー）を含む行為、または
- オペレーティングシステムまたはシスルートの配布イメージの一部としてCachyOSリポジトリから取得したパッケージを含む行為
#1は「他のOSを始めるときに怠けて俺たちのサーバーを使うな」と言ってるだけで、GPLには関係ないことに同意できる。
#2は「このポリシーでは『再配布』をCachyOSリポジトリから取得したパッケージと定義します」と言ってたら悪いことになると思う。でも、そうは言ってない。
言ってることは2つの方法で解釈できる：
このポリシーでは「再配布」を定義します CachyOSリポジトリから取得したパッケージをオペレーティングシステムまたはシスルートの配布イメージの一部として。
それは、君の「配布イメージ」はパッケージを取得すべきではないと言ってる。つまり、1+2を合わせると「通常のアップデートのために俺たちから引っ張ってくるな、でもブートストラップ中に俺たちから引っ張ってくるための抜け道があると思うな！」ってことだ。
要するに、君は彼らのパッケージを使った自分のサーバーを立てる権利がある（商標や非GPLのものを除いて）。
彼らに言ってみて、言葉が解釈しにくいって。だけど、意図は「CachyOSだけが俺たちのサーバーにアクセスする。俺たちは他のOSが俺たちのサーバーを使うのを望んでない。つまり、1) 君のサードパーティOSに俺たちのリポジトリを追加するな、2) 君の新しいOSのブートストラップの一部としてCachyOSサーバーを使うな」ってことだ。
君はGPLが実際に何を意味するか全く理解してないんじゃない？
もしカスタムイメージがあるなら、他の誰かのインフラと限られた時間を使うな。
誰かのパッケージを使うと、すべてのサポートリクエストは彼らに影響を与える、君には影響しない。 それは良くない。
リポジトリを維持するのはお金がかかる。
他のディストリビューションが彼らのリポジトリを使うのを望まない理由は完全に理解できる。彼らの費用を増やすだけで、他のディストリビューションは何も支払わないから。
絶対にそうだ。誰もフリーローダーを望んでない。誰かが自分のディストロを作りたいなら、自分のリポジトリを運営する必要がある。ソースコードを取得してコンパイルして、自分のリポジトリに入れるのは問題ない。
彼らのリポジトリからすでに手に入れたパッケージに対する主張
まず第一に、Linuxディストリビューションには多くのソフトウェアが含まれていて、ライセンスもたくさんある。すべてがGPLじゃない。でも、ほとんどの場合、特にGPLやオープンソースに関しては、彼らが求めるのはソースを利用可能にすることだ。それは、彼らがそのソースから作成したバイナリを制限できないということではない。彼らは君がソースにアクセスできるように合理的な配慮をしなければならない。結局のところ、オープンソースはオープンバイナリやオープンパッケージ、オープンリポジトリではなく、オープンソースが最も重要なのはソースコードだからだ。これがバイナリの作成や修正、変更の自由を可能にする。これがオープンソースの本質であり、GPLは彼らが作成したバイナリを自由に再配布することを義務付けているわけではない。
もし君がその点でずっとマシなディストリビューションを望むなら、Debianを勧める。自由に再配布可能で、ほとんどがオープンソース（メインはそうだが、非自由なものも提供しているし、自由に再配布可能なファームウェアもある）。以下も見てみて：
- Debian Social Contract（100%自由であり続ける、問題を隠さない、ユーザーと自由ソフトウェアが優先される…）
- The Debian Free Software Guidelines (DFSG)（自由な再配布；ソースコード；人、グループ、活動分野に対する差別なし…）
_________________________________________________
これは合理的に思える
- 誰でも自分でコンパイルできる
- ホットリンクで彼らのサーバーに負荷をかけるのはフェアじゃない
- 彼らのビルドコストから利益を得るのもフェアじゃない
俺はRHELとCentOSでも同じことがあったと思う。すべてが再構築されてた。
これはずいぶん前に見たことがあるけど、何年も前にSuseソースからRPMをビルドしようとしたことがある。すべてのソースコードがそこにあったけど、ビルドスクリプトは含まれてなかった。何百行にも及ぶことがある。要するに、ソースからRPMをビルドすることはできない。これがスタールマンを「自由なシェルスクリプトが欲しい」と言わせた。俺はそれについてどう感じるかはわからない。
これはちょっとレッドヘリングだ。なぜなら、GPLのようなライセンスの根本的なポイントは、ソフトウェア自体のソースコードが利用可能であるべきだということだから。ビルドスクリプトはそのソフトウェアに付随するものだ。理論的には、GPLライセンスのソフトウェアのソースコードを提供することはできるが、完全に独自のビルドスクリプト実装を持っていても、他の人が自分で書くことを制限することはできない。
俺が思いつく最良のアナロジーは、Archが最近AURのPKGBUILDファイルをBSD 0条項の下で再ライセンスしたことだ。これは基本的に「誰もこれに文句を言ったことがないが、仮に誰かが言うかもしれないので、自己防衛のためにこれをやってる」ってことだ。
これがスタールマンを「自由なシェルスクリプトが欲しい」と言わせた。俺はそれについてどう感じるかはわからない。
スタールマンはすべてのものが彼/FSFの基準に従って自由なソフトウェアであるべきだと思っているので、そう言うのは当然だ。
じゃあ、君はこれがOKだと思ってるの？俺はこのことについてはどっちつかずだ。一方では、Linuxシステムを使ってRPMをビルドするための知識を持っているべきだと思う。もう一方では、大規模なソフトウェアには多くの手間がかかり、俺が知らないか、リフレッシュが必要な言語で書かれていることがある。システム管理者はどれくらいのことを知っておくべきだ？もし君がTCLで書かれた新しいパッケージを渡して、会計のことをやるためにLuaでビルドスクリプトを書く必要があるとしたら、君はおそらく時間をかければ理解できるだろう。もし同じパッケージをAPLで書かれ、大きなCUDAの塊があって、PTXで何かを書く必要があるとしたら、君は大変なことになるだろう。
広く言えば、システム管理者の仕事は、一つのソフトウェアパッケージを一つのマシンから別のマシンで動かすことだと思う。俺はtermuxが好きだ。これはAndroidとBionicの間の互換レイヤーで、準LSB的な機能を持つLinux環境だ。もし俺が君に、ExcelをAndroidで動かすためにそれをすべて書く必要があると言ったら、君はその場合GPLが満たされていると言うだろうか（ExcelがGPLだと仮定して）。俺たちは仮定する必要はない。これは現在のLibreOfficeの状況だ。termuxにはLibreOfficeがない。
そのシナリオでは、はい、GPLは満たされている。もし俺が望むなら、GPLでライセンスされたソフトウェアを完全に壊れた状態や半端な状態でリリースすることができる。ライセンスは配布するコードをカバーしていて、それが使用可能であることや、特定のツールチェーンなしでコンパイルできることを保証するものではない。
もしそうなら、俺の主張はGPLがほとんど空っぽだということだ。これは滑りやすい坂道だが、弁護士のように考えてみて。若い頃、俺は6502のコードを16進数で書いた。ソースコードは存在せず、オブジェクトコードだけだった。今でもそうする人がいる。スティーブ・ウォズニアックもそれについての記事を書いた。レッドハットがバイナリをリリースして「それがすべてだ」と言うことを防ぐものは何だ？
君のポイントを理解してない。GPLは配布するソースコードをカバーしている。GPLを使わずにバイナリだけをリリースしたいなら、それは君の選択だ。レッドハットは自分のコードを好きな形式やライセンスでリリースできるが、サードパーティのソフトウェアや派生物を配布する際にはライセンスに従わなければならない。
GPLの目的は、エンドユーザーに自由なソフトウェア（両方の意味で）を提供することだった。もしそのアイデアを回避するなら（「俺は16進数で書く」「Androidで動かすために互換レイヤーが必要だ」）、全体が無駄な行為になる。最も有名な例はTivoだ：
これがフリーソフトウェア財団にGPLを変更させる原因になった。
とにかく、君は俺のポイントを理解していると思う。君はただ法的なことにこだわっているだけだ。
俺は君のポイントを十分に理解していると思うが、君のポイントは誤解されていると思う。GPLはすべてのGPLソフトウェアを使用できるということだ。杖は、バイナリを提供する場合はソースコードを提供しなければならない、さもなければ刑務所に行くということだ。これを回避しようとする努力は、可能であれば公的圧力で、そうでなければ法的手段で止めるべきだと思う。
GPLはソフトウェアが自由であることを要求しているわけではない。彼らは自由ソフトウェアを販売することについてのページも持っている。
自由ソフトウェアの目的は何だと思う？スタールマンが人々にコンピュータを使わせ、彼らができることに柔軟性を持たせたかったのは明らかだ。スタールマンは共産主義者ではなく、ソースを手に入れられる限りソフトウェアを販売することに問題はない。彼が自由で制約のないソースを望む理由は、彼がそれを使ってバイナリを作り（簡単に販売できる）、ソフトウェアの価格に上限を設けるためだ。その上限はボランティアプログラマーの利用可能性によって決まる。俺はこのことについてたくさんの考えを持っているが、ひとつの見方は高価なソフトウェアへの攻撃だ。もしほとんどの人がソフトウェアを書いている世界に住んでいたら（今そう見えるかもしれないが、そう考えてみて）、GPLは冗長になるだろう。スタールマンは安価な「自由な」ソフトウェアを望んでいる。
もしそうなら、俺の主張はGPLがほとんど空っぽだということだ。
そうではない。GPLは、君が使えるコードや、コンパイルしやすいコードや、特定のツールチェーンを必要としないコードを保証するものではなく、ただ…コードを提供するものだ。
俺はGPLの純粋主義者ではないが、GNewSenseのようなディストリビューションが存在し、広く言えば使えることは、GPLソフトウェアの周りに十分なエコシステムが構築されていることの証明かもしれない。
じゃあ、レッドハットがバイナリをリリースして「それがすべてだ」と言うことを防ぐものは何だ？
基本的に、バイナリはソースコードではない。
でも、いずれにせよ、レッドハットはバイナリをいくらでもリリースできるが、彼らが修正または作成したGPLソフトウェアのソースコードを利用可能にしなければならない。これは強く注意しておくべきことだ。
ずいぶん前に見たことがあるけど、何年も前にSuseソースからRPMをビルドしようとしたことがある。すべてのソースコードがそこにあったけど、ビルドスクリプトは含まれてなかった。何百行にも及ぶことがある。
だから、俺は何年もRPMをビルドしてきたが、.src.rpmとその.specファイルがあれば、ビルドスクリプトがある。俺はRed Hat、SuSE、そして他のRPMベースのディストリビューションでソースからRPMをビルドしてきた。
ソースからRPMをビルドする際には、ビルド順序が最も重要な問題だが、最後に確認したとき、.src.rpmがあれば、必要なビルド「スクリプト」があった。かなりの時間が経っているので、状況が変わっているかもしれないが、OpenSUSE LEAP 16.0のために、今でもsrc.rpmファイルを取得できる。OSSのもののリポジトリは
俺は調査するつもりはないが、確かに2005年頃にSuseのソースからビルドする際にこの問題があった。偶然にも、これはスタールマンが「自由なスクリプト」キャンペーンを始めた時期だ。これが君が問題に直面しなかった理由かもしれない。
いずれにせよ、これはまだ利用されているかどうかに関係なく、抜け道だ。
俺は調査するつもりはないが、確かに2005年頃にSuseのソースからビルドする際にこの問題があった。
俺は1998年から2005年の間にほとんどのプロフェッショナルなRPM作業を行った。ほとんどがRed Hatベースのパッケージングで、2000年の終わりに短期間非常に高額な報酬でSUSEのパッケージを作ったことがある。その時は問題がなかった。
今のOpenSUSEのソースRPMリポジトリを見てみると、必要なものはすべてsrc.rpmsの形で存在している。再ビルドは非常に簡単だが、実際には対処しなければならない特異性がある。
GPL2+は、最初からビルドスクリプトを利用可能にすることを要求している。
でも、君が言っているように、いくつかの明らかな抜け道がある。一つはビルド環境やビルドルートに何が含まれているかの文書化であり、もう一つはビルド順序だ。プロフェッショナルな作業をしていた頃、Red Hatはかなり改造された古いRed Hat Linuxディストリビューションを使ってビルドを行っていたし、特定のRPMバイナリのビルドルートの内容は文書化されていなかったし、RHELでは非常に秘密にされていた。ビルド順序は.src.rpmのビルドタイムスタンプから推測できたが、並行ビルドではそれが難しくなる。ビルド順序は実際には「ビルドルートに何があるか」の裏返しであり、もし君のパッケージがfooパッケージの特定のバージョンに依存していて、bazバージョンがビルドルートにあると、正しくビルドされないかもしれない。
俺は、特定のライブラリパッケージが一つのパッケージセットのためにダウングレードされ、他のすべてのパッケージのためにアップグレードされなければならないという状況に直面したことがある。これについては詳しくは言わないが、非常に古いパッケージングで、完全にサポートされていないアーキテクチャの長期的なEoLディストリビューションのものだ。
今では「君のビルドルートに何があるか」はFedoraではかなり公開されているが、RHELではあまりそうではない。両者は現在、各パッケージがビルドされる際に動的にビルドルートを構築する自動化ツールを使用して、gitソースリポジトリからビルドされている。ビルドルートマニフェストがここで重要であり、これはRPM specファイルには完全な形で含まれていない。ビルド依存関係のリストは存在するが、それはビルド環境の全体像を描くものではない。
俺は今のSUSEについて調査するつもりはない。なぜなら、俺はSUSEを運営していないし、RPMパッケージングももうやっていないからだ。個人的にもプロフェッショナルにもDebianに移行している。Debianのパッケージングは、俺の限られた経験の中では、はるかに透明で再現可能だ。
彼らは確かに自分たちのサーバーに接続してファイルをダウンロードすることをブロックする権利があるが、彼らのリポジトリからすでに取得されたものの再配布を禁止しているように聞こえる。
しかし、彼らのリポジトリが彼ら自身が著作権を持たないコンテンツをホスティングしている場合、彼らはそのコンテンツが彼らのサーバーを通過したという理由だけで、そのコンテンツの再配布に追加の条件を課す権限があるのだろうか？
例えば、本屋が顧客に、そこで購入した本を第三者に再販することを禁止できるのか？それが著作権で禁止されていない場合でも。
俺は弁護士じゃないが、これは非常に疑わしい。
本屋が顧客に、そこで購入した本を第三者に再販することを禁止できるのか？
それは全くそうではない。本屋は本を印刷（コンパイル）したり、無料で配布したりするわけではない。
むしろ、フードバンクからの再贈呈のようなものだ。
_________________________________________________
これは、ディストリビューションが自分たちのサーバーをミラーリングしてホストすることを言っているだけだ。基本的に、他のディストリビューションのために俺たちのサーバーやネットワークリソースを使うなってことだ。
それはちょっと違うと思う。彼らの言葉（強調は俺の）：
このポリシーでは「再配布」を、 CachyOSリポジトリ（およびそのミラー）を含む行為、またはCachyOSリポジトリから取得したパッケージをオペレーティングシステムまたはシスルートの配布イメージの一部として含める行為と定義します。
だから、俺が彼らのリポジトリを完全にコピーしようとする場合だけでなく、そこから取得した単一のパッケージを配布することさえもカバーされている。
君は非常に重要な部分を見逃しているようだ。
「エンドユーザーとサードパーティのミラーは再配布ポリシーの対象外です。」
これはさらに複雑にするね。
もし彼らが他のディストリビューションが彼らのリポジトリにホットリンクするのを防ごうとしているだけなら、それは彼らのサーバーの利用規約を確立することに過ぎず、コンテンツの再配布には関係ない。
「再配布ポリシー」と呼び、その言葉を使って、サーバーを通過したすべてのファイルに適用されるように見せかけ、特定のユーザークラスをポリシーから除外するのは、一貫性のない混乱だ。
_________________________________________________
もしパッケージに商標アイテムが含まれているなら、それは意味があるかもしれない。商標と著作権法は互いに関連しておらず、著作権ライセンスの制限は商標をカバーしない。
そして、もし彼らが著作権を持つコードだけのパッケージについて話しているなら、彼らは好きなことをすることができる。たとえそれがGPLであっても、何であっても。ライセンスは君を制限するものであり、彼らを制限するものではない。もし他の人の著作権と混ざっていなければ。
俺は弁護士じゃないし、ディストリビューションにはたくさんの異なる著作権ライセンスがあるから、包括的な答えを出すのは不可能だ。
でも、彼らがバイナリのそばにソースコードを提供している限り、GPLの法律の文言には合致しているだろう。
ソースコードが本当に重要な部分だ。
確かに、通常、CachyOSが解決しようとしている問題は商標/著作権法で扱われている。
オープンソースライセンスでは、「ソースとバイナリを自由に使えるが、どちらかを変更した場合は、その結果をCachyOSと呼ぶことはできない」と言う方がはるかに簡単で問題が少ない。
もしパッケージに商標アイテムが含まれているなら、それは意味があるかもしれない。
彼らは商標の所有権に基づいてそれらのパッケージの再配布を禁止することができるが、彼らのサーバーにホストされているものの再配布を禁止する権利を主張しているように聞こえる。
「我々が関連する商標や著作権を持つコンテンツを含むパッケージは、我々のサーバーから直接配布されるべきであり、サードパーティによって再配布されるべきではない」と言うのは意味がある。
「我々のサーバーにホストされたことのあるものをすべて再配布することは禁止されている」というのは意味がない。
_________________________________________________
見て、もし君がCachyOSに基づく自分のディストロを作りたいなら、自分のサーバーを持って、自分のリポジトリを作れ。Cachyチームが支払っているサーバーの配布コストをオフロードするのはやめろ。
はい、それが全く期待されることだと思う。人間の良識といったところだ。それを言う理由があるとしても、そうしたポリシーがアップストリームライセンスを破っているかどうかという質問には関係ない。
俺はかなりのソフトウェアを書く人間で、そのほとんどが自由でオープンソースとしてリリースされているが、俺のソースに適用したライセンスに従わないディストリビューションに自分のものがパッケージ化されているのを見つけるのは非常にイライラする。
_________________________________________________
いいえ、これはライセンス違反ではない。このことは異常でもなく、GPLの条件を破っているわけでもない。
_________________________________________________
エンドユーザーとサードパーティのミラーは再配布ポリシーの対象外だ。彼らは他のディストリビューションのために自分たちのサーバーからコンテンツを提供したくないが、自分たちのサーバーを運営している限り、誰もがコンテンツを再配布するのを妨げてはいない。
_________________________________________________
これはレッドハットがやっていることに似ている。彼らがリポジトリへのアクセスを持っている人々にソースを提供する限り、問題はない。
_________________________________________________
Clearify users and redistribution by SchrodingerZhu · Pull Request #83 · CachyOS/wiki
This patch addresses some concerns by third-party mirrors: we explicitly waive the liability and warranty of the repository change the policy to forbid redistribution of the repo in other os distr...
これらの「サードパーティミラーによる懸念」が何なのかは不明だ。
_________________________________________________
GPLv3の前文にはこう書かれている：
自由ソフトウェアについて話すとき、私たちは価格ではなく自由を指しています。私たちの一般公衆ライセンスは、あなたが自由ソフトウェアのコピーを配布する自由を持っていることを保証するために設計されています（望むなら料金を請求することもできます）、あなたがソースコードを受け取るか、望むならそれを入手できること、あなたがソフトウェアを変更することや新しい自由なプログラムにその一部を使用することができること、そしてあなたがこれらのことができることを知っていることを保証します。
あなたの権利を守るために、他の誰かがあなたの権利を否定したり、あなたに権利を放棄させたりすることを防ぐ必要があります。したがって、あなたがソフトウェアのコピーを配布する場合やそれを変更する場合、他の人の自由を尊重する責任があります。
たとえば、そのようなプログラムのコピーを配布する場合、無償であれ料金を取るにせよ、受取人にあなたが受け取ったのと同じ自由を渡さなければなりません。 あなたは、彼らもまたソースコードを受け取るか、入手できることを確認しなければなりません。そして、彼らにこれらの条件を示して、彼らの権利を知ってもらわなければなりません。
彼らが再配布を法的に防ぐことができるとは思えないが、彼らが「6. 非ソース形式の伝達」を遵守し続ける限り、サーバーへのアクセスを制御することはできる。
_________________________________________________
彼らがソースコードをバイナリと同じように簡単にアクセスできるように提供する限り、GPLを破っているわけではない。基本的に、誰かがバイナリにアクセスできるなら、彼らはソースコードにもアクセスできなければならず、そのソフトウェアを変更、コンパイル、再配布する権利を持っている。
理論的には、GPLソフトウェアの一部を変更して、その変更を他の誰かに販売することができる。しかし、実際には、その人に変更を含むソースコードを提供し、その人がそのソフトウェアを変更し、再配布する権利を持たせなければならない。だから、実際には長期的に実行可能な戦略ではなく、GPLを妨げるための追加のライセンスはGPLの違反になる。
_________________________________________________
免責事項：この特定の法律用語を学んでからしばらく経つので、間違っているかもしれない。
彼らが禁止しているのは再配布であり、つまり君はCachyパッケージを配布するために自分のサーバーを立てることができない。言い換えれば、彼らはパッケージの配布に関して自分たちのサーバーを唯一の真実のソースにしたいということだ。俺の知識の限りでは、GPLはそれを妨げていない。そうでなければ、どの部分がGPLに違反しているのか指摘できるか？
パッケージはソースの派生物であり、バイナリを含むため、GPLはパッケージにも適用される。彼らは、すでに手に入れた場合、彼らから取得したパッケージを好きなように配布できないと言っている。彼らはGPLの上に新しい条項を追加し、配布を制限しようとしている。GPLが違反されている。
これが俺の投稿に至った論理的過程だ。
FSFの解釈は、根本的な文言に直接関連している：
彼らのインフラがGPLに従うべきだと主張しているわけではない限り、GPLを違反していない。これは彼らのインフラへのアクセスに関することであり、他のディストリビューションは直接彼らのリポジトリからパッケージを取得すべきではない。その理由は、これらのことにはお金がかかり、彼らは「サービス」の一部であり、「パッケージ」には含まれないからだ。さらに、これは特にエンドユーザーやミラーには適用されないと言っている。
逆に見ても、君のリンクは、彼らがオブジェクトコードに対して料金を請求することさえ許可されていることを示している。それを確実にする唯一の方法は、すべてを有料にするか、パッケージごとのダウンロード料金を設定することであり、結果は同じ状況になる。これはGPLによって許可されており、君のリンクもそれを明確にしている。君は作業するための正確なソースを持っているので、GPLは満たされている。
君は何もないところから何かを作り出そうとしているように見える。おそらく、君はそのソースをビルドするコストを負担したくないからだが、それは見苦しい。
OPが提供した引用は、彼らのサーバーからすでに取得されたパッケージを下流のOSイメージに含めることを禁止しようとしている。これは、他のディストリビューションが彼らのリポジトリからホットリンクすることを防ごうとしているという理論に矛盾している。
彼らは、すでに手に入れたパッケージを好きなように配布できないと言っている。
いいえ：
_________________________________________________
なんかおかしい。
確かにおかしい。俺は他のディストリビューションがどのようにポリシーを表現しているか（もしあれば）を見るのが興味深いが、このポリシーは俺には本当に正しく感じられない。
_________________________________________________
リポジトリが何であるかを見て、光を当ててみよう。
リポジトリは単なるパッケージのコレクション以上のものだ。リポジトリは通常、実際に構築されたパッケージに加え、このパッケージのコレクションがどのように組み合わさっているかに関するメタデータのセットを含む。また、通常はこれらのパッケージやメタデータの暗号署名も含まれる。このメタデータや署名が著作権で保護されているかどうかが問題だ。メタデータは、パッケージのコレクションから再構築できることがあるため、かなり混乱を招く。なぜなら、今や構築されたパッケージのコレクションには配布されたメタデータが含まれているからだ。これらのメタデータは、元の作品として著作権の対象になるのか、派生物として著作権の対象になるのか？しかし、署名キーの所有が必要であり、署名キーは著作権で保護されている可能性がある（署名キーは、通常はプログラム的に行われるが、創造的な行為として手動で構成されることもある）。
人々は自分の意見を延々と述べることができるが、法的な問題が管轄権のある裁判所でテストされるまで、実際には何も重要ではない。
俺の意見としては、バイナリパッケージの配布制限は一般的であり、20年以上行われてきた。Red Hat Enterprise Linuxがその代表例だ。Red Hatは、GPLの権利を行使してソースRPMを再配布すると、今後のRPMのアップデートへのアクセスを失う可能性があると言っている。これも裁判でテストされたことはない。誰も訴訟を起こしていないからだ。
_________________________________________________
他のArchベースのディストリビューションに対して、より悪質なライセンスと設計がされている可能性がある。
明らかに、他のディストリビューションがそれをパッケージ化できれば、バグがCachyOSにリダイレクトされることになる（彼らがそれをトラブルシュートすることはないだろうが）、しかし実際の理由は、CachyOSにプロジェクトが成長する理由がないからだ（スポンサーシップやエゴのためかもしれない）。
悲しいことに、これは良いディストリビューションだ。特に最新のZen CPUを使用して最新の最適化を行う場合は。
悲しいことに、これは良いディストリビューションだ。特に最新のZen CPUを使用して最新の最適化を行う場合は。
そうだ。IntelがClear Linuxのサポートを終了した後、俺がこれを試してみた理由だ。しかし、ベンダーロックインの欠如がLinuxを使う理由そのもので、俺は自分をMicrosoftのような動きをするプロジェクトに興味を持たせない。
笑、誰かが君のポイントに賛成するまで待ってたってことか？他の誰もが君が間違っていると指摘しているのに、エコーチャンバーは強いね。
タイムスタンプをチェックして。これは文字通り最初に投稿されたコメントの一つで、俺はその後、同意しないコメントにもたくさん返信してる。
君のポイントが理解できない。
_________________________________________________
彼らは本当に、インストーラーにZFSを含める方法で誰かを非難できるのか？Ubuntu版のMintがそれを行い、GNUとCDDLを混ぜることについてリーナスと多くの激しい議論をした。俺の意見では、インストーラーにZFSを含めることはGNUとCDDLの著作権を侵害している。だから、彼らはそれを正さない限り、文句を言う余地はない。
彼らは本当に、インストーラーにZFSを含める方法で誰かを非難できるのか？
（動的）リンクが派生物を構成するかどうかは、最終的には未解決の問題であり、これはおそらく変わらないだろう。FSFでさえ、この問題についての判決を得ることに興味を持っていない。
また、ここで細かいことを言うと、インストーラーに含めることは、どの解釈を支持してもほとんど関係がない。潜在的に違反する行為は、カーネルモジュールバイナリを配布することだ（ほとんどのディストリビューションは、これをDKMSパッケージとして配布することで回避しているが、CachyOSは実際のバイナリを配布しているようだ）。
_________________________________________________
こんなに退屈だなんて想像してみて。
_________________________________________________
もしこれが嫌なら、Red HatやFedoraなども嫌いだろう。
この言葉が言っているのは、Manjaroや他のディストリビューションがCachyOSをベースにすることができず、ユーザーにCachyOSの設定を有効にするように指示できないということだ。ディストリビューションがCachyOSパッケージを使うことを望んでいない。
エンドユーザーはそうすることができる。なぜなら、彼らはLinuxディストリビューションによって促されていないから。彼らは自分の意思でそうした。
それは、君が無料のサービスを提供し、誰かがそれを取り、彼のバージョンのサービスでハックして、何かが壊れたときに君にサポートを提供することを期待するようなものだ。
車の例で言えば、君は俺たちの車を取り、それを改造し、君のエラーによって壊れたときに保証の下で俺たちが修理することを期待する。
ソースコードはまだ利用可能で、君は自分でビルドすることができる。
実際、Fedora Remixを作って、Fedoraリポジトリを指すことは完全に合法だ。
RHELは別の話だが、Fedoraに関しては、これは完全に問題ない。