毕春丽:非常高兴有这个机会跟大家一起分享关于知识产权风险内容。
这次分享的时间点对于今年来说也是意义非常重大,因为今年出现了一些非常有影响力的事件,在事件出现以后,大家都在想开源到底是否风险很大,它的风险会给使用开源软件的企业带来什么样的影响?在很多群里大家都在讨论,而且这些问题到底是什么样的,我今天从知识产权角度,从一些简单的案例来逐渐进行剖析它的一些知识产权的问题,还有我们作为开源应用的企业如何关注它的风险,从哪些角度进行关注。
今天演讲的内容是围绕三方面:
一、开源软件知识产权相关案例分析
二、开源软件知识产权风险
三、企业开源知识产权风险防控建议
我们在进行开源发生一些纠纷、发生一些问题时,一旦上升到法院角度时,有时候大家不知道到底用合同法还是用著作权法。如没有遵守开源协议,是否可以用合同法?侵权代码和源代码之间关系是否可以用著作权法呢?现在在很多法院、业界当中也是关注的一个问题,即应该用什么样的法律进行规制,因为不同的法律制约原告、被告进行侵权举证或进行自己本身防御举证时的路径和思路完全不一样,这是需要特别关注的一个问题。
案例,ARTIFEX诉HANCOM
这个软件本身是用于PDF可描述的编译软件,很多操作系统里都可以适用。这个软件是双许可证,既可以用开源的许可证,AGPLv3.0版本进行开源,还可以用商业许可证,也就是可以直接购买它的商业服务的许可证。这个软件本身是由ARTIFEX公司所拥有,在这个事件当中,HANCOM是一个韩国公司,在出售office软件当中同时搭载了ARTIFEX所研发的工具。在进行下载使用这个工具时,因为有两个许可证,一是没有要求购买商业软件的服务或没有花这个钱购买这个软件,二是没有按照开源许可协议要求进行修改的代码回馈给社区,ARTIFEX就控告HANCOM,希望把以前损害赔偿进行上诉。这个案件就是非常简单的不遵守开源许可协议。
我讲的重点是中间适用法律问题。在ARTIFEX提出两项指控:1.侵犯版权,因为没有购买我的商业许可证,也就是说这个版权是在我这里,你侵犯了我的版权;2.没有购买我的商业许可证,默认是使用开源许可证的软件,这个软件需要按照开源许可证GPL要求来做,但没有按照它的要求来做,所以构成违约或构成违反合同。这里指出控告既有版权内容,又有合同内容。
如何进行反驳?这个反驳非常有意思,1.认为在进行下载软件时没有切除任何东西,按照合同法约定,进行下载时没有人让我签署这个内容,没有承诺任何相关条款,不构成一个合同。2.在美国联邦版权法是优先于合同索赔,这里主要涉及到2008年的一个案例,在那个案例里,法官第一审按照合同法进行判,原告一直希望通过版权进行诉讼,二审最后结果是按照版权赔偿来结案的,所以得出结论:联邦版权法优先于合同法。
3.通过这两条,第二条不成立。被告发生侵权所在地不在美国,知识产权法是有地域性的,不管是版权、专利、商标都有地域性,正是因为在美国控告,但美国管不着我,版权法只能管在美国发生的侵权行为,所以版权也无法进行规制我,所以用这三条进行反驳原告一些指控。
最后法官认为如果用户没有得到商业许可证的同时,默认构成合同法的约束。所以最后这个案子结论是开源许可协议可以作为有约束力的合同,这也是开辟了我们后面对开源许可协议的看法。
这个案件对我们的启示:开源软件不是公有软件,不等同于免费软件,不意味着可以任意使用。网站上可以随意下载的软件,明确说是开源的话,一定要注意不是一个公有软件,这个案子里认为是公有软件,也有可能是一个故意行为。公有软件明确放弃一些版权或放弃对于这些版权经济上的回馈,但开源软件这些东西没有完全放弃,要遵循开源许可协议的一些要求。同时不等于免费软件,是需要有一些前提条件遵守开源协议。我们在使用开源软件时,一定要遵循开源协议,这个协议已经达成一个自动的合同,就要遵守合同里一些约定。
案例:MangoDB变更开源许可协议
MangoDB在很多云计算、云服务中用到很多数据库的内容,在整个查询功能里非常强大,很多互联网厂商也使用MangoDB来做数据库的服务功能。
MangoDB也是使用两个版本:1.开源版本。2.企业版本。这个事件是2018年10月16号之前使用的是AGPL条款,之后使用SSPL,翻译成中文就是属于服务器端公共许可证,也就是说明确说了许可证修改主要内容或方向将来要约束服务器端公共许可的内容。这个事件缘由和中国厂商也有一些关系。
有一个问题,开源许可协议是否能够随意更改?大家讲开源治理时,首先选择开源软件时要考察开源许可协议,考察完之后,忽然某一天又变了,这种风险如何进行考虑?
首先要清楚哪些类型的开源许可协议可以进行更改,就像MangoDB一样是一个企业主导,而且所有软件权利都归自己一家所有,是有权利进行更改许可协议的,还有可以进行闭源。还有一些是要根据开源许可协议社区的规定或基金会规定,首先看权利都在谁手里,再进行更改协议时也需要权利人或相关人一起同意后才能更改协议。大家要观察企业开源许可协议控制权都在谁手里。
现有这些更换许可协议的事件还是在整个开源发展过程中比较频繁的,所以大家在考虑开源风险、开源治理过程中也是需要关注的一个问题。
MangoDB开源许可协议到底更改了哪些内容?
AGPL就是一个传染性非常强的许可协议,更改的主要是第13条,更改内容具体是细化的里面一些具体对象和服务内容。如果将本程序或修改版本的功能作为服务提供给第三方,根据本许可协议规定,必须通过网络下载方式免费向所有人提供服务源代码。首先服务给第三方内容是什么,什么样的第三方包括在这个服务里,对原来AGPL网络交互内容进行细化;对服务源代码进行更具体详细的定义,对源代码所涉及的程序,如涉及一些管理软件、用户界面等,这些服务也都是需要遵守开源需要的。
接下来详细介绍为什么要从AGPL修改成SSPL的许可协议内容。这里最重要的内容就是因为我们在进行整个开源许可协议选择和大家在使用过程中还是要有一个遵守规则的意识。更改协议时,当时CEO发布的新闻,第一,是为了对竞争对手进行打击;第二,为了维护自己软件盈利的可能性。
这个事件出来以后,对开源社区一般使用者到底有没有风险,我们对整个开源社区来说,整个使用MangoDB的用户来说,仍然可以自由地使用、审查、修改、再发布源代码等等。这里影响大的是云服务商,云服务商在进行使用过程中只有这两种选择,要么公开源代码,要么购买MangoDB的商业版本。
这个事件就是更改开源许可协议的事件,但这个协议给予我们的启示很重要,首先大家要理解开源的游戏规则,就是一个软件代码或一个稍微成熟的大家都能接受的软件背后会付出很多劳动,不仅是开发员、程序员的劳动,还有涉及到开源社区的管理等等。这么多劳动很多不是纯粹的义务劳动,大家要有逐利的可能性,在这里要进行斟酌,不可能完全免费得到自己的利益,我们理解了它,就会选择开源软件应用自己产品过程中谨慎选择哪些可以用,哪些不可以用。
开源软件知识产权风险。
包括版权、专利、商标、商业秘密,从涉及到的开源许可协议里,讲的比较多的是版权的内容,这里还会涉及到第三方版权瑕疵,不经意间会流入到开源软件过程当中的风险。
这个专利有时候是防不胜防的东西,根据你所选择的开源协议、所选择的开源社区也有很大的关系,有可能会进行规避。其风险来自于内部的,根据开源社区做的过程中申请一些专利,外部是不受约束的第三方申请专利可能会受到将来索取权利的收费等风险。尤其大家在自己进行开源过程中也需要特别注意,把自己代码开放之前还是要注意先把代码相关内容如果能转化成专利,先转化成专利,然后再去开源,这些也是大家在开源过程中需要特别注意的。
商标也存在一些风险,使用未授权商标,如开源许可协议没有经OSI认证,不按开源许可规定,不该进行公开或披露的一些商标、商号在开源代码里体现进行宣传等等。
开源知识产权风险分析无外乎就三个维度,这三个维度来源于最基础的开源生态里的三个方面:
开源协议。在构建开源整个过程中的基本规则。商业运营模式,商业运营模式不同带来资产风险也不同,比如就做科研研究,就做内部研究,不进行对外商业,可能风险就很小或没有。但如果一旦进行商业化使用时,这里风险性可能就比较大。
开源社区管理。有些开源许可协议本身规定没那么多,有些开源社区希望把开源内容进行扩大化或进行更广泛的使用,它自己会做一些更详细的规定。
影响因素之一:开源许可协议
举例,开源许可协议版权专利商标和其他规避内容,从强传染性到弱传染性开源许可协议的内容中,强传染性GPL风险就很大呢?这和商业规模有一定关系,MangoDB等这些软件代码在一家公司或几家比较大的权利人所拥有时,可能为了保证整个软件一致性,选择GPL更多一些,一般选择双证的软件使用GPL也比较多一些,是为了更多卖商业的软件。给了强传染性,也给了其他知识产权的保证。BSD,用商业化软件是比较多的,但是专利、版权、商标都没有规定,相当于风险性非常大,因为不知道哪一天就会有人告你,所以大家使用时是一个辩证角度来看待这个问题。
影响因素之二:开源软件使用方式
是否访问源代码,如果不访问源代码,仅仅观看的话,风险很小。如果访问源代码,是否要进行修改?如果进行修改,还要考虑是否要进行传播,进行传播的话,将其原封不动或仅仅是将部分或修改一部分内容进行发布的话,这里也有很大风险的。进行商业化使用过程中,其风险性是我们需要着重进行考虑的。
这里还加上一条:是否对外提供服务。就牵涉到MangoDB的问题,要对它提供一些服务,这些也是需要考虑他的许可协议的规定。
影响因素之三:开源社区知识产权规定
除了开源许可协议知识产权规定以外,也会进行额外知识产权的规定,比如在Apache里,额外要求贡献者必须提交贡献者协议,贡献者协议目的是要保障提供进来的代码是纯洁的,不受侵权困扰的代码。在商标规定里也进行细化的内容,哪些可以使用,哪些不可以使用。这些开源社区的规定我们也在开源进行治理过程中需要着重看的一些内容。
开源知识产权风险大的框架从三个维度来看,一些比较细的内容还是需要我们根据自己商业用途和使用情况来进行选择。
建议。
要增强风险防范意识。
我们在调研过程中发现一些比较小的软件公司认为既然已经开源了,就没有任何风险或风险性很小。当然现在发生的这些纠纷,尤其在中国发生的纠纷还比较少,但并不排除这里就没有相关风险。当然我们也不要进行无谓扩大,现在80%以上的纠纷案例都会进行私底下的和解,所以我们要正确看待开源的知识产权风险。还要加强风险意识,不仅是知识产权的管理人员,更重要的是技术开发人员、管理者的风险意识。
进行风险防控体系里需要战略协同,我们要和产品、策略、成本控制等策略进行协同。还有部门之间进行协同,需要法务、技术、采购等多个部门一起协作,共同配合来工作。
在建立开源软件风险防控全流程管理体系里,从开源软件引入、开源软件开发、开源产品发布,都要按照流程来做,这些内容都需要大家在进行开源管理中注意的一些点。
企业开源进行风险防控内容中离不开法务工作者的工作,首先在准确解读开源许可协议规则里,因为很多开源许可协议都是英文版非常晦涩的法律术语,往往一个开源许可协议规定以后,后面有时候弄不清楚到底讲的是什么内容,就要看它的问答内容,而且有些内容需要结合技术术语、法律术语一起来理解,所以需要专门人员来做。
跟踪一些开源相关司法案例,了解现有法官或不同国家对开源的理解,如我们国家能否用合同法,在版权法里如何进行使用的。对于这些案件大家都要及时跟踪、及时了解。
风险防控建议,从意识体系到开源防控全流程管理到最后研究工作,我们也在做很多工作,已经和一些企业做相关服务,大家如果有相关问题的话,也可以和我们联系,大家一起进行解决。
《开源知识产权风险防控研究报告》马上会发布,我今天所讲的大部分内容在这个报告中都有,如果大家感兴趣的话可以关注一下我们中心的公众号,一旦我们院里审批通过以后,就会发布在公众号上,希望大家给我们提出一些宝贵的意见,大家共同营造开源生态健康的发展。
谢谢大家!