4

MySQL++ 通过 LGPL 获得许可，这意味着我可以发布动态链接到它的可执行文件，而不必担心源代码不是 GPL。但是，MySQL++ 确实链接到了GPL的 libmysqlclient{_r}.{a,so} ( http://tangentsoft.net/mysql++/#linkerrors )。
正如所见，MySQL++ 在技术上只是一个面向 GPL 的 libmysqlclient{_r}.{a,so} 的“包装器”（顺便说一句，包装器实现得非常好，不要误会我的意思），如果我链接到 MySQL++ 就像链接到libmysqlclient{_r}.{a,so}？

如果是这种情况，那么 MySQL++ 被 LGPLed 的目的是毫无意义的，因为任何动态链接到它的可执行文件都必须随后链接到 libmysqlclient{_r}.{a,so} 。我哪里错了？

4

4 回答 4

4

如果您的程序根据 MySQL 分发文件中列出的许可之一获得许可EXCEPTIONS-CLIENT，那么您的程序不必与 GPL 兼容即可使用 MySQL 客户端库。

但总的来说，是的，如果您想链接到 GPL 库，那么您的程序必须与 GPL 兼容。

于 2009-08-11T14:11:46.383 回答
3

您可能需要咨询律师。我不是一个。但这里有一些事情需要考虑：

  1. 只有在结果工作适用于 MySQL 的 GPL 许可时，才能在 LGPL 下使用 MySQL++，这是 GPL+例外。因此，您的程序需要是 GPL 或例外许可之一。其他任何事情都可能违反 GPL。
  2. 分发作品时适用 GPL 和 LGPL。我可以合法地将 nVidia 二进制驱动程序安装到我计算机上的 GPL 内核中，因为我没有以这种方式分发它。如果您的应用程序不是 MySQL 的派生作品，则它不属于 MySQL 的版权。如果分发您的应用程序不侵犯 MySQL 的版权，那么您无需担心 MySQL 的许可条款。律师可以告诉您派生的工作边界在哪里。FSF 声称链接会创建衍生作品。
  3. 可能如果您的程序不与 MySQL 链接，而仅与 MySQL++ 链接，那么您的应用程序不是 MySQL 的派生作品。当两个组件之间有足够厚的层时，这通常是正确的。例如，在 JVM 中运行的 Java 应用程序链接到 JVM，但不链接到内核。它不能被认为是内核的派生作品（*迂腐注意：大多数内核不认为程序是派生作品。但概念是相同的）。

请记住，(L)GPL 的权力来自版权。如果 A 是 B 的派生作品，您需要获得 B 的版权所有者的许可才能分发它。如果 A 不是，则分发 A 不需要许可。如果 A 从 B 派生，但 B 从 C 派生，A 可能从 C 派生，也可能不从 C 派生。您需要所有版权所有者的许可才能分发他们的作品或衍生作品作品。(L)GPL 规定了在什么条件下自动授予权限。

于 2009-08-11T14:24:29.593 回答
1

我相信你的结论是正确的，即链接到 LGPL 库 A 本身链接到 GPL 库 B 与链接到 GPL 库相同，因此要求你的程序在 GPL 下。

所以我同意 libmysql++ 成为 LGPL 是毫无意义的，但我认为可能是因为旧版本的 MySQL 客户端库曾经是 LGPL。（不过，正如你所注意到的，它们现在都是完整的 GPL）

于 2009-08-11T14:11:58.693 回答
1

Oracle（neé Sun，neé MySQL AB）很乐意向您出售C API 库的 GPL 豁免。然后，您可以将 MySQL++ DLL 与您的程序一起分发，并且只受 LGPL 约束。

于 2009-08-12T02:31:20.077 回答