在GPL应用程序中使用闭源API?[关闭]

GPL已经包含“系统库”和某些“标准接口”的规定,您的DLL扩展接口可能在这些规定之下。像C运行时、.NET框架和POSIX API之类的东西将属于这些异常。您的DLL扩展接口可能属于“标准接口”术语。

然而,如果 你 正在编写应用程序(而不是修改现有的GPL应用程序),然后您可以做任何您想做的事情——它毕竟是您的。

如果您担心dll扩展接口不是“以源代码形式向公众提供实现的标准接口”,那么您可能需要向gpl编写一个特定的异常,以允许在非gpl第三方库中为扩展dll链接,以使其明确,并允许其他人提供这些扩展。请注意,有这样一个例外,一些开发人员可能会尝试将其作为一个漏洞,因为不必通过将修改打包到扩展dll中来释放修改。

当然,与任何与许可证或其他法律事务有关的帖子一样,标准免责声明也适用(IANAL,由您自己承担风险使用,这不是建议,这可能是完全错误的,如果您试图就此起诉我,我会声称我没有写它(一定有人闯入了我的SO帐户),等等)。

请记住,这是一个你应该问的知识产权律师,而不是软件开发人员的问题。我们能给的只是我们最好的猜测。

我的建议是阅读相关API随附的许可证,如果您还有任何疑问,请直接联系API发行商。猜测,甚至是集体猜测,都是构建软件的糟糕框架。

根据 FSF's FAQ 关于GPL:

我可以发布一个使用非免费工具开发的GPL下的程序吗?

您用来编辑源代码、编译源代码、研究源代码或记录源代码的程序,通常对源代码的许可问题没有影响。 但是,如果您将非自由库与源代码链接起来,这将是您需要处理的问题。它并不排除释放GPL下的源代码,但是如果库不适合__系统库__例外,您应该附上一个明确的通知,允许您的程序与它们链接。金融稳定基金会可以给你建议。

见 this entry 在常见问题解答中了解更多详细信息(粘贴到这里有点复杂)。

DR 如果它是一个系统库,你可以做到。否则,您可以附加一个通知,说明最终用户可以链接到关闭的源代码库(如果需要帮助,请与FSF联系)。

虽然您不太可能(如其他人所说)将其作为GPL应用程序发布,但请记住,您可以使用其他许可证,这些许可证对您可以对第三方代码执行的操作更为宽松,但仍然允许您维护源代码的某些控制(或不按您的意愿):链接等。LGPL、MPL、BSD许可证等,但