面对法律,开源应负什么安全责任

2023/12/17 21:00
阅读数 24



本文主要考虑两个法律,我国的《网络安全法》¹(以下简称网安法)和欧盟的《网络韧性法案》(以下简称CRA,欧盟议会修正案版本²),另外,还会涉及我国的《网络产品安全漏洞管理规定》³(以下简称漏洞管理规定)。


本文主要就以下几个问题做讨论:


【问题1】 在开源产生之日起就有“开源开发者免责” 还能否、或在何种程度上行得通?


【问题2】开源项目是否要适用网络安全相关法律?特别是发现安全漏洞是否要履行上报义务?


【问题3】有涉欧业务的非欧盟企业发现漏洞先上报欧盟还是本国,本国不允许对外披露漏洞怎么办?


【问题4】开源基金会应当承担什么样的责任?


此外,我在文末给出两个具体例子,请大家思考研判。

了解过开源许可证的人都知道,几乎所有的开源许可证,都明明白白说了“不负责任”。

比如最常见的MIT协议⁴,是这么说的:

本软件系“按原样”提供,不包含任何形式的明示或默示保证,包括但不限于适销性、特定目的适用性及不侵权的保证。在任何情况下,无论是在合同、侵权或其他案件中,作者或版权持有人均不对因本软件、或因本软件的使用或其他利用而引起的、引发的或与之相关的任何权利主张、损害赔偿或其他责任承担责任。


开源项目作者是不是认为这样,就不会有任何外部麻烦了呢?


未必。


因为所有许可证,都得遵从法律,并不能突破法律的约束。如果有不一致的地方,以法律为准。


通常而言,开源项目的产出是软硬件,我们看看法律对软硬件规定了哪些安全要求。

在网安法中,最相关的是第二十二条:

第二十二条 网络产品、服务应当符合相关国家标准的强制性要求。网络产品、服务的提供者不得设置恶意程序;发现其网络产品、服务存在安全缺陷、漏洞等风险时,应当立即采取补救措施,按照规定及时告知用户并向有关主管部门报告。网络产品、服务的提供者应当为其产品、服务持续提供安全维护;在规定或者当事人约定的期限内,不得终止提供安全维护。网络产品、服务具有收集用户信息功能的,其提供者应当向用户明示并取得同意;涉及用户个人信息的,还应当遵守本法和有关法律、行政法规关于个人信息保护的规定。

在CRA中,最为概括性说明的是第1条:

本法规规定了 (a) 具有数字元素的产品在市场上的销售规则,以确保此类产品的网络安全; (b) 具有数字元素的产品的设计、开发和生产的基本要求,以及与这些产品相关的经济运营者在网络安全方面的义务;(c) 具有数字元素的产品的制造商关于漏洞处理流程的基本要求,以确保产品在整个生命周期内的网络安全,以及经济运营者对这些流程的义务;(d) 对上述规则和要求进行市场监控、监督和执行的规则。


当然,在其后的条款中,有着更为详细和具体的安全规定与要求。


仔细阅读,可以看出,这些法律法规,主要是说网络产品的制造者、提供者这些主体,应该保证产品是安全的,并且在发现漏洞后,要及时报告和处置。


那么,开源项目的产出是不是“网络产品”,是不是“具有数字元素的产品”呢?


尤其 是,作为一种最常见的情况,那些放在GitHub上的开源项目的产出,是不是法律所关注的产品?


这就需要细究对“产品”的定义。


然而,这并不容易。
网安法并没有给出“网络产品”的定义。


在国家标准《信息安全技术 网络产品和服务安全通用要求》(GB/T 39276—2020)中,对“网络产品”有定义,定义为:

网络产品:作为网络组成部分以及实现网络功能的硬件、软件或系统,按照一定的规则和程序实现信息的收集、存储、传输、交换和处理。


那么,不卖的是不是产品?我自己在家里做一个小的网络软件自己玩,算不算网络产品?


毕竟,开源项目中,绝大多数都是自己玩玩的,并没有考虑商业化。


在《现代汉语词典》⁵中,“产品”是“生产出来的物品”,而“生产”是指“人们使用工具来创造各种生产资料和生活资料”,从这些定义上看,他们关注的是产品这个东西的最本质属性,并没有关注这个东西是否用于销售。


《牛津高阶英汉双解词典》倒是说 product通常是用来销售的

Product:a thing that is grown or produced, usually for sale.


在大多数人的直觉感受上,法律所关心的“产品”,应该是制作出来用于销售的那些“产品”。


我翻了翻《民法典》,也没有找到对“产品”的定义,但在《中华人民共和国产品质量法》⁶中,发现了对“产品”的定义,它在第二条中,明确写道:


本法所称产品是指经过加工、制作,用于销售的产品。


虽然我不知道《产品质量法》中对产品的定义能否用在《网安法》中,但我认为大体上可以类比,在民法典和网安法中,也确实都提到了产品的“销售”,也都没有提及不用于销售的产品如何规范,所以, 我个人认为,网安法中的产品,应该不是泛指所有制作出来的物品,而更多是说指商业活动中的产品。


现在看看CRA。


CRA全文都是在描述对“具有数字元素的产品”(product with digital elements) 的要求,并在第3条给出了定义:

product with digital elements’ means any software or hardware product and its remote data processing solutions, including software or hardware components to be placed on the market separately;


翻译:“具有数字元素的产品”是指任何软件或硬件产品及其远程数据处理解决方案,包括单独投放市场的软件或硬件组件;


一样地,CRA对产品的定义,也是关心它的本质属性,而没有说是否用于销售。

但CRA在第2条明确说明了适用范围:


本法规适用于市场上提供的具有数字元素的产品,这些产品可以与设备或网络直接或间接数据连接。


这里明确了一点,但还是不够,因为“市场”未必一定是商业的,“市场”是需求和供给相遇并通过某种机制达成交换的场所,完全可以把GitHub认为是一个代码市场,程序员和用户在这里实现需求和供给的交换:有人需要代码,有人提供代码。


幸好,CRA在第3条中对“在市场上提供”也做了定义:

“在市场上提供”是指在商业活动中,无论是有偿还是免费,将带有数字元素的产品提供给联盟市场以供分发或使用。

这样,疑惑就完全解开了。法律中所说的“网络产品”、“具有数字元素的产品”,我认为,都明示或暗示了这样的条件:


所谓产品,是指用于商业活动的产品。


所以,对于那些并不参与任何商业活动,仅仅是放在GitHub或是类似的代码托管平台上的开源项目,法律是不管的。


但,开源项目一旦涉及商业活动,相关主体就要受到约束。


这就是开源商业化的代价。
在《网安法》中,最主要的受到约束的两个主体是“网络运营者”和 “网络产品、服务的提供者”


在网安法的附则中,对“网络运营者”有定义,“是指网络的所有者、管理者和网络服务提供者。”网安法对“提供者”没有定义,但这相对容易理解,提供者应该是指产品的生产者、经销者、集成者等。


在CRA中,涉及的主体主要是 “经济运营者”,主要是指制造商、进口商、分销商等,每个主体在CRA第3条中有定义。


这些主体的义务,正如本文前面所提到的,在法律条文中有明确而详细的规定。


综上,开源项目只有涉及商业活动,其相关主体才受到法律约束。


这就是对【问题1】的回答。


然而,现实要更复杂一点,什么是涉及商业活动?


举个例子,一个开源软件,同时提供社区版和企业版,那么其社区版是否涉及商业活动?
网安法没有明确提及这些,但CRA有说。


CRA不仅说了,而且把这个说得很清楚。


在其序言部分的第10条中,明确说道:


(10) 只有在商业活动过程中在市场上提供的自由和开源软件才应受本法规管辖。自由开源产品是否作为商业活动的一部分提供,应根据每个产品进行评估,同时考虑免费开源产品的开发模式和供应阶段。


(10a) 例如, 在完全去中心化的开发模式中,没有任何一个商业实体对项目代码库中接受的内容进行控制,这应该被视为该产品是在非商业环境中开发的。另一方面,如果自由和开源软件是由单个组织或不对等社区开发的,并且单个组织通过对其使用(与商业有关联)产生了收入,则应将其视为商业活动。同样,如果自由和开源项目的主要贡献者是商业实体雇用的开发人员,并且当这些开发人员或雇主可以控制代码库中接受哪些修改时,该项目通常应被视为商业性质。

(10b) 在供应阶段,自由和开源软件的商业活动可不只是对产品收费, 对技术支持收费也是商业活动,除非该收费只是为了收回实际成本;自由和开源软件的制造商提供一个软件平台并通过其他服务收费也是商业活动;出于除专门提高软件的安全性、兼容性或互操作性以外其他原因而使用个人数据也是商业活动;不以营利为目的接受捐赠不应被视为商业活动,除非此类捐赠是由商业实体提供的并且具有经常性。

(10c) 单独为自由和开源项目做出贡献的开发人员不应承担本法规规定的义务。


(10d) 仅仅在开放式代码库上提供对自由和开源软件的托管,该行为并不构成在市场上提供具有数字元素的产品。因此,大多数软件包管理器、代码托管和协作平台不应被视为本法规含义内的分销商。


(10e) ……如果产品制造商发现组件(包括免费和开源组件)中存在漏洞,则应通知该组件的开发人员,解决并修复该漏洞,并且在适用的情况下,为开发人员提供应用的安全修复。一旦制造商将产品投放市场,就应负责确保在整个支持期内处理产品中漏洞,包括其中集成的自由和开源组件。


以上几条,足以解决绝大多数关于开源项目是否涉及商业活动的困惑了。


比如,按照以上定义,GitHub不是市场,GitHub公司也不是分销商,无需承担CRA中所述的分销商义务。再比如,谷歌提供了Andriod平台但通过服务收费,属于受管辖范围;RedHat收取技术支持费,属于受管辖范围;XX社区版有助于XX企业版的销售,所以XX社区版被认定为涉及商业活动。 当然,这个认定,需要“根据每个产品进行评估”。


如果仅仅是对开源项目作出个人贡献,不适用CRA。


没有任何商业化行为的开源项目,也不受管束。


之所以这样做,原因很简单,也很符合常识,在序言第9a里面说,这是“为了促进自由和开源软件的开发和应用”。如果人家又不赚钱,你还要求人家做这个做那个,是不是太过分,以至于没人愿意再搞开源?


所以,我相信,不管是中国的立法者还是国外的立法者,都不至于真的强人所难。


多说一句,如果你是用别人的非商业化开源软件搞自己的商业化,别人不用负责,但你要为那个开源软件负责任。


简单地讲,谁挣钱谁负责任。


以上就是对【问题2】的回答。

这并不是个问题,因为怎么报、报给谁,法律或相关规定都有写得很明确,没有歧义。

比如在我国的《网络产品安全漏洞管理规定》中,第七条说明了产品提供者的义务:


第七条 网络产品提供者应当履行下列网络产品安全漏洞管理义务,确保其产品安全漏洞得到及时修补和合理发布,并指导支持产品用户采取防范措施:


(一)发现或者获知所提供网络产品存在安全漏洞后,应当立即采取措施并组织对安全漏洞进行验证,评估安全漏洞的危害程度和影响范围;对属于其上游产品或者组件存在的安全漏洞,应当立即通知相关产品提供者。


(二)应当在2日内向工业和信息化部网络安全威胁和漏洞信息共享平台报送相关漏洞信息。报送内容应当包括存在网络产品安全漏洞的产品名称、型号、版本以及漏洞的技术特点、危害和影响范围等。


(三)应当及时组织对网络产品安全漏洞进行修补,对于需要产品用户(含下游厂商)采取软件、固件升级等措施的,应当及时将网络产品安全漏洞风险及修补方式告知可能受影响的产品用户,并提供必要的技术支持……


CRA中则在第十一条的1a中说明了制造商的义务:


(a) 在制造商意识到存在被积极利用的漏洞后的 24 小时内发出早期警告,不得无故拖延,包括是否有任何已知的纠正措施或建议的风险缓解措施可用;

(b) 制造商应在意识到存在被积极利用的漏洞后 72 小时内发出漏洞通知,不得无故拖延,如果适用,应更新 (a)中的信息,包括采取的任何纠正措施或缓解措施,并指出漏洞的危害程度,包括其严重性和影响;

(c) 当纠正措施或缓解措施可用时,或当(b)发出后一个月内,应提交漏洞最终报告,至少应包括以下内容:


(1) 对漏洞的描述,包括其严重性和影响;(2) 如果有的话,给出已利用或正在利用漏洞的行为者的信息;(3) 为修复漏洞而提供的安全更新或其他纠正措施的详细信息。

其中,所谓“被积极利用的漏洞”,是指“有可靠证据表明攻击者在未经系统所有者许可的情况下在系统上执行了恶意代码的漏洞”。


对于有涉欧业务的中国企业,要注意学习CRA,按照如上要求及时报告,报告对象是ENISA(欧盟网络安全局)。


有人说,“对于有涉欧业务的中国企业,发现漏洞先上报欧盟还是我国,我国不允许对外披露漏洞怎么办?”这看似是一个难题,实则不然,处理起来也很简单。


第一,对于我国,要在2日内报。对于欧盟,要在24小时、72小时、一个月内报。


第二,并不冲突,漏洞管理规定只是说在第九条里说,“从事网络产品安全漏洞发现、收集的组织或者个人”“不得将未公开的网络产品安全漏洞信息向网络产品提供者之外的境外组织或者个人提供。 ”这里的被约束主体是专门从事漏洞发现和收集的组织和个人,而非“网络产品提供者”。在对提供者的要求中(见第七条),没有类似的约束。


也就是说,从漏洞管理规定上看,对于未公开的漏洞,发现者可以告诉产品提供者,但未公开前不能告诉产品提供者之外的境外组织和个人;有涉欧业务的产品提供者,一旦发现漏洞,不管是否已公开,没有说不能报告ENISA(欧盟网安局)。


因为,发现者可能远早于制造商知道漏洞,如果告诉境外某些组织或个人,可能给敌对方带来极大便利。而制造商知道漏洞后,必须第一时间告诉监管机构(不管境内境外),并抓紧给出修复或缓解方案,禁止制造商报告境外监管机构意义不大,除非我们不信任ENISA(比如认为ENISA会滥用漏洞信息)。


在这方面,这两个法规并不冲突。


这是对【问题3】的回答。
对这个问题,也要一事一议,要具体看一下某基金会的性质。


我们知道,基金会旗下有很多开源项目,基金会为其提供组织、法律和资金上的支持,那么,能否认为基金会就是开源软件的制造商或分销商?


对此,有人很焦虑,觉得一旦落入什么商,基金会可能无法承担起如此沉重的安全义务。


其实,我觉得并不难,虽然CRA并没有具体说基金会算什么性质,但在序言第10条中其实已经说明了:


如果“没有任何一个商业实体对项目代码库中接受的内容进行控制,这应该被视为该产品是在非商业环境中开发的。”


“不以营利为目的接受捐赠不应被视为商业活动,除非此类捐赠是由商业实体提供的并且具有经常性。”

一个基金会的项目,是不是有商业实体在对项目进行控制,基金会是不是以营利为目的接受捐赠,若涉及具体的案子,相信不难做出调查和判断。


比如ASF(Apache软件基金会),其宗旨⁷之一就是:


“项目独立于任何公司或组织的影响”


如果ASF真的是这样做的,那就显然不在CRA管束范围之内。


但有的基金会显然不是这样,这里就不点名了。


这是对【问题4】的回答。
下面提出两个具体问题,请读者思考:


1、“禅道”是一款研发项目管理软件,它有开源版和企业版,如果开源版发现了安全漏洞,禅道软件有限公司是否要履行法律中所规定的漏洞报告和漏洞修复义务?


2、2023年11月23日,特斯拉CEO埃隆·马斯克在个人微博上发布消息,宣布公司旗下初代特斯拉Roadster的原始设计和工程现已完全开源。那么,如果某公司用了这些开源技术出了严重事故,从法律上讲,马斯克要负责任吗?


作者:卫剑钒
2023.11.28



免责声明:
本文仅仅是从个人角度出发,对法律做的一般性研究,仅代表个人意见,请读者审慎阅读并自行甄别, 作者不就读者对任何依据本文采取的任何作为或不作为承担责任。

1.《中华人民共和国网络安全法》(https://baike.baidu.com/item/中华人民共和国网络安全法/16843044?fr=ge_ala) 


2. 欧盟议会的CRA修正案(2023年7月)(https://www.europarl.europa.eu/doceo/document/A-9-2023-0253_EN.html) 


3.《网络产品安全漏洞管理规定》(https://baike.baidu.com/item/网络产品安全漏洞管理规定/57980910?fr=ge_ala) 


4. 认识开源许可证—MIT 


5.《现代汉语词典》(第 7 版) 


6.《中华人民共和国产品质量法》(http://www.npc.gov.cn/zgrdw/npc/xinwen/2019-01/07/content_2070255.htm) 


7. Apache 项目成熟度模型 

上下滑动查看详情



转载自丨卫sir说

编辑丨胡欣元

相关阅读 | Related Reading

COSCon 的台前幕后:KCC@上海 12.2 活动总结
号外:欧盟就全球首个全面人工智能规则达成协议!(中英文对照)

开源社简介

开源社(英文名称为“KAIYUANSHE”)成立于 2014 年,是由志愿贡献于开源事业的个人志愿者,依 “贡献、共识、共治” 原则所组成的开源社区。开源社始终维持 “厂商中立、公益、非营利” 的理念,以 “立足中国、贡献全球,推动开源成为新时代的生活方式” 为愿景,以 “开源治理、国际接轨、社区发展、项目孵化” 为使命,旨在共创健康可持续发展的开源生态体系。


开源社积极与支持开源的社区、高校、企业以及政府相关单位紧密合作,同时也是全球开源协议认证组织 - OSI 在中国的首个成员。


自2016年起连续举办中国开源年会(COSCon),持续发布《中国开源年度报告》,联合发起了“中国开源先锋榜”、“中国开源码力榜”等,在海内外产生了广泛的影响力。



本文分享自微信公众号 - 开源社KAIYUANSHE(kaiyuanshe)。
如有侵权,请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”,欢迎正在阅读的你也加入,一起分享。

展开阅读全文
加载中
点击引领话题📣 发布并加入讨论🔥
打赏
0 评论
0 收藏
0
分享
返回顶部
顶部