设计一个对专有库有弱依赖的GPL库，最好的方法？

Question

我打算编写一个C库，它将充当其他几个库的伞形“包装器”。一些库将是GPL，一些将是专有的。此外，某些库可能在编译时不可用，因此我计划让autotools在配置期间检测它们。我也想知道我是否应该支持这些弱依赖项，然后在运行时检测它们 - 特别是对于专有库。原因如下：

无需详细说明，该库旨在提供用于与各种设备通信的API，其中一些设备没有开源驱动程序。目前很难为这些设备编程，因为没有标准的，易于使用的API。每个供应商都提供自己的。还有一些其他API可以尝试包装它们，但它们基本上都是

• C ++ - 只有
• 专为Windows环境而设计，* nix作为事后的想法。
• 无法构建，除非您在正确的位置有依赖关系，即完全缺乏正确的配置/构建系统。
• 最重要的是，它设计的方式通常直接链接到专有的库，这让我几乎100％确定将这些API用于Debian是不可能的。

因此，我的最终目标是构建一个非常简单直接的C API，它有可能将它变成发行版，这样人们就可以用简单的apt-get为这些设备编写程序。

我的问题是，我应该如何最好地设计库与GPL兼容和Debian友好，但仍然能够在必要时调用专有库？

理想情况下，我希望用户能够使用此库来获取程序，然后只要供应商的用户级驱动程序安装到预期的位置，一切都应该开箱即用。 / p>

我的担忧是双重的：

• 依赖于可选的专有库意味着无法编译库的二进制发行版以动态链接到这些库，因为它们可能可用也可能不可用。
• 用户不必为他没有，开放或专有的设备安装依赖项。

其他软件包如何处理链接到专有库并具有运行时弱依赖性的问题？ dlopen是正确的方法吗？我应该dlopen只有专有的东西吗？ Debian可能会拒绝这样的一揽子计划的原因是什么或者是什么原因？

最后，我意识到这可能不是关于Debian政策这个问题的正确论坛，所以有人能指出我更好的地方提出这个问题吗？

感谢。

Answer 1

我与Debian没有任何关系，也无法谈论他们的政策。但是，对于您的框架，这似乎是一种合理的方法：

1. 定义一个简单的头文件，表示您需要从这些插件中获得的功能
2. 创建一个使用该接口的有用的GPL / LGPL / BSD插件
3. 正如您所提到的那样，使用libdl加载主程序（如果您的主程序是GPL，则需要许可例外以允许链接专有插件）
4. 提交包含在Debian中的内容，并且不提及专有内容

重点是你的插件系统应该对自由软件有用，而不仅仅是一个允许加载专有代码的特洛伊木马。

Answer 2

使用dlopen不会改变您编写程序以同时故意链接到专有库和GPL库的事实，它只是将链接从编译时间转移到运行时。虽然大众之间的共识是，GPL并未以这种方式在运行时动态链接，但依赖这种共同理解并不是安全的法律建议。我解决问题的方法是编写一个带有插件的通用API的程序（可以使用dlopen，但关键是你没有专门编写这个程序来链接到专有库）。该程序必须在免费许可下，该许可与您最终希望与之一起使用的所有插件兼容（即LGPL，或该API除外的GPL）。然后为GPL库和专有库编写单独的插件，并单独分发它们。如果一次只能加载一个插件，那么就没有法律问题。如果有必要同时允许多个插件，那么您需要小心分开您的发行版。由于GPL是分发许可证，最终用户所做的事情并不是一个问题。