库依赖性兼容性用于非商业用途

时间:2012-06-14 12:51:27

标签: java licensing dependencies

我目前正在攻读研究背景中的数据分析/信息学,并为全球研究界开发实用工具,目前我的预期用户绝大部分都是计算机新手。换句话说,我的大多数用户都不会打扰(或能够)收集必要的依赖关系并将它们放在类路径中。为了避免人们忽略我的软件,我一直将它作为“胖子”分发,所有依赖项都包含在一个可执行文件中。

我一直在阅读有关软件许可的一些内容,并意识到这样做可能在法律上很棘手,而且不必过多关注图书馆的个别许可。我在StackOverflow(下面是一个完整的集合)中经历了一些问题,但最终变得越来越困惑。 请注意,我完全清楚有许多其他关于软件许可的问题,但不是在自包含的软件包中,我在下面列出了很多很好的问题,这些问题提供了一些谜题,但不是直截了当的在我的场景中回答。

如果开发人员能够通过确认或否认下面的陈述,能够更好地了解此事,我将不胜感激。我认为这对于那些不是程序员但是专业但是越来越多地参与编程的人来说可能是有用的。我的理解是:

  • 只要您不重新分发您的依赖项,与您为自己的项目选择的许可证相比,它们拥有的许可证并不重要。 [不幸的是,这样做也意味着我会疏远/恐吓我的用户群的很大一部分]

  • 如果要重新分发所有依赖项,那么项目许可证应与您的依赖项兼容。 [因此,我作为开发人员必须知道每个依赖项的许可证的详细信息??]

  • GPL是最严格的开源许可证(来自常见的),因此如果我使用GPL许可下的库,我自己的项目也必须在GPL下,理论上这可能是矛盾的获得其他一些依赖的许可。

  • 假设我的项目属于GPL,项目非商业化并不重要,它也必须是开源的。 [这在我的情况下相当棘手,因为算法和计算方法需要“新颖”才能发布]

我是否误解或错过了重要的事情,或者这是对情况的一个很好的总结?鉴于我的情况,我是否有其他选项,我可能没有在这里提到/想到,例如,是否可以避免有关我的依赖项的许可证的问题?


参考文献:

Should I be concerned with large number of dependencies?

Which licences are compatible with each other?

Where can I find an authoritative overview of open source licences?

How do you choose an open-source license?

Searching for non-commercial license for source code

Is it legal way to get use GPL code in close-source application through plugin?

How do I tell if I can re-use a 'free' software library in a commercial app? [closed]

Correctly Applying an Open Source License(特别是this answer来自@Michael Aaron Safyan)

How do I find the open source license that is right for my project?

How to use an Open Source License

How do you choose an open-source license?

5 个答案:

答案 0 :(得分:5)

  

只要您不重新分发您的依赖项,与您为自己的项目选择的许可证相比,它们拥有的许可证并不重要。

是的,对于主流许可证的开源依赖性,这是真的。但是:

  • 它强制您的用户下载所有依赖项,这是一个坏主意。
  • 对于专有依赖项(以及具有“疯狂”许可证的开源依赖项),许可证可能禁止此操作,或者通过禁止他们来使用户很难(-er)
  

如果要重新分发所有依赖项,那么项目许可证应与您的依赖项兼容。

是。但这通常不难。有什么地方可以找出哪些许可证与其他许可证兼容;例如FSF的GPL页面。

  

[因此我作为开发人员必须知道每个依赖项的许可证的详细信息??]

是。但是,您可以通过仅使用安全许可证的依赖项来简化此操作。 (而且大多数开源许可证都是。)

  

GPL是最严格的开源许可证(来自常见的),因此如果我使用GPL许可下的库,我自己的项目也必须在GPL下......

是。但请注意,GPL和LGPL之间存在很大差异。 LGPL没有这个限制。

  

......理论上这可能与某些其他依赖的许可相矛盾。

理论上是的。实际上,GPL允许将库与大多数其他开源许可证一起使用。唯一的问题是如果其他图书馆的许可证需要GPL禁止的东西;即在下游用户,包装商等处放置额外条件

  

假设我的项目属于GPL,项目非商业化并不重要,它也必须是开源的。

这是正确的。

  

[这在我的情况下相当棘手,因为算法和计算方法需要“新颖”才能发表]

我认为你从一些根本不应成为问题的事情中解决了一个大问题:

  • 如果您担心其他人在您发布之前窃取您的想法,请暂停发布您的代码,直到您发布为止。这是普通的常识......而不是许可问题。

  • 如果算法和方法体现在以前分发的软件中,我认为编辑/审稿人不会拒绝您的出版作品。您的出版物必须在出版媒体方面具有新颖性......

  

...是否可以避免有关我的依赖项许可的问题?

  • 您可以从头开始编写自己的所有代码,也可以聘请其他人为您执行此操作。 (不太现实)

  • 您可以将商业软件用于所有依赖项,并支付重新分配的权利。

  • 您可以联系您的依赖项的版权所有者,并协商替代许可协议。 (假设它们是可联系的,并愿意进行谈判。)

但你不能忽略这个问题。

最重要的是,当您使用开源依赖项构建代码时,您可以免费获得某些内容,但 quid pro quo 是您必须按照规则进行播放。如果您不喜欢这些规则,请找到一种不涉及开源的不同方式。

答案 1 :(得分:1)

最大的问题是,如果您正在处理未使用任何常见开源许可证的软件。简单地说,如果这些许可证禁止重新分发他们的软件,那就几乎可以阻止那里的辩论。

您可以以这样的方式打包软件:如果用户自己获得适当的许可证,那么您可以让用户轻松地将他们的许可库合并到您的系统中(通过适当地更新类路径,也许复制文件到已知的地方等)。结合良好的文档或自动脚本,这可以使您使用这些库安装软件减轻用户的负担。

如果您仅使用开源许可软件,事情就会简单得多。

正如您所说,GPL是最严格的,但大多数OSS许可都与GPLv3兼容。 Apache,BSD,麻省理工学院,MPL,X11 / MIT。

而且,是的,您需要了解所有许可证,尤其是GPL。如果可行,你可以避免使用GPL,所有这些问题都会消失。如前所述,LGPL比GPL严格得多,许多采用这种方式的库因此选择LGPL,但也有一些使用纯GPL代替。

现在的美丽OSS社区已经非常成熟,即使在许可方面仍然有点分散,但仍然真正可以互操作。大多数人甚至不会问这些问题并继续他们的快乐方式,但仍然设法保持麻烦。

但是,归结为3个概念:

  • 如果您使用的是专有库,那么您的选择非常有限 在分配方面。

  • 如果您使用的是GPL库,您也应该使用GPL软件。

  • 如果不是上述情况,请不要担心。

答案 2 :(得分:1)

许可 非常重要,但如果您制作的开源,非商业软件与商业软件没有直接竞争,那么有人会抱怨您可能滥用其中一个图书馆的风险许可证非常接近于零(这样的投诉在法庭上不会走得太远,尽管你的里程可能会因你所在国家的原因而有所不同。)

所以,不要太担心并坚持游戏精神:

  • 如果您使用商业图书馆,请获取许可证(其中批次实际上拥有开源项目的免费再发行许可证)

  • 如果您使用GPL图书馆,请将您的项目设为GPL(无论如何,这都是您正在做的事情)

答案 3 :(得分:0)

我认为你的四点是正确的。

即使您的项目使用了与重新分配相互矛盾的依赖关系,有一件事情是您不会分发您的程序,而是提供它(或使用相关依赖项的部分)作为托管的(Web)服务在你自己的服务器上。然后你可以使用你想要的几乎所有依赖项,甚至不必开源任何东西。但请注意,某些许可证(主要是商业许可证)可能会限制服务器的使用。

答案 4 :(得分:0)

很抱歉,如果您使用专有库,则无法解决此问题。

如果您使用免费的专有库,则无法以任何方式包含在您的软件中“除非您与作者达成协议”,客户必须从作者的网页或存储库下载它们,否则您将重新分发图书馆并发生侵犯版权。

最近有几个类似的案例Java's Oracle in Linux.


GPL问题:

您的算法可能的解决方案可能是将其放在一个没有任何依赖性的单独库中,并将其添加到您的主“GPL”项目中,这是大多数公司用来做的。