GPL在实现其目标方面有多成功？[关闭]

当涉及到代码的商业使用时，有两种类型的FOSS许可证-假设是GPL型和BSD型。广义上，第一个是对许可下的代码的商业使用（即使用，我也指修改和再分配，以及创建派生的作品等）进行限制，第二个则更为宽松。

据我了解，GPL类型许可证背后的想法是鼓励人们放弃专有软件模型，而转而转换为FOSS代码，而许可证是诱使他们这样做的工具-即“您可以使用此出色的软件，但前提是您同意参加我们的训练营并按照我们的规定参加比赛”。

我想问的是-这项策略到目前为止是否成功？就是说，由于GPL，某个大型项目从封闭走向开放的过程中，是否有重大成就？或者仅仅因为GPL做到了，才公开开发某些软件？与每个人都拥有BSD类型许可证或在公共领域发布所有开源代码的世界相比，该策略的影响有多大？

请注意，我并不是在问FOSS模型是否成功-这是毫无疑问的。我要问的是，诱使人们从GPL类型的许可证而不是BSD类型的许可证使用的从专有方式转换为FOSS的特定方法是否成功。我也没有询问GPL本身作为许可证的优点-只是有关其有效性的事实。

首先，这个问题有一个固有的主观性-无法确定，历史可以用任何一种方式解释。这是一个古老的争论，也是争论开源与自由软件的核心问题之一。您还需要定义达到目标的含义。很难说GPL和FSF并没有使开源成为过去2-3年的重要运动。但是，它并没有达到所有代码都是自由软件的目标。

GPL软件的典范当然是linux，而一切都来自FSF（gcc等）。有趣的是，对于Linux而言，选择GPL并不是出于其政治立场，而是出于互惠的想法，正如Linus Torvald多次指出的那样。我给您我的代码，但是如果您使用我的代码，则必须给我您的代码。

就Linux本身而言，我认为GPL非常有价值-最近的一个例子是BTRFS，这是在Oracle内部开发的新fs。BTRFS的主要作者表示，Oracle首先同意使用GPL的唯一原因是因为它没有选择余地。更大的问题是，Linux本身是否由于GPL而获得成功。诸如Linus令人难以置信的领导能力，当时* BSD项目的版权问题等各种因素使得该假设无法得到证明/反证。

对于gcc，Stallman 已经写了好几次 GPL为何保存该项目以防止其“专有化”。

我要说的是，非限制性许可证（例如BSD，MIT和Apache许可证）在推广FOSS方面比GPL所做的要多得多。

例子：

• 城堡计划
• jQuery，
• SQLite，
• 阿帕奇
• 休眠和nHibernate，
• ASP.NET MVC，
• JSON.ORG，

还有很多其他

大多数企业对GPL过于警惕，不允许在其开发工作附近的任何地方使用GPL代码，除非企业本身实际上是在GPL /增值服务模型下工作的。

尽管执行了FLOSS，但GNU GPL还是成功的，并不是因为它。公司在很大程度上根据GPL自愿贡献和发布代码。它没有涵盖任何重要的算法和库，这将迫使商业开发人员进行专有权。

苹果公司就是一个很好的例子。他们采用了KHTML并将其扩展到WebKit中。然后，他们将代码发布回了开源社区。尽管可以认为这是由于LGPL强迫他们这样做，但似乎不太可能。对于达尔文和BSD用户，他们非常自愿地发布了代码。借助LLVM，他们甚至开始了一个全新的FLOSS项目。然而，显然，苹果在很大程度上仍然是专有软件供应商。

Android与此类似。当然，硬件支持在这里起着重要的作用，但是Google可以采用BSD代码库并将其专有。但是他们选择了Linux。因此，他们愿意回馈，不是因为没有非GPL替代方案。

Openoffice是一个更有趣的故事，因为它确实在某一时刻是专有的。但同样，LGPL转换是自愿的，没有必要。但是，* GPL类型的许可证在这种情况下使其成为可能。BSD型学术许可对于Sun发行Openoffice来说是不够的，因为那时其他人可能已经专有了该代码。在这方面，GNU * GPL已经成功。

互惠/病毒条款不会直接导致更多开放源代码。但是软件供应商可以在需要时利用它，从而为FLOSS池做出贡献。但是，大多数供应商都不愿这样做。在鼓励增加代码贡献方面，我发现BSD风格许可证和GPL风格许可证之间几乎没有区别。
总而言之，GNU GPL已经取得了成功，但在更合适的地方推动了BSD / MIT风格的许可。但是您也可以简单地通过“代码量”来衡量成功，我相信这是实际的FSF指标。

纵观该GNU宣言，但目前尚不清楚，说服公司发布FOSS软件的目标之一。这是一个报价：

为了使我能够继续使用计算机而不会感到羞耻，我决定将足够的自由软件组合在一起，以便能够在没有任何非自由软件的情况下相处融洽。

如果我们只看这个目标，那么GNU项目就大体上成功了。我们拥有一个GPL OS，一个办公套件，数据库以及许多其他可以自由修改和重新分发的应用程序。

我认为（GPL和BSD类型的许可证）对于FOSS领域都很重要。我看到了GPL的使用情况，分为两组。其中一个是一群非常敬业的开源支持者。他们认为，再次将开放源代码转换为专有工作的可能性将破坏OSS世界。我个人认为，这不是大问题。PC-BSD（专有的BSD变体）不会损坏BSD社区。第二个采用GPL的是大公司。他们使用许可证来保持对产品的更多控制（例如，以支持其业务模型）。竞争会遇到问题，要与他人获得GPL许可的软件产品一起赚钱。因此，公司可以保持竞争优势，同时可以通过开放式采购为其产品赢得良好的业力。

我个人的观点是作为个体开发人员之一，由于残疾而没有被雇用一段时间，并希望（或梦想）能够利用我唯一的宝贵技能重新谋生。

GPL一直用于商业项目。问题是有时称为“病毒”性质的问题，这意味着，如果在项目中使用某些GPL代码，则可能需要全部使用GPL对该项目的代码进行。有些人声称排除了动态链接。GPL的FAQ声称动态链接到插件被禁止，由于共享数据结构- http://www.gnu.org/licenses/gpl-faq.html#GPLAndPlugins。这似乎很奇怪，因为每个Windows应用程序都动态链接到Windows组件并与Windows共享数据结构（一个应用程序在许多方面是一个操作系统插件），但是GPL Windows应用程序包括GNU发布的大量应用程序。也许这意味着将指针伪装成句柄，并且通过函数进行的大多数访问不算作共享数据结构，这可能是任何专门设计的插件API或动态链接库都可能利用的漏洞，但是显然，单个开发人员必须谨慎行事这样的问题。

无论如何，GPL的“病毒式”性质是有充分的理由的，但是对于一个迫切需要谋生的小型开发商而言，这看起来可疑地就像是一无所获。我们无法通过收取支持费用或有效销售手册来赚钱，因为除其他问题外，我们都不具备相关技能。另外，如果您的产品缺少免费的手册，那么实际的手册可能最终会是Stack Overflow或Superuser或其他东西-而不是您的付费手册。这是假设任何人都想尽办法。

从这个角度来看，BSD风格的许可证非常有吸引力。我承认，利用其他开放源代码的工作同时保持最终产品的封闭性是虚伪的，但这必须与其他问题保持平衡。

OTOH，我实际上从未发布过任何打开或关闭的东西-至少自从大约十年前我基本上将其公开域化的一堆插件以来（而且由于多年的经验告诉我，它们的编写并不那么好） ）。所以整个事情对我来说是学术的，至少目前是这样。

不过，每次查看带有GPL样式许可的库时，我的第一个念头就是“如果我依赖于此，则会限制我的选择”。

我确实认为，当人们想到GPL时，他们会想到gnu理想，在该理想中，软件应该是自由思考的，这样想法就会泛滥成灾，大公司是坏人，因为他们不允许这样做。问题在于，这种思维方式并不能吸引很多程序员，因为他们只想编写自己的东西，拥有程序并拥有自己的生活，不一定涉及软件，因此BSD和其他许可更具吸引力，从同样的意义上来说，Linus在开发人员中比Richard Stallman更受欢迎，因为第一个人只是想做他的事情（就像我们中的许多人一样），而另一个人想尝试改变整个世界。因此，最终GPL就像Mikhail Gorbachev一样，是一个开始进化但注定不会成功的人。