GPL开源协议的传染性问题
-
pyqt5的开源协议是GPL3，这使得我发现今年上半年开发的cyber-life和visual-file这两个项目的开源协议都选错了。
最开始我以为只有基于pyqt5做的衍生版本才必须使用GPL3，后来发现使用pyqt5作为依赖也算。
甚至发现在github上有2.7kstar的QuickCut用的pyqt5也没有用GPL3协议，感觉有点尴尬 -
是的GPL主要从自由软件角度设计的协议, 所以他限制基于他的软件(一般是代码层面, 二进制使用一般没什么问题)也要用GPL来保证衍生品代码的公开 其他方面都很自由包括拿去商业化 - 所以感觉GPL协议是更强调 代码公开 和 软件自由方面
而对于 QuickCut 没有使用GPL3协议, 其实更可能是 很多开源软件作者最初并没有特别研究协议关系所导致的情况。一般来说 在开源软件上 这方面现实操作是想对宽松的 - 但严格上来说是应该用GPL3
-
@Littlefean 在 GPL开源协议的传染性问题 中说：
最开始我以为只有基于pyqt5做的衍生版本才必须使用GPL3，后来发现使用pyqt5作为依赖也算
这方面典型的就是ffmpeg。很多软件不直接使用ffmpeg的代码 而是 把自己的软件和ffmpeg进行隔离, 然后通过 二进制命令行 的形式来调用ffmpeg的功能
-
感觉协议选错还有点风险，想到一个问题，假如A做了一个基于GPL3开源的工具库，B依赖这个工具库做了一个软件，但协议选了个MIT协议，然后C看到B做的软件是MIT协议，直接做了个衍生版本然后闭源收费了。A发现了C的行为，这个责任会是B的责任吗
-
@Littlefean 在 GPL开源协议的传染性问题 中说：
A发现了C的行为，这个责任会是B的责任吗
问了下AI，AI回答是B是主要责任，C是次要责任。
在这种情况下，B 承担主要责任，因为他没有正确地遵守上游许可证（GPLv3）的要求。同时，C 在不知情的情况下可能也违反了许可证，但如果 C 是基于对 B 的 MIT 许可声明的信任而行事，则 C 的责任相对较小。不过，这并不意味着 C 完全免责，特别是在 C 已经意识到或应当意识到软件中包含 GPL 许可组件的情况下。
为了防止此类问题的发生，开发者在使用第三方库时应仔细审查其许可证，并确保自己的软件发布符合所有相关许可证的要求。 -
@Littlefean 这可能就是一个复杂的问题了, 虽然B是主要责任。但在这种情况发生时 可能 C 承担的成本更大一些。因为如果B本身就是开源的话 可能最多需要更换正确协议就可以了。 但C可能要决策是否要公开代码 进行 替换。所以一般大一点的公司对外的软件都有 合规团队进行审核的
-
@sunrisepeak 了解了
-
@Littlefean 个人感觉开源软件中 一般把代码公开的情况下, 遇到大问题的概率比较小。且多数情况下 现实对 这方面好像也是偏向“宽容”处理的。 往往 是否代码公开 是核心争议点
-
@sunrisepeak 在 GPL开源协议的传染性问题 中说：
把自己的软件和ffmpeg进行隔离, 然后通过 二进制命令行 的形式来调用ffmpeg的功能
类似于这样，可以避免传染性对吧
ffmpeg -f lavfi -i color=c=black:s=1280x720:d=10 output.gif -
@sunrisepeak 在 GPL开源协议的传染性问题 中说：
个人感觉开源软件中 一般把代码公开的情况下, 遇到大问题的概率比较小。且多数情况下 现实对 这方面好像也是偏向“宽容”处理的。 往往 是否代码公开 是核心争议点
确实
