Discussion related to license compatibility issue 有关协议兼容性的讨论 #10
Comments
|
文本列数有超过80列（不包含一般c或者其他语言的注释符号），需要稍微重新排版下。 |
|
@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 可以申请对方发布一个 比如GPL 潜在的兼容性无法避免。 一般的想法是修改其它协议变成Anti-996-License, 但是996ICU协议的核心条款其实只有一条。 避免形式上的冲突可以省却不少时间和麻烦。 In my raw thoughts, I agree with this solution in LICENSES
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. 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 <notifications@github.com<mailto:notifications@github.com>> 写道：
我其实不是很明白，法律已经明确了的违法行为，何必再用一个依靠法律来实现约束力的许可呢？虽然我没数据，但我猜国内因违反开源许可而起诉的案例可能比劳动仲裁的案例少很多吧。
另外需要意识到，有些开源项目是有大厂的贡献的，如果到头来不让它们使用自己曾经贡献过的代码，我觉得有点过河拆桥了。我认为应该放弃阻止个人或组织使用开源代码，转为以普及劳动法相关条款、提高开发者维权意识、降低维权成本为主，避免盲目维权，少走弯路。
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub<#10 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AXt52R-pXpVJNzyWtzrbRwGdQ2qe4y82ks5vdRmNgaJpZM4cW_lU>.
|
|
许可证的选择权利在项目创建人的手里。 |
|
如果我们的视线都在license上，确实是跑题了。
应该明确我们的需求是什么？
希望最后可以是一个公益基金或者其他什么公益组织可以为大家发声，而不是取代劳动法去执行私法。行业中缺少对加班文化的质疑声，我想很多人响应也是对996项目发声的肯定。
程序员在争取自身利益的同时，有可能帮助企业提升管理水平，帮助行业改善发展环境。如果能够推进合作共赢，未来回过头来看，才是真正可以推动历史发展的事情，而不是坚持对抗的状态。
开源社区有很多技术和管理的牛人，但是不需要搞对抗分裂的牛人。
在 2019年4月4日，17:12，ThinkLoudly <notifications@github.com<mailto:notifications@github.com>> 写道：
@Tedko<https://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 GitHub<#10 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AXt52bo3mMV9AwyTuyBeBHwa-rmMBrlRks5vdcIHgaJpZM4cW_lU>.
|
|
谢谢讨论和建议 |
我把第五条贴一下。
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。
那么是否可以在license中设定一种开关机制，在特定条件触发的情况下，协议将从Copyright变更为Copyleft。 |
|
自由度0 保护的更多是软件的使用权，而不是软件使用者。 可以考虑 把 强制 软件使用者 回馈开源社区 作为一种惩罚。 GPL 和AGPL 对大厂是比较致命的。 以MySQL为例，ali 对其做了大量优化，它可舍不得开源。 |
|
其实我认为： 996文化有害程序员社区 这句话能够达成病毒式传染。挂在每个repo上面。 完成这种事情本身就是有用的。 |
|
同意楼上。不要限制太多，我觉得规定到要求必须将 996是可耻的置于文件与发布说明，甚至产品的ppt中。达到宣传的目的即可。让观念深入到下一代程序员，甚至普通人心中。资本家觉得我们cheap，他们使用的996行为更cheap。 |
emmm..... 我到底要说什么，白天敲了一天代码，脑子有点不好使，后面比较乱了，还是争取一条条清晰的列出观点吧
胡言乱语 不知所言 与君共勉 吃夜宵不会长胖 |
|
已经在联系Open Source License方面的专家Heather Meeker，希望她会给我们提供帮助。 |
我突然有个不成熟的建议：
这样既不违反开源精神，又能狠狠的恶心商业公司一把。 ============= UPDATE =============== Just add License like /**
* Copyright (c) 2019 Jerry Lee <jerrywdlee@gmail.com>
*
* 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. |
|
dual license有意思！ |
|
知乎上有一位答主写了这些 https://www.zhihu.com/question/317920060/answer/643386522 我会和这位答主也讨论讨论，其实很多点我们当时想到了 但是也没有很好方案 |
在责任上，使用不同许可证进行的是豁免，而不是约束。提供强制约束的仍然是法律，因为没有许可证，按版权法的默认条款会造成潜在的侵权风险，遵循许可证允许免除这样的风险和责任。和传统开源许可证相比，新的许可证只是豁免的条件更严格了。而要以其它的影响来评价，开源许可对现有需求来讲是最软弱的。你可以使用类似的逻辑诘问 FSF ，为什么在有开源的许可下所谓“自由软件”（注意 FSF 定义的自由软件的许可明显比多数开源许可更不自由）仍然是必要的？（和这里情形的差别也就是自由软件运动历史上更早而已。） 开源跟大厂也没有直接关系。你引用的 OSD 第 5 条强调的是非歧视，强调参与者地位的公平性，正好和这个提法相反。平衡大厂和其他开发者利益的“生态”建设，并不是开源运动自身的一部分，而是需要协调的外部环境——尽管这点被时常混淆。 此外，就字面上来说的 not discriminate 是否和新的许可证必然冲突，仍然是个问题。许可证的文本明确的资格并没有区分具体对象（禁止特定企业），使用黑白名单可以是许可证之外的用于判断前置条件的个别行为，而不是许可证要求的义务。一般意义上，企业应能自主决定是否满足许可证的条件，这里的冲突是不应当存在的；如果否认这点，这跟所有 copyleft 许可中要求同时提供源代码才能取得授权的要求也有类似的冲突，那么所有此类 copyleft 许可都不是符合 OSD 的开源许可，这不符合常理。 |
|
但是要 许可证 符合 OSD 或者 FSF 的认证标准是个问题。 |
|
是的
…On Fri, Apr 12, 2019 at 2:48 PM FrankHB ***@***.***> wrote:
@terrynoya <https://github.com/terrynoya> 那个不是重点。使用许可证是为了*避免不适格的对象获得合法授权*
，而非通过*提名*定义什么算是 evil 然后划清界限。这针对的是客观的遵守规则的资格，而不是discriminate against
persons or groups，所以不应有直接冲突。GNU GPL 就是个例子。
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#10 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AGYKzcixXbETA8NyR_5IJ2LyJWS7o44Fks5vgCxbgaJpZM4cW_lU>
.
|
|
@FrankHB 不知道你说的相似是指什么。GPL并没有限制使用，只是限制分发；只有在得到代码之后才有违反GPL的可能，而不是之前；该限制是为了确保用户自由，明显和禁用条款的目的相悖。而且也不是说非得有个指名道姓的名单才算区别对待，如果按特定行为来划分就不算区别对待，那就可以通过添加多种行为来精确到个人或组织了。我不认为改变话术来规避与开源定义的冲突能让Github官方接受这个许可，我认为官方很明白这先例一开将意味着什么。 |
|
首先，对许可证的法律文本来说，“用户”就是 licensee ；除此以外的“确保用户自由”（例如 FSF 所谓的“自由之零”）只能是表明 licenser 和特定涉众的态度（特别是“用户”还有不确定第三者的情况），并不直接确保法律效力。在版权法的意义上，这样的权利通常也无从确保，因为除了涉及衍生作品和演绎的具体权利，版权法不并直接明确什么是对软件的“使用”；而更具体的专门法可以对软件有附加的限制，这又是一个想要尽量兼容不同管辖的许可证无法阻止的。具体到 GNU GPLv3 ，其中强调的保证用户使用软件的基本自由的条款设计，实际上仅限要求 licensee 不得对用户依照所谓的 Anti-Circumvention Law 附加限制性条款这类特定的情形，而并不要求向用户提供一般的合法可用性担保（实际也没法完全做到）。 其次，之前提过多次，许可证是获取授权的方式。不满足许可证的条件，则不会由许可证取得合法授权。非源码形式的“使用”也依赖 GNU GPL 等许可证显式地许可而避免落入版权法中限制使用的情形，因此在没有得到源代码而仅得到二进制形式时，仍然可能因为（包括非源码形式的）使用造成侵权。这种由许可证免除法律限制的机制是各个管辖普遍共通的（尽管限制可能各有不同），并不因为授权针对的代码形式和具体条件的变化而有区别，也不依赖开源的定义而有所变化。 举个例子，一个以 GNU GPLv3 许可证授权的软件，因为某些原因只提供捆绑了源代码、二进制代码和许可证文本的光盘映像；一个用户提取了其中的二进制代码和源代码但遗漏了许可证文档在网络上进行分发；你下载了这个没有许可证的版本并使用了其中的二进制代码。那么技术上，提供遗漏许可证文档的用户和你都有可能直接构成侵权（具体细节按依管辖有所不同）。虽然一个是（包含源代码的）“复制”，一个是“使用”，具体侵权的理由并不同，共同点是，因为 GNU GPLv3 中规定了具体条件没被满足，这类情况也通常不满足版权法规定的合理使用或法定许可的情形。（具体来讲，前者比较直接： GNU GPLv3 Conveying Verbatim Copies 要求 and give all recipients a copy of this License along with the Program ，而专有复制权是各个版权法普遍保护的；后者则依赖适用的管辖，如《中华人民共和国计算机软件著作权保护条例》第三十条“软件的复制品持有人不知道也没有合理理由应当知道该软件是侵权复制品的，不承担赔偿责任；但是，应当停止使用、销毁该侵权复制品。”） 第三， GNU GPL 中的向下游 licensee 提供源码才有权提供源代码的条件，这种条件不应具有特殊性（之前也提过，唯一的特殊性是 GNU GPL 比 OSD 更早，这跟内容无关），有理由认为也是一种“特定行为”。这就和这里的情形有相似性。 至于“如果按特定行为来划分就不算区别对待，那就可以通过添加多种行为来精确到个人或组织了”，逻辑上是不通的。会构成区别对待的理由的，并不是授权的条件，而是“精确到个人或组织”这一结果。许可证的条件应当是明确的，不会有任意添加以至于会有这样的结果的余地。 另外，请注意，开源的普遍含义不由 GitHub Inc. 决定。解释 OSD(Open Source Definition) 的是 OSI(Open Source Initiative) 。一直以来主张 Free Software 的，是 FSF(Free Software Foundation) 。让 GitHub 接受许可证不是讨论许可证符合开源定义的直接目的。反过来，解决兼容问题使之符合某类许可证的定义，倒是更容易（也是现在看来唯一可能）实现这个目的的途径。 |
|
@FrankHB 咱们好像有什么误会。如果你觉得我误解了你，望指正。 我的主张很简单：禁止条款与OSD冲突，与OSD冲突就不该叫开源许可或者自由软件许可。你前面说本许可与GPL类似，还说本许可并没有区分具体对象，我认为你是想说明本许可与开源定义不冲突，我也认为这是咱们有实质分歧的地方。然后针对你说的这些，我说了几个GPL和本许可的区别，以及为何不同意你没具体名单就不算区分具体对象的观点，以支持我的主张。 之后你的回复却多次提及版权法，我就不太清楚你想表达什么了，看起来你有研究也很认真，但好像和我的主张关系不大。我先解释一些我认为可能存在误解的地方，以便后续讨论：
对不住各位issue的订阅者，希望没把讨论搞复杂。 |
|
|
Hi谢谢楼上两位。具体问题我觉得katt会参与讨论更好。 关于名称 我们曾经有想过Ethical Software. 但现在还倾向于落实在free名下 |
|
@FrankHB 感谢回复。大致明白你的意思了。看起来你是坚持认为“禁止条款与OSD冲突”和“GPL与OSD不冲突”存在矛盾。关于这个问题我认为我上面已经解释了，可能不够说服你，我认同你说的最终需要OSI明确。No Harm许可证的一个PR中有来自OSI官方人员对No Harm许可证的评论，你可以参考一下。我只贴个tldr，就不@那位官方人员了，毕竟这里对话全是中文。如果你愿意的话可以考虑新开一个issue和OSI官方交流一下你认为存在的矛盾。
@Tedko 感谢告知进度。当然，能落实在free名下确实能扩大影响力。不过我觉得，只要通过许可搞社会运动的需求持续存在，那就会不可避免地独立出来，根本原因在于其它社会运动与开源运动、自由软件运动的目标不同。或许你们有其它考量。顺便问一下Meeker女士对双许可的方案有什么意见么？ |
|
@ThinkLoudly @FrankHB http://cardozolawreview.com/wp-content/uploads/2018/08/GREENBAUM.37.4.pdf 在1312页，有这样一段话：
我的理解是GPL并没有区别对待用户，而是对某些特定的使用方式有不同的影响，这样是不违反OSD的。至于Anti-996是否和OSD冲突，那还是要OSI还决定的。 |
实际上 我在这里提出的疑问还是没有得到 解答。 既然 GNU Copyleft不违反OSD， 那么把Copyleft 作为惩罚为什么不行。 违反 license 强制开源，那怕是业务程序也是一样强制开源。使用了包含 license 的组件，只要违反了 license，那怕是商业 业务 软件也要必须开源。 这样既不违背OSD， 也对公司有所威慑。 为什么不行。 |
|
@ff4415 Copyleft和是否违反OSD没有直接关系吧。Copyleft只是为了保证传染性，GPL作为Copyleft的一种实现是不违反OSD的，因为它的限制是为了保证用户自由，而不是剥夺。而Anti-996无论是否有传染性，都会禁止部分用户使用，这是违反OSD的关键。 |
|
@ThinkLoudly Anti-996 并没有禁止部分用户使用，只是在用户违反License 规定时才认为是侵权，也就是说这个License 给予了所有用户使用的自由，而且这个自由是掌握在用户手中的 。 同时 “不得侵害劳动者权益” 这一规定 又不像 "尊重同性恋"、"信仰宗教"、“不得性别歧视” 这类会因为文化地域不同而出现显著争议，劳动者权益 在任何一个现代 国家都不具有争议性。 还有一点Anti-996 没说清楚，就是用户违反了规定，后来又改正了怎么办？ |
|
@Tedko 我认为考虑到潜在的混淆和混乱，恐怕最终仍然不得不需要一个新的名称（虽然我一时也想不到合适的）。使用 free 来宣传看上去只是权宜之计。我们仍然需要为此的一些准备。 @ThinkLoudly 感谢提供素材。 关于 “Do No Harm” license 的问题，我同意它应该几乎不可能被 OSI 批准，不过违反 No Discrimination Against Fields of Endeavor 这一条即为充分理由。 这个许可证会被认为违反 No Discrimination Against Persons or Groups ，是因为许可证文本有进一步歧义，会导致判定是否符合条件时不得不有一些副作用，如这里说的：
我想，在这里起草的许可证需要的条件无疑是比 “Do No Harm” license 的情形好得多的。它并不直接违反 No Discrimination Against Fields of Endeavor ；也不需要有上面的操作问题而违反 No Discrimination Against Persons or Groups 。 关于条件认定操作的明确性，可以参考 @yyrdl 的解释。 另外，我建议合适的时候这个项目的维护者考虑直接咨询 OSI 。 @bingao 基本上，这篇文献的描述和我理解的 non-discrimination 的内涵是一致的。 我的理解是这里的情形和 GPL 本身有一定相似，因为，承诺遵守特定法律（并非担保合法）本身是 licensee 自主决定的事项，而非 immutable individual characteristics 。这和决定是否提供源代码（以满足 GNU GPL 的条件）是相似的——不存在 certain users 因这样做出是否承诺的选择而被区分出 “discrete” groups 或者 “suspected” classes or characteristics 从而存在 disparate treatment 。 虽然在目的上，确实可能有人想利用这样的许可证来 prohibit certain users ，但这样的目的并没体现在许可证上——就像专利本身不是为了排除商业竞争对手而存在的一样，怎么被（滥）用并不影响法律工具的内涵。 而认定是否符合 OSD ，看的也是许可证条款本身。 当然，这件事比提供源代码这样的条件实际更复杂一些。 比如说，提供源代码是不受到管辖影响的事实判断，而是否合法则需要先判断合哪个法。 再如，提供源代码事实上没法撤销（虽然某些版权法普遍有权撤销不过被许可证的条款堵死了……），而（和 @yyrdl 的提问相对）不违法的条件是可能被自主打破的。那么权利是否继续有效？ 不过这些是符合 OSD 以外的问题了。 |
|
谢谢。我也非常同意license的作者、负责人在合适的时间咨询、或者提交给OSI。好运！ |
|
有个想法：Anit-996许可证的颁发能否不基于要求用户遵循相关法律，而是要求基于Anti-996发布的软件及其衍生品在使用、扩散、转发等方式中要遵循相关法律。这样，就把从对用户的要求转化为对软件等客体的要求。这样，更符合open source的哲学？ |
这会使许可证的文本大幅复杂。不过考虑侵权行为和授权的时效相关性，可能本来就没法避免这个复杂性就是了（上面说过，条件至少比要求发布源代码复杂）。 我倒是有另外一个主意：把前提作为显式的承诺并扩大适格权利人范围——比如明确要求允许任意下游衍生作品的自然人在违反条件时起诉，因为侵权会导致下游使用非法副本而可能受到法定限制。 |
|
@FrankHB 谢谢。明确一下我上一条的评论，如果一个简单文本方式的Anti-996就足够通过OSI和OSD，我认为是最好的。我的评论是建立在如果目前Anti-996的版本不被OSI认可的话——虽然希望能被认可:-) |
由于我们正在草拟全新的协议（算子），完全可以做到草拟多个子协议，使得对于所有的其它协议，我们草拟的协议（的组合）中，至少有一个能兼容。 抱歉我有点语死早。。 |
|
@firedom Copyright和contract law都是属于private law的范畴 |
同意，根据GPL官方FAQ ，这应该符合GPL声明，996文化有害程序员社区 这句话再斟酌一下，符合版权声明，比如来自反996联盟之类的，这个声明不抵触GPL还具有传播性，这就够了，反996本来就该劳动法做的事目前，目前这个Anti 996 license反而多此一举，还违反了开源精神。我们只要表明态度就行了。 |
我觉得争取员工待遇和促进开源繁荣之间不抵触。 而且准确的说，应该是研发型企业和大学才是推动开源的重要力量。 但实质上还是依靠的技术人员。 为研发人员提供良好的待遇，也应该是企业竞争的一环。 我现在想的，
觉得差不多就是现在能做到的全部了。 足够好的项目有议价权力， 完全可以使用完全版权来保护自已的利益。 所以这才是Anti 996 license 有意思的地方。 荣誉有时候比利益更重要。 |
|
其实现在外部环境这么好，主项目也得到了github内部认可。 [关于让Github官方认可996 license的讨论] 然后如果以后研究更深入了，再考虑出一个2.0版本。 |
|
现在因为兼容性，无法与开源自由软件互相调用，会极大阻碍该许可证和劳工运动的发展。可否考虑开具不同版本的许可证，类似gnu那样有lgpl，gpl1/2/3，agpl。
|
我不认为附加具有传染性的义务能兼容大部分 GNU 许可证（如 GNU GPL ）。 |
https://www.gnu.org/philosophy/free-sw.en.html
与“不得将软件用于某种目的”的声明不同，口号声明的传染性义务并未阻碍用户获得、传播软件。可由以上 GNU 对 Copyleft 释义的举例类推：既然可以规定保留商标声明、保留版权声明之类义务作为附加条款，那么要求保留某种其它的、并未限制用户的声明也是可以接受的。 上面的评论其实讨论过这个问题了。 |
有关协议兼容性的问题请在这里讨论，谢谢！
Pls discuss license compatibility issues here, thank you!
The text was updated successfully, but these errors were encountered: