Anti-996-License
Anti-996-License copied to clipboard
kattgu7
Discussion related to license compatibility issue 有关协议兼容性的讨论
有关协议兼容性的问题请在这里讨论，谢谢！ Pls discuss license compatibility issues here, thank you!
@Xianguang-Zhou I'm studying the compatibility issues because it is so damn complicated. The license is intended to be compatible with other commonly used licenses.
@1989wanghang can you help adjust that? I'm not a programmer so I'm not familiar with how some functions work.
我认为按照这个方式处理兼容性挺好:
一个独立的996ICU协议。约束力仅仅高于MIT。 一个可以附加在其它协议后面的最小条款， 构成不侵权的附加版本协议。
这两个作为独立的协议
然后其它的协议，以继承扩展对方协议的方式发布：
比如 Mozilla Public License Version 2.0
可以申请对方发布一个 Mozilla Public License 2.0 IN Anti 996 Version 这样的形式。
比如GPL 则是GPL IN Anti 996 Version
潜在的兼容性无法避免。
一般的想法是修改其它协议变成Anti-996-License,
但是996ICU协议的核心条款其实只有一条。
避免形式上的冲突可以省却不少时间和麻烦。
In my raw thoughts, I agree with this solution in LICENSES
- an individual Anti-996-License, restraint just more than MIT.
- a tenderer License which could attach to other Licenses but not cause problems on it.
As for famous Licenses, like GPL or MPL, could extend it but intrude it.
for example:
as Mozilla Public License Version 2.0, it's Mozilla Public License 2.0 IN Anti 996 Version. Same as GPL. like GPL IN Anti 996 Version
In normal thoughts, it's adjusting other Licenses to fit Anti-996-License, but core items of Anti-996-License are less.
avoid conflicts with other License will save time and vitality.
我认为对于MPL 和GPL 来说，协议约束要强于 Anti-996-License。 从而 导致 Anti-996-License 失效, 或者破坏对方的效力。
我其实不是很明白，法律已经明确了的违法行为，何必再用一个依靠法律来实现约束力的许可呢？虽然我没数据，但我猜国内因违反开源许可而起诉的案例可能比劳动仲裁的案例少很多吧。
另外需要意识到，有些开源项目是有大厂的贡献的，如果到头来不让它们使用自己曾经贡献过的代码，我觉得有点过河拆桥了。我认为应该放弃阻止个人或组织使用开源代码，转为以普及劳动法相关条款、提高开发者维权意识、降低维权成本为主，避免盲目维权，少走弯路。
同意，license可能杀死开源社区。不要盲动，把自己逼到墙角。
在 2019年4月4日，05:13，ThinkLoudly <[email protected]mailto:[email protected]> 写道：
我其实不是很明白，法律已经明确了的违法行为，何必再用一个依靠法律来实现约束力的许可呢？虽然我没数据，但我猜国内因违反开源许可而起诉的案例可能比劳动仲裁的案例少很多吧。
另外需要意识到，有些开源项目是有大厂的贡献的，如果到头来不让它们使用自己曾经贡献过的代码，我觉得有点过河拆桥了。我认为应该放弃阻止个人或组织使用开源代码，转为以普及劳动法相关条款、提高开发者维权意识、降低维权成本为主，避免盲目维权，少走弯路。
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHubhttps://github.com/kattgu7/Anti-996-License/issues/10#issuecomment-479661209, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AXt52R-pXpVJNzyWtzrbRwGdQ2qe4y82ks5vdRmNgaJpZM4cW_lU.
https://github.com/kattgu7/Anti-996-License/issues/10#issuecomment-479661209
许可证的选择权利在项目创建人的手里。 法院只有法律解释权力，而没有执行权力。
@Tedko GPL是GNU的许可，禁止个人或组织使用开源代码也是违反GNU哲学的。如果这个许可既不符合开源定义，又不符合GNU哲学，我认为是无法满足Github官方收录条件的。
如果一定要禁止别人使用，我觉得可以考虑从开源和自由软件中独立出来，这样才能摆脱相关理念的束缚，也就无所谓兼容不兼容了。不过我希望发起者和参与者能重新思考这个运动的目标，禁止别人使用只是方法，而且是众多方法之一，也不一定是好方法。
如果我们的视线都在license上，确实是跑题了。
应该明确我们的需求是什么？
希望最后可以是一个公益基金或者其他什么公益组织可以为大家发声，而不是取代劳动法去执行私法。行业中缺少对加班文化的质疑声，我想很多人响应也是对996项目发声的肯定。
程序员在争取自身利益的同时，有可能帮助企业提升管理水平，帮助行业改善发展环境。如果能够推进合作共赢，未来回过头来看，才是真正可以推动历史发展的事情，而不是坚持对抗的状态。
开源社区有很多技术和管理的牛人，但是不需要搞对抗分裂的牛人。
在 2019年4月4日，17:12，ThinkLoudly <[email protected]mailto:[email protected]> 写道：
@Tedkohttps://github.com/Tedko GPL是GNU的许可，禁止个人或组织使用开源代码也是违反GNU哲学https://www.gnu.org/philosophy/programs-must-not-limit-freedom-to-run.html的。如果这个许可既不符合开源定义，又不符合GNU哲学，我认为是无法满足Github官方收录条件的。
如果一定要禁止别人使用，我觉得可以考虑从开源和自由软件中独立出来，这样才能摆脱相关理念的束缚，也就无所谓兼容不兼容了。不过我希望发起者和参与者能重新思考这个运动的目标，禁止别人使用只是方法，而且是众多方法之一，也不一定是好方法。
— You are receiving this because you commented. Reply to this email directly, view it on GitHubhttps://github.com/kattgu7/Anti-996-License/issues/10#issuecomment-479817112, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AXt52bo3mMV9AwyTuyBeBHwa-rmMBrlRks5vdcIHgaJpZM4cW_lU.
我把第五条贴一下。
- No Discrimination Against Persons or Groups The license must not discriminate against any person or group of persons.
Rationale: In order to get the maximum benefit from the process, the maximum diversity of persons and groups should be equally eligible to contribute to open sources. Therefore we forbid any open-source license from locking anybody out of the process.
Some countries, including the United States, have export restrictions for certain types of software. An OSD-conformant license may warn licensees of applicable restrictions and remind them that they are obliged to obey the law; however, it may not incorporate such restrictions itself.
最后有提到，面对国家法律 license 不强制执行法律，但是可以提出 违法警告。
这个是否可以作为一个约束力底线， 至少，可以在开源定义范围之内，达到“在香烟盒上 印上 吸烟有害健康” 的效果。
其次，进一步设想，是否可以在触犯底线之后达到 协议提权的效果，比如，违法之前，是MIT相关，违法之后，提权到GPL， 这样。
毕竟现在这个事情 不是 针对某个特定 集体或个人，而是996作为一种 文化，威胁到了整个社区。
是理念间的对立。 反对的是一种文化。
在这个层面上面，首先 应该 表面立场： 996文化是有害的。
具体得失是次要考虑的。
里面有提到 自由软件”不等于’非商业软件‘
其次存在Copyleft。
Copyleft不同于传统的公共领域（public domain）。因为公共领域的作品，任何使用者虽然都可以使用，但可以不回馈变成已用；而Copyleft作品的使用者若在发布的时候不按Copyleft的许可证要求保持同样的授权条款，并将更改的版本回馈社群的话，就是违反著作权法的侵权行为。
Copyleft授权许可有时被认为具有“传染性”，因为任何从Copyleft许可衍生出的作品也必须是遵守Copyleft许可的规定。“传染性”虽然带有贬义，但是这与病毒的传染并不相同，因为病毒的传染是通过不为用户所知道的途径传播的；Copyleft则是公开透明的。
那么是否可以在license中设定一种开关机制，在特定条件触发的情况下，协议将从Copyright变更为Copyleft。
自由度0 保护的更多是软件的使用权，而不是软件使用者。
可以考虑 把 强制 软件使用者 回馈开源社区 作为一种惩罚。
GPL 和AGPL 对大厂是比较致命的。 以MySQL为例，ali 对其做了大量优化，它可舍不得开源。 这个例子可能有点不当。不过国内大厂对开源社区的贡献和他的市值不匹配。
同意楼上。不要限制太多，我觉得规定到要求必须将 996是可耻的置于文件与发布说明，甚至产品的ppt中。达到宣传的目的即可。让观念深入到下一代程序员，甚至普通人心中。资本家觉得我们cheap，他们使用的996行为更cheap。
其实我认为： 996文化有害程序员社区 这句话能够达成病毒式传染。挂在每个repo上面。
完成这种事情本身就是有用的。
-
“程序员” 这个词建议改成工程师，考量是 “身份” 问题，并不是任企业宰割的某某某，一直以来我们都太忽视自己社会地位了。
-
关于“No Discrimination Against Persons or Groups” 我觉得没违背，因为我们并没有指名道姓说谁谁谁不能用（这是诡辩么，hhh）
-
感谢Tedko 和 kattgu7 的出色工作！手动点赞 （^_^）. License 兼容性问题我觉得倒是其次，而是如何在理念上让别人接受，我没出过国，不清楚国外不同文化背景的人对此的看法
-
996ICU道出了社会现象，还需要往理论升华，可以从 经济、人权、法律、开源软件历史演进进程、人类文明演进进程多方面进行系统论证，
开源软件作为生产资料，在生产资料里面附加协议还是比较先进的尝试的，古时候打仗都讲究一个师出有名，这个协议可以创造出这个名
- 实际上996ICU就是要往开源文化 “自由”、“分享” 的核心价值观里面再加一个成员 ---- “保护劳动者权利” ，啊 ，赤裸裸的野心 ，偷笑。（立马严肃） 在我看来这是进步的，所以在往996ICU 提的关于"原则 和 目的"的PR 里面包含了关于 Anti-996 License 进步性表述，
emmm..... 我到底要说什么，白天敲了一天代码，脑子有点不好使，后面比较乱了，还是争取一条条清晰的列出观点吧
- 理论 很重要，当年毛大爷这辈老人打天下的时候都是先搞理论，如果需要在多数人中达成广泛共识， 一定需要 理论 来支撑， 除此之外还需要 事件 和 利益 ， 事件是契机，这个已经有了，利益这个点也很明白，Anti-996 License 站在开发者（劳动者）这一边，就缺理论。 高素质、高学识的人需要 客观的 理论 来说服他们。 我相信 Tedko 和 kattgu7 参与这件事 绝对不是为了凑热闹或者是出名， 一定是出于某种社会责任感。同样， 那些开源大神 也绝对不会因为 996ICU的 star 增长速度多么多么高， 而接受 Anti-996 License， 只能吸引他们看一眼，发表一下评论而已，但如果触及他们 的 理论认知就不一样了。 所以我们需要一篇 paper , 我要狗带了，最不会的就是写paper，还不知道这个内容属于哪个学科的范畴，反正就是觉得 996ICU 可以往理论这一方向再升华一下 ，跪求各路大神，我要去社区卖膝盖 T_T
胡言乱语 不知所言 与君共勉 吃夜宵不会长胖
已经在联系Open Source License方面的专家Heather Meeker，希望她会给我们提供帮助。 另外，UIUC法学院再联系我写一篇这方面的论文，希望这件事希望能从学校，特别是工程学院的老教授那里开始发酵（毕竟UIUC也是一些License的发源地）
@kattgu7 反996许可与开源定义第五条冲突。
美国已有先例。例如去年美国ICE的事让一些开源项目在许可里加入了禁止向包括微软在内的一些公司授权，后来被认为违反开源定义第五条，revert了。
里面有提到 自由软件”不等于’非商业软件‘
其次存在Copyleft。
Copyleft不同于传统的公共领域（public domain）。因为公共领域的作品，任何使用者虽然都可以使用，但可以不回馈变成已用；而Copyleft作品的使用者若在发布的时候不按Copyleft的许可证要求保持同样的授权条款，并将更改的版本回馈社群的话，就是违反著作权法的侵权行为。
Copyleft授权许可有时被认为具有“传染性”，因为任何从Copyleft许可衍生出的作品也必须是遵守Copyleft许可的规定。“传染性”虽然带有贬义，但是这与病毒的传染并不相同，因为病毒的传染是通过不为用户所知道的途径传播的；Copyleft则是公开透明的。
那么是否可以在license中设定一种开关机制，在特定条件触发的情况下，协议将从Copyright变更为Copyleft。
我突然有个不成熟的建议： 本软件的使用必须遵循下列许可证之一
- GPL / MPL 2.0 之类的Copyleft
- Anti 996 License
这样既不违反开源精神，又能狠狠的恶心商业公司一把。
============= UPDATE ===============
Just add License like
/**
* Copyright (c) 2019 Jerry Lee <[email protected]>
*
* This project is dual licensed under
* Anti 996 License Version 1.0 & Mozilla Public License 2.0
*
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
* See Anti 996 License Version 1.0 Here:
* https://github.com/jerrywdlee/no-cron/blob/master/LICENSE#L5
*
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
* See Mozilla Public License 2.0 Here:
* https://github.com/jerrywdlee/no-cron/blob/master/LICENSE#L52
*
*/
Check HERE for more info.
知乎上有一位答主写了这些 https://www.zhihu.com/question/317920060/answer/643386522
我会和这位答主也讨论讨论，其实很多点我们当时想到了 但是也没有很好方案
@ThinkLoudly
我其实不是很明白，法律已经明确了的违法行为，何必再用一个依靠法律来实现约束力的许可呢？虽然我没数据，但我猜国内因违反开源许可而起诉的案例可能比劳动仲裁的案例少很多吧。
另外需要意识到，有些开源项目是有大厂的贡献的，如果到头来不让它们使用自己曾经贡献过的代码，我觉得有点过河拆桥了。我认为应该放弃阻止个人或组织使用开源代码，转为以普及劳动法相关条款、提高开发者维权意识、降低维权成本为主，避免盲目维权，少走弯路。
在责任上，使用不同许可证进行的是豁免，而不是约束。提供强制约束的仍然是法律，因为没有许可证，按版权法的默认条款会造成潜在的侵权风险，遵循许可证允许免除这样的风险和责任。和传统开源许可证相比，新的许可证只是豁免的条件更严格了。而要以其它的影响来评价，开源许可对现有需求来讲是最软弱的。你可以使用类似的逻辑诘问 FSF ，为什么在有开源的许可下所谓“自由软件”（注意 FSF 定义的自由软件的许可明显比多数开源许可更不自由）仍然是必要的？（和这里情形的差别也就是自由软件运动历史上更早而已。）
开源跟大厂也没有直接关系。你引用的 OSD 第 5 条强调的是非歧视，强调参与者地位的公平性，正好和这个提法相反。平衡大厂和其他开发者利益的“生态”建设，并不是开源运动自身的一部分，而是需要协调的外部环境——尽管这点被时常混淆。
此外，就字面上来说的 not discriminate 是否和新的许可证必然冲突，仍然是个问题。许可证的文本明确的资格并没有区分具体对象（禁止特定企业），使用黑白名单可以是许可证之外的用于判断前置条件的个别行为，而不是许可证要求的义务。一般意义上，企业应能自主决定是否满足许可证的条件，这里的冲突是不应当存在的；如果否认这点，这跟所有 copyleft 许可中要求同时提供源代码才能取得授权的要求也有类似的冲突，那么所有此类 copyleft 许可都不是符合 OSD 的开源许可，这不符合常理。
@ff4415 具体如何能符合 OSD ，可以咨询 OSI 。我不认为这样的许可证有必要符合 FSF 的现有定义，需求本来就不同；但是，这里的方法实际上和 FSF 的类似，所以可以继续讨论。