GPLはその目標を達成するのにどの程度成功していますか？
コードの商用利用に関連するFOSSライセンスには、大きく分けて2つのタイプがあります。たとえば、GPLタイプとBSDタイプです。 1つ目は、ライセンスの下でのコードの商用利用（変更とは再頒布、派生作品の作成なども意味します）について広く制限されており、2つ目はより寛容です。
私が理解しているように、GPLタイプのライセンスの背後にある考え方は、独自のソフトウェアモデルを放棄し、代わりにFOSSコードに変換することを人々に奨励することであり、ライセンスはそうするように彼らを誘惑する手段です。 、ただし、あなたが私たちのキャンプに来て私たちのルールに従って遊ぶことに同意した場合のみ」.
私が聞きたいのは-これまでのところこの戦略は成功したのか？つまりGPLのためにクローズドからオープンに移行する大きなプロジェクトの形で大きな成果はありますか、またはGPLがそうしたためにオープンソースで開発されているいくつかのソフトウェアはありますか？この戦略の影響はどのくらいですか。たとえば、誰もがBSDタイプのライセンスを持っているか、すべてのオープンソースコードをパブリックドメインでリリースする世界と比べて、どうですか。
FOSSモデルが成功したかどうかは尋ねていません。これは問題外です。私が求めているのは、GPLタイプで使用され、BSDタイプのライセンスでは使用されないプロプライエタリからFOSSに変換するように人々を誘導する特定の方法が成功したかどうかです。また、ライセンスとしてのGPL自体のメリットについては質問しません。その有効性の事実についてです。
まず、質問には固有の主観性があります。確実に知る方法はなく、歴史はどちらの方法でも解釈できます。これは古い議論であり、オープンソースとフリーソフトウェアの議論における中心的な問題の1つです。また、その目標を達成することによって、あなたが何を意味するかを定義する必要があります。 GPLとFSFがオープンソースを過去20〜30年間の大きな動きに貢献していないことを主張することは困難です。ただし、すべてのコードをフリーソフトウェアにするという目標には達していません。
GPLソフトウェアの典型は、もちろんLinuxであり、FSFからのすべて（gccなど）です。興味深いことに、Linuxの場合、GPLはその政治的立場から選ばれませんでしたが、Linus Torvaldが何度か述べたように、互恵性の考え方のためです。私はあなたに私のコードを渡しますが、私のものを使用する場合はあなたと引き換えにあなたに私を与えなければなりません。
Linux自体に関しては、GPLは非常に価値があると思います。最近の例は、Oracleの内部で開発された新しいfsであるBTRFSです。 BTRFSのメインライターは、オラクルが最初に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に基づくコードに自発的に貢献し、コードをリリースしています。対象となる重要なアルゴリズムとライブラリはありません。それは商業開発者に非所有化を強いるでしょう。
アップルは良い例です。彼らはKHTMLを採用し、それをWebKitへと進めました。そして彼らはオープンソースコミュニティにコードをリリースしました。これはLGPLによって強制されたためと考えられますが、そうではないようです。ダーウィンとBSDユーザーランドの場合、彼らは非常に自発的にコードを公開しています。そして、LLVMを使用して、まったく新しいFLOSSプロジェクトを開始しました。しかし、明らかにAppleは、主に専有ソフトウェアベンダーのままです。
Androidも同様です。もちろん、ここではハードウェアサポートが重要な役割を果たしますが、GoogleがBSDコードベースを採用して独自仕様にすることもできました。しかし、彼らはLinuxを選びました。したがって、GPL以外の代替手段がなかったためではなく、喜んで貢献してくれました。
Openofficeは、ある時点で実際に独占的であったため、より興味深い話です。しかし、繰り返しになりますが、LGPLの変換は任意であり、必要ではありませんでした。ただし、* GPLタイプのライセンスにより、この場合が可能になりました。学術的なBSDタイプのライセンスでは、SunがOpenofficeをリリースするのに十分ではなかったでしょう。この点で、GNU * GPLは成功しています。
相互/ウイルス条項は、より多くのオープンソースコードに直接つながるわけではありません。しかし、ソフトウェアベンダーは、必要に応じてアドバンテージを利用して、FLOSSプールに貢献しています。しかし、ほとんどのベンダーはそれを無礼なやり方で行っています。より多くのコードの貢献を奨励することに関して、BSDスタイルのライセンスとGPLスタイルのライセンスの違いはほとんどないようです。
結論として、GNU GPLは成功していますが、BSD/MITスタイルのライセンスの方が適切な場合はそれも推進しています。しかし、「量「コードの」、これは実際のFSFメトリックと考えています。
The GNU Manifesto を見ると、企業がFOSSソフトウェアをリリースするよう説得することが目標の1つであったことは明らかではありません。ここに引用があります：
私は不名誉なしにコンピュータを使い続けることができるように、私は自由でないソフトウェアなしでうまくいくことができるように自由ソフトウェアの十分なボディをまとめることに決めました。
その目標を見れば、GNUプロジェクトは大部分が成功しました。GPLOS、オフィススイート、データベース、および自由に変更および再配布できる他の多くのアプリケーションがあります。
両方（GPLとBSDタイプのライセンス）はどちらもFOSSの世界にとって重要だと思います。 GPLの使用は2つのグループに分かれています。 1つは、非常に熱心なオープンソースサポーターのグループです。彼らは、オープンソースを再びプロプライエタリな仕事に変える可能性は、OSSの世界に損害を与えると信じています。個人的には、それは大きな問題ではありません。 PC-BSD（独自のBSDバリアント）は、BSDコミュニティに影響を与えません。 GPLを採用する2番目のグループは大企業です。ライセンスを使用して、製品をより詳細に制御できます（たとえば、ビジネスモデルをサポートするため）。競争には問題があり、他の誰かとGPLライセンスのソフトウェア製品でお金を稼ぐことになります。そのため、同社はその製品をオープンソース化することで良いカルマを得ながら、競争をリードすることができます。
私の個人的な見方は、障害のためにしばらくの間雇われていない個人の開発者の1つであり、私が持つ唯一の貴重なスキルから再び生計を立てられることを期待（または夢）しています。
GPLは常に商用プロジェクトで使用されています。問題は、その「バイラル」の性質と呼ばれることもあり、プロジェクトでGPLコードを使用する場合、おそらくGPLallそのプロジェクトのコード。動的リンクの除外を主張する人もいます。 GPL FAQは、データ構造が共有されているため、プラグインへの動的リンクが禁止されていると主張しています- http://www.gnu.org/licenses/gpl-faq.html#GPLAndPlugins 。これは、すべてのWindowsアプリケーションがWindowsコンポーネントに動的にリンクし、データ構造をWindowsと共有する（アプリケーションは多くの点でオペレーティングシステムプラグインである）ため、奇妙に見えますが、GNUによってリリースされた多くを含むGPL Windowsアプリがあります。これは、ポインターをハンドルとして偽装し、関数を介してほとんどのアクセスを行うことは、データ構造の共有としては数えられないことを意味します。そのような問題。
とにかく、GPLの「バイラル」の性質には十分な理由がありますが、生計を立てる必死の必要性を持つ小規模な開発者にとって、これは疑わしいことにあなたの仕事を無料で譲渡するように見えます。他の問題の中でも、私たち全員が関連するスキルを持っているわけではないので、サポートに請求したり、効果的なマニュアルを販売したりして、すべてを稼ぐことはできません。また、製品に無料のマニュアルがない場合、実際のマニュアルは、おそらく有料のマニュアルではなく、Stack OverflowやSuperuserなどになります。そして、それは誰もがそれを理解することを邪魔することを前提としています。
その観点から、BSDスタイルのライセンスは非常に魅力的です。他のオープンソース作業を利用しながら、結果として得られる製品を閉じたままにすることは偽善的だと認めますが、それは他の問題とのバランスを取る必要があります。
OTOH、私は実際に何もオープンまたはクローズしてリリースしたことはありません-少なくとも10年ほど前に基本的にパブリックドメインにしたプラグインの束以来（そして、余計な経験が私に教えたように、それらはあまりよく書かれていませんでした） ）。つまり、少なくとも今のところ、すべてが私にとって学術的です。
それでも、GPLスタイルのライセンスのライブラリを見るたびに、「これに依存するようになると、オプションを制限する」と最初に思いました。