我有一个开源 Java 库 ( http://jolbox.com ),目前已获得 LGPL 许可。
据我了解 LGPL,基本上任何人都可以将其链接到他们的应用程序中并分发它,无论是否商业化,而不必“污染”他们的代码。然而,我有时会认为公司误解了这一点,并且不会触及许可证中带有 GPL 字母的任何内容。
这在您的公司中是否合理?如果是,哪种许可证是理想的?
(我只关心我的工作是否得到认可——而不是其他人在这个过程中变得富有)
我有一个开源 Java 库 ( http://jolbox.com ),目前已获得 LGPL 许可。
据我了解 LGPL,基本上任何人都可以将其链接到他们的应用程序中并分发它,无论是否商业化,而不必“污染”他们的代码。然而,我有时会认为公司误解了这一点,并且不会触及许可证中带有 GPL 字母的任何内容。
这在您的公司中是否合理?如果是,哪种许可证是理想的?
(我只关心我的工作是否得到认可——而不是其他人在这个过程中变得富有)
我认为企业正在缓慢但肯定地对 LGPL 进行热身。也就是说,您可能想查看一些更宽松的许可证,例如 MIT、BSD 和 Apache 的许可证 - http://en.wikipedia.org/wiki/Permissive_free_software_licence
我认为答案取决于版本。LGPL v3 对大多数公司来说都是毒药,因为它的措辞使得他们必须将任何使用 LGPL v3 许可的组件的系统提供给任何需要它的人。
你是否同意即使拥有最专有的源代码也会给你带来很多好处是另一回事,但这是他们关心的问题。
LGPL 许可证 v2.1很长,有一个“政治”标题,许多人认为留下了太多不清楚的地方(尝试阅读并思考律师如何故意误读它)。
作者使用它是因为他们认为他们知道这意味着什么,对项目的更改需要回馈,但使用不需要。我的观点是,解释是乐观的,对法律挑战持开放态度。因此,许多企业避免使用 LGPL v2.1 许可代码,尽管它确实有所不同(一些法律意见认为可以,有些则不然)。
奇怪的是,当你问许多作者(比如你自己)他们关心什么时,通常会最大程度地采用和承认,而左复制的更多“政治”方面就不那么有趣了。这就是为什么 Apache v2 许可证是一个很好的默认选择。
MIT 或 BSD-3-clause 许可证也是可选的,因为它们很短而且很少说,但对于大多数正常使用,Apache v2 已经取代了它们。
如果你的解决方案是值得的,无论如何你都会得到认可。看看 SQLite3 - 它是公共领域,但却是部署最广泛的数据库。