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

[HikariLan]

昨天发了一个 花两天总结了市面上主流开源许可证的区别，希望能给点建议，看评论区感觉大家对开源以及开源许可证有各种不同的理解，遂重新开贴询问诸位的想法：

• 您如何看待开源，对您来说，不开源是可以接受的吗
• Copyleft 许可证（例如 GPL ）和宽松许可证（ MIT ）您更愿意使用哪个
• 您是否接受 GPL 「以限制为代价为所有人群获得最大的自由」的观念

[yazinnnn]

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

[hoopan]

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

[L4Linux]

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

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

[sunwei0325]

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

[lsyAndroid]

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

个人用的话也是 MIT 。

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

[cmdOptionKana]

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

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

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

[L4Linux]

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

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

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

[nothingistrue]

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

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

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

[hez2010]

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

[hez2010]

开源协议的区别向来不在是否甩锅和担责上，因为大多数开源协议都是 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 隔离开，确保自己的系统是商业友好的。

[07ly]

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

[TcDhl]

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

[HikariLan]

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

[tanek]

@cmdOptionKana

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

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

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

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

[tanek]

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

[tanek]

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

[tanek]

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

[cmdOptionKana]

@tanek

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

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

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

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

[shyangs]

@cmdOptionKana

作業系統 Linux
虛擬機 KVM 、VirtualBox 、QEMU
密碼管理器 Bitwarden 、KeePass


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

MIT 收穫名氣容易你需要給出證明.

[tanek]

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