pos*_*def 12 java dependencies licensing
我目前正在攻读研究领域的数据分析/信息学,并为全球研究界开发实用工具,我的绝大多数用户都是计算机新手.换句话说,我的大多数用户都不会打扰(或能够)收集必要的依赖关系并将它们放在类路径中.为了避免人们忽略我的软件,我一直将它作为"胖子"分发,其中所有依赖项都包含在一个可执行文件中.
我一直在阅读有关软件许可的一些内容,并意识到这样做可能在法律上非常棘手,而且不必过多关注图书馆的个别许可.我在StackOverflow(下面是一个完整的集合)中经历了一些问题,但最终变得越来越困惑.请注意,我完全清楚有许多其他关于软件许可的问题,但不是在自包含的软件包中,我在下面列出了许多很好的问题,这些问题提供了一些难题,但不是我的直截了当的答案.场景.
如果开发人员能够通过确认或否认下面的陈述来更好地了解此事,我将不胜感激.我认为这对于那些不是程序员但是专业但是越来越多地参与编程的人来说可能是有用的.我的理解是:
只要您不重新分发您的依赖项,与您为自己的项目选择的许可证相比,它们拥有的许可证并不重要.[不幸的是,走这条路也意味着我会疏远/恐吓我的用户群的很大一部分]
如果要重新分发所有依赖项,那么项目许可证应与依赖项兼容.[因此,我作为开发人员必须知道每个依赖项的许可证的详细信息??]
GPL是最严格的开源许可证(来自常见的),因此如果我使用GPL许可下的库,我自己的项目也必须在GPL下,这理论上可能与其他一些许可证相矛盾依赖.
假设我的项目是在GPL下,项目是非商业的这一事实并不重要,它也必须是开源的.[这在我的情况下相当棘手,因为算法和计算方法需要"新颖"才能发布]
我是否误解了或者只是错过了重要的事情,或者这是对情况的一个很好的总结？鉴于我的情况,我是否有其他选项,我可能没有在这里提及/想到,例如,是否可以避免有关我的依赖项的许可证的问题？
参考文献:
如何判断我是否可以在商业应用中重复使用"免费"软件库？[关闭]
只要您不重新分发您的依赖项,与您为自己的项目选择的许可证相比,它们拥有的许可证并不重要.
是的,对于主流许可证的开源依赖性,这是真的.但:
如果要重新分发所有依赖项,那么项目许可证应与依赖项兼容.
是.但这通常不难.有什么地方可以找出哪些许可证与其他许可证兼容; 例如FSF的GPL页面.
[因此,我作为开发人员必须知道每个依赖项的许可证的详细信息??]
是.但是,您可以通过仅使用安全许可证的依赖项来简化此操作.(而且大多数开源许可证都是.)
GPL是最严格的开源许可证(来自常见的),因此如果我使用GPL许可下的库,我自己的项目也必须在GPL下...
是.但请注意,GPL和LGPL之间存在很大差异.LGPL没有这个限制.
......理论上可能与某些其他依赖的许可相矛盾.
理论上是的.实际上,GPL允许将库与大多数其他开源许可证一起使用.唯一的问题是如果其他图书馆的许可证需要GPL禁止的东西; 即为下游用户,包装商等提供额外条件
假设我的项目是在GPL下,项目是非商业的这一事实并不重要,它也必须是开源的.
那是正确的.
[这在我的情况下相当棘手,因为算法和计算方法需要"新颖"才能发布]
我认为你从一些根本不应成为问题的事情中解决了一个大问题:
如果您担心其他人在您发布之前窃取您的想法,请暂停分发您的代码,直到您发布为止.这是普通的常识......而不是许可问题.
如果算法和方法体现在您以前分发的软件中,我认为编辑/审稿人不会拒绝您的出版作品.您的出版物必须在出版媒体方面具有新颖性......
...是否可以避免有关我的依赖项许可证的问题？
您可以从头开始编写所有自己的代码,或雇用其他人为您完成.(不太现实)
您可以将商业软件用于所有依赖项,并支付重新分配的权利.
您可以联系您的依赖项的版权所有者,并协商替代许可协议.(假设它们是可联系的,并愿意进行谈判.)
但你不能忽视这个问题.
最重要的是,当您使用开源依赖项构建代码时,您可以免费获得一些东西,但是quid pro quo是您必须按规则进行游戏.如果您不喜欢这些规则,请找到一种不涉及开源的不同方式.
| 归档时间： |
|
| 查看次数： |
1028 次 |
| 最近记录： |