看了这帖子 https://ex.noerr.eu.org/t/1148581#reply90 里项目下 issue 的评论有感而发
不要为了开源而开源，直接面向终端用户、有商业价值、打算商业化的库不应该用 MIT 协议。
理由 1：好的创意应该被保护，劳动应该获得回报
理由 2：使用 MIT 协议的好处是更容易获得社区贡献，但面向终端用户或者有商业价值的项目很难获得代码/文档贡献，大部分是 bug 反馈和功能建议这部分个人认为是各取所需作为社区贡献有点勉强
理由 3：有限开源也是开源，开放源代码+开放使用能够覆盖绝大部分使用场景，真有商业场景需要授权可以进行额外的免费/付费授权，选择权完全在自己
 |
1
maocat 2 天前
没错，这点 dify 做得很好，有限开源+限制二开，直接堵死二开商业化
|
 |
2
darksword21 2 天前
准备个 PakePlusPlus 🐶
|
 |
3
geebos OP PRO @darksword21 PakeUltra
 |
 |
4
DT27 2 天前
君子协议。
对于侵权的，你什么协议都没用。 就像新浪抄袭小鸡词典，法庭上满口胡话，被侵权的小鸡词典又能怎样呢。 |
 |
5
est 2 天前
MIT 还是太松弛了。
|
 |
6
AkinoKaedeChan 2 天前
其实首先是商标问题，商标没注册就基本上没法维权
|
 |
9
DiamondYuan 2 天前  1
|
 |
10
cmdOptionKana 2 天前 via Android
这不是新问题了，采用什么协议，如果你不是随手选择的话，稍稍了解一下都能找到一大堆网站给你解释各种协议的利弊，包括商业上的考虑，都早已有充分讨论。
|
 |
11
iOCZS 2 天前
己所不欲勿施于人
|
 |
12
iamqk 2 天前
名称权和代码的开源协议还是有区别的吧？
一、主流开源协议对“名称使用”的规定 开源协议 是否限制名称被商业使用？ 备注 MIT ❌ 不限制 协议不涉及商标和项目名称 Apache 2.0 ✅ 有明确限制 明确禁止使用原作者的名称、商标或项目名做“背书”或“宣传” GPL ❌ 不限制 仅关注代码的自由传播，不限制名称使用 MPL 、BSD ❌ 不限制 名称和商标需单独声明 方式 1：注册商标保护项目名称 方式 2：在 License 或 README 中明确名称限制 |
 |
13
SiLenceControL 2 天前
NASA 开放的 CEA 之类的代码，被某东大二次开发成了机密，不在某院某所还用不了呢
美名其曰，遥遥领先 |
|
14
maocat 2 天前
@SiLenceControL #13 这么机密的事被你知道了，遥遥领先
|
|
15
SiLenceControL 2 天前
@maocat #14 有没有可能我是当事人呢？
|
 |
16
imaple 1 天前
@SiLenceControL #13 航天系也这样吗
 |
|
17
SiLenceControL 1 天前 1
|
 |
18
james122333 1 天前 via Android
这都讲了多久了 我四处在讲很多了
自己用当然是 AGPL 等级以上协议 都这样都还不能完全保障 更何况 MIT 现在叫 AI 产协议文件也方便 |
 |
19
linuxsuren 1 天前
推荐自己开源的接口测试工具项目 https://github.com/LinuxSuRen/api-testing/releases/tag/v0.0.20
|
 |
20
Geon97 1 天前
防君子不放小人，
还口口声声的说没抄 pake 的代码 PakePlus 的作者在 v 站，把不要脸发挥到了极致 |
 |
21
TuxcraFt 1 天前
个人开源就用 GPL
|
 |
23
Gilfoyle26 1 天前
@darksword21 #2 那我就弄一个 Pake Pro Max
|
Select Language