这是一个创建于 804 天前的主题，其中的信息可能已经有所发展或是发生改变。
昨天发了一个 花两天总结了市面上主流开源许可证的区别，希望能给点建议，看评论区感觉大家对开源以及开源许可证有各种不同的理解，遂重新开贴询问诸位的想法：
- 您如何看待开源，对您来说，不开源是可以接受的吗
- Copyleft 许可证（例如 GPL ）和宽松许可证（ MIT ）您更愿意使用哪个
- 您是否接受 GPL 「以限制为代价为所有人群获得最大的自由」的观念
 |
1
ysc3839 2022-08-29 12:32:18 +08:00 via Android
建议使用“开放源代码”而不是“开源”，中文语境下的“开源”已经变成了“公开源代码”了，只要源代码公开，即使使用限制多么严格的许可协议都能被称作开源。
|
 |
2
HikariLan OP @ysc3839 同意您的想法，但是这篇主题旨在探讨和了解人们对开源的看法，即使是片面的「仅公开源代码」也是一种观点，因此就不作细化了
|
 |
3
yazinnnn 2022-08-29 14:13:02 +08:00
我是自由软件拥趸, 对开源软件没有任何看法
|
 |
4
Kasumi20 2022-08-29 14:17:31 +08:00
我比较喜欢 WTF 协议
|
 |
5
thinkershare 2022-08-29 15:01:46 +08:00
总是尽量使用 MIT 协议的开源软件, 公司用第三方库的时候会评估是不是这个.
|
 |
6
tanek 2022-08-29 16:30:59 +08:00
我和楼上相反，尽可能使用 GNU 协议而不是 MIT 协议的软件。
MIT 协议是一个让强者更强弱者更弱的协议。 |
 |
7
ltkun 2022-08-29 16:45:26 +08:00 via Android
FOSS 坚决拥护者 能开源软件就绝不闭源商业软件 现在还有两大方面不能替代 微信和办公软件 wps 其他基本都可以 包括手机 os 可以用 lineageos 或者 ubuntu touch 桌面 Linux 电视盒 coreelec 常见 app 都去 fdroid 去下载 诸如 Windows MacOS iOS 之流这种对我来说就是毒瘤能离多远就多远
|
 |
8
placeholder 2022-08-29 16:54:53 +08:00
1 、不开源但是你永远免费给我用全部的现有功能和将来会添加的新功能，我就能接受
2 、如果只能二选一，那我永远都选择约束更少的 3 、不接受，你要限制限制别人去，莫挨老子 ---------- 另外就是 GPL 那个限制是限制了一些什么玩意儿？ |
 |
9
msg7086 2022-08-29 16:59:39 +08:00
我自己的业余项目大多 MIT/BSD 开源了。
对我来说，有的项目是商业化的，要赚钱要吃饭的，这些软件我支持专有、收费。有些项目是个人兴趣爱好，这些软件我支持开源。 |
 |
10
libook 2022-08-29 17:00:06 +08:00
1. 开源和开放是两码事，有很多商业公司驱动的项目开源但不开放，也有明面上开放实际上闭锁的项目（每次聊到这个我都会点名 Google ），主要还是看社区的精神和氛围。选软件一般不看是否开源，主要还是看软件品质，只不过一些场景下开源软件做得比较良心，比如通常不会捆绑乱七八糟的广告。
2. 自己的项目的话，根据项目情况来选，如果功利性一些就选非 Copyleft 的，如果使用场景比较适合且希望持续发展下去可以选 Copyleft 的。我用得比较多的是 MPL-2 和 WTFPL(或 WTFNMFPL)。 3. 同上，看项目情况，如果与应用场景不兼容会导致项目难以推广，特别是希望让企业来贡献开源社区的话，适当让步使其能保留一部分知识产权可以让企业和开源社区双赢，比如一些硬件厂商和 Linux 生态的合作。 针对 MIT 稍微多说一句，很多人在项目里署自己名字用 MIT 协议，可能并没有深思熟虑，甚至都没有正确使用，给我的感觉基本就是： 1. 我对项目本身、用户、贡献者都不想负任何责任，你们看着办； 2. 提前说一句未来版权也都属于我自己，如果还愿意贡献的话我不拦着。 |
|
11
HikariLan OP @placeholder 您或许可以看看我写的那篇文章，里头有一些描述。但是简单来说，就是通过要求使用者也必须遵循 GPL 要求，并在修改公开时开源
|
 |
12
liuidetmks 2022-08-29 17:08:25 +08:00  1
除了 GPL ，其他协议的都是商业公司从开源攫取利益的工具而已。
|
 |
13
cmdOptionKana 2022-08-29 17:41:19 +08:00
@tanek 为什么说 MIT 协议是一个让强者更强弱者更弱的协议？
总假设：大家都尊重协议的法律效力。 A. 假设一个“弱者”使用 MIT 协议，那么别人用他的代码，会带上作者信息，他至少能获得名气。 B. 假设一个“弱者”使用 GNU 协议，别人为了避免 GNU 的传染性，会不乐意用他的代码，另外找替代品，弱者有啥好处，啥都没有啊。 |
|
14
cmdOptionKana 2022-08-29 17:42:08 +08:00
GNU 改为 GPL
|
|
15
HikariLan OP @cmdOptionKana 个人是这么想的，也欢迎讨论：因为任何人可以将使用 MIT 协议分发的软件源代码用于专有用途，接下来，这些人（公司）将会使用这些代码闭门造车，可能发明出了更好的东西，但是这些东西是外界所无法获得的。
而 GPL 协议分发的软件，这些公司经过修改并发布时必须包含修改版源代码，这时，所有人都可以从这些修改中受益 |
|
16
cmdOptionKana 2022-08-29 17:57:58 +08:00
@HikariLan 分两种情况，一是普通开发者，做出来的东西容易被找到替代方案，此时用 GPL 只能阻挡自己发展，别人直接找替代品就行，根本不用你的代码。
另一种情况是高人，做出来的东西比较难找替代方案，此时用 GPL 才能有效果。 我前面默认了第一种情况，没有考虑第二种情况，因为高人毕竟是少数，尤其是能写出“难找替代方案”同时又不想做成闭源赚钱的高人，就更少了。 |
|
17
HikariLan OP @cmdOptionKana 是这个理了
|
 |
18
cyp0633 2022-08-29 18:29:27 +08:00
1. 目前来说个人的项目几乎一定会开源，虽然写得很烂；用的话在可接受的水平下优先选择开源项目
2. 更愿意使用 MIT 3. 开不开源才是个人的自由吧 另外我好像在 Comin 里看到过 OP ？ |
 |
20
lanlanye 2022-08-29 19:54:04 +08:00 via iPhone
1. 可以接受，主要是因为我也改变不了什么
2. 当我想要在社区中主张自己的权利时，我会选择 GPL ，一般用于一些对生产有直接帮助的项目；简单项目或可能为他人学习提供帮助的内容使用 MIT 3. 接受，不如说相当喜欢 |
 |
21
nightwitch 2022-08-29 21:13:04 +08:00 via Android
我一般用 wtfpl
|
 |
22
cnbatch 2022-08-29 21:28:42 +08:00 via Android
由于我个人并不靠制作开源软件来吃饭，所以都是怎样宽松怎样来，原则就是“不要来打扰我”：
其他人用不用我的代码，我无所谓。 其他人如何使用我的代码、拿去干嘛，我不想知道。 fork 了我的代码改东改西然后 push 回来却发现有一大堆冲突行需要梳理，烦！ 进而发现对方把许可证改得更严格了，对我问东问西，烦！ 我不愿意限制他人如何使用我的代码，正如同不愿意被别人限制一样。不过，如果有办法对付“我就是要限制你”，那么我还是很乐意使用这类办法的。 |
 |
23
hez2010 2022-08-29 21:30:15 +08:00 via Android
使用 GPL：我希望社区来给我贡献代码，但是我不希望别人借着我的代码和成果私自盈利，所有的名声和成果都应该集中在我的项目上。
使用 MIT：我希望社区来给我贡献代码，并且我选择放弃权利，允许任何人使用我的代码盈利，并且不限制任何人对我的代码进行修改和再分发。 从这一点看，当项目开发者需要利用开源协议来保护自己的项目的时候可以选择 GPL ，而项目开发者希望将自己的项目像做慈善一样向所有人无偿捐赠的时候可以选择 MIT 。 |
|
24
HikariLan OP @hez2010 这个观点是错误的...因为 GPL 是允许盈利的...如果 GPL 不允许盈利，那么它甚至称不上是“自由”得，只是分发手段有一些区别
|
|
25
cmdOptionKana 2022-08-29 21:42:47 +08:00
@hez2010
> 使用 GPL：我希望社区来给我贡献代码，但是我不希望别人借着我的代码和成果私自盈利，所有的名声和成果都应该集中在我的项目上。 这里有一个问题，如果 “所有的名声和成果都应该集中在我的项目上”，那别人为什么要给你贡献代码？为什么要给你名声？你不想做慈善，别人也不会无条件给你做贡献吧。 反而 MIT 更能互惠互利，原创作者付出了代码，别人可以拿去盈利，然后别人才会回来给你贡献代码、给你名声。 |
 |
26
aguesuka 2022-08-29 23:12:22 +08:00
出于鼓励创作的目的会陷入八奇领域, 开源精神的目的本身就是自由和开放. 如果有外星人, 发现人来写代码或者创作是为了虚名或者利益, 一定会感叹这个社会真是低级.
|
 |
27
shyangs 2022-08-29 23:19:22 +08:00
|
|
28
cmdOptionKana 2022-08-29 23:26:16 +08:00
@aguesuka 在这个主题下我回复得有点多了，但我实在忍不住，为名为利怎么就低级了？外星人的思想一定没有这么偏执和狭隘。
不择手段追求名利才是低级的。但以正当途径、付出了大量劳动、给别人带来了好处，希望收获名利有什么问题，为什么低级？ 举个例子，一个 NBA 球员想拿总冠军的名誉，想拿高年薪，他拼命训练，克服很多困难，把球打得精彩，这样追求名利有什么低级？明明很高级，也能得到全球各地非常多人的尊敬。 追求自由和开放很好，追求名利也很好，只要堂堂正正没有伤害别人，任何目的都应该是平等的。 |
|
29
hez2010 2022-08-29 23:53:46 +08:00
@HikariLan 这里的盈利加了一个“私自”，我的意思其实是通过将原项目包装后再分发的这种方式盈利，而没有将盈利的成果反馈到原项目上。
@cmdOptionKana GPL 协议要求分叉出去的更改最终都要回到原项目里。比如 Linux 就是典型，别的公司分叉出去的对 Linux 代码进行的改动，不仅需要开源，最终还需要反向移植合并到原项目里。因此实现的新特性最终不会变成“XX 公司 Linux 内核新特性”，而是直接作为“Linux 内核 x.x 版本新特性”来宣传和发布的，于是这个名声和成果都是直接在 Linux 项目头上的，而不是在那个实现特性的公司上的。但是实现特性的公司当然也可以因为“我帮 Linux 实现了 xx 特性”而间接获得所谓的名声。 |
 |
30
LindsayZhou 2022-08-30 00:00:25 +08:00
@cmdOptionKana #25
用 GPL 是出于对商业公司的不信任，我不知道它会不会回来贡献代码。fork 一个私有库，修改后的代码不给上游，对于利益导向的公司来说，是很正常的事情，我希望有更多人从我的代码中收益，而不是给商业公司打白工。 如果有人给我的 GPL 项目贡献代码，这个项目的版权是我和贡献者共同所有。如果觉得这样名声还是我的，大可以另外开一个项目自己维护，定期拉我的代码过去我也没意见。 |
|
31
HikariLan OP @hez2010 没什么不同，将原项目原封不动的以盈利方式分发也是被 GPL 允许的，这没什么问题。
GPL 协议分发的项目分叉不一定必须要回到原项目，你只需要公开分叉即可（并且这一行为还是在您「向公众发布」项目的前提下才需要做的，您自己私用修改是不需要公开的」 |
 |
32
icyalala 2022-08-30 00:23:10 +08:00
有些代码我感觉写得不错，分享出来，有人用到我会很高兴，"看，你用的 xx 里有我的代码"。
所以我想稍微少一些限制，自己的开源项目基本都是 MIT ，代码片段是 Unlicense 。 我个人对 GPL 稍微有点偏见。 |
 |
33
shihira 2022-08-30 00:28:28 +08:00 1
自由軟體運動誕生於的 70 年代，它有它的時代大背景。它跟在那些著名的後現代主義左翼激進思潮之後，嬉皮士運動、Mai 68 、民權運動、女權主義運動，一同綻放。
但是到了今天、所有這些激進思潮都已經被騎劫的今天，自由軟體運動也跟它的姊妹運動一同，早就成為建制的一部分了。可以說這些運動都一同成功，也一同失敗了。成功在於它是如此廣泛地被接受和應用，失敗在於舊的信條今天已經失去了它的解放性。 現在絕大部分的自由軟體代碼，都是由巨頭們貢獻的。巨頭向我們證明：任何挑戰他們地位的嘗試都是徒勞的，要麼被擊潰，要麼被吸收。 今天我們需要重新思考自由知識產權、自由軟體這一命題，甚至是重新思考自由這個命題。 |
 |
34
james122333 2022-08-30 01:05:22 +08:00 via Android
利己、利他、双赢 双赢是不容易的
成功的商业项目在大众脑内留下印象 成功的开源项目通常只会在程序员脑内留下印象 除非加上商业推广 以上三项是複选题 如果你不担心被白嫖利他与双赢可勾选 担心白嫖利己与双赢可勾选 当然还可以细分 |
|
35
aguesuka 2022-08-30 01:19:30 +08:00
@cmdOptionKana 饭圈也是"正当途径", 所以你举 NBA 的例子 -- 怎么说呢 -- 感觉是为我做佐证
|
|
36
aguesuka 2022-08-30 01:38:54 +08:00
@cmdOptionKana 本来也不想回复的, 但是看到 NBA , 我突然有一万个地狱笑话想讲
https://www.google.com/search?q=饭圈+nba 想了想还是算了, 言归正传, 饭圈对创作的危害有目共睹, 不过至少今天, 它是简单, 高效, 被官方认证的 "正当途径" |
 |
37
dingwen07 2022-08-30 01:49:09 +08:00 via iPhone
GNU：“开源”错失了自由软件的重点
|
 |
39
ly841000 2022-08-30 08:25:21 +08:00
尽量远离 GPL ，指不定你的代码一不小心就被污染
|
|
41
yazinnnn 2022-08-30 08:59:11 +08:00
如何远离 GPL? 服务器用 bsd 吗?
|
 |
42
hoopan 2022-08-30 09:01:18 +08:00
支持开源，软件使用者更放心一点，但开源绝对不是免费、自由的。
协议方面，除了 GPL 要慎重选择，其他协议大同小异。 |
 |
43
L4Linux 2022-08-30 09:03:28 +08:00 via Android
自由软件的目的是保证用户在软件上的自由，包括能够修改或找人修改软件的代码。这背后的逻辑是用户是软件的所有者，对他的持有品有最大的权利，符合私有财产神圣不可侵犯这一原则。
挟代码自重的程序员认为自己写的代码只是自己的所有物，讨厌保障用户自由的 GPL 很正常。 |
 |
44
sunwei0325 2022-08-30 09:27:34 +08:00
很多人对 GPL 有误解
服务端可以用 GPL 的同时不开源 要求服务也开源的是 AGPL |
 |
45
lsyAndroid 2022-08-30 09:42:58 +08:00
公司层面评估，一般就是 MIT 为主，apache license 2.0 为辅。
个人用的话也是 MIT 。 但是最讨厌国内说开源开了个半拉子，还觉着很牛逼的项目！ |
|
46
cmdOptionKana 2022-08-30 10:47:54 +08:00
@shyangs GPL 允许盈利，但由于有传染性，想拿来盈利的人就不太乐意使用 GPL 代码。
@LindsayZhou 这点我前面说过了，重点在于我开源出来的代码是否具有较强的 “不可替代性”，如果有，用 GPL 确实很好，如果没有，商业公司直接找个替代品就行，那我就相当于闭关锁国而已。 @L4Linux 不对吧？ GPL 允许用户修改代码，MIT 也允许用户修改代码，MIT 没有保障用户的自由吗？也保障了呀。用 MIT 许可的程序员是 “挟代码自重的程序员”？我很难理解这个说法。 |
|
47
L4Linux 2022-08-30 12:22:52 +08:00
@cmdOptionKana #46 越说越暴露你对自由软件理解之肤浅。
我没说用 MIT 许可证分发的软件不是自由软件。 挟代码自重的程序员不就是自己改了代码不情愿发布出来吗？不然有什么理由排斥 GPL ？不情愿发布出来还是出于自己写的软件是自己的而不是用户的这种思想，其实和 DRM 是共通的。 |
 |
48
nothingistrue 2022-08-30 16:40:23 +08:00
@hez2010 #22 你对 GPL 的理解是错误的。首先 GPL 允许盈利。其次 GPL 的名声属于每个贡献者而非原始组织者。再次 GPL 协议项目的社区集中是因为社区管理成本的而非 GPL ，原始社区摆烂后另起社区，或者新旧两个社区和解后再次合并，在开源界是经常发生的事。
GPL 最大的问题是，哪怕只有 0.0001%的部分不适合公开，整体上都没法参与 GPL 了。别得东西都是抛开剂量谈毒性是耍流氓，到 GPL 这就成了只看毒性不看剂量，这就导致 GPL 没法通用。 你对 MIT 的理解也是错误的。MIT 协议的核心不是放弃权力，而是避免被甩锅——代码你想咋用就咋用，但是出了问题别找我。举个例子来说，门口种的可能有毒蘑菇，别人偷吃了你要担责，但你要是树了个 MIT 的牌子，那就不能找你的事。这种甩手掌柜的态度，怎么可能还会有让社区贡献代码的想法，使用 MIT 协议的软件往往连社区都没有。 |
|
49
hez2010 2022-08-30 19:21:20 +08:00 via Android
@nothingistrue 然而你对 GPL 的理解也是错的。GPL 也是 no warranty 的，这在协议中写的很清楚，同样有避免被甩锅的属性。
|
|
50
hez2010 2022-08-30 19:54:15 +08:00
开源协议的区别向来不在是否甩锅和担责上，因为大多数开源协议都是 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 隔离开，确保自己的系统是商业友好的。 |
 |
51
07ly 2022-08-31 09:09:46 +08:00
关于开源协议这块，我建议看下之前 faker.js 的例子，再结合实际情况考虑何种情况下选择什么协议。https://www.v2ex.com/t/826515 。
尽管这个例子在某种程度上算是挺极端的，但是作为参考还是有价值的 |
 |
52
TcDhl 2022-08-31 10:46:15 +08:00
这些协议都在法律里吗?
如果有些开源项目用了一个不允许商用, 不允许二次开发的协议, 但我偏偏就拿去二次开发还商用, 有啥关系不? |
|
53
HikariLan OP @TcDhl 这些协议都是标准的法律文件，可以当作法律依据。在中国，司法实践下这些协议被当作民事合同而有效。
如果你这么干了，那么版权人有权起诉您侵犯其著作权（只能亲告，所以事实上结果是跨国官司很难打，一般不会有人这么做，基本是一个君子协议） |
|
54
tanek 2022-08-31 11:48:02 +08:00
@cmdOptionKana
GPL 类具有传染性的协议，确保了作者可以获取到使用者的修改的代码，并且在决定需要的时候可以使用这份修改。 MIT/BSD 这里协议没有这个要求，所以可能被"抄袭"逼死原作。 BSD 类系统不就是这样么？很多 BSD 系统的 fork 没有动力回馈，例如群晖。 我有一份 GPL 协议的源码，它首先是解决了我的问题。其他人爱用不用。 但是如果用了并且修改了，请保证我能获取到修改。这是 GPL 的好处。 MIT 没有这个要求，只能挥舞道德的大棒了，之前有一个 MIT 协议的 AI 生产艺术话的项目被用于 NFT ，然后原作者只能靠道德大棒了。 |
|
55
tanek 2022-08-31 11:52:42 +08:00
@cmdOptionKana 从保护自己的利益的角度来说，GPL 其实更能保护自己的利益。你付出了付出了大量劳动做了一个 MIT 协议的项目，我可以直接拿来改改就用，但是不需要给你一分钱。甚至我可以做独家改进，也不需要反馈。
根据情况，我可以一直蹭你的劳动成果，或者想办法逼死你。这都符合 MIT 协议。 |
|
56
tanek 2022-08-31 11:54:54 +08:00
@hez2010 具体来说，是要公开你做的修改，是否合并到原项目，是原项目作者决定的。现在也有一堆没有被合并也不大可能被合并的补丁不是么？
|
|
57
tanek 2022-08-31 12:27:18 +08:00
一个更加有趣的例子：
A 做了一个 MIT 项目的代码。B fork 之后修改了，修改的部分使用 GPL 协议，这是 MIT 协议允许的。 |
|
58
cmdOptionKana 2022-08-31 12:35:43 +08:00
@tanek
如果选择 GPL ，收获名气的难度较大，收获改进代码反馈的也未必多。因为名气小，使用者少，参与改进的人也少。唯一的优点是，一旦有人使用且改进，就一定能获得反馈。 这里要注意的是，GPL 只能确保别人有改进时会反馈，却不能确保提高反馈数量，因为所馈数量还与使用者的多少有关，而 GPL 恰恰会减少使用者。 而如果选择 MIT ，收获名气相对容易一些，使用者多，参与改进的人也随之增多，但别人改进了不一定反馈回来。 总结：改进代码的反馈的多少，GPL 与 MIT 打成平手；名气方面 MIT 更优。 |
|
59
shyangs 2022-08-31 13:16:09 +08:00
@cmdOptionKana
作業系統 Linux 虛擬機 KVM 、VirtualBox 、QEMU 密碼管理器 Bitwarden 、KeePass 就算一般程序員都做的了的密碼管理器，MIT 加上 BSD 陣營都打不過以 GPL 授權的 Bitwarden 、KeePass 的名氣吧. MIT 收穫名氣容易你需要給出證明. |
|
61
tanek 2022-08-31 13:36:41 +08:00
|
|
62
cmdOptionKana 2022-08-31 13:38:53 +08:00
@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 不利于获得名气，这能解释上述数据，你们如果不同意，是不是也应该提供一种对上述数据的解读？ |
|
63
tanek 2022-08-31 14:32:29 +08:00
@cmdOptionKana 商用领域不爱用呗，特别是 iOS 相关的，是不允许在上架 APP 上使用。这个趋势对应着这些年移动端的发展。
|
 |
64
NPC666 2022-08-31 15:17:00 +08:00
卑鄙是卑鄙者的通行证，高尚是高尚者的墓志铭。
|
 |
65
NebulaGraph 2022-08-31 18:10:21 +08:00
开源和闭源都有各自的优缺点，但对于大部分互联网项目来说，用开源软件可以减少购买软件成本，以及方便自己改 bug 、加功能、优化性能等，更加自主可控。
开源协议一般推荐 MIT 和 Apache ，对商业友好 |
 |
67
vAvyummyICE 2022-09-03 16:59:37 +08:00 via Android
|
Select Language