[L]GPL 许可证应如何应用于 Java 和 C# 代码?我知道当 Sun JDK 成为 GPL 时,他们对标准库做了特殊的例外。
所以,如果我无法打开我的应用程序源并且仍然想分发它......
- ...我可以使用 GPL 的库(通过import 'ing 它的类)吗?
- ...我可以使用 LGPL 的吗
- ...我的应用程序能否在 GPL 的应用程序服务器之上运行(使用它的服务和 API)
在上述所有问题中,GPL = GPL v.2。
谢谢
[L]GPL 许可证应如何应用于 Java 和 C# 代码?我知道当 Sun JDK 成为 GPL 时,他们对标准库做了特殊的例外。
所以,如果我无法打开我的应用程序源并且仍然想分发它......
在上述所有问题中,GPL = GPL v.2。
谢谢
首先,如果您在其他人的作品之上构建商业软件,您应该聘请律师来帮助您确保您始终遵守版权所有者的许可和您的特定用途。
也就是说,这是我的建议:
现在,如果您担心 Java 运行时,我认为您不必担心。如果 Sun 只制作 Java GPL,我会感到惊讶。他们有太多的客户,他们依赖于 Java 可以扩展并用于构建专有应用程序这一事实。软件通常在多个许可下发布,允许用户选择条款(例如,Firefox 使用这种方法并获得三重许可:GPL、LGPL 和 MPL)。
不管 Sun 对开源的承诺如何,您都可以使用 GPL、LGPL、MIT 甚至所谓的“专有”许可来许可您的 Java 应用程序。
“......我可以使用 GPL 的库(通过导入它的类)吗?” 不。除非它不是纯 GPL(它可能是双重许可的,具有“类路径异常”或类似的东西,或者具有用于外部访问的公共域接口)。但是,这仅适用于您分发应用程序的情况。如果您的应用程序仅在内部使用,那么您不需要分发源代码。
“...我可以使用 LGPL'ed one” 如果您将其保存在单独的文件中,您可以参考 LGPL 代码。对于 Java,将 LGPL 代码保存在单独的 jar 中。对于 C#,将其保存在单独的 DLL 中。如果您允许最终用户替换它,您可以在您的应用程序中包含 LGPL 代码(但这可能比仅将其保留为单独的文件更难)
“......我的应用程序能否在 GPL 的应用程序服务器之上运行(使用它的服务和 API)”。不,除非这些服务/API 有其他许可。
[咆哮] GPL 和 LGPL 是由非常糟糕的律师编写的糟糕的许可证,他们无法弄清楚他们的术语。因此,任何人都可以猜测它们的真正含义以及它们如何应用于现实世界的情况 [/rant]
正确的答案是,如果被版权所有者起诉是您真正关心的问题,那么您应该咨询律师。这些许可证太复杂,您无法在此论坛上获得有意义的答案。
现实世界的答案是,将他们的 Java 库置于 LGPL 之下的人很可能打算将它们链接到商业 Java 应用程序中/在其中重新分发,因此如果您只是简单地重新分发那些未修改的库,则极不可能遇到任何麻烦。应用。
在 GPL 下分发 Java 库的人要么不打算将它们嵌入到商业应用程序中,要么不关心法律后果,因为 GPL 不是库的适当许可,而仅适用于独立应用程序. 我建议在商业代码中避开 GPL 的 Java 库。不过,将 GPL 应用程序与您的商业应用程序并排包含在内是可以的。
关于在 GPL 应用程序服务器中运行,只要您坚持使用标准 API(servlet、jsps、JMX 等),您肯定没问题。如果您必须使用服务器专有的 API,那么问题会更加复杂,所以我肯定会咨询律师,尽管 App Server 代码所有者的意图很可能是应该允许这样的使用。
IANAL 但我认为重要的是要记住 GPL 取决于版权。因此,版权法允许的任何内容在 GPL 下都是允许的。例如,GPL 禁止制作派生作品并将其链接到非 GPL 模块。例如,这种参数用于防止使用二进制 Linux 内核模块。但是,不是内核派生作品的模块不能被认为属于内核的版权,因此不必是 GPL。注意:带有模块的生成内核可能被认为是派生作品,并且证明模块不是派生作品可能是一个问题。但它不是切割和干燥的。
此外,GPL 包含基本操作系统的例外情况,允许将 GPL 软件链接到平台的非自由库。这允许自由软件在非自由平台上运行。可以说 JVM 是一个平台,甚至像 J2EE 应用程序服务器这样的东西也可能是一个平台。您可能不允许将 GPL Web 应用程序和平台一起重新分发,但移植到 Websphere(例如)的 GPL Web 应用程序可能仍然符合 GPL。
鉴于复杂性,与律师讨论这件事是有意义的。