以下文章来源于木兰开源社区 ,作者mulan
[
木兰开源社区 .
发布木兰开源社区相关工作动态、活动安排等新闻和信息
](#)
以下文章来源于木兰开源社区 ,作者mulan
2024年3月底4月初,夜莺监控(Nightingale)GitHub仓库某个PR被要求关闭,原因是该PR由某开源公司的实习生在【上班时间】提交。该公司CEO回复称,根据实习生签署的知识产权协议,此PR的知识产权属于公司,而非个人,并提出关闭这个PR。目前相关PR已关闭。
想来这位CEO所说的知识产权协议,可能类似于在劳动合同及相关保密协议中非常常见的条款“员工在职期间开发的项目、专利、著作都属于公司所有”。而且按照国内法律规定,只要是和公司业务领域重合的,不管代码,还是专利、著作权,都是归公司所有。
这时,就出现一个问题,开发者向开源项目贡献的时候,通常被要求需要签署CLA(Contributor License Agreement,贡献者许可协议)或类似协议,此协议只需签署一次,对该贡献者的所有提交都生效。其目的是确保贡献者拥有的著作权与专利许可权被合理、充分、不可撤销的授权给项目管理组织以及项目的使用者。
如果说上面这个案例中,只是开源项目失去了一个PR,那么更早之前的这个案例,则让开发者失去了自己的项目。
2019年12月,俄罗斯警方突击搜查了NGINX公司(nginx服务器项目商业化公司)在莫斯科的办事处,并带走了NGINX公司联合创始人Igor Sysoev与Maxim Konovalov,lgor Sysoev同时也是nginx服务器项目的创建者。起因是俄罗斯最大的搜索引擎和互联网门户之一rambler.ru的母公司Rambler集团对NGINX公司提起版权侵犯诉讼,声称其拥有nginx Web服务器代码的完全所有权,而依据就是Igor Sysoev在担任公司的系统管理员时开发了nginx,因此他们是该项目的合法所有者。
现在流行斜杠青年,大家都乐忠于发挥自身的热情与长处,去参与到更多感兴趣的行业和工作中去,增加自己的能力和收入。而参与开源,本身就符合这样的斜杠气质,既可以让开发者学习和参与更多的项目,增加自己的能力,丰富自身履历,也可以反哺本职工作,为所在公司产生更好的价值。
但是这两个案例的出现,让参与开源,变成了一个风险性工作。
针对以下五个开发者比较关心的话题,木兰开源社区特别邀请了OSPO、托管平台技术负责人、律师、开源项目负责人等,来进行多角度解读。
- 个人签署的CLA,单位不承认,开源项目社区只能照办,那么签署的意义何在呢?
- 开源项目社区应该如何规避这种风险?
- 离职专心做开源贡献,显然是不现实的。那么个人在某家公司任职期间,如何能够合理参与开源贡献呢?
- 每个人的工作内容,都是和自己的能力直接相关的,而参与开源或者创建自己的开源项目,也多是基于此。那么如何在任职期间,成功打造自己的开源项目呢?
- 我国劳务合同中对任职期间产生的知识产权相关条款,以及我国法律在相关诉讼中的判例,是如何认定的?
01 蚂蚁开源技术委员会副主席,Kata Containers项目创始人 王旭
相对于开源许可证是代码分发的时候的法律约束,CLA是贡献者许可协议,是一段代码在贡献到一个项目时要签署的协议,一般说,都是向项目的持有者转让一定的权利,比如方便项目持有者在未来改变许可证。对于项目维护者和参与开发者来说,明确地签署CLA,至少是一种法律上的显式的权利转让,对于未来项目换许可证的预期等来说,在一开始明确总比将来没有准备地爆发要好。
一般的CLA分为两类,对个人开发者的个人许可(ICLA),和对组织的企业许可(CCLA),因为我们在公司的职务开发的知识产权是属于公司的,理论上说,只有企业授权才是合法有效的,个人授权是不适用的。所以,从流程上说,该PR确实是有授权问题的。当然,不论是对于开源社区还是对于公司的公众形象来说,这种处理方式显然是双输的,本来可以有更好的方案,比如重新签署CCLA。
不过在近年,社区中其实有弃用CLA的趋势的,很多贡献者都不希望在签署了CLA之后,让项目控制方可以随意将软件改为不再开源。如果项目本来就希望开源一辈子,那可能就不签署CLA或者放松它比较好。比如Fedora就把CLA换成了一个FPCA,确保所有贡献都有开源许可证,并且贡献者有权不签署;而2017年我们在创立 Kata Containers 项目的时候也讨论过是否需要CLA,最终基金会决定,因为 Apache 2.0 许可证已经保障了代码被授权自由分发,所以代码版权可以仍然属于原作者而不影响其开源使用,因此项目没有CLA。
所以,即使对于商业相关的开源项目,也不是必须有CLA,我们并不鼓励大家滥用CLA来让大家对项目未来的开放性产生怀疑,但CLA相关的故事也让大家更能认识到开源软件的著作权的存在性和复杂度,对于大家更多理解软件知识产权是一个推动,希望大家能够更多地了解开源、热爱开源。
02 CCF开源发展委员会副秘书长,Trustie及GitLink确实开源平台技术负责人 王涛
开源项目成功的根源在于开源社区的积极贡献。CLA是开源项目源头贡献者对本人所做贡献的授权许可协议,签署CLA可以降低开源项目潜在的知识产权合规风险,但是在贡献者的权益保护方面还存在不足。开源知识产权管理涉及到贡献者、开源项目、贡献者所在机构等的多方平衡,还需要更多的探索和实践。
GitLink平台在探索运用区块链技术来实现对社区贡献的存证、确权和激励,试图运用技术的手段来简化事前贡献参与和事中共识达成流程,并为事后法律追溯等提供依据,希望能够为此提供一些有益的探索。
03 国浩律师(南京)事务所合伙人 陶冶
这个问题其实也是很多开源爱好者十分关心的问题。大部分个人贡献者贡献开源可能主要出于个人爱好,如果贡献开源还可能给自身带来诉讼风险,可能会使开源贡献的热情大打折扣。
在我国,根据《计算机软件保护条例》的规定,以下软件作品的版权归公司所有:“针对本职工作中明确指定的开发目标所开发的软件;开发的软件是从事本职工作活动所预见的结果或者自然的结果;主要使用了法人或者其他组织的资金、专用设备、未公开的专门信息等物质技术条件所开发并由法人或者其他组织承担责任的软件”,这是对员工权利的法定限制。
进一步的,大部分的《劳动合同》中也会有“员工工作期间所产出的软件著作权归公司所有”的有关约定,这是通过约定对员工取得软件版权所做的又一步限制。
但这样的限制也并不仅在我国存在,存在这样的限制也并不当然抹杀所有的开源贡献。在美国,也同样有着类似的规定,《美国版权法》§ 201(b)即规定了works made for hire规则。但在Roeslin v. District of Columbia, 921 F. Supp. 793一案中,原告Roeslin就是DISTRICT OF COLUMBIA的员工,但最终法院认为,Roeslin主张权利的软件作品,既不是雇主直接指令其编写的,也不是其日常工作可以预见的产出。且该作品主要是在非工作时间,在办公室之外完成的,因此并不属于这里的works made for hire.这也为美国开发者利用业余时间参与开源贡献提供了可能。
对于国内开发者来说,虽然大多数开源贡献者所选择贡献的项目,是与工作经验相关的,但这并不代表就是与工作任务直接相关。贡献者们可以选择自己熟悉的技术栈内的其他技术点进行贡献。同时,建议贡献者们在参与开源贡献时,避免贡献与工作任务直接相关的代码,同时,也应避免在工作时间,使用工作电脑贡献代码。
04 快猫星云CEO 来炜
个人认为开源项目提交PR要签署CLA,入职公司要签属相关知识产权协议,都是合理且规范的操作。前者是开源项目规避知识产权纠纷,确保所接纳的贡献,与自身的许可证要求相符合、相一致;后者则是公司为了保护其知识产权的必要措施。
两者发生冲突不是偶然,向开源项目做贡献,前提是不能损害各方的正当利益。在这个原则之下,找到一些方法,规避冲突,在开发者自我实现、开源项目健康发展、公司知识产权保护、公司从开源项目获益几个方面,取得多赢。
我们看到,很多成熟的公司都设有开源项目办公室,结合自身的业务需求和商业模式,制定对外开源的战略、制定向外部项目贡献代码的流程、制定使用开源项目的评估措施等,这是公司在保护自身权益的前提下,使用开源,贡献回馈开源的好实践。
开源具有很大的社会价值和竞争优势,在某些案例中,沟通缺失和双重标准,是争议的主要点,不应因此而否定开源协作的模式。
转载自丨木兰开源社区
编辑丨nomi
相关阅读 | Related Reading
AI生成的代码又快又好,但是我要不要相信ta?
可信开源,产业共进——2024 OSCAR开源产业大会正式启动
开源社简介
开源社(英文名称为“ KAIYUANSHE ”)成立于 2014 年,是由志愿贡献于开源事业的个人志愿者,依 “贡献、共识、共治” 原则所组成的开源社区。开源社始终维持 “厂商中立、公益、非营利” 的理念,以 “立足中国、贡献全球,推动开源成为新时代的生活方式” 为愿景,以 “开源治理、国际接轨、社区发展、项目孵化” 为使命,旨在共创健康可持续发展的开源生态体系。
开源社积极与支持开源的社区、高校、企业以及政府相关单位紧密合作,同时也是全球开源协议认证组织 - OSI 在中国的首个成员。
自2016年起连续举办中国开源年会(COSCon),持续发布《中国开源年度报告》,联合发起了“中国开源先锋榜”、“中国开源码力榜”等,在海内外产生了广泛的影响力。
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用
。你还可以使用@
来通知其他用户。