这是一个创建于 619 天前的主题，其中的信息可能已经有所发展或是发生改变。
这个题目我看外国网友也有讨论的，但是感觉和国内生态不符，因此提出来请各位网友批评指正：
-
想要禁止国内一些对开源不友好的企业或者其他单位使用我的代码；
-
禁止把我的代码用于云服务或者某些特定业态；
-
部分企业使用开源代码的时候，会找一个外包，让外包全权负责相关代码的维护，但是外包往往不会回馈开源社区——这种行为能通过 GPL 等协议，至少在名义上禁止么？
讨论这些问题的几个要点：
-
“你不懂国内的业态”，“你就算搞了，国内法律生态也不会支持你”——这种属于离题万里没有任何意义；
-
对于上述问题是否还是“开源”，我认为没有讨论的必要性。因为我的本意只是在讨论一种更加符合国内部分人需求的代码分发方式；
-
建议先 google 一下相关网友的讨论；
 |
1
duke807 2023-04-19 20:56:37 +08:00 via Android
同样关注
|
 |
2
ufo5260987423 OP @duke807 #1 我不知道如果在 README 里面单独声明一点东西可不可以。
|
 |
3
FENebula 2023-12-03 10:58:27 +08:00
@ufo5260987423 这个问题很有意思，想和 op 共同探讨：
1. 这个形式上应该比较容易，在 License 上加禁止 XX 和 XX 使用，不过这样可能 anti GPL 的“自由”条款，所以可能要拟一个新协议，然后实际上应该禁止不了，op 可能比我更了解，各种白手套的话…… 2. 这点可以参考 AGPL ，它针对 GPL 没有明确约束上云和 SAAS 做了补充，然后形成新协议； 3. GPL 要求强制回馈，外包如果公开发布修改后的产品其实就在违反协议吧，只是无法实际反制？ |
|
4
ufo5260987423 OP @FENebula #3
--关于“实际反制”：这个对于任何开源的个人而言，本来就是不可能的。但是这个不可能，要做区分——所谓有的事儿不上称三两三，上称一万斤打不住。开源不上称，但是如果有条件上称追求的是上称一万斤打不住。 --关于上云和 SAAS：这个就是我说的上称的问题，虽然一般开源不上称是因为法律是统治阶级的工具而开源社区多数是被统治阶级，但是这个矛盾不意味着统治工具不对被统治者的反弹做出反应。此外，上云和 SAAS 这个本质上是原来开源协议的一个未覆盖领域，AGPL 是对原有开源协议的延伸而不是修改。 --关于实际上禁止，这个问题和实际反制，是一个道理。不过这里我想谈一下 license 的问题：不要局限于公认的开源许可，现在国内一些人在搞所谓的“木兰”什么的，等于实际上开了个口子——你摸得我便摸不得？现在是一个机遇期。 |
|
5
ufo5260987423 OP @FENebula #3
--关于“实际反制”：这个对于任何开源的个人而言，本来就是不可能的。但是这个不可能，要做区分——所谓有的事儿不上称三两三，上称一万斤打不住。开源不上称，但是如果有条件上称追求的是上称一万斤打不住。 --关于上云和 SAAS：这个就是我说的上称的问题，虽然一般开源不上称是因为法律是统治阶级的工具而开源社区多数是被统治阶级，但是这个矛盾不意味着统治工具不对被统治者的反弹做出反应。此外，上云和 SAAS 这个本质上是原来开源协议的一个未覆盖领域，AGPL 是对原有开源协议的延伸而不是修改。 --关于实际上禁止，这个问题和实际反制，是一个道理。不过这里我想谈一下 license 的问题：不要局限于公认的开源许可，现在国内一些人在搞所谓的“木兰”什么的，等于实际上开了个口子——你摸得我便摸不得？现在是一个机遇期。 |
|
6
FENebula 2023-12-06 00:00:47 +08:00
@ufo5260987423
我和 op 的观念实际上相近，如果协议是一种规则，那么即便规则暂时不能执行，也应当定明，也许有一天它就能起到实际约束，退一步说即便没遇到那一天，协作者之间也需要它，它帮我们明确协作框架和边界。 另外 op 的意思是 AGPL 是对 GPL 的衍生，所以依然是以 GPL 的视角看待问题而没有解决吗？ 之前读过几篇 why GPL is dead 类的文章，得到的信息是 GPL 诞生时背景是单机上独立运行软件，所以对于软件的自由化核心就围绕源代码的约束展开。在云时代软件的形式发生了转变，分发运行复制修改不仅仅靠源代码就能完成，而 GPL 仅围绕源码展开的约束有些不与时俱进了，可能要从新的（ other than source code ）角度来看问题。我想这在当下深度学习领域也有体现，大模型即便完全公开，依大众的算力也无法完成运行或修改，所以可能也需要新的框架。 |
|
7
FENebula 2023-12-06 00:03:49 +08:00
@ufo5260987423
感谢 op 的提示，去粗略读了木兰宽松版和公共版协议，感觉木兰是针对 Apache 这类依然受美国出口管制法律限制的协议提出的国产替代，着眼点也还主要是源码。“现在是一个机遇期”是说拟定一个新开源框架的机遇吗？ |
|
8
ufo5260987423 OP @FENebula #7
我指的是现在礼崩乐坏了。 你可以搜索一下 cyber security act ，这个是欧盟的网络安全法，以及前段时间在 oschina 上对于中国的网络安全法的讨论——他们明确提出了，开源作者要对开源作品的网络安全影响负责。 旧的秩序被破坏了，新的秩序需要建立起来：木兰就是在这个机遇期上道的，但是木兰显然没有考虑到 cyber security act 和网络安全法的影响。这就叫老虎的屁股木兰摸得，我也摸得。 |
|
9
FENebula 2023-12-17 17:37:46 +08:00
@ufo5260987423 抱歉没她明白 op 的礼崩乐坏，是指像 cyber security act 这样要求开源软件作者为开源产品的漏洞，安全补丁以及造成的影响负责，这破坏了过去开源协议的常见（免责）约定？
“如果商业实体单独开发并控制产品内置开源软件，就必须履行《网络弹性法案》的所有义务，包括基本要求、技术文档、合规标志和市场监管。 更复杂的情况下，开源软件是在支持组织支持下协作开发，如开源软件基金会或“管理者”，欧盟的想法是引入一种义务明确的轻量级制度。该制度为开源软件管理者量身定制的要求包括：启用并推动漏洞处理流程，包括立即发布安全补丁、报告已被积极利用的漏洞。” 从这报道上来看要想遵守 cyber security act(CSA)还必须细细明确开源软件的开发方组织形式，协作方式，目的用途等等，这点确实之前都没有协议定明，又或者我们可以撸这 CSA 玩自己的一套？ |
|
10
ufo5260987423 OP @FENebula #9 你找的这一段文本是网络弹性法案的，也就是 cyber resilience act.
|
Select Language