在GPL应用程序中使用闭源API？

我想编写一个作为GPLv3发布的应用程序(将用.NET编写),我正在编写它,以便其他人可以将扩展名编写为DLL库.我假设这些也必须作为GPLv3发布,这是预期的.

我希望应用程序在第一个版本上附带的库之一将是一个与第三方应用程序连接的库.第三方应用程序提供了一个免费的(如在啤酒中)带有API的.NET库,它实际上是与第三方应用程序通信的通信驱动程序.

我的问题 - 这样可以吗？我假设它是,否则我无法编写基于.NET的代码并将其作为GPLv3发布,因为.NET实际上是带有API的库的集合.我有道理吗？

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

我的建议是阅读相关API附带的许可证,如果您有任何其他问题,请直接与API发布者联系.猜测,即使是集体猜测,也是构建软件的糟糕框架.

GPL已经包含"系统库"和某些"标准接口"的规定,您的DLL扩展接口可能位于其中.诸如C运行时,.NET Framework和POSIX API之类的东西都属于这些例外.您的DLL扩展接口可能属于"标准接口"术语.

但是,如果您正在编写应用程序(不修改现有的GPL应用程序),那么您可以随心所欲 - 毕竟它是您的.

如果您担心DLL扩展接口不是"以源代码形式向公众提供实现的标准接口",您可能希望为GPL编写特定的例外以允许非链接用于扩展DLL的GPL第三方库使其清晰并允许其他人提供这些扩展.请注意,除了这样的例外,一些开发人员可能会尝试将其用作漏洞,因为不必通过将它们打包到扩展DLL中来释放它们的修改.

当然,与任何与许可证或其他法律事务相关的帖子一样,标准免责声明适用(IANAL,使用风险自负,这不是建议,这可能完全不正确,如果你试图起诉我,我会声称我没有写它(有人必须闯入我的SO帐户),等等,等等)