您如何看待开源和开源协议？

@HikariLan 这里的盈利加了一个“私自”，我的意思其实是通过将原项目包装后再分发的这种方式盈利，而没有将盈利的成果反馈到原项目上。
@cmdOptionKana GPL 协议要求分叉出去的更改最终都要回到原项目里。比如 Linux 就是典型，别的公司分叉出去的对 Linux 代码进行的改动，不仅需要开源，最终还需要反向移植合并到原项目里。因此实现的新特性最终不会变成“XX 公司 Linux 内核新特性”，而是直接作为“Linux 内核 x.x 版本新特性”来宣传和发布的，于是这个名声和成果都是直接在 Linux 项目头上的，而不是在那个实现特性的公司上的。但是实现特性的公司当然也可以因为“我帮 Linux 实现了 xx 特性”而间接获得所谓的名声。

@cmdOptionKana #25
用 GPL 是出于对商业公司的不信任，我不知道它会不会回来贡献代码。fork 一个私有库，修改后的代码不给上游，对于利益导向的公司来说，是很正常的事情，我希望有更多人从我的代码中收益，而不是给商业公司打白工。

如果有人给我的 GPL 项目贡献代码，这个项目的版权是我和贡献者共同所有。如果觉得这样名声还是我的，大可以另外开一个项目自己维护，定期拉我的代码过去我也没意见。

@hez2010 没什么不同，将原项目原封不动的以盈利方式分发也是被 GPL 允许的，这没什么问题。
GPL 协议分发的项目分叉不一定必须要回到原项目，你只需要公开分叉即可（并且这一行为还是在您「向公众发布」项目的前提下才需要做的，您自己私用修改是不需要公开的」

有些代码我感觉写得不错，分享出来，有人用到我会很高兴，"看，你用的 xx 里有我的代码"。
所以我想稍微少一些限制，自己的开源项目基本都是 MIT ，代码片段是 Unlicense 。
我个人对 GPL 稍微有点偏见。

自由生於的 70 年代，它有它的代大背景。它跟在那些著名的後代主左翼激思潮之後，嬉皮士、Mai 68 、民、女主，一同放。
但是到了今天、所有些激思潮都已被劫的今天，自由也跟它的姊妹一同，早就成建制的一部分了。可以些都一同成功，也一同失了。成功在於它是如此泛地被接受和用，失在於的信今天已失去了它的解放性。
在大部分的自由代，都是由巨的。巨向我明：任何挑他地位的都是徒的，要被，要被吸收。
今天我需要重新思考自由知、自由一命，甚至是重新思考自由命。

利己、利他、双赢 双赢是不容易的
成功的商业项目在大众脑内留下印象
成功的开源项目通常只会在程序员脑内留下印象 除非加上商业推广
以上三项是选题 如果你不担心被白嫖利他与双赢可勾选 担心白嫖利己与双赢可勾选 当然还可以细分

@cmdOptionKana 饭圈也是"正当途径", 所以你举 NBA 的例子 -- 怎么说呢 -- 感觉是为我做佐证

@cmdOptionKana 本来也不想回复的, 但是看到 NBA , 我突然有一万个地狱笑话想讲

https://www.google.com/search?q=饭圈+nba

想了想还是算了, 言归正传, 饭圈对创作的危害有目共睹, 不过至少今天, 它是简单, 高效, 被官方认证的 "正当途径"

GNU：“开源”错失了自由软件的重点

@hez2010 #23 你可以卖你修改过的 GPL 软件，没有问题的哦

尽量远离 GPL ，指不定你的代码一不小心就被污染

@dingwen07 只能卖服务，GPL 不允许纯卖代码

如何远离 GPL? 服务器用 bsd 吗?

支持开源，软件使用者更放心一点，但开源绝对不是免费、自由的。
协议方面，除了 GPL 要慎重选择，其他协议大同小异。

自由软件的目的是保证用户在软件上的自由，包括能够修改或找人修改软件的代码。这背后的逻辑是用户是软件的所有者，对他的持有品有最大的权利，符合私有财产神圣不可侵犯这一原则。

挟代码自重的程序员认为自己写的代码只是自己的所有物，讨厌保障用户自由的 GPL 很正常。

很多人对 GPL 有误解
服务端可以用 GPL 的同时不开源
要求服务也开源的是 AGPL

公司层面评估，一般就是 MIT 为主，apache license 2.0 为辅。

个人用的话也是 MIT 。

但是最讨厌国内说开源开了个半拉子，还觉着很牛逼的项目！

@shyangs GPL 允许盈利，但由于有传染性，想拿来盈利的人就不太乐意使用 GPL 代码。

@LindsayZhou 这点我前面说过了，重点在于我开源出来的代码是否具有较强的 “不可替代性”，如果有，用 GPL 确实很好，如果没有，商业公司直接找个替代品就行，那我就相当于闭关锁国而已。

@L4Linux 不对吧？ GPL 允许用户修改代码，MIT 也允许用户修改代码，MIT 没有保障用户的自由吗？也保障了呀。用 MIT 许可的程序员是 “挟代码自重的程序员”？我很难理解这个说法。

@cmdOptionKana #46 越说越暴露你对自由软件理解之肤浅。

我没说用 MIT 许可证分发的软件不是自由软件。

挟代码自重的程序员不就是自己改了代码不情愿发布出来吗？不然有什么理由排斥 GPL ？不情愿发布出来还是出于自己写的软件是自己的而不是用户的这种思想，其实和 DRM 是共通的。

@hez2010 #22 你对 GPL 的理解是错误的。首先 GPL 允许盈利。其次 GPL 的名声属于每个贡献者而非原始组织者。再次 GPL 协议项目的社区集中是因为社区管理成本的而非 GPL ，原始社区摆烂后另起社区，或者新旧两个社区和解后再次合并，在开源界是经常发生的事。

GPL 最大的问题是，哪怕只有 0.0001%的部分不适合公开，整体上都没法参与 GPL 了。别得东西都是抛开剂量谈毒性是耍流氓，到 GPL 这就成了只看毒性不看剂量，这就导致 GPL 没法通用。

你对 MIT 的理解也是错误的。MIT 协议的核心不是放弃权力，而是避免被甩锅代码你想咋用就咋用，但是出了问题别找我。举个例子来说，门口种的可能有毒蘑菇，别人偷吃了你要担责，但你要是树了个 MIT 的牌子，那就不能找你的事。这种甩手掌柜的态度，怎么可能还会有让社区贡献代码的想法，使用 MIT 协议的软件往往连社区都没有。

@nothingistrue 然而你对 GPL 的理解也是错的。GPL 也是 no warranty 的，这在协议中写的很清楚，同样有避免被甩锅的属性。

开源协议的区别向来不在是否甩锅和担责上，因为大多数开源协议都是 no warranty 的，包括 GPL 和 MIT 都是如此，意味着都是没有保证的，出了问题也不能甩锅回去。而项目是否有保证则是由项目作者或者背后的公司单独承诺的，例如有的项目尽管使用了 MIT 或者 GPL 协议，但是其背后的公司有额外的免费或收费支持方案。
至于 GPL 和 MIT 最明显的区别，在于 GPL 自身的传染性将项目用途限制在了开源中，而 MIT 就无此限制。部分开发闭源产品的商业公司甚至不允许员工查看 GPL 代码，否则难以证明员工给公司编写的代码中不包含 GPL 代码。
这也是为什么说 GPL 是一种商业不友好的协议。
举两个例子：
1. Google 开发安卓做的第一件事就是在内核之上编写一套 Apache 协议开源的 HAL ，将 GPL 协议的 Linux 内核彻底和安卓的驱动模型隔离开，使得其他厂商都能无需接触 Linux 内核而只对 HAL 来进行驱动开发，因此不会对自己的驱动代码造成污染，也不需要开源自己的驱动代码，开源的部分只有 Google 做的 HAL 就够了。
2. Microsoft 的 WSL2 有着优秀的 GPU 支持，同样也是利用 WDDM 将 Linux 内核和驱动模型隔离开，各厂商只需要面向 WDDM 提供支持 D3D12 的驱动就能用在 WSL2 中进行硬件加速，而无需开源自己的驱动代码，开源的部分只需要是 Microsoft 的 Linux D3D12 用户态驱动。
可以看到无论是安卓还是 WSL2 ，各厂商都积极进行了跟进（ WSL2 更是在 GPU 加速预览版发布当天 Intel 、AMD 、NVIDIA 就直接推出了自己用于 WSL2 的 GPU 加速驱动）。而安卓也好，WSL2 也罢，这些图形上的生态没有一个反馈到了 Linux 自身上，大家都在用实际行动把 GPL 协议的 Linux 隔离开，确保自己的系统是商业友好的。

关于开源协议这块，我建议看下之前 faker.js 的例子，再结合实际情况考虑何种情况下选择什么协议。t/826515 。
尽管这个例子在某种程度上算是挺极端的，但是作为参考还是有价值的

这些协议都在法律里吗?
如果有些开源项目用了一个不允许商用, 不允许二次开发的协议, 但我偏偏就拿去二次开发还商用, 有啥关系不?

@TcDhl 这些协议都是标准的法律文件，可以当作法律依据。在中国，司法实践下这些协议被当作民事合同而有效。
如果你这么干了，那么版权人有权起诉您侵犯其著作权（只能亲告，所以事实上结果是跨国官司很难打，一般不会有人这么做，基本是一个君子协议）

@cmdOptionKana

GPL 类具有传染性的协议，确保了作者可以获取到使用者的修改的代码，并且在决定需要的时候可以使用这份修改。

MIT/BSD 这里协议没有这个要求，所以可能被"抄袭"逼死原作。
BSD 类系统不就是这样么？很多 BSD 系统 fork 没有动力回馈，例如群晖。

我有一份 GPL 协议的源码，它首先是解决了我的问题。其他人爱用不用。
但是如果用了并且修改了，请保证我能获取到修改。这是 GPL 的好处。

MIT 没有这个要求，只能挥舞道德的大棒了，之前有一个 MIT 协议的 AI 生产艺术话的项目被用于 NFT ，然后原作者只能靠道德大棒了。

@cmdOptionKana 从保护自己的利益的角度来说，GPL 其实更能保护自己的利益。你付出了付出了大量劳动做了一个 MIT 协议的项目，我可以直接拿来改改就用，但是不需要给你一分钱。甚至我可以做独家改进，也不需要反馈。
根据情况，我可以一直蹭你的劳动成果，或者想办法逼死你。这都符合 MIT 协议。

@hez2010 具体来说，是要公开你做的修改，是否合并到原项目，是原项目作者决定的。现在也有一堆没有被合并也不大可能被合并的补丁不是么？

一个更加有趣的例子：
A 做了一个 MIT 项目的代码。B fork 之后修改了，修改的部分使用 GPL 协议，这是 MIT 协议允许的。

@tanek

如果选择 GPL ，收获名气的难度较大，收获改进代码反馈的也未必多。因为名气小，使用者少，参与改进的人也少。唯一的优点是，一旦有人使用且改进，就一定能获得反馈。

这里要注意的是，GPL 只能确保别人有改进时会反馈，却不能确保提高反馈数量，因为所馈数量还与使用者的多少有关，而 GPL 恰恰会减少使用者。

而如果选择 MIT ，收获名气相对容易一些，使用者多，参与改进的人也随之增多，但别人改进了不一定反馈回来。

总结：改进代码的反馈的多少，GPL 与 MIT 打成平手；名气方面 MIT 更优。

@cmdOptionKana

作系 Linux
KVM 、VirtualBox 、QEMU
密管理器 Bitwarden 、KeePass


就算一般程序都做的了的密管理器，MIT 加上 BSD 都打不以 GPL 授的 Bitwarden 、KeePass 的名吧.

MIT 收名容易你需要出明.

@shyangs 我能想到的只有 iOS 应用这种明确不允许 GPL 协议的地方了。

@shyangs
@tanek

一份统计了 4 百万开源项目的统计结果：用 GPL 协议的占约 25%, 用 MIT 的占约 30%, MIT+Apache 占约 65%
https://www.mend.io/resources/blog/open-source-licenses-trends-and-predictions/

其中 GPL 还呈逐年下降趋势。

如果说 GPL 既能确保作者权利，获得更多反馈，又能获得更多名气，那大家为什么不爱用呢？看这个数据，GPL 总有什么缺点吧？

我认为 GPL 不利于获得名气，这能解释上述数据，你们如果不同意，是不是也应该提供一种对上述数据的解读？

@cmdOptionKana 商用领域不爱用呗，特别是 iOS 相关的，是不允许在上架 APP 上使用。这个趋势对应着这些年移动端的发展。

卑鄙是卑鄙者的通行证，高尚是高尚者的墓志铭。

开源和闭源都有各自的优缺点，但对于大部分互联网项目来说，用开源软件可以减少购买软件成本，以及方便自己改 bug 、加功能、优化性能等，更加自主可控。
开源协议一般推荐 MIT 和 Apache ，对商业友好

@HikariLan #53
好的谢谢

取决于想用什么 。
另外分享一个真实的案例
https://github.com/FBlackBox/BlackBox/issues/126
或者 https://mp.weixin.qq.com/s/0Az43fwaH_DWaK5jAhGQ1Q