随着当前关于Oracle的发展，宣布其打算为专业版（或任何你称之为）JVM收费，以及IBM宣布支持OpenJDK的意图，对于大量Java开发人员而言，事情变得相当复杂。 我们在Java中有大量工作，到目前为止我们在选择许可条款方面没有任何问题。看来我们将不得不切换到IBM将提供支持的OpenJDK。但是OpenJDK是GPL V2，据我所知，链接到GPL V2的任何代码都必须是GPL V2。 我们还有一些JNI代码，它们会变得更大。鉴于这些事实，是否意味着如果我们使用OpenJDK运行我们的软件，我们将不得不切换到GPL进行许可？ 毋庸置疑，这会打破我们的整个许可证。商业模式设置。
答案 0 :(得分：24)
OpenJDK的许可证不是“GPL v2”，而是"GPL v2 with the Classpath Exception"。引用：
作为特殊例外，此库的版权所有者会为您提供 允许将此库与独立模块链接以生成 可执行文件，无论这些独立模块的许可条款如何， 并根据您的条款复制和分发生成的可执行文件 选择，只要您同意，每个链接的独立模块， 该模块许可的条款和条件。一个独立的 module是一个不是从该库派生或基于该库的模块。
答案 1 :(得分：12)
如果我使用OpenJDK作为JVM，是否需要打开我的源代码？
绝对不是。
有许多使用基于OpenJDK的JVM的商业闭源Java应用程序。 @Chris Lercher特别提到的“Classpath例外”使其合法化。
顺便提一下，“类路径异常”是由FSF的律师专门发明的，以允许GNU Classpath库（Java SE库的洁净室重新实现）用于运行专有/闭源应用程序。因此，名称......
您需要担心的唯一情况是：
在OpenJDK 11中，最后一个类别似乎包含大量未包含在OpenJDK发行版中的“测试”类，以及您不应该（也可能不能）链接到的内部类。一个应用程序。这些类很容易识别。在OpenJDK源代码树中搜索包含单词“GNU”而不是单词“Classpath”的Java源文件
值得注意的是，OpenJDK Java代码库的很大一部分是具有许可开源许可证的第三方代码。允许链接到这些类。
将OpenJDK与封闭源捆绑不是问题。 GPL允许您将GPL软件的二进制文件与闭源软件的二进制文件一起分发。
答案 2 :(得分：9)
请阅读类路径异常开头的行。类路径异常似乎不适用于整个库。
Sun Microsystems，Inc。分发的某些源文件受GPL的以下澄清和特殊例外的约束，但只有在Sun明确包含在特定源文件的标题中时，“Sun指定此特定文件”作为Sun在LICENSE文件中提供的“类路径”例外的主题。“