6.7 外部库

作为 FSF 版权的 GNU 软件包的维护者，您如何使用单独发布的通用自由模块？（我们也将它们称为“库”，因为我们正在将它们用作库；它们是否打包为库并不重要。）

要求他们的作者将版权转让给 FSF 是不合理的。他们编写这些模块并不是为了向 GNU 贡献。我们只是碰巧想使用它们，就像任何开发者都可能做的那样。突然要求开发者将他们的版权给予 FSF 是无礼的。请不要在这些情况下提出这样的要求。

使用这些模块的正确方法是将您的软件包与它们链接，并声明它们不是您的软件包的一部分。请参阅下文了解其机制。

为避免当前或未来的法律麻烦，您必须确保该模块的许可证与当前和未来的 GPL 版本兼容。“GNU GPL 第 3 版或更高版本”是可以的，任何包含允许在这些 GPL 版本下使用的许可也都可以（包括“GNU GPL 第 2 版或更高版本”、“LGPL 第 n 版或更高版本”、“LGPL 第 2.1 版”、“GNU Affero GPL 第 3 版或更高版本”）。宽松的许可协议也是可以的，因为它们与所有 GPL 版本兼容。

“GPL 第 2 版仅限”显然是不可接受的，因为它与 GPL 第 3 版不兼容。“GPL 第 3 版仅限”和“GPL 第 2 版或第 3 版仅限”有一个更微妙的问题：如果我们要制作 GPL 第 4 版，它们将与 GPL 第 4 版不兼容，因此该模块将成为将您的软件包的许可证升级到“GPL 第 4 版或更高版本”的障碍。请勿使用此类模块。

您需要避免的一个库是 goffice，因为它仅允许 GPL 第 2 版和第 3 版。

因此，以下是如何安排您的软件包以使用不相关的自由模块的机制。

1. 假设该模块已安装在系统上，并在链接您的程序时与之链接。只有当该模块确实具有库的形式时，这才合理。
2. 将该模块包含在您的软件包的发行版中，将源代码放在一个单独的子目录中，该子目录的 README 文件中写道：“这不是 GNU FOO 程序的一部分，而是与 GNU FOO 一起使用。” 然后设置您的 makefiles 来构建此模块并将其链接到可执行文件中。

   使用此方法，无需将该模块视为库并从中创建一个 ‘.a’ 文件。您可以像往常一样直接与 ‘.o’ 文件链接。

这两种方法都会产生不规则性，我们的律师告诉我们，要尽量减少这种不规则性。因此，仅对并非为您的软件包编写的通用模块使用这些方法。对于任何作为您软件包的贡献而编写的内容，请签署文件。