关于 MySQL++、GPL 和 LGPL [关闭]

Question

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++ 成为 LGPL 的目的是毫无意义的，因为任何动态链接到它的可执行文件都必须随后链接到 libmysqlclient{_r}.{a,so}。我哪里错了？

Answer 1

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

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

Answer 2

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

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 规定了在什么条件下自动授予权限。

Answer 3

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

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

Answer 4

Oracle (neé Sun, neé MySQL AB) 将很高兴sell 您获得 C API 库的 GPL 豁免。然后您可以随您的程序一起分发 MySQL++ DLL，并且只受 LGPL 约束。