D2Learn Forums

刚刚上面的图表述有点不清晰，改进一下表述：

OR框可以用虚线框表示

引入AND框和OR框的概念感觉清晰一些

感觉情况有点复杂了

还没细看他们的争论评论具体内容，第一直觉上感觉项目命名结尾加后缀的方式，让原作者感觉自己被蹭热度了？

我猜测可能这个耻辱柱的作法能在一定程度上保护开源劳动成果，但可能会产生纠纷，比如如果一个个人模仿ffmpeg也做了个网页页面，然后他的开源项目被一个公司拿去做产品并违反对应的开源协议了，这个个人如果把这个公司名字写进入耻辱柱界面，可能反而网页会被公司里的人举报或者认为是敲诈。

如果转变思维，反过来，把耻辱柱写成“友好合作柱”，给所有经过手动授权（MIT协议需要手动授权）的合作者写到一个页面里，这样别人浏览的时候还能为对方提高一点点知名度。这样可能一种更好的方式

确实，看到有人说过源代码里还能看到

ffmpeg对违反开源协议的行为作法是做了一个耻辱柱，但现在好像这个界面不知道为什么关闭了。如果开发者个人模仿ffmpeg的方法做耻辱柱是不是会有风险

刚刚又瞬间想到：上面一楼的内容我本是想记录在自己的个人备忘录或者“idea集”中的，不对外公开的。现在我把这个论坛地方也当成一种专门记录与开源问题相关信息的地方，从某种意义上来说也算一种开源。把“idea公开”。这样和上面的一楼内容对照来看，idea公开本身就能够让它被看见，有被“生长”和“优化”的可能。
（临时快速记录，可能表述比较仓促）

刚刚瞬间想到，开源的一个好处是：对于需求很小很窄的小项目开源出来，实现自己个人的核心需求之后，别人看到的可能对他来说是他的次要需求，他可能会有想继续完善添加对方的核心需求的想法，因此这样一个项目会逐渐“自发性”的“生长”起来。

只是先做个记录，以后突然又想到什么了再来继续填。

@sunrisepeak 在 开源协议总结 中说：

CC和OSI感觉最主要的冲突点应该是 "是否能商用自由"

确实，NC直接禁止商用了。CC系列感觉范围主要是一些创意作品而非软件了。感觉有人往github上发自己创作的一些“开源文章”可能有用吧。

@sunrisepeak 在 开源协议总结 中说：

CC协议是可以组合的

确实，BY NC SA ND四个属性各种组合挺多的

放一张总结的更完善的开源协议选择路径图。

@sunrisepeak 在 GPL开源协议的传染性问题 中说：

个人感觉开源软件中 一般把代码公开的情况下, 遇到大问题的概率比较小。且多数情况下 现实对 这方面好像也是偏向“宽容”处理的。 往往 是否代码公开 是核心争议点

确实

@sunrisepeak 在 GPL开源协议的传染性问题 中说：

把自己的软件和ffmpeg进行隔离, 然后通过 二进制命令行 的形式来调用ffmpeg的功能

类似于这样，可以避免传染性对吧

ffmpeg -f lavfi -i color=c=black:s=1280x720:d=10 output.gif

@sunrisepeak 了解了

@Littlefean 在 GPL开源协议的传染性问题 中说：

A发现了C的行为，这个责任会是B的责任吗

问了下AI，AI回答是B是主要责任，C是次要责任。

在这种情况下，B 承担主要责任，因为他没有正确地遵守上游许可证（GPLv3）的要求。同时，C 在不知情的情况下可能也违反了许可证，但如果 C 是基于对 B 的 MIT 许可声明的信任而行事，则 C 的责任相对较小。不过，这并不意味着 C 完全免责，特别是在 C 已经意识到或应当意识到软件中包含 GPL 许可组件的情况下。
为了防止此类问题的发生，开发者在使用第三方库时应仔细审查其许可证，并确保自己的软件发布符合所有相关许可证的要求。

问题已解决

感觉协议选错还有点风险，想到一个问题，假如A做了一个基于GPL3开源的工具库，B依赖这个工具库做了一个软件，但协议选了个MIT协议，然后C看到B做的软件是MIT协议，直接做了个衍生版本然后闭源收费了。A发现了C的行为，这个责任会是B的责任吗