Oracle似乎在GPL下许可了所有与Java相关的开放源代码,但有classpath例外。据我了解,这似乎可以将这些库与您自己的代码组合成GPL不必涵盖的产品。
- 这是如何运作的?
- 有哪些示例说明我如何使用和不能使用这些类?
- 为什么使用这个新许可证而不是LGPL,LGPL似乎允许几乎相同的事情,但是可以更好地建立和理解?
- 与LGPL有何区别?
Oracle似乎在GPL下许可了所有与Java相关的开放源代码,但有classpath例外。据我了解,这似乎可以将这些库与您自己的代码组合成GPL不必涵盖的产品。
Answers:
首先,我不是律师。但是我研究了许多许可证,并且了解与许可证有关的问题。
第二,我知道这是一个古老的问题,但我认为这仍然是一个令人困惑和关注的问题。如果不是要关注的问题,那应该是。选择许可证是很大的事情,您不能轻易改变,特别是在涉及多个贡献者的情况下。
不幸的是,(L)GPL是在考虑C / C ++的情况下编写的。它说的是“源代码”,“目标代码”,“动态链接”,“静态链接”,“编译器”和“目标代码解释器”。因此,将其翻译为不遵循相同编译技术的其他语言(例如Java的字节码,Python的即时编译或Javascript的解释性质)需要一些猜测和假设。当您谈论法律时(例如,考虑两方争论的最终法院案件时),没有明确的区分是不好的事情。
标准的GPL许可代码在意图上非常简单。使用该代码的任何人都应在其分发或出售该代码时将其代码发布给所有用户。这就是Richard Stallman想要创建的GPL病毒,而且清晰,干净。
LGPL最初是试图允许一个不会传播的“图书馆”。但是他们仍然希望最终用户能够自己替换库,因此“静态”链接和“动态”链接之间的区别-用户可以交换到另一个动态链接的库,因此不需要获得GPL许可。静态链接要求用户为GPL。该许可证实际上是在谈论“头文件”,这些头文件在C / C ++中是清楚的,但在Java,Python,Javascript等世界中却显然不清楚。因此,LGPL内容的L(“库”)充其量是泥泞的。
这成为问题的症结所在。在法律界,尚不清楚的是BAD。如果我正在考虑使用GPL或LGPL组件构建某些东西,那么我想确定如果我上法庭,将来我的法律地位如何。但是直到今天,我还不确定,因为实际上还没有很好的法院案例来确立法律先例,只有像这样的论坛才有理智的论据。
这是Classpath异常不可估量的地方。它明确指出,许可下的代码是(L)GPL,但是使用该代码的任何内容都可以遵循他们想要的任何许可。没有if,ands或buts。如果您更改核心代码(例如,修复错误),则仍必须将这些更改作为GPL的一部分发布。但是使用不会感染您。
从业务角度来看,我理解为什么有些人不想用10'杆触碰GPL代码。法律地位尚不明确,最终树立法律先例时,业务可能会走下十年。否则他们可能会在法庭上为争取建立法律先例而奋斗多年。不管他们只是不想冒险付出那场战斗的代价。添加Classpath Exception子句消除了法律问题,并避免了任何(严重)潜在的法院案件。
因此,对我来说,类路径异常与LGPL有很大不同。这是划清界线的合法方法,允许非GPL使用GPL或LGPL源代码或库。
看起来“具有类路径异常的GPL”样式的许可证可能早于LGPL。
也许任何人仍然使用它的唯一原因是,如果没有提供过代码的所有人的书面许可,则GPL代码无法迁移到LGPL代码。