GPLは目標を達成する上でどれほど成功していますか？[閉まっている]

コードの商用利用に関連する場合、広く2つのタイプのFOSSライセンスがあります。たとえば、GPLタイプとBSDタイプです。1つ目は、ライセンスの下でのコードの商業的使用（使用法によっては、修正や再配布、派生作品の作成なども含む）を広く制限し、2つ目ははるかに寛容です。

私が理解しているように、GPLタイプのライセンスの背後にある考え方は、人々にプロプライエタリなソフトウェアモデルを放棄し、代わりにFOSSコードに変換することを奨励することです。 、ただし、あなたが私たちのキャンプに来て、私たちの規則に従ってプレーすることに同意する場合にのみ」。

私が尋ねたいのは、これまでのところこの戦略は成功したのでしょうか？すなわち、GPLまたはGPLがそうしたからといってオープンで開発されているソフトウェアのために、クローズドからオープンに移行する大きなプロジェクトという形で大きな成果はありますか？この戦略の影響はどれほど大きいでしょうか？たとえば、誰もがBSDタイプのライセンスを持っているか、パブリックドメインの下ですべてのオープンソースコードをリリースする世界と比較して？

FOSSモデルが成功したかどうかを尋ねているのではないことに注意してください-これは疑いの余地がありません。私が尋ねているのは、GPLタイプで使用され、BSDタイプのライセンスで使用されていないプロプライエタリからFOSSに人々を変換する特定の方法が成功したかどうかです。また、ライセンスとしてのGPL自体のメリットについても、その有効性の事実については尋ねません。

まず、質問には固有の主観があります-確実に知る方法はなく、歴史はどちらの方法でも解釈できます。これは古い議論であり、オープンソースとフリーソフトウェアの議論の中心的な問題の1つです。また、目標を達成することで、意味を定義する必要があります。GPLとFSFがオープンソースを過去2〜30年の重要な動きに貢献していないと主張するのは困難です。ただし、すべてのコードがフリーソフトウェアであるという目標には達していません。

GPLソフトウェアのパラゴンはもちろんlinuxであり、FSFからのすべてのもの（gccなど）です。興味深いことに、Linuxの場合、GPLはその政治的スタンスのために選択されませんでしたが、Linus Torvaldが何度か述べたように、相互主義のアイデアのためです。私にコードを提供しますが、私のコードを使用する場合は、引き換えにコードを提供する必要があります。

Linux自体に関して言えば、GPLは非常に価値があると思います。最近の例は、Oracle内で開発された新しいfsであるBTRFSです。BTRFSの主な執筆者は、OracleがGPLを最初に使用することに同意した唯一の理由は、GPLに選択肢がないことだと述べています。大きな問題は、Linux自体がGPLのために成功したのか、それともGPLにかかわらず成功したのかということです。Linusの信じられないほどのリーダーシップ、当時の* BSDプロジェクトの著作権の問題などのさまざまな要因により、仮説を証明/反証することができなくなりました。

gccの場合、ストールマンは GPLがプロジェクトを「プロプライエタリゼーション」に対して保存した理由を何度か書いています。

BSD、MIT、Apacheなどの非制限的なライセンスは、GPLよりもはるかに多くのことをFOSSの推進に役立てていると思います。

例：

• 城プロジェクト、
• jQuery、
• SQLite、
• Apache、
• HibernateおよびnHibernate、
• ASP.NET MVC、
• JSON.ORG、

その他多数。

ほとんどの企業は、GPLを警戒しすぎて、GPL /付加価値サービスモデルで実際に機能している場合を除き、GPLコードを開発作業の近くで使用することはできません。

GNU GPLは、そのためではなく、FLOSSの施行にもかかわらず成功しています。企業の大部分は、GPLの下で自発的にコードに貢献し、リリースしています。それによってカバーされる重要なアルゴリズムとライブラリはありません。それは商用開発者に所有権を剥奪することを強いるでしょう。

Appleは良い例です。彼らはKHTMLを採用し、WebKitに追加しました。そして彼らはコードをオープンソースコミュニティにリリースしました。これはLGPLによって強制されたためと思われますが、ありそうにないようです。DarwinとBSDユーザーランドの場合、彼らは非常に自発的にコードを公開しています。また、LLVMを使用して、新しいFLOSSプロジェクトを開始しました。しかし、明らかにAppleは依然として独占的なソフトウェアベンダーのままです。

Androidも同様です。もちろん、ここではハードウェアサポートが重要な役割を果たしますが、GoogleはBSDコードベースを採用して独自のコードベースを採用することもできました。しかし、彼らはLinuxを選びました。したがって、彼らは喜んで貢献しますが、それは非GPLの代替がなかったからではありません。

Openofficeは、ある時点では実際にプロプライエタリだったため、より興味深い話です。ただし、LGPL変換は任意であり、必要ではありません。ただし、この場合、* GPLタイプのライセンスにより可能になりました。SunがOpenofficeをリリースするには、アカデミックなBSDタイプのライセンスでは十分ではありませんでした。この点で、GNU * GPLは成功しています。

相互/バイラル条項は、オープンソースコードの増加に直接つながりません。しかし、ソフトウェアベンダーは、必要に応じてそれを有利に使用しているため、FLOSSプールに貢献しています。しかし、ほとんどのベンダーはそれを無断で行っています。より多くのコードの貢献を奨励することに関して、BSDスタイルのライセンスとGPLスタイルのライセンスの違いはほとんどありません。
結論として、GNU GPLは成功しましたが、BSD / MITスタイルのライセンスも推進しました。しかし、「コードの量」の成功を単純に測定することもできます。これは、実際のFSFメトリックです。

GNU Manifestoを見ると、企業にFOSSソフトウェアをリリースするよう説得することが目標の1つであったかどうかは明らかではありません。引用は次のとおりです。

不名誉なくコンピューターを使い続けることができるように、フリーではないソフトウェアがなくてもうまくいくことができるように、十分な数のフリーソフトウェアをまとめることにしました。

その目標を見れば、GNUプロジェクトはほぼ成功しています。GPL OS、オフィススイート、データベース、および自由に変更および再配布できるその他の多くのアプリケーションがあります。

FOSSの世界にとって、両方（GPLとBSDタイプのライセンス）の両方が重要だと思います。GPLの使用は2つのグループに分かれています。1つは、非常に熱心なオープンソースサポーターのグループです。彼らは、オープンソースを再びプロプライエタリな作品に変える可能性がOSS世界に損害を与えると信じています。個人的には、それは大きな問題ではないと思います。PC-BSD（独自のBSDバリアント）は、BSDコミュニティに損害を与えません。GPLを採用する2番目のグループは大企業です。彼らはライセンスを使用して、製品をより細かく制御し続けます（たとえば、ビジネスモデルをサポートします）。競争には、他の誰かがGPLライセンスを取得したソフトウェア製品でお金を稼ぐための問題があります。そのため、同社は製品のオープンソース化で優れたカルマを獲得しながら、競合他社の先を行くことができます。

私の個人的な見方は個人の開発者の一人であり、障害のためにしばらく雇用されておらず、私が持っている唯一の貴重なスキルから再び生計を立てることができることを望んでいます。

GPLは常に商業プロジェクトに使用されています。問題は、「ウイルス」性と呼ばれることもあります。つまり、プロジェクトでGPLコードを使用する場合は、おそらくそのプロジェクトのすべてのコードをGPLする必要があります。動的リンクの除外を主張する人もいます。GPL FAQは、共有データ構造のためにプラグインへの動的リンクが禁止されていると主張しています-http ://www.gnu.org/licenses/gpl-faq.html#GPLAndPlugins。これは、すべてのWindowsアプリケーションがWindowsコンポーネントに動的にリンクし、データ構造をWindowsと共有しているため（アプリケーションは多くの点でオペレーティングシステムプラグインです）、奇妙に思えますが、GNUによってリリースされたGPL Windowsアプリもあります。おそらく、これは、ポインターをハンドルとして偽装し、関数を介してほとんどのアクセスを行うことは、データ構造の共有としてカウントされないことを意味します。これは、特別に設計されたプラグインAPIまたは動的にリンクされたライブラリがおそらく悪用する可能性のある抜け穴ですが、明らかに個々の開発者は安全にプレイする必要がありますそのような問題について。

とにかく、GPLの「バイラル」な性質には十分な理由がありますが、生計を立てる必要がある必死の小さな開発者にとって、これはあなたの仕事を無料で提供するようなものです。サポートに課金したり、マニュアルを効果的に販売したりして、すべての人がお金を稼ぐことはできません。また、製品に不十分な無料のマニュアルがある場合、実際のマニュアルはおそらくStack OverflowまたはSuperuserなど、有料のマニュアルではありません。そして、それはだれでもそれを理解することを気にすることを前提としています。

その観点から、BSDスタイルのライセンスは非常に魅力的です。私は、他のオープンソースの作業を悪用しながら、結果の製品を閉じたままにすることは偽善的だと認めますが、それは他の問題とのバランスを取る必要があります。

OTOH、私は実際に何も公開していませんし、公開していません-少なくとも10年前に基本的にパブリックドメインを作ったプラグインの束以来）。少なくとも今のところ、私にとってはすべてがアカデミックです。

それでも、GPLスタイルのライセンスを持つライブラリを見るたびに、最初に考えたことは「これに依存するようになったらオプションを制限する」ことです。

人々がGPLについて考えるとき、彼らはソフトウェアが自由に考えられるべきであるgnuの理想で考え、それでアイデアが生まれ、そして大企業はそれを許さないので悪者だと思うと思います。問題は、彼らが自分でコードを書きたいだけでなく、プログラムを持っているだけでなく、人生を所有しているため、多くのプログラマーを買うという考え方ではないということです。同じ意味で、Linusは開発者にとってRichard Stallmanよりも人気があります。なぜなら、最初の人は（私たちの多くのように）自分のことをやりたいだけで、もう1人は世界全体を変えようとするからです。そのため、最終的にGPLはミハイルゴルバチョフのようなものになります。ミハイルゴルバチョフは、進化を開始しますが、成功を収める運命にありません。