为什么你的下一个库不应该使用 Lesser GPL

GNU 项目有两个主要的库许可证。一个是 GNU Lesser GPL；另一个是普通的 GNU GPL。许可证的选择非常重要：使用 Lesser GPL 允许在专有程序中使用该库；对库使用普通的 GPL 则使其仅适用于自由程序。

哪个许可证最适合特定的库是一个策略问题，它取决于具体情况。目前，大多数 GNU 库都采用 Lesser GPL，这意味着我们只使用这两种策略中的一种，而忽略了另一种。因此，我们现在正在寻求发布在普通 GPL 下的更多库。

专有软件开发人员拥有资金优势；自由软件开发人员需要为彼此创造优势。对库使用普通的 GPL 使自由软件开发人员比专有开发人员更具优势：他们可以使用该库，而专有开发人员无法使用。

使用普通的 GPL 并非对每个库都有利。在某些情况下，使用 Lesser GPL 可能会更好。最常见的情况是，当专有软件可以通过其他库轻松获得自由库的功能时。在这种情况下，该库无法为自由软件提供任何特定的优势，因此最好对该库使用 Lesser GPL。

这就是为什么我们对 GNU C 库使用 Lesser GPL 的原因。毕竟，还有许多其他的 C 库；对我们的库使用 GPL 会迫使专有软件开发人员使用另一个库——这对他们来说没有问题，但对我们来说却有问题。

但是，当库提供重要的独特功能时，例如 GNU Readline，情况就大不相同了。Readline 库为交互式程序实现输入编辑和历史记录，而这通常在其他地方不可用。在 GPL 下发布它并将其使用限制为自由程序，将为我们的社区带来真正的推动。至少有一个应用程序程序今天成为自由软件，正是因为这是使用 Readline 所必需的。

如果我们收集大量强大的 GPL 许可的库，而专有软件没有可用的并行库，那么它们将提供一系列有用的模块，作为新自由程序中的构建块。这将为进一步的自由软件开发带来显著优势，并且一些项目将决定使软件自由以使用这些库。大学项目很容易受到影响；如今，随着公司开始考虑使软件自由，即使是一些商业项目也可能受到这种方式的影响。

专有软件开发人员为了剥夺自由竞争的重要优势，会试图说服作者不要向 GPL 许可的库集合贡献库。例如，他们可能会迎合虚荣心，承诺如果我们允许他们在专有软件产品中使用代码，那么“这个库会有更多用户”。受欢迎程度很诱人，而且库开发人员很容易合理化这样一种想法，即提高该库的受欢迎程度才是社区最需要的。

但是我们不应该听从这些诱惑，因为如果我们团结一致，我们可以取得更大的成就。我们自由软件开发人员应该互相支持。通过发布仅限于自由软件的库，我们可以帮助彼此的自由软件包超越专有软件包。整个自由软件运动将更受欢迎，因为作为一个整体，自由软件将在竞争中表现得更好。