分类 开源智慧 下的文章

开源网络出版软件 WordPress 的联合创始人 Matt Mullenweg 日前表示,出于对 Facebook 开源许可证中专利条款的担忧,WordPress 社区将不再使用 Facebook 的 React JavaScript 库。

Mullenweg 在一篇博客文章中对其决定做出了解释。几个星期之前,即便是在 Apache 基金会表示了不再允许其项目使用 Facebook 许可证后,Facebook 还是决定保留其在 React 许可证中附加的专利条款。Mullenweg 认为,试图去删除该专利条款将“增加他们在对抗无事实根据的诉讼方面所花费的时间和费用”。

Mullenweg 表示,他不是在评论 Facebook 或者认为 Facebook 错了。Facebook 的决定对于 Facebook 来说是正确的,这是他们的工作,Facebook 可以决定以任何他们想要的方式来授权其软件。但对于 Mullenweg 来说,Facebook 的意图已经非常明确了。

几年之前,Automattic 将 React 作为基础来重写 WordPress.com 的前端 Calypso,这应该是基于 React 的最大的开源项目之一。正如 Automattic 的法律顾问所写,Automattic 做出了最好不要牵涉到专利问题的决定,在今天仍是如此。

总体来说,Mullenweg 过去一直对 React 很满意。最近,WordPress 社区开始将 React 用于 Gutenberg 项目,这是该社区多年以来最大的核心项目。人们在 React 方面的经验以及 React 社区(包括 Calypso)的规模,是 WordPress 将 React 用于 Gutenberg 项目的考虑因素之一。这使得 React 成为 WordPress 以及为 WordPress 编写的数以万计插件的事实上的标准。

Mullenweg 在博客里表示,WordPress 曾准备了一份几千字的公告,阐述了 React 是多么伟大,WordPress 如何正式采用了 React,以及鼓励插件同样采用 React。在该公告中,Mullenweg 一直希望专利问题能够以一种让用户放心使用的方式解决。

但这份公告现在不会被公布了。Mullenweg 表示,Gutenberg 项目将会退而采用另外的库来进行重写。这使得 Gutenberg 项目至少要延迟几个星期,其发布日期可能要推到明年。

Automattic 还将采用另外的同样的库来重写 Calypso,这将需要更长的时间。Automattic 目前还未牵涉到专利条款的问题当中。虽然会对业务造成短期影响,但是从内核的长期一致性来考虑,重写是值得的。WordPress 的内核升级涉及到全部网页的四分之一以上,让它们全部继承专利条款问题令人担忧。

Mullenweg 认为,Facebook 的专利条款实际上比许多公司可以采取的其他方法更清晰,Facebook 已经成为不错的开源贡献者之一。让全世界夸赞 Facebook 专利条款不是 Automattic 的工作,而是 Facebook 自己的战斗。

Mullenweg 在博客中表示,采用哪个库来重写将会在另外的帖子中公布,这主要是技术性的决定。Automattic 将会寻求具备 React 的大部分优势,同时又没有给许多人造成混淆和威胁的专利条款包袱的替代选择,并请大家就这些问题提供反馈。目前针对替换的库已经有了几个建议,包括 VueJS 、Preact 等。

另据 TechCrunch 报道,针对 Facebook 公司的专利条款,一些最激烈的批评家认为其将“特洛伊木马”引入了开源社区。对于 Mullenweg 在博客中发布的决定,一位评论家称之为“艰难但重要的决定”,其他评论家则将其称为“明智”和“有益”的决定。

而另外一些评论则发出了警告:“不要过度反应。过去五六年来,WordPress 生态系统的动荡和流失已经足够多了。Facebook 的业务规模和范围使得该条款变得非常可怕。它们最终必须放弃。”


译者简介:薛亮,集慧智佳知识产权咨询公司高级咨询师,擅长专利检索、专利分析、竞争对手跟踪、FTO分析、开源软件知识产权风险分析,致力于为互联网企业、高科技公司提供知识产权咨询服务。

Facebook 公司的 BSD+专利许可证失败的原因不是因为许可证本身,而是因为它忽略了开源软件更深层次的本质。

2017 年 7 月,Facebook 公司应用于 react 等项目的许可证组合被 Apache 软件基金会禁止使用。该许可证组合曾被 Facebook 应用于其所有作为开源软件发布的项目,它使用了被 OSI 批准的广泛使用的非互惠许可证 BSD 3-Clause,并且加入了宽泛的、非互惠的专利授权条款,但为了应对挑衅者,该许可证组合的终止规则同样宽泛。这种组合代表了一种新的开源许可证,我称之为“Facebook BSD+专利许可证”(FB + PL),在我看来,该许可证试图与 GPL v2 和 Apache v2 许可证保持兼容,以规避这些许可证所指称的不兼容性。

使用 FB + PL 许可证的 Apache 项目仍在发挥作用,但是我认为 Facebook 所犯错误的原因可能不会立即被一贯秉持实用主义态度的软件开发人员们所注意到。例如,由律师转行做程序员的 Dennis Walsh 针对这个问题表示:“它没有什么实质意义”。他的观点是,FB + PL 许可证仅对你所使用的适用该许可证的特定软件项目产生影响,专利授权撤回的后果对另一个专利持有者来说并不严重。他得出结论说:

“Facebook 想要推广开源软件同时不被起诉——这是一个崇高的目标。为此,它可以使用一些苛刻的条款。但在这种情况下,由于上述实践和法律方面的原因,很难在被攻击之后发现是谁干的。”

Dennis 也许是对的,但这并不重要。Facebook 自出机杼地发明自己的开源许可证是一个坏主意。有一系列非直接风险或具体情境的重要因素需要考虑,Facebook 的许可证几乎将它们完全忽略了。

  1. 许可证审批很重要
    使用非 OSI 批准的许可证意味着,就像任何专有许可证一样,将其应用于企业用途时总是需要法律审查。OSI 许可证审批之所以重要,是因为它为开发人员提供了一种指示,即社区评估已经认可了该许可证,并认为它以不会产生不可接受风险的方式提供了软件自由。如果 Facebook 采取了寻求 OSI 批准的路线,那么很有可能一开始就会发现并且回避了他造成的问题。实际上有一种 OSI 批准的许可证能够实现 Facebook 的明确目标(BSD + 专利许可证)。该许可证最近刚被提交和批准,这看起来是 Facebook 可以考虑采用的合理替代方案。
  2. 较少的提前许可
    不仅仅是许可证批准很重要。任何有关创新自由的不确定性都会阻碍开发人员使用代码。与使用相关的含糊条款在使用前需要消除歧义——该步骤相当于为了继续推进而寻求许可。出于同样的原因,公共领域对于软件开发者来说是不利的,因为使用条款规定了在采用之前需要寻求许可。由于需要向项目添加一个与 Facebook 相关的法律文件,每个企业开发人员现在都需要与法律顾问联系,才能继续推进。即使答案是“是的,可以”,他们仍然不得不停下来寻求许可。正如 Aaron Williamson 指出的那样,这可能不是他们的反应。
  3. 不公平的比赛场
    Facebook 使用的专利授权条款为其提供了特殊权利和保护,而项目中的其他人并不享有。这使得开源开发人员感到紧张,原因与 贡献者协议 contributor agreements 一样。开源项目的软件自由的全部价值在于它创造了一个安全的空间,在其中每个人都是平等的,它保护每个人免受他人动机的影响。刻意为自己设置额外权利是反社会的行为,可悲的是,开源社区有很多不平等权利最终被滥用的例子。
  4. 隐含的授权无效
    许多开源法律机构认为,通过对用于任何目的的软件使用授予许可,即使没有提及专利的许可证也隐含授予专利许可。通过添加任意形式的外部专利授权,Facebook 表示它不认为隐含授权足够(最好的情形)或存在(最差的情形)。专注于开源软件的律师们认为,这是 Facebook 毫无根据的扩大化解释。这也是为什么 OSI 放弃了对 CC0 许可协议批准的原因
  5. Apache 基金会的规则
    虽然我没有找到清晰和完整的理由,但 Apache 基金会似乎已经对 Facebook 的许可证组合做出了裁定,因为 Apache 基金会认为,Facebook 的专利授权比 Apache v2 许可证中的专利条款限制性更强。Apache 基金会希望自身是一个中立的软件来源——一个“万能供血者”,而对此产生妨害的条款很有可能违背其规则。对于旨在成为 Apache 生态系统一部分的组件,与 Apache 的许可证产生混乱的做法看起来不太明智。

所以争论这个问题没有什么意义,因为风险很小,问题微不足道。以一种忽视我上面列出的五个社区规范的方式行动无益于任何人,甚至也帮不了 Facebook。虽然 Facebook 目前正在坚持己见,但我希望它能够改正,我愿意提供帮助。


作者简介:Simon Phipps 是 “公开软件” Public Software 开源项目的发起人,以志愿者身份担任 OSI 和 文档基金会 The Document Foundation 的理事。

译者简介:薛亮,集慧智佳知识产权咨询公司高级咨询师,擅长专利检索、专利分析、竞争对手跟踪、FTO分析、开源软件知识产权风险分析,致力于为互联网企业、高科技公司提供知识产权咨询服务。

引子:开源软件作者发出求救

约一个月前,笔者撰写了“开源情怀遭遇专利咸猪手”。现在我们回一下锅:看看事情的进展,分析可能的结果,以期开源人再碰到类似状况时,对可能的发展能多一点预期和准备,少一点盲目性和不确定性。

事情是这样开始的:按照开源中国博客文章,一名开源软件作者发出求救的呼声,指出知名公司将他的开源软件 XXL-JOB 申请成了专利。

XXL-JOB 作者于 2017 年 6 月在他人提醒之后,发现他的作品 XXL-JOB 被他人申请了中国专利(CN201610843823.X)。

依照开源中国的另一篇博客文章,XXL-JOB 作者委托开源中国与专利申请人进行交涉,作者的基本诉求包括:申请人撤回专利申请并发布声明加以澄清。开源中国与作者进一步希望,如,申请人从事实和技术角度加以澄清,并提出如果专利授权,应声明其与有关开源项目的关系,并“无偿开源”等。

如笔者在前文中指出的,此事件很典型,无论在国内还是国外都不是孤立性事件。事情的根本在于:开源软件的开发者仅对自己智力劳动成果的知识产权做了很少的保留,将软件基本开放、贡献给公众无偿使用。而开发者的无私奉献却被一些人窃取或搭便车谋利:包括但不限于通过专利咸猪手式的手段侵占公用领域开源软件的全部或一部分,或是针对某些典型应用场景设下埋伏,迫使公众在使用开源软件时有可能侵犯相关专利权而需向他们缴纳费用。

从此事开始以及开源中国与专利申请人进行交涉的进展报告发出到现在,3 个多月过去了,没有进一步的实质性进展。笔者并不认为奇怪。为什么呢?

如何发展?我们来抽丝剥茧……

没有进展,就是双方谈不拢。开源作者及开源中国一方的要求总结如下:

作者的诉求包括:

  • 专利申请人向专利局申请撤销专利。
  • 以公司名义发布正面声明,客观的描述此事。

开源中国与作者对声明内容的要求是:

  1. 详细描述出现使用开源软件申请专利的管理不善问题,如果是在开源软件上做改进,那么应该详细描述改进的内容。
  2. 在声明中表明将公开宣布主动申请撤销专利。
  3. 如果专利撤销失败,已经授予,那么公司将发布另外声明,声明该专利基于某某开源项目,并将无偿开源。

从法律角度讲,双方对话行为属于民事行为,是基于双方自愿而进行的,任何一方都没有义务必须要进行对话协商。而如果对话不能进行,且当任何一方认为自己的正当权益受到对方损害时,可以向法院针对对方提起民事诉讼,也就是让法院做主。

专利申请人那头先按下不表,让我们看看作者一方的正当权益是否受到了损害。很遗憾,看来现在的主动权在专利申请人一边。

开源作者的要求:专利申请人向专利局申请撤销专利。

解读:如果专利申请是不正当的,上述要求是合理的。反之,则不合理。所以问题的关键是专利申请人所提出的专利申请是否正当。该问题随后再进行分析。

开源作者的要求:(专利申请人)以公司名义发布正面声明,客观的描述此事。

解读:公司就这个问题做出声明和澄清,从法律角度讲,公司可以自主做出决定,通常出于礼貌和善意的沟通,尤其不会产生负面影响时,公司会比较愿意进行。但法律方面没有强制要求,也就是说,专利申请人没有沟通或发出声明的义务,即使公司方面存在问题。而实际上,公司方面是否存在问题,即专利申请人所提出的专利申请是否正当,尚没有确定。

开源中国与作者对声明内容的要求 1:详细描述出现使用开源软件申请专利的管理不善问题,如果是在开源软件上做改进,那么应该详细描述改进的内容。

解读:“管理不善”应当是指专利申请人如果进行了不正当的专利申请,则是一个管理不善的问题。这就又转回到了那个关键问题:专利申请是否正当。

这句话是比较有意思的:“如果是在开源软件上做改进,那么应该详细描述改进的内容”。这句话字面之下似乎淡淡的有一层意思:如果专利申请针对的是在开源软件基础上做出的改进,那么专利申请可以是正当的。是否如此呢?答案基本上是肯定的。

如笔者前文中提到过的,按照专利制度的本意,任何人可以在现有的公知技术的基础上做出创新性的改进,然后就改进的内容去申请专利。这是正当的,也是受到鼓励和法律保护的。

关键问题的答案

所以,“专利申请是否正当”这个关键问题的答案就依赖于专利申请人是否做出了创新性的改进并就该改进来申请的专利,如果是,则专利申请是正当的;如果不是,就不正当。

接下来,就更加微妙了。开源方要求“细描述改进的内容”,仅就此要求而言,站在专利申请人立场上,是绝对不可以加以说明的。原因是:专利申请人就此内容的任何技术性说明都可能对申请人的专利构成不良影响。专利正在经受国家知识产权局的审查,审查的重点内容就是专利的新创性,也就是其对现有技术到底做出了什么样的改进,改进是否有新创性。专利申请人就此内容发表的任何意见,专利审查员都可以从中摘出对专利申请的新创性不利的内容,利用其来缩小专利的保护范围甚至驳回专利申请。

这种情形之下,申请人不针对“改进的内容”发表任何意见是明智、正当的。而开源方如果坚持要求申请人“细描述改进的内容”就显得强人所难,就不那么正当了。这时,开源方正确的做法是自己来完成开源软件作品与专利申请的比对,如果认为专利申请并未做出实质性的创新,可以将技术分析意见及相关支持性的技术文件按照第三方意见的形式通过正当程序提交给专利审查员。如果审查员认为开源方提出的意见是正确的,当然会加以采纳,相应会对专利申请加以合理限制或予以驳回。如果开源方对审查员的认定结果并不满意,后续还有行政和司法救济程序可以利用。

三点提示

这里提示的第一点是:不能简单因为专利申请当中涉及到的开源软件中采用的技术就直接认为专利申请中不存在新创性的技术改进。对新创性改进而得来的技术方案,在加以描述时要涉及到现有技术,这是正常的,不可避免的。

第二点:真正完成专利申请是否有实质性创新,专业性很强,成本很高;走行政和司法救济程序,成本就更高了。

第三点暂且不表。为什么事情还没有进展其实已经清楚了:专利申请人方面不表态是正当和必然的。至少要等到专利审查员做出授权或驳回的决定才有初步分晓。

开源中国与作者对声明内容的要求:

2、在声明中表明将公开宣布主动申请撤销专利。

3、如果专利撤销失败,已经授予,那么公司将发布另外声明,声明该专利基于某某开源项目,并将无偿开源。

解读:如果专利审查员做出授权决定,表明专利针对开源软件在内的现有技术做出了新创性改进,相应专利申请也就是正当的。既然是正当的,专利申请人想来不会撤销或放弃专利申请,也不会将辛苦得来的专利“开源”或开放给公众。如果专利审查员做出驳回决定,也就不存在专利申请人撤销或放弃专利申请的问题了。当然,如果有人发起后续行政、司法救济程序,则可能带来变数。

完整地讨论好问题,就要说到第三点:如果专利最终被行政或司法认定成没有新创性从而被驳回,是否就足以证明专利申请人恶意窃取开源软件的技术成果呢?如果没有充分的相关理由和证据,还真不好这么下结论。因为很可能专利申请人出于善意想做出发明,并认为自己已经做出了具有新创性的改进,而最终做出认定的国家知识产权局或法院对新创性的理解和要求与专利申请人不同,才得出了不具有新创性的结论。如果是这种情况,专利申请人只是犯了一个诚实的错误而并不具有恶意。

收尾,旧话重提

我看到,投身开源软件的有情怀的理想主义者,有一些在黑暗和不公的打击之下,愤而退出了开源事业。笔者非常理解他们。我还看到,更多的人无视这些打击,以不变的情怀和理想,在这条道路上继续栉风沐雨,砥砺前行。笔者非常敬佩他们。人间正道是沧桑。


作者:李可,江湖人称“可哥”,老牌专利代理人,集慧智佳知识产权咨询公司的知识产权高级咨询师。70 后文艺理工男,属牛,性子慢但踏实稳妥。

本文由高级咨询师薛亮据自由软件基金会(FSF)的英文原文翻译而成,这篇常见问题解答澄清了在使用 GNU 许可证中遇到许多问题,对于企业和软件开发者在实际应用许可证和解决许可证问题时具有很强的实践指导意义。

  1. 关于 GNU 项目、自由软件基金会(FSF)及其许可证的基本问题
  2. 对于 GNU 许可证的一般了解
  3. 在您的程序中使用 GNU 许可证
  4. 依据 GNU 许可证分发程序
  5. 在编写其他程序时采用依据 GNU 许可证发布的程序
  6. 将作品与依据 GNU 许可证发布的代码相结合
  7. 关于违反 GNU 许可证的问题

2、对于 GNU 许可证的一般了解

2.1 为什么 GPL 允许用户发布其修改版本?

自由软件的一个关键特点是用户可以自由合作。绝对有必要允许希望彼此帮助的用户与其他用户分享他们对错误的修复和改进。

有些人提出了 GPL 的替代方案,需要原作者批准修改版本。只要原作者持续进行维护,这种做法在实践中可能会不错,但是如果作者停止维护(或多或少会)去做别的事情,或并不打算去满足所有用户的需求,这种替代方案就会失败。除了实践上的问题之外,该方案也不允许用户之间互相帮助。

有时候对修改版本的控制,是为了防止用户制作的各种版本之间造成混淆。根据我们的经验,这种混乱不是一个大问题。在 GNU 项目之外出现了许多版本的 Emacs,但用户仍可以将它们区分开。GPL 要求版本创造者将他/她的名字标注其上,以区别于其他版本,并保护其他维护者的声誉。

2.2 GPL 是否要求将修改版本的源代码公开发布?

GPL 不要求您发布修改后的版本或其中的任何一部分。您可以自由地进行修改并私人使用它们,而无需进行发布。这也适用于组织(包括企业);组织可以制作修改版本,在内部使用它,并且绝不将修改版本发布到组织之外。

但是,如果您以某种方式向公众发布修改后的版本,依据 GPL 许可证,GPL 要求您保证程序的用户可以获得修改后源代码。

因此,GPL 给你以某些特定方式发布修改后的程序的授权,而不是以其他方式发布;但是,是否发布修改版本的决定取决于您。

2.3 我可以在同一台电脑上安装一个遵循 GPL 许可证的程序和一个不相关的非自由程序吗?

可以。

2.4 如果我知道某些人有一个遵循 GPL 许可证的程序的副本,我可以要求他们给我一个副本吗?

不可以,GPL 给人们制作和再分发程序副本的授权,倘若有人选择这样做的话。那个人也有权选择不去再分发该程序。

2.5 GPL v2 中的“ 书面文件 written offer 对任何第三方有效”是什么意思? 这是否意味着世界上每个人都可以获得任何遵循 GPL 许可证的程序的源代码?

如果您选择通过书面文件提供源代码,那么任何向您索求源代码的人都有权收到。

如果您对不附带源代码的二进制文件进行商业分发,GPL 要求您必须提供一份书面文件,表明将稍后分发源代码。当用户非商业性地再分发他们从您那里获取的二进制文件时,他们必须传递这份书面文件的副本。这意味着不能直接从您那里获取二进制文件的人,仍然可以收到源代码副本以及该书面文件。

我们要求书面文件对任何第三方有效的原因是,以这种方式间接收到二进制代码的人可以从您那里订购源代码。

2.6 GPL v2 中规定,发布后的修改版本必须“授予…所有第三方许可”。这些第三方是谁?

第 2 节中规定,依据 GPL,您分发的修改版本必须授权给所有第三方。 “所有第三方”当然是指所有人,但这并不要求您为他们任何事情。这仅仅意味着他们依据 GPL 从您那里获得了您的修改版本的许可。

2.7 GPL 允许我出售程序的副本以获利吗?

是的,GPL 允许每个人这样做。销售副本的权利是自由软件定义的一部分。除了一种特殊情况之外,对您可以收取什么样的价格是没有限制的。(这种例外情况是:二进制版本必须附有表明将提供源代码的书面文件。)

2.8 GPL 允许我从我的分发网站收取下载程序的费用吗?

允许。您可以对您分发程序副本收取任何您想收取的费用。如果您通过下载分发二进制文件,则必须提供“等同的访问权限”来让人们下载源代码,因此,下载源代码的费用可能不会超过下载二进制文件的费用。

2.9 GPL 允许我要求任何接收软件的人必须向我支付费用和/或通知我吗?

不允许。实际上,这样的要求会使程序变成非自由软件。如果人们在获得程序副本时必须支付费用,或者他们必须特别通知任何人,那么这个程序就不是自由软件。请参阅自由软件的定义

GPL 是自由软件许可证,因此允许人们使用甚至再分发软件,而不需要向任何人支付费用。

您可以向用户收取费用,以获取您的副本。当他们从别人那里获得副本时,您不能要求人们向您支付费用。

2.10 如果我收费分发遵循 GPL 的软件,我是否还需要向公众免费提供?

不需要。不过,如果有人向您支付费用并获得副本,GPL 给予他们免费或收费向公众发布的自由。例如,有人可以向您支付费用,然后把他的副本放在一个网站上,让公众去获取。

2.11 GPL 允许我根据保密协议分发副本吗?

不允许。GPL 规定,任何从您那里获取副本的人都有权再分发已修改或未修改的副本。您不得在任何更严格的基础上分发作品。

如果有人要求您签署保密协议(NDA),以获取来自 FSF 的遵循 GPL 的软件,请立即通知我们 mailto:[email protected]

如果违规行为涉及其他版权所有者的遵循 GPL 的代码,请通知该版权所有者,就像您对其他任何类型的 GPL 违规行为所做的工作一样。

2.12 GPL 允许我根据保密协议分发程序的修改版或测试版吗?

不可以。GPL 规定,您的修改版本必须具备 GPL 中规定的所有自由。因此,从您那里获取您的版本副本的任何人都有权再分发该版本的副本(已修改或未修改)。您不得在更严格的基础上分发该作品的任何版本。

2.13 GPL 是否允许我根据保密协议开发程序的修改版本?

可以。例如,您可以接受一份合同来开发修改版本,并同意不得发布您的修改版本,直到客户同意才可以发布。这是允许的,因为这种情况下不处于 GPL 协议之下的代码是依据 NDA 分发的。

您还可以依据 GPL 将您的修改版本发布给客户,但须同意不将其发布给其他任何人,除非客户同意。也同样在这种情况下,不处于 GPL 协议之下的代码是以保密协议或任何其他限制条款分发的。

GPL 将给予客户再分发您的版本的权利。在这种情况下,客户可能会选择不行使这项权利,但他确实拥有这项权利。

2.14 为什么 GPL 要求程序的每个副本必须包含 GPL 许可证副本?

作品包含许可证副本至关重要,因此获得程序副本的每个人都可以知道他们的权利是什么。

包括一个指向许可证的 URL,而不是将许可证本身包含在内,这是一种看起来很诱人的做法。但是您不能确定该 URL 在五年或十年后仍然有效。二十年后,我们今天所知道的 URL 们可能已不复存在。

不管网络将发生什么样的变化,确保拥有该程序副本的人员能够继续看到 GPL 许可证的唯一方法是,将许可证的副本包含在该程序中。

2.15 如果作品不是很长,那该怎么办?

如果整个软件包中只有很少的代码——我们使用的基准是不到 300 行,那么您可以使用一个宽松的许可证,而不是像 GNU GPL这样的 Copyleft 许可证(除非代码特别重要)。我们建议这种情况使用 Apache License 2.0

2.16 我是否需要将我对遵循 GPL 的程序所做的修改声明版权?

您不需要对您的修改声明版权。不过,在大多数国家/地区,默认情况下会自动获得版权,因此,如果您不希望修改受到版权限制,您需要将修改明显地放置于公有领域。

无论您是否对您的修改声明版权,依据 GPL,您都必须将修改版本作为整体发布(参见:2.2 GPL 是否要求将修改版本的源代码公开发布?)。

2.17 GPL 对于将某些代码翻译成不同的编程语言是如何规定的?

根据著作权法,翻译工作被认为是一种修改。因此,GPL 对修改版本的规定也适用于翻译版本。

2.18 如果一个程序将公有领域代码与遵循 GPL 的代码相结合,我可以取出公有领域的部分,并作为公有领域代码来使用吗?

您可以这样做,如果您能弄清楚哪个部分是公有领域的部分,并将其与其他部分区分开。如果代码曾经由其开发人员放置在公有领域,那么它就是公有领域代码,无论它现在究竟在哪里。

2.19 我想要因我的作品获得声誉。我想让人们知道我写了什么,如果我使用 GPL,我还能获得声誉吗?

您一定能获得这份作品的声誉。遵循 GPL 发布的程序的一部分是以您自己名义撰写的版权声明(假设您是版权所有者)。GPL 要求所有副本携带恰当的版权声明。

2.20 GPL 允许我添加条款,要求在使用遵循 GPL 的软件或其输出物的研究论文中包含引用或致谢吗?

不可以,根据 GPL 的规定,这是不允许的。虽然我们认识到适当的引用是学术出版物的重要组成部分,但引用不能作为对 GPL 的附加要求。对使用 GPL 软件的研究论文要求包含引用,超出了 GPL v3 第 7(b)条中可接受的附加要求,因此将被视为对 GPL 第 7 节的额外限制。而且版权法也不允许您在软件的输出物中设置这样的要求,无论该软件是依据 GPL 还是其他许可证的条款获得许可。

2.21 为了节省空间,我是否可以省略 GPL 的引言部分,或者省略如何在自己的程序上使用GPL的 指导 instructions 部分吗?

引言和指导是 GNU GPL 的组成部分,不能省略。事实上,GPL 是受版权保护的,其许可证规定只能逐字复制整个 GPL。(您可以使用法律条款制作另一个许可证,但该许可证不再是 GNU GPL。)

引言和指导部分共约 1000 字,不到 GPL 总文字数量的 1/5。除非软件包本身很小,否则引言和指导不会对软件包的大小产生大幅度的改变。在软件包很小的情况下,您可以使用一个简单的 全权 all-permissive 许可证,而不是 GNU GPL。

2.22 两个许可证“兼容”是指什么?

为了将两个程序(或它们的实质部分)组合成一个更大的作品,您需要有以组合方式使用这两个程序的权限。如果两个程序的许可证允许这种使用方式,则它们是兼容的。如果没有办法同时满足这两个许可证,则它们是不兼容的。

对于一些许可证,组合的方式可能会影响它们是否兼容,例如,它们可能允许将两个模块链接在一起,但不允许将其代码合并到一个模块中。

如果您只想在同一个系统中安装两个独立的程序,那么它们的许可证并不是必须兼容的,因为它们没有组合成更大的作品。

2.23 许可证与 GPL 兼容是什么意思?

这意味着其他许可证和 GNU GPL 兼容;在一个更大的程序中,您可以将根据其他许可证发布的代码与根据 GNU GPL 发布的代码进行组合。

所有 GNU GPL 版本都允许进行这种组合;它们还允许分发这些组合,只要该组合在相同的 GNU GPL 版本下发布。其他许可证如果允许这样做,则其与 GPL 兼容。

与 GPL v2 相比,GPL v3 与更多的许可证兼容:它允许您与具有特定类型附加要求(GPL v3 本身不包含)的代码进行组合。GPL v3 第 7 节中有关于此问题的更多信息,包括了允许的附加要求的列表。

2.24 为什么原始的 BSD 许可证与 GPL 不兼容?

因为它规定了 GPL 不包含的具体要求,即对程序广告的要求。GPL v2 第 6 节规定:

您不得对接受者行使本协议授予的权利施加进一步的限制。

GPL v3 在第 10 节中提到类似的内容。广告条款正好提供了这样一个限制,因此与 GPL 不兼容。

修订的 BSD 许可证没有广告条款,从而消除了这个问题。

2.25 “ 聚合 aggregate ”与其他类型的“修改版本”有什么区别?

“聚合”由多个单独的程序组成,分布在同一个 CD-ROM或其他媒介中。GPL 允许您创建和分发聚合,即使其他软件的许可证不是自由许可证或与 GPL 不兼容。唯一的条件是,发布“聚合”所使用的许可证不能禁止用户去行使“聚合”中每个程序对应的许可证所赋予用户的权利。

两个单独的程序还是一个程序有两个部分,区分的界限在哪里?这是一个法律问题,最终由法官决定。我们认为,适当的判断标准取决于通信机制(exec、管道、rpc、共享地址空间内的函数调用等)和通信的语义(哪些信息被互换)。

如果模块们被包含在相同的可执行文件中,则它们肯定是被组合在一个程序中。如果模块们被设计为在共享地址空间中链接在一起运行,那么几乎肯定意味着它们组合成为一个程序。

相比之下,管道、套接字和命令行参数是通常在两个独立程序之间使用的通信机制。所以当它们用于通信时,模块们通常是单独的程序。但是,如果通信的语义足够亲密,交换复杂的内部数据结构,那么也可以视为这两个部分合并成了一个更大的程序。

2.26 为什么 FSF 要求为 FSF拥有版权的程序做出贡献的贡献者将版权 分配 assign 给 FSF?如果我持有 GPL 程序的版权,我也应该这样做吗?如果是,怎么做? (同1.11)

我们的律师告诉我们,为了最大限度地向法院要求违规者强制执行 GPL,我们应该让程序的版权状况尽可能简单。为了做到这一点,我们要求每个贡献者将贡献部分的版权分配给 FSF,或者放弃对贡献部分的版权要求。

我们也要求个人贡献者从雇主那里获得版权放弃声明(如果有的话),以确保雇主不会声称拥有这部分贡献的版权。

当然,如果所有的贡献者把他们的代码放在公共领域,也就没有用之来执行 GPL 许可证的版权了。所以我们鼓励人们为大规模的代码贡献分配版权,只把小规模的修改放在公共领域。

如果您想要在您的程序中执行 GPL,遵循类似的策略可能是一个好主意。如果您需要更多信息,请联系mailto:[email protected]

2.27 如果我使用遵循 GNU GPL 的软件,那么允许我将原始代码修改为新程序,然后在商业上分发和销售新程序吗?

您被允许在商业上出售修改程序的副本,但仅限于在 GNU GPL 的条款之下这么做。因此,例如,您必须依照 GPL 所述,使得程序用户可获取源代码,并且,用户也依照 GPL 所述,被允许再分发和修改程序。

这些要求是将遵循 GPL 的代码包含在您自己的程序中的条件。

2.28 我可以将 GPL 应用于软件以外的其他作品吗? (同1.6)

您可以将 GPL 应用于任何类型的作品,只需明确该作品的“源代码”构成即可。GPL 将“源代码”定义为作品的首选形式,以便在其中进行修改。

不过,对于手册和教科书,或更一般地,任何旨在教授某个主题的作品,我们建议使用 GFDL,而非 GPL。

2.29 我想依据 GPL 授权我的代码,但我也想明确指出,它不能用于军事和/或商业用途。我可以这样做吗?

不可以,因为这两个目标相互矛盾。GNU GPL 被专门设计为防止添加进一步的限制。GPL v3 在第 7 节允许非常有限的一组附加限制,但是用户可以删除任何其他添加的限制。

2.30 我可以依据 GPL 来对硬件进行许可吗?

任何可以受版权保护的 材料 material 都可以依据GPL进行许可。GPL v3 也可以用于受其他类似版权法的法律保护的材料,如半导体掩模。因此,作为一个例子,您可以依据 GPL 发布物理对象的图纸或电路。

在许多情况下,版权不涵盖依照图纸制作的物理硬件。在这种情况下,无论您使用什么许可证,您对图纸的许可都不能对制造或销售物理硬件施加任何控制。当版权不涵盖利用 IC 掩膜等进行硬件制作时,GPL 能以有效的方式处理这种情况。

2.31 将遵循 GPL 的二进制文件 预链接 prelinking 到系统上的各种库,以优化其性能,将被视为修改吗?

不。 预链接 prelinking 是编译过程的一部分;与编译过程所涉及的其他各个方面相比,预链接没有引入更多的许可证要求。如果您被允许将程序链接到各种库,那么也可以预链接到各种库。如果您分发预链接后的目标码,则需要遵循第 6 节的条款。

2.32 LGPL 如何与 Java 配合使用?

详情请参阅这篇文章。LGPL 如同被设计、被预想、被期待的那样去工作。

2.33 为什么你们在 GPL v3 中发明新的术语“ 传播 propagate ”和“ 传递 convey ”?

(译者注:convey 这个词汇在一个 GPL 译本中被翻译为“转发”,此处,我们认为“转发”一词在计算机领域存在一定的歧义,因此,采用“传递”的翻译。)

GPL v2 中使用的“分发”一词来自美国版权法。多年来,我们了解到,一些司法管辖区在自己的版权法中使用了同一个词,但却给出了不同的含义。我们发明了这些新术语,无论在何处对许可证进行解释,都使我们的意图尽可能清楚。这些新术语没有使用在世界上的任何版权法中,我们直接在许可证中提供了它们的定义。

2.34 在GPL v3中的“ 传递 convey ”与GPL v2中的“ 分发 distribute ”意思一样吗?

是的,差不多是一个意思。在执行 GPL v2 的过程中,我们了解到一些司法管辖区在自己的版权法中使用了“分发”这个词,但给出了不同的含义。我们发明了一个新的术语,以使我们的意图清晰,避免这些差异可能引起的任何问题。

2.35 如果我只复制遵循 GPL 的程序并运行它们,而不分发或传递给其他人,许可证对我施加什么要求?

没有要求。GPL 不对此活动附加任何条件。

2.36 GPL v3将“向公众提供”作为 传播 propagate 的一个例子。这是什么意思? 是提供一种可获取的传递形式吗?

“向公众提供”的一个例子是将该软件放在公共网页或FTP服务器上。在您这样做之后,在任何人从您那里真正获取软件之前,可能会需要一段时间,但是由于这种情况可能会立即发生,您也需要能够立即履行 GPL 的义务。因此,我们将“ 传递 convey ”定义为包括这一活动。

2.37 鉴于分发和向公众提供作为传播形式,同样也构成了 GPL v3 中的“ 传递 conveying ”,那么有哪些传播的例子不构成传递吗?

为自己制作软件的副本是不构成“传递”的主要传播形式。您可以依此在多台计算机上安装软件,或进行备份。

2.38 GPL v3 如何让 BitTorrent 分发变得更容易?

因为 GPL v2 是在软件的点对点分发普及之前编写的,所以当您利用这种方式分享代码时,很难满足 GPL v2 的要求。在 BitTorrent 上分发 GPL v2 目标代码时,确保您合规的最佳方法是将所有相应的源代码包含在相同的 种子文件 Torrent 中,但这种方式代价高昂。

GPL v3 以两种方式解决了这个问题。首先,作为该过程的一部分,下载此种子文件并将数据发送给其他人的人不需要做任何事情。因为第 9 节规定:“受保护作品的辅助传播如果仅仅是使用点对点传输来接收副本,不需要接受[本许可证]。”

第二,通过告知接收人在公共网络服务器上哪里可获取,GPL v3 的第 6(e)节旨在给予分发者(最初制作种子文件的人)一种清晰、直观的方式来提供源代码。这样可以确保每个想要获取源代码的人都可以如此获取,而且分发者几乎不用担心。

2.39 什么是 TiVo化 tivoization ? GPL v3 对此如何防止?

一些设备使用可升级的自由软件,但被设计为用户不能修改该软件。有很多不同的方式可以做到这一点;例如,有时硬件校验所安装的软件,如果与预期签名不匹配,则关闭软件。制造商通过提供源代码来遵循GPL v2,但是您仍然无法自由修改您使用的软件。我们称这种做法为 TiVo 化 tivoization

当人们分发包含遵循 GPL v3 软件的“ 用户产品 User Products ”时,第 6 节要求他们为您提供修改该软件所需的信息。“用户产品”是该许可证特别定义的术语;“用户产品”的示例包括便携式音乐播放器、数字录像机和家庭安全系统。

2.40 GPL v3 是否禁止 DRM?

不禁止,您可以使用遵循 GPL v3 发布的代码来开发您喜欢的任何类型的 DRM 技术。不过,如果您这样做,第 3 节规定,系统不会被视为一种有效的技术“保护”措施,这意味着如果有人破坏了 DRM,他也可以自由分发他的软件,不受《美国数字千禧版权法》(DMCA)和类似法律的限制。

像往常一样,GNU GPL 并不限制人们在软件中怎么做,只是阻止他们限制他人。

2.41 GPL v3 是否要求投票人能够修改在投票机中运行的软件?

不要求。企业分发包含遵循 GPL v3 软件的设备,最多只需要为拥有目标代码副本的人提供软件的源代码和安装信息。使用投票机(如同任何其他信息亭一样)的选民不能拥有它,甚至不能暂时拥有,所以选民也不能拥有二进制软件。

不过,请注意,投票是一个非常特殊的情况。仅仅因为计算机中的软件是自由软件,并不意味着您可以信任计算机,并进行投票。我们认为电脑不值得信任,不能被用作投票。投票应在纸上进行。

2.42 GPL v3 是否包含“专利报复条款”?

实际上,是的。第 10 节禁止传递该软件的人向其他被许可人发起专利诉讼。如果有人这样做,第 8 节解释他们将如何丧失许可证权益以及与之伴随的所有专利许可。

2.43 在 GPL v3 和 AGPL v3中,当说到“尽管有本许可证的其他规定”时,是什么意思?

这仅仅意味着以下条款胜过许可证中可能与之冲突的其他任何内容。例如,如果没有该文本,有些人可能声称,您不能将遵循 GPL v3 的代码与遵循 AGPL v3 的代码结合在一起,因为 AGPL 的附加要求将被归类为 GPL v3 第 7 节下的“进一步限制”。该文本明确表示我们的预期解释是正确的,您可以进行组合。

该文本仅解决许可证不同条款之间的冲突。当两个条件之间没有冲突的时候,您必须同时满足它们。这些段落不允许您轻率地忽略许可证的其余部分,它们只是强调了一些非常有限的例外。

2.44 在 AGPL v3 中,怎么才算是“通过计算机网络远程与[软件]进行交互”?

如果程序被明确设计为接受用户请求并通过网络发送响应,则它符合这些标准。属于此类程序的常见示例包括网络和邮件服务器、交互式网络应用程序和在线游戏的服务器。

如果程序没有被明确设计为通过网络与用户进行交互,而是恰好在这样做的环境中运行,那么它不属于此类。例如,仅仅因为用户通过 SSH 或远程 X 会话来运行的应用程序不需要提供源代码。

2.45 GPL v3 中“ you ”的概念如何与 Apache License 2.0 中“ 法律实体 Legal Entity ”的定义相比较?

它们是完全相同的。Apache License 2.0 中“法律实体”的定义在各种法律协议中是非常标准的,因此,如果法院在缺乏明确定义的情况下没有以同样的方式解释该术语,将会令人非常惊讶。我们完全期待他们在看 GPL v3 时也会如此,并考虑到谁有资格作为被许可人。

2.46 在 GPL v3 中,“ 该程序 the Program ”是指什么? 是每个依据 GPL v3 发布的程序?

术语“该程序”是指依据 GPL v3 进行许可的特定作品,由特定被许可人从上游许可人或分发者那里接收。“该程序”是您在 GPL v3 许可的指定情境下接受到的特定软件作品。

“该程序”并不意味着“依据 GPL v3 进行许可的所有作品”;由于一些原因,这种解释没有任何意义。针对那些想要了解更多的人,我们已经发表了对“该程序”一词的分析

2.47 如果某些网络客户端软件依据 AGPL v3 发布,是否必须能够向与之交互的服务器提供源代码?

AGPL v3 需要该程序向“所有通过计算机网络进行远程交互的用户”提供源代码。至于您将程序称为“客户端”还是“服务器”,那无关紧要。您需要询问的问题是,是否存在合理的期望让一个人通过网络远程与该程序交互。

2.48 对于一个运行在代理服务器上的依据 AGPL 进行许可的软件来说,如何向与该软件交互的用户提供源代码书面文件?

对于代理服务器上的软件,您可以通过向此类代理的用户传递消息的常规方法来提供源代码书面文件。例如,Web 代理可以使用登录页。当用户最初开始使用代理时,您可以将他们引导到包含源代码书面文件以及您选择提供的任何其他信息的页面。

AGPL 规定,您必须向“所有用户”提供书面文件。如果您知道某个用户已经被展示过书面文件,对于当前版本的软件,您不必再重复向该用户提供。

本文撰写参考了以下文章,并引用了该文章部分内容:专利告诉你,为何 Apache 禁用 FB + PL 代码,作者:付钦伟。

哪里有压迫,哪里就有反抗

身为知识产权圈里的专利人,笔者钦佩开源情怀,并曾写道:即使专利人也有专利情怀,现实世界中开源与专利的碰撞依然难免丑陋。现在看来,这话有点轻描淡写了。

笔者未能认真发掘开源运动史,只好拍拍脑袋认定:开源软件运动是针对知识产权制度,尤其是专利制度,对软件产业之压迫的暴动。

“哪里有压迫,哪里就有反抗。”

这场轰轰烈烈的暴动在发展过程中,于 2017 年 7 月,“Apache Software Foundation 主管兼法律事务副主席 Chris Mattmann 正式发表声明称:Facebook BSD+Patents license(以下简称 FB+PL)已经正式被列入 “CategoryX” 列表,因此 Apache 项目中将不能够包含或依赖于 Facebook Patents license 的代码;而已经发布的代码,涉及 FB+PL 许可证的,需要在 8 月 31 号前完成替换。”

简而言之,Apache 一脚将 FB+PL 踢出了。这是不是 Apache 在开源暴动中的激进声明?为什么这么说?

专利情怀

故事要从头讲起:

专利制度产生了,那时候大家并不认为这是一个万恶的吃人的制度。专利制度的根本目的还是促进技术进步,从而推动产业和经济发展。为了达成此目的,则需要合理保护发明人的积极性,具体而言,就是给予他们一定时期的专有保护为回报,在这种利益驱动下,他们会积极的做出发明,并通过申请专利,在向社会公布技术促进技术进步的同时,兑现专有保护。

"Before then [the adoption of the United States Constitution], any man might instantly use what another had invented; so that the inventor had no special advantage from his own invention. The patent system changed this; secured to the inventor, for a limited time, the exclusive use of his invention; and thereby added the fuel of interest to the fire of genius, in the discovery and production of new and useful things. "

-- Abraham Lincoln, Second lecture on discoveries and inventions, February 11, 1859

以上这段诠释了专利情怀的话出自美国总统林肯的演讲。只需要读懂这个短句就好了:专利制度为天才之火添上利益之油。

开源与专利的碰撞

到上世纪 90 年代,专利海盗开始大行其道,软件产业受害最深。在软件行业里,程序员和开发者需要开放、自由地交流和利用彼此的成果才利于行业发展。这一特性先天与专利制度八字不合。这个死结是一百多年的林肯总统绝对意料不到的。

从根本上,开源情怀在于:对于自己的智力劳动成果,放弃可取得收益的专有权利,给软件松绑,从而利于成果的流通、利用,以及行业发展。

绑在软件身上的主要知识产权绳索有两条:版权,专利。商标不起核心作用。解开版权这条绳索的方式比较成熟:版权开源许可证。而专利很微妙,最主要的原因是它的无形,主动权常常不在开源作者自己手里。版权是属于作者的,所以作者有主动权;而专利属于申请人,申请人有主动权,申请人可以是任何第三方。这是开源与专利之矛盾的根源。

对开源情怀的最大伤害在于:不知道是谁用专利这根无形绳索悄悄捆绑了自己的作品。这是开源人对专利的敏感和敌视的由来。开源人常常感到愤怒和难以理解的是:为什么自己的智力成果,别人可以用专利来捆上?

对不起,这一个很让人遗憾的回答:任何人都可以对包括已公开的开源技术在内的任何现有技术做出改进,并就改进获得专利权。而当有别人在某项开源技术比较可行的主要改进方向上都申请了专利,就相当于把主要出路都卡上了,那么这项开源技术也就被别人的专利绑上了。这种专利申请技术,在圈内有一个好听的名字:专利布局。防御性的专利布局可以用来对自己的技术成果形成严密保护。进攻性的专利布局可以用来摘别人的桃子的,包括摘开源的桃子。专利海盗就属于充分、高超地利用专利手段和法律程序,激进地玩进攻性专利布局来摘别人桃子的。有时,手法可以高超到骗过专利审查员的法眼,将与现有技术很接近的内容纳入自己的保护范围。软件行业是重灾区。

应当说,在专利方面,对开源最大的威胁来自第三方,而不是开源的作者、后续开发者、用户。在社区内,大家尝试在版权开源许可之外附加专利开源许可,但是因为这种附加许可的效力仅能延伸到后续开发者、用户,不能规制第三方或专利海盗,实质能达到的效果较为有限。

Facebook 被踢的委屈

现在,我们重新梳理一下 Apache 踢 FB+PL 这件事。Apache 主要是对 Facebook Patents license,即对专利许可的条件不满意才开踢的。

Apache 的表态很干脆地捍卫了开源情怀,但是不是有些偏强硬激进了呢?

对于发展开源事业,首要的问题是什么呢?当然应当是分清谁是朋友,谁是敌人。然后,团结一切可以团结的进步力量,形成对敌统一战线。

笔者猜想,开源的敌人是第三方专利海盗,以及供专利海盗滋生的土壤。Facebook 看起来更像可以团结的朋友:Facebook 对开源有很积极的贡献和推动,其在专利许可方面的动作应当也没有越线。Facebook 如果真想以专利捆绑开源,另安排一个白手套作为第三方来布局专利,岂不干脆彻底?哪里还需要如此费事的搞 Facebook Patents license?至少应当说,Facebook 还是出于基本善意的立场提出的专利许可。

扒扒 Facebook 专利许可

再深入剖析这个问题,就要梳理 Facebook Patents license 的主要条款对开源的影响了。

Facebook Patents license 的主要条款

Additional Grant of Patent Rights Version 2

"Software" means the React software distributed by Facebook, Inc.

Facebook, Inc. ("Facebook") hereby grants to each recipient of the Software
("you") a perpetual, worldwide, royalty-free, non-exclusive, irrevocable
(subject to the termination provision below) license under any Necessary
Claims, to make, have made, use, sell, offer to sell, import, and otherwise
transfer the Software. For avoidance of doubt, no license is granted under
Facebook's rights in any patent claims that are infringed by (i) modifications
to the Software made by you or any third party or (ii) the Software in
combination with any software or other technology.

The license granted hereunder will terminate, automatically and without notice,
if you (or any of your subsidiaries, corporate affiliates or agents) initiate
directly or indirectly, or take a direct financial interest in, any Patent
Assertion: (i) against Facebook or any of its subsidiaries or corporate
affiliates, (ii) against any party if such Patent Assertion arises in whole or
in part from any software, technology, product or service of Facebook or any of
its subsidiaries or corporate affiliates, or (iii) against any party relating
to the Software. Notwithstanding the foregoing, if Facebook or any of its
subsidiaries or corporate affiliates files a lawsuit alleging patent
infringement against you in the first instance, and you respond by filing a
patent infringement counterclaim in that lawsuit against that party that is
unrelated to the Software, the license granted hereunder will not terminate
under section (i) of this paragraph due to such counterclaim.

A "Necessary Claim" is a claim of a patent owned by Facebook that is
necessarily infringed by the Software standing alone.

A "Patent Assertion" is any lawsuit or other action alleging direct, indirect,
or contributory infringement or inducement to infringe any patent, including a
cross-claim or counterclaim.

简要而言,关键点有两个:

  • Facebook 对免费专利许可设了限制条件:你不可以诉我知识产权侵权;
  • 专利许可所涉及的专利,仅限于所涉及的开源软件本身,对于软件修改后或与其他技术共同使用而可能侵犯的专利,不在许可之列。

法律背景扑朔迷离

即使分析以上两个要点,也要仔细衡量,须考虑现实背景中的重要因素:

  • 如果无专利许可,会如何?
  • 许可不涉及实质性的对价。
  • 许可涉及复杂的国际司法环境。

笔者认为,许可条款之外的上述背景中的三条因素才真正使许可的效力变得扑朔迷离。

就背景因素 1 而言,现实情况中,普遍存在开源许可证仅涉及版权而回避了专利的情况。这是社区当中大家普遍可以接受的条件。未提及专利,并不等于没有给予专利许可,尤其在许可证中没有明示“专利要另收钱”的情况下。有一个奇妙的东西,可以叫作基于诚实信用或善意公平原则的“默认许可”。

何为“默认许可”?简单讲,当你给人家什么东西去用,没有明示这个东西要收钱,人家用了之后,你向人家去收钱,这么做不太厚道吧?基于诚实信用或善意公平原则,通常法院不会支持这种像是给人下了套,然后去收钱的行为的,而会认为当你给人家东西去用,没有明示这个东西要收钱时,已经“默认许可”人家免费用了。

开源软件的作者或提供者,同时又作为相关专利的专利权人时,在提供了明确免除版权费用的许可证的情况下,如果在向用户交付产品的同时,没有明示要收取专利费,“默认许可”应当成立。从学术讨论的角度,也有将之称为“专利权权利用尽”的。但是由于未收钱,“专利权权利用尽”的成立更有困难些。笔者还是坚持“默认许可”路线。

但还是很遗憾,法律世界不同于软件世界。在软件世界里,每一段算法程序,在给定条件后,都会给你执行出一个清楚的结果。法律世界里很难如此。“默认许可”是否会得到司法完全支持?真的很难讲,各个国家,甚至一个国家在不同时期,都可能对相似的情况采取不同的思路并给出不同的分寸和方向的判决。在美国、英国、澳大利亚等海洋法系的国家,前后判例的一致性会比较高。而中国、德国等大陆法系国家,变化可能较大。以下将要讨论的诸多问题均受各国司法差异因素影响,以下不再赘述。

总之,不确定性较大。尽管笔者对各国实际判例缺少一手研究,但从法理和情理上倾向于在专利“默认许可”成立,即利于开源免费。

就背景因素 2 而言,许可是否涉及实质性的对价是很重要的因素。实际上,我们现在讨论的是许可证,性质又不同于协议,但一些相关因素可以类比来考虑。没有实质性对价,指没有因交易性的收获进行实质支付,比如,支付价款。在这种情形下,许可证或协议在性质上更类似于赠与,对有关方的权利义务要求未必牢固。比如,Facebook 将自己开发的软件拿出来开源,自己付出了开发成本,却没有向使用者收取费用;使用者可以较随意地拿 Facebook 的开源软件免费使用。如果由于这种免费的行为中暗藏玄机,而导致 Facebook 或使用者要承受重大的义务、付出重大代价,则是有失基本公平的,除非有特别原因。所以,各国从司法的角度,会考虑“是否涉及实质性的对价”这一因素,但仍然是会采取不同的思路并给出不同的分寸和方向的判决。简而言之,Facebook Patents license 并不涉及实质性的对价,所以司法层面不会随便基于这种许可而使有关方承担与对价不相匹配的重大义务。

总之,还是不确定性较大,尽管笔者还是对各国实际判例缺少一手研究,但从法理和情理上仍倾向于 Facebook Patents license 因不存在实质性对价,相关方带来重大义务或损失的可能性较低,即利于开源免费。

背景因素 3 已经融合在以上讨论之中了。

综合以上背景因素的讨论,可知 Facebook Patents license 对开源还是比较友好的,至少不会造成重大损害。

Facebook,面子大于里子

再审视 Facebook Patents license 的两个关键点,其对“默认许可”是否仍能成立各有微妙影响。笔者的观点是,很可能使情形确实反而不如没有这个 Facebook Patents license,不过负面影响有限。

就关键点 1,Facebook 对免费专利许可设了限制条件:你不可以诉我知识产权侵权。

明示的效力当然优于默认的效力,所以笔者倾向认为默认许可的效力被破坏了。但以下三个因素将对开源有利:

  • 用户对 Facebook 发起诉讼时,许可终止,但用户此前的使用仍享受免费许可。所以,主动权还是在用户手里,可以选择有利形势。当用户认为自己更多的知识产权为 Facebook 所使用,份量重于自己所使用的 Facebook 开源软件的知识产权时,才发起诉讼,并在诉讼前做好调整和准备;如果自己用的 Facebook 的知识产权比较多,而被 Facebook 使用的知识产权少,自己还是在赚便宜,何必去找 Facebook 麻烦呢?更应当指出,Facebook 所设的这个条件较容易做被规避:可以将专利转移给第三人,也就是白手套,由白手套去诉 Facebook。这样,即可以继续享受免费许可,又可以搞 Facebook。这在法理上是成立的。
  • 对单一用户来讲,出现要诉 Facebook 而会破坏免费许可这一情况的现实可能性较低。
  • Facebook 此条件有构成滥用知识产权的风险。

以上第 1 条实际上已经能够让 Facebook 的关键点 1 形同虚设,达不成实际意义了。以上第 3 条,不确定性很大。

就关键点 2,专利许可所涉及的专利,仅限于所涉及的软件本身,对于软件修改后或与其他技术共同使用而可能侵犯的专利,不在许可之列。

关键点 2 实际上暗藏杀机,比形同虚设的关键点 1 凶险些,但实际威力也还有限。重点在于:

  • Facebook 明示不予许可的专利:软件修改后或与其他技术共同使用而可能侵犯的专利,实际上照样可能将开源软件捆死。这是其心机最凶险之处。
  • 尽管 Facebook 明示排除了软件修改后或与其他技术共同使用而可能侵犯的专利,但只是泛泛而论。实际上,用户修改软件或将之与其他技术共同使用是必然普遍发生的情况,如果 Facebook 没有及时向用户提示这些具体专利的存在,并对收费有明确具体要求,笔者倾向于默认许可的效力仍应成立。当然,不确定性仍然较大。“及时向用户提示”指对于软件交付之前已经持有的专利,应在软件交付前明确提示;对于软件交付之后获得的专利,应在专利获得后马上提示。

综上,尽管复杂的不确定性仍较多,笔者倾向于认为 Facebook Patents license 总体上对开源较为友善,与不涉及专利的许可证相比较,没有带来实质性变劣。对 Facebook 而言,可能象征意义更大于实质意义,即面子大于里子。

Apache 潜在风险

另外,还有一个潜在风险因素,使 Apache 踢掉 FB+PL 之后使自己处在更为不利的境地。

Apache的风险控制措施是:“Apache 项目中将不能够包含或依赖于 Facebook Patents license 的代码;而已经发布的代码,涉 及FB+PL 许可证的,需要在 8 月 31 号前完成替换。”这一措施理论上说说还好,但在可操作性上问题很多。笔者认为,剔除 FB+PL 版权许可证所涉及的内容比较好操作:只要剔除相关的代码,替之以其他来源或自编的代码就好了。因为其他来源或自编的代码,基本就能确保在表达方式上的不同,从而规避版权侵权。这是现实的操作方式。

而规避侵犯 Facebook 专利权,上述方式很可能并不奏效。简单而言,版权保护表达形式,专利保护构想。规避表达形式,也就是从表述方式上加以实质调整就可以做到了。而规避构想,确实很难。实际上,Facebook 到底有哪些专利与之相关恐怕也很不清晰,还要加以规避,就更是难上加难了。分析工作和代码的重新设计对专利的专业性要求非常高,工作很复杂,工作量也很大。

这种情况下,Apache 可能面对的最坏情况是:放弃了 FB+PL 的开源代码,仍存在侵犯 Facebook 专利的高风险,又不会得到 Facebook 明示、默认许可。

Apache 的激进开源

所以,笔者认为,Apache 的表态很干脆地捍卫了开源情怀,踢掉 FB+PL 的行事方式有可能略偏强硬激进,尽管从规避不确定的风险而言,也不是完全没有道理。

(题图:HuffPost)


作者简介:

李可

集慧智佳知识产权咨询公司,李可。江湖人称“可哥”,老牌专利代理人,知识产权高级咨询师。70 后文艺理工男,属牛,性子慢但踏实稳妥。

投身开源软件的人,多是有情怀的理想主义者,期望通过无私的努力,让世界更美好。这是原本专注于专利问题的笔者,偶然被牵入到开源研究项目后,对他们所产生的第一印像。

然而,即使专利人也有专利情怀,现实世界中开源与专利的碰撞依然难免丑陋。这要求投身开源的理想主义者必须比一般人更加坚强和执着,才可能推进他们的美好理想。以下,笔者从伸向开源情怀的专利咸猪手这一角度,来提示一下开源人所要面对的现实、承受的考验。

引子

相信社区里的人对此事并不陌生:一名开源软件作者发出求救的呼声,指出知名公司将他的开源软件 XXL-JOB 申请成了专利

按照开源中国博客文章XXL-JOB 作者于 2017 年 6 月在他人提醒之后,发现他的作品 XXL-JOB 被他人申请了中国专利(CN201610843823.X)。依照开源中国的另一篇博客文章,XXL-JOB 作者委托开源中国与专利申请人进行交涉,作者的基本诉求包括:申请人撤回专利申请并发布声明加以澄清。开源中国与作者进一步希望,如,申请人从事实和技术角度加以澄清,并提出如果专利授权,应声明其与有关开源项目的关系,并“无偿开源”等。

开源软件遭遇专利咸猪手

我们暂且将之称为开源软件遭遇专利咸猪手吧!应当说,此事件很典型,无论在国内还是国外都不是孤立性事件。事情的根本在于:开源软件的开发者仅对自己智力劳动成果的知识产权做了很少的保留,将软件基本开放、贡献给公众无偿使用。而开发者的无私奉献却被一些人窃取或搭便车谋利:包括但不限于通过专利咸猪手式的手段侵占公用领域开源软件的全部或一部分,或是针对某些典型应用场景设下埋伏,迫使公众在使用开源软件时有可能侵犯相关专利权而需向他们缴纳费用。

开源软件开发者的情怀在于:多少相信,免费获取和利用知识是人的权利。投身开源的人,对售卖知识的知识产权制度多少有些敌意。不得不承认,我们当今的知识产权制度并不完美,最典型的就是专利海盗现象,它给技术进步和产业发展,尤其是软件产业发展带来了巨大的负面冲击。从某种意义上讲,开源软件的产生,就是一种打破目前知识产权制度对软件行业过度禁锢的积极尝试,而且发展势头良好。

而现实世界比较复杂。从开放的眼光看,存在即为合理,开源软件所遭遇的海盗式专利咸猪手,并非一无是处。因为目前不完美的知识产权制度仍是当下最为现实的解决方案。对于智力成果给予专有保护的必要性和积极意义是毋庸质疑的。知识产权专有保护的着力点主要在限制商业应用;而对于利用知识、技术进行学习和研发,则采取支持、鼓励的态度。

专利咸猪手的法理依据是这样的:

  • 在前人智力成果的基础上再进行创造性改进是每个人的权利,是利于社会进步的,即使前人智力成果也受知识产权保护。
  • 创造性改进的成果也是智慧成果,可以申请成专利,它的知识产权属于做出创造性改进的人,也就是专利发明人。

应再强调,这里的发明人不应将前人的成果纳入自己的权利保护范围,仅可以就自己做出的改进部分主张权利。相信有情怀的开源人和专利人都不会反对以上两条。

而以下这两个问题,大家可以充分探讨和质疑:仅就 XXL-JOB 专利事件,专利是将 XXL-JOB 的已有技术也纳入了保护范围?还是仅对 XXL-JOB 的改进部分要求进行保护?

如果情况属于前者,该专利将不符合法定授权条件,不应获得授权。如果情况属于后者,第三方发明人获得专利保护则是完全正当的。

现实的狗血在于,想回答清楚这个问题:专利是否将 XXL-JOB 的已有技术纳入了保护范围,是技术上很复杂,成本非常高的问题。负责任地回答这个问题,需要进行非常专业的技术和法律分析,而得出的结论还不能是定论。没错,这个专业分析的成本几千元起,花几万元可能也不奇怪,即专业性强,还成本高,而且没有定论,这一点是肯定的。

为什么没有定论?简单讲,经过司法程序认定,例如,在产生了生效判决的情况下,才有司法定论。请注意,是生效判决,指不被后续司法救济程序推翻的判决。通常,有了司法定论可能还平息不了学术争议,但司法定论是现实中管事的。而要得到司法定论,成本就更高了。

这是开源作者必然会面对的局面,并且常常让人感觉悲哀无助,因为专业性问题可以先放其次,高成本是谁都难以轻易承担的。

还就 XXL-JOB 专利事件而言,即使专利说明书中包括了 XXL-JOB 的技术内容,也不能简单得出专利要求将 XXL-JOB 的已有技术内容纳入了保护范围的结论。技术改进中涉及原有技术的内容是正当的、不可避免的。专利申请人是否不恰当地将 XXL-JOB 的已有技术内容纳入了保护范围,各方各有观点,但尚无定论,第一个要正式面对和回答这一问题的就是专利局的专利审查员。

专利审查员的工作受技术条件、现实条件的制约,也并不能解决全部问题。很多问题只能留待以后产生争议时,由后续准司法和司法程序解决。这又回到了前面所提及的:问题分析专业性强,成本高。

开源作者未完结的悲哀无助

开源作者所受的悲哀无助还没有完。使问题更为加剧的是恶意利用制度和程序而产生的问题。简单而言,就是专利海盗式的操作。既然问题难有定论,就拦不住有人在商业利益的驱动之下,百折不挠地努力尝试打各种擦边球,而且总会有所收获。他们中的急先锋便是各类专利海盗。专利海盗充分利用了复杂的程序、高专业性、高成本形成的高门槛。专利,经过专业性的包装等手法,会给专利审查增加很高的技术难度,有可能将开源软件中的已有技术改头换面包装成改进过的新技术,变相纳入私有保护范围,从而混水摸鱼得偿所愿:例如通过专利咸猪手式的手段侵占公用领域开源软件的全部或一部分,或是针对某些典型应用场景设下埋伏,迫使公众在使用开源软件时有可能侵犯相关专利权而需向他们缴纳费用。

实际上,以这种方式做事的,不仅止是专利海盗,背后和之后还有大批正当公司,因为有商业利益驱动。有可能有些激进,但这属于合理利用法律制度和程序。这个问题,至少目前还看不到根本性的解决办法。

开源软件遭遇专利咸猪手,说开了,就是被摘了桃子。实际上,专利高手,充分利用制度和程序,合理合法地何止是摘开源软件的桃子,谁的桃子都摘。这已经属于商业经营活动中的正常专利风险,任谁都避不干净。

白话总结

如果以简单直白的方式总结一下的话:任何人都有权利对开源软件中的技术方案加以改进然后去申请专利,如果做得专业老道,有可能用这些专利卡住开源软件的脖子。这种做法合理合法,其中手段高超的,还会被圈里人称赞为:专利布局水平很高!

笔者忍不住要插一句:当年我们都不懂知识产权时,外国人没少这么搞我们。现在,我们也已经有一些高手可以这么去搞外国人了。这是有钱才玩得起的昂贵的游戏。一旦搞起来,谈不上对内对外,外国人和我们对内自然也免不了一样搞法。没办法,这就是西方人设计的知识产权制度骨子里的东西。

这是开源作者必然面对的局面,很多时候除了想开些,除了以很高的成本对簿公堂,没有现实的解决办法。笔者有把世界描写得太过黑暗吗?

我看到,投身开源软件的有情怀的理想主义者,有一些在这些黑暗和不公的打击之下,愤而退出了开源事业。笔者非常理解他们。我还看到,更多的人无视这些打击,以不变的情怀和理想,在这条道路上继续栉风沐雨,砥砺前行。笔者非常敬佩他们。人间正道是沧桑。

开源软件开发者这边的故事讲完了,而开源用户应当如何面对这些问题呢?希望以后有机会与大家讨论。

(题图:legalraasta.com)


作者:李可,江湖人称“可哥”,老牌专利代理人,集慧智佳知识产权咨询公司的知识产权高级咨询师。70 后文艺理工男,属牛,性子慢但踏实稳妥。