なんでこれがダウンボートされてるのか分からないけど、同意だわ。ソースからビルドするのもそんなに難しくないしね（sqliteを見てみて）。

実際のソフトウェアライセンスによるけど、多くの商業ベンダーはソースコードを提供してるよ。ただ、そのライセンスではコードを好き勝手に使うことはできないんだ。技術的には可能でもね。商業製品では、スクリプト言語が使われることが多いから、そういうことがよくあるんだよね。例えば、エンタープライズコンサルティングでは、コードがプロジェクトの一部として提供されるけど、コンパイルのためにはエージェンシーに縛られることが多い。顧客がその権利のために追加料金を払わない限りね。

これが私がGuixを好きな理由の一つなんだ: そのパッケージシステムは、ソースビルドを通常のケースとして扱っていて、バイナリパッケージはキャッシュを通じて利用可能なんだ。だから、パッケージをインストールしようとしてキャッシュされたバイナリがない場合、Guixはその場で喜んでビルドしてくれるよ。ビット単位で再現性があれば、なおさらね。事前にビルドされたパッケージの利点は得られるけど、常に逃げ道があるんだ。これにより、他のすべてのパッケージマネージャーと同じように、パッチを当てたバージョンのパッケージを簡単にインストールできる。専用のビルドインフラは必要ない（もちろん、大規模なフリートにデプロイする場合は、ほとんどのマシンで再ビルドの必要を避けるためにビルドサーバーを設定した方がいいかもしれないけど）。

許可的なライセンスを使うなら、ラグプルはその一部だよ。確かに。でも、CLAは必ずしもすべての権利を放棄するわけじゃないよ。

オープンソースに関しては、ラグプルなんて存在しないよ。GPLのコピーは永遠に残るからね。

私の理解では、CLAにサインすると、通常はCLAの受益者に再ライセンスする権利を与えることになる。これを明確にするために言うと、これはサインするCLAの内容による。例えば、CanonicalのCLA（CCLA）には、セクション2.3のアウトバウンドライセンスにこの条項がある。> 私たちは、コピーレフト、許可、商業的、または独自のライセンスを含む、いかなるライセンスの下でも貢献をライセンスすることができます。この権利を行使する条件として、私たちは提出日現在で使用している素材のライセンスの条件の下でも貢献をライセンスすることに同意します。つまり、彼らはあなたの貢献を元のライセンスの下でリリースすることを約束しているということ。言い換えれば、古い貢献を遡って再ライセンスしないってことだね。他のCLAではこの約束がない場合もあるから、何にサインしているのかを理解するのは一般的に良いアイデアだよ。（これはCLAだけでなく、すべての契約に当てはまるからね。）ほとんどのCLAは、貢献者が著作権を保持できるようにしている。（私の理解が正しければ、著作権の移転はCAAにのみ関係している。）だから、あなたが貢献に対して好きなようにできるオプションもあるよ。いずれにせよ、実際の問題は、プロジェクトのオーナーに対する暗黙の信頼を裏切られることだよ。あなたが彼らや他の人たちに自分の作品を寛大に提供したから、将来他の人たちの貢献に対しても同じように返してもらえると思うよね。でもCLAはそれをオープンにして、プロジェクトのオーナーの単独の管理下に置くから、ラグプルの危険があるんだ。ラグプルの後にその貢献の恩恵を受ける唯一の方法は、他の貢献者と直接協力することだね。要するにフォークすることだ。> ラグプルを避けたいなら、コピーレフトライセンスを使ってCLAにはサインしない方がいいよ。これら二つの奇妙で特にひどい組み合わせがある - AGPL + CLA。私は一般的にAGPLの支持者だけど、この組み合わせは許可ライセンス + CLAよりも悪いと思う。コピーレフトライセンスは、アプリケーションを配布した相手に対して、ソースコード（カスタム修正を含む）を要求されたら提供する必要があるんだ。AGPLでは、オンラインサービスの使用も「アプリケーションの配布」の定義に含まれるから、あなたのサービスを使う誰にでもサーバーサイドコードの修正を配布しなきゃいけない。これは良いことだと思う - なぜなら、リソースが豊富な他の誰かがあなたのサービスを改善してホストして、あなたがその改善の恩恵を受けられないってことがないからね。でもCLAがあると、プロジェクトのオーナー（おそらく会社）が未公開の改善を加えた再ライセンス版をホストできる一方で、あなたは同じことをしようとすると自分の改善を公開しなきゃいけない（AGPLのコードを使っているから）。許可ライセンス + CLAの下では同じ問題は起こらないけど、ここで特にひどいことが起こる。上記の問題は、許可ライセンスだけでCLAがないソフトウェアにも影響を及ぼす可能性がある。これがIncusとLXDに起こったことだ。LXDは当初Apacheライセンスの下で、Canonicalと協力してLinuxコンテナコミュニティのもとにあった。ある朝、Canonicalがプロジェクトの管理を決定し、LinuxコンテナコミュニティがそれをフォークしてIncusを作ることになった。その後しばらくの間、両プロジェクトは同じライセンスの下でお互いからコードを借りていた。でもその後、CanonicalがLXDをAGPLv3 + CLAの下で再ライセンスすることに決めた。これにより、ライセンスの不整合のためにIncusがLXDからコードを借りることができなくなり、Canonicalは少し変わった取り決めの下でそれを続けた。詳しくはここで読めるよ: [2] [1] https://canonical.com/legal/contributors/agreement?type=indi... [2] https://stgraber.org/2023/12/12/lxd-now-re-licensed-and-unde...

一般的にラグプルの対象になる このオープンソースの純粋主義は有害だよ。プロジェクトは持続可能でなきゃいけない。ハイパースケーラーたちはインターネット全体を吸い上げて、モバイルデバイスのカテゴリを完全に支配してる。私たちはここで小さな開発者がソースが利用可能なOSSやCLA付きのOSSについて言い争ってる。コミュニティがそんなに気にするなら、最後のオープンバージョンを取って自分たちでメンテナンスすればいいじゃん。このネガティブなエネルギーを全部持っていって、大手テック企業の分裂のために戦ってほしい。

でもGNUはどうなの？彼らのプロジェクトはCLAにサインする必要があるし、ラグプルはしないと思うけど。