标签 许可证 下的文章

开源软件虽然可以免费使用,但就如同饲养一条幼犬一样(开始虽然花钱不多,后边越养越费钱)。在采用开源之前,确保能够了解其隐藏的成本和陷阱。

对于初创公司来说,开源软件是一把双刃剑。它可以成为一家创业公司的生命线,因为开源软件可以帮助初创企业快速创新,而不必从头开始。不过,正如有些人所说的,开源软件虽然可以免费使用,但就如同饲养一条幼犬一样,开始虽然花钱不多,后边越养越费钱。开源软件的真正代价是开源许可证合规成本。

滥用开源软件可能会造成获得投资的机遇被延迟或破坏。但是,如果遵守这些简单的法则,初创企业可以轻松地实现开源许可证合规。

法则一:不使用没有许可条款的软件

互联网上的一些软件不包含许可证通知,但这不意味它们可以自由使用。发布软件的人可能没有遵守上游许可条款。或者软件的作者可能尚未为其软件指定许可协议——无论是以开源方式亦或是其他方式。“没有许可条款”是指没有许可证:您应该避免使用该软件或要求作者为其该软件指定许可证。

法则二:不要违反开源许可证

开源软件的使用可能难以让其作者进行追踪,但并不意味着该软件的使用和不合规行为会被忽视。违反开源许可证可能会使初创公司面临法律责任和公众谴责,甚至可能会影响其被投资或收购。也可能导致潜在客户由于担心下游责任而拒绝购买您的产品。软件开发人员为实现其软件开源付出了巨大的努力,其中也包括上述的许可费用。滥用开源软件对这些开发人员是不公平的,并且损害了他们希望促成的创新。

法则三:跟踪您正在使用的软件

将来有一天您将必须提供您正在使用的开源软件的列表。及时维护该列表将会为您节约大量的时间和精力,因为潜在的投资者和收购方将会要求您提供该列表。大多数开源软件下载包中都包括一个 “license.txt” 或 “copy.txt” 文件。保留该许可证的副本,并记录其涵盖的软件。大多数创业公司都使用简单的电子表格跟踪软件许可情况。

法则四:了解 宽松 permissive 许可证和 左版 copyleft 许可证

开源许可证大致分为两种类型:宽松许可证(BSD、MIT 和 Apache)和左版许可证(GPL、LGPL、Eclipse 公共许可证、Mozilla 公共许可证以及 通用开发和分发许可证 Common Development and Distribution License )。大多数公司及其客户对于使用遵循宽松许可证的软件没有什么法律上的担心。不过,遵循左版许可证需要更加谨慎,将软件保留为专有可能会与某些特定计划不一致。

法则五:遵守许可证 通知 notice 要求

无论是宽松许可证还是左版许可证,所有开源许可都有通知要求。通常,这意味着在分发开源软件时,您需要包含其所适用的许可证的副本,仅仅包括许可证的链接或缩略形式通常是不完备的。为了避免混淆或疏离您的客户,开发一个符合大多数开源许可证的通知传送策略非常重要。

法则六:了解哪些开源许可证与分布式软件兼容

除了 Affero GPL 之外,大多数开源许可证都没有涉及软件即服务(SaaS)的情境。对于 SaaS 和云系统的分布式组件(如 JavaScript)或分布式软件(包括移动 APP 和测试版),您可以使用遵循宽松许可证的软件,但在使用遵循左版许可证的软件之前,您需要特别小心。仅在其完全在自己的进程中执行并且没有链接的代码时才去使用遵循 GPL 的软件,而不要相信以下如何让 GPL 合规的谣传:动态链接至 GPL 代码或让客户下载 GPL 软件。仅将 LGPL 软件作为动态链接库进行使用。在不修改 API 的前提下使用遵循其它左版许可证的软件。遵循移动 APP 市场的分发规定也许与遵循某些特定的左版许可证有冲突(例如 GPL 或者 LGPL)。

法则七:在咨询律师之前不要贡献或发布开源软件

贡献和发布开源软件可能是公众的福音,但它可能不是您业务上的正确选择。一旦作出贡献或发布,您在软件中拥有的任何知识产权将不大可能构成您公司估值的依据。您的律师可以帮助您更好地理解在专有和开源软件之间如何选择,并对这一重要业务决策提供指导。

法则八:确保您的员工和第三方开发人员遵守这些规则

不管是由于您的员工或第三方承包商造成的开源违规行为,所引起的法律和宣传问题都将砸在您的头上。您可以通过适当的培训和跟踪开源软件来避免这些问题。

法则九:规划未来

初创公司业务模式可以快速变化。SaaS 模式可以快速转变为分布式软件模式。无论您当前的模式是什么,遵守分布式软件的规则将为您转变为分布式软件模式提供更大的灵活性,而无需删除某些开源软件并更改相关功能。

采用这些法则将有助于初创企业利用开源软件的优势,降低您在获取投资或收购时遇到的风险。对您的初创企业感兴趣的第三方想知道您如何应对开源软件问题,确保您做好准备,并能够为他们提供积极和专业的答案。

(题图:Beth Cortez-Neavel on Flickr. Public Domain. Modified by Opensource.com)


作者简介:Heather Meeker 是 O’Melveny & Myers 硅谷办公室的合伙人,为客户提供技术交易和知识产权方面的建议,是国际知名的开源软件许可专家。Heather 于 2016 年获得加州律师协会知识产权先锋奖。 《最佳律师》 Best Lawyers 将她提名为 2018 年年度 IT 律师。

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

就在几个小时前,Facebook 宣布,将在下周发布的 React 16 会以 MIT 许可证重新授权,以应对社区对之前的 BSD + 专利许可模式的不安。

Facebook 负责 React 和 GraphQL 等产品的产品架构组工程总监 Adam Wolff 写道:

“下周,我们将以 MIT 许可证对我们的开源项目 React、Jest、Flow 和 Immutable.js 重新进行许可。我们重新许可这些项目是因为 React 是广泛的互联网开源软件生态的基石,我们并不想因非技术原因而阻碍其前行的道路。”

React.js 是 Facebook 推出的一个用来构建用户界面的 JavaScript 库,起源于 Facebook 的内部项目,用来架设 Instagram 的网站。

  • 2013 年 5 月,Facebook 将 React.js 开源
  • 2016 年 7 月,React.js 开源许可协议中的附加专利条款引发争议。
  • 2016 年 11 月,Facebook 发布官方问答,对附加专利条款进行澄清。
  • 2017 年 7 月,Apache 基金会禁止使用遵循 BSD 许可证 + 专利开源协议的 JAR 包。

在 Apache 基金会将 React 这样的采用 BSD 许可证 + 专利条款的软件列入“X 类别”之后,社区再次引发了对此问题强烈关注,并导致很多大型的互联网公司开始绸缪放弃和替换 React——尤其是在 WordPress 宣布将重写其软件,剥离对 React 的依赖之后达到了顶峰。而国内的互联网公司,如百度、阿里,也纷纷有传言将追随这一动作,弃用 React。

迫于这种压力,Facebook 决定对 React 等开源项目放弃其原有的 BSD 许可证 + 专利条款的许可模式,虽然他们认为“BSD 许可证 + 专利条款为项目的用户提供了一些好处”,但是他们也“承认没能说服社区接受这一许可模式”。

在感受到这一许可证的不确定性风险之后,许多团队开始选择替代性的产品。Facebook 对此感到抱歉,对 React 重新许可虽然不一定能赢得这些团队回心转意,但是还是“希望将这扇门继续打开”。

这一转变自然也会引起人们对 Facebook 其它的开源项目的质疑,因为目前 Facebook 许多流行的开源项目都采用的是 BSD 许可 + 专利条款方式。但是他们会“重新评估这些项目的许可证,而每个项目的情况有所不同,替换许可证取决于各种因素”。下周,除了 React 之外,Facebook 也将对 Jest、Flow 和 Immutable.js 等开源项目进行重新许可。

这一许可证的变化将随着下周即将发布的 React 16 一起更新。React 16 已经开发了一年,内部进行完全重写,解锁了强大的功能,让每个人都可以用它来构建大规模的用户界面。

Adam Wolff 表示,将许可证的讨论放到后面,无论大家用不用 React ,希望它都可以给开发者以灵感,毕竟,我们最关心的是:交付伟大的产品。

对 Apache 基金会禁止将 BSD+专利许可证(FB + PL)用于其项目的批评,在理性的审视之下是无法成立的。

最近,Apache 基金会将 Facebook 公司 BSD + 专利许可证下的代码重新分类为 “X 类”,从而有效地阻止了其未来对 Apache 基金会项目的贡献。这一举动再度引发了对专利授权的争议,但是像开源社区的许多事件一样,与实际情况相比,这个争议更具倾向性。事实上,这样做不太可能影响 React.js 的采用,对 BSD +专利许可证(FB + PL)的批评大多数不能在理性的审视下成立。

官方名称为“专利权的补充授权第二版”的 Facebook 专利授权条款已经生效多年。它用于非常受欢迎的 React.js 代码,该代码是一种用于呈现用户界面的 JavaScript 库。使用该代码的主要技术公司的名单令人印象深刻,其中包括像 Netflix 这样面向消费者的巨头公司,当然还有 Facebook 自身。(LCTT 译注:国内包括百度、阿里云等顶级互联网公司也在使用它,但是据闻这些公司在纷纷考虑更换对该库的依赖。)

对旧授权的新反应

对这个消息的反应是令人惊讶的,因为并行专利许可模式并不是什么新鲜事。 Facebook 在 2013 年发布了 BSD + 专利授权许可证(2015 年进行了修订)。而 Google 2010 年也在 WebM 编解码器上有些高调地使用了类似的模型。该许可模式涉及两个并列和同时授权的权利:软件版权的 BSD 许可,以及单独授予的执行该软件的专利授权。将两者合在一起意味着有两个独立和平行的授权权利。在这方面,它与 Apache 2.0 许可证非常相似,与 BSD 一样,Apache 2.0 是一个许可证,并且还包含与版权许可授权一起存在的防御性终止条款。

对 Apache 基金会通告的大部分反应造成了混乱,例如有篇文章误导性地称之为“陷阱”。事实上,许多开源许可证都有防御性的终止条款,这些规定大多被认为是阻止专利诉讼的合理机制,而不是陷阱。它们是规则而不是例外;所有具有专利授权的主要开源许可证也具有防御性的终止条款——虽然每个条款略有不同。在 Apache 所拒绝的 Facebook 专利授权与 Apache 对其项目所采取的 Apache 2.0 许可证之间,其中的区别比争议提出的更为微妙。

防御性终止条款有多种风格

防御性终止条款在两个主要方面有所不同:终止条款的触发和权利终止的范围。

关于权利终止的范围,有两个阵营:仅终止专利授权(包括 Apache 2.0、Eclipse 公共许可证和 Facebook 专利授权)以及也同时终止版权许可(Mozilla 公共许可证和 GPL v3)。换句话说,对于大多数的许可证,提起专利侵权诉讼只能导致专利权的终止;对于其他许可证来说,提起专利诉讼能够同时导致版权许可的终止,即让某人停止使用该代码。版权许可终止是一个更强大的反专利机制,对于私营企业来说风险更大,因此导致一些私营公司拒绝使用 GPL v3 或 MPL 代码。

与大多数其他开源许可证相比,Facebook 专利授权触发终止的阈值不同。例如,在 Apache 2.0 中,专利授权的终止是由对该许可证下的软件提出指控的专利权利主张引发的。这个想法是为软件创建一个 “专利共同体” patent commons 。大多数其他开源许可证大致遵循这个推演。(但在 Facebook 许可证中,)如果被许可人向 Facebook 或任何对 Facebook 产品提出指控的第三方提出权利主张,Facebook 专利许可也将终止。在这方面,终止触发机制类似于 IBM 多年前撰写的 Common Public License 1.0 (CPL)中的终止触发机制。(“如果接收者利用适用于本软件的专利对贡献者提出专利诉讼,则该贡献者根据本协议授予该接收者的任何专利许可,将在提起诉讼之日终止。”)

天下无新事

Facebook 授权范围的防御性终止条款在开源场景之外的专利许可中很常见。如果被许可人向许可人提出专利权利主张,大多数专利许可将被终止。原因是许可人不想在专利战争中被单方面“解除武装”。大多数专利只有在竞争对手起诉专利所有人时才被防御性使用。A 起诉 B,然后 B 起诉 A,导致互相伤害。如果 B 在没有广泛的防御性终止条款的情况下以开源许可证发布其软件,则 B 可能没有追索权,并且为其开源代码的发布付出高昂的代价。A 在免费利用 B 的软件进行开发的同时,还起诉 B 专利侵权。

最后,Facebook 专利授权本身并不新鲜。该授权于 2013 年发布,自那时起,React.js 的受欢迎程度一直在增长。与许多开源许可证一样,行业忍受新许可证的意愿取决于其下发布的代码的质量。在 React.js 代码质量非常好的情况下,这个专利许可条款虽然是新的,但合理。

还是开源吗?

有些人认为 BSD + 专利条款违反 “开源定义” Open Source Definition 。OSD 不接受歧视个人、团体或领域的许可证。但专利授权没有许可范围限制;如果被许可人有不当行为,许可就会终止,并且与其他人相比,针对代码作者的不当行为的触发门槛更低。因此,BSD + 专利许可似乎并不违反 OSD,而且 CPL 已经被 OSI 认可为合规的。如同 BSD + 专利许可一样,CPL 根据针对代码作者的专利诉讼,设定了一个较低的终止门槛。

结果是什么?

Apache 基金会决定的实际结果尚不清楚。 遵循 X 类许可的代码不能包含在 Apache 基金会的存储库中(该类别还包括 GPL 等许可证)。Apache 的重新分类并不意味着任何人都不能使用 React.js——它只是不能在 Apache 项目中被提交。目前甚至不清楚 Apache 项目是否包含对 BSD + 专利许可代码的依赖。

同时,在私营企业中,根据 BSD + 专利条款使用代码几乎没有争议。大多数公司已经检查了该许可证与其他许可证(如 Apache 2.0)相比的边际法律风险,并认为没有需要特别注意的地方。除非公司决定起诉 Facebook(或指控其产品侵权),否则终止触发机制没有实际效果。如果您想要在开发和发布一大堆代码的公司中发起专利权利主张,将该代码从您的业务中删除似乎是一种合理的代价。

有些争议似乎起因于担心 Facebook 在许可条款中比其他人占优。但是,这与伤害开源社区是不一样的。与 Apache 2.0 一样,BSD + 专利授权以“专利共同体”为基准建立,但是为贡献者(Facebook)针对被许可人的软件专利权利主张提供了更多的保护。很奇怪的是,一个如此反对软件专利的社区会发现这是令人反感的,特别是考虑到过去使用的一系列防御性终止规定。

请注意:此文章是关于 BSD + 专利许可,而不是关于 Facebook 公司。这篇文章仅代表作者的个人观点,而不是 Facebook 的观点。作者在开源事务上代表 Facebook,但作者没有起草 BSD + 专利许可证。

(题图:techtimes.com)


作者简介:Heather Meeker 是 O’Melveny & Myers 硅谷办公室的合伙人,为客户提供技术交易和知识产权方面的建议,是国际知名的开源软件许可专家。Heather 于 2016 年获得加州律师协会知识产权先锋奖。 《最佳律师》 Best Lawyers 将她提名为 2018 年年度 IT 律师。

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

使用开源的方式有利于你的盈亏底线以及开源生态系统。

 title=

合规性工业联合体 The Compliance Industrial Complex ” 是一个术语,它会唤起那些组织参与精心设计并且花费昂贵流程的以遵守开源许可条款的反乌托邦想象。由于“生活经常模仿艺术”,许多组织采用了这种做法,可惜的是它们剥夺了许多开源模型的好处。本文介绍了一种经济高效的开源软件许可证合规性方法。

开源许可证通常对从第三方授权的代码分发者有三个要求:

  1. 提供开源许可证的副本
  2. 包括版权声明
  3. 对于 copyleft 许可证(如 GPL),将相应的源代码提供给接受者。

(与任何一般性声明一样,可能会有例外情况,因此始终建议审查许可条款,如有需要,请咨询律师的意见。)

因为源代码(以及任何相关的文件,例如:许可证、README)通常都包含所有这些信息,所以最简单的遵循方法就是随着二进制/可执行程序一起提供源代码。

替代方案更加困难并且昂贵,因为在大多数情况下,你仍然需要提供开源许可证的副本并保留版权声明。提取这些信息来结合你的二进制/可执行版本并不简单。你需要流程、系统和人员来从源代码和相关文件中复制此信息,并将其插入到单独的文本文件或文档中。

不要低估创建此文件的时间和费用。虽然有工具也许可以自动化部分流程,但这些工具通常需要人力资源(例如工程师、质量经理、发布经理)来准备代码来扫描并对结果进行评估(没有完美的工具,几乎总是需要审查)。你的组织资源有限,将其转移到此活动会增加机会成本。考虑到这笔费用,每个后续版本(主要或次要)的成本将需要进行新的分析和修订。

也有因不选择发布不能被很好识别的源码而导致增加的其他成本。这些根源在于不向开源项目的原始作者和/或维护者发布源代码, 这一活动称为上游化。独自上游化一般不满足大多数开源许可证的要求,这就是为什么这篇文章主张与你的二进制/可执行文件一起发布源代码。然而,上游化和提供源代码以及二进制/可执行文件都能提供额外的经济效益。这是因为你的组织不再需要保留随着每次发布合并开源代码修改而产生的私有分支 - 由于你的内部代码库与社区项目不同,这将是越来越消耗和凌乱的工作。上游化还增强了开源生态系统,它会鼓励社区创新,从中你的组织或许也会得到收益。

那么为什么大量的组织不会为其产品发布源代码来简化其合规性工作?在许多情况下,这是因为他们认为这可能会暴露他们竞争优势的信息。考虑到这些专有产品中的大量代码可能是开源代码的直接副本,以支持诸如 WiFi 或云服务这些当代产品的基础功能,这种信念可能是错误的。

即使对这些开源作品进行了修改来适配其专有产品,这些更改也往往是微不足道的,并包含了很少的新的版权部分或可用来专利的内容。因此,任何组织都应该通过这种方式来查看其代码,因为它可能会发现其代码库中绝大部分是开源的,只有一小部分是真正专有的、与竞争对手区分开来的部分。那么为什么不分发和向上游提交这些没有差别的代码呢?

考虑一下拒绝遵从工业联合体的思维方式, 以降低成本并大大简化合规性。使用开源的方式,并体验发布你的源代码的乐趣,以造福于你的盈亏底线和开源生态系统,从中你将继续收获更多的利益。


作者简介

Jeffrey Robert Kaufman - Jeffrey R. Kaufman 是全球领先的开源软件解决方案提供商红帽公司的开源知识产权律师。Jeffrey 还担任着 Thomas Jefferson 法学院的兼职教授。 在加入红帽前,Jeffrey 在高通担任专利法律顾问,为首席科学家办公室提供开源顾问。 Jeffrey 在 RFID、条形码、图像处理和打印技术方面拥有多项专利。更多关于我

(题图: opensource.com)


via: https://opensource.com/article/17/9/economically-efficient-model

作者:Jeffrey Robert Kaufman 译者:geekpi 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出

本文由高级咨询师薛亮据自由软件基金会(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 后文艺理工男,属牛,性子慢但踏实稳妥。