这就是为什么商业机构应该选择开源模式的原因

在相同的基础上，开源软件要优于专有软件。想知道为什么？这里有六个商业机构及政府部门可以从开源技术中获得好处的原因。

1、 让供应商审核更简单

在你投入工程和金融资源将一个产品整合到你的基础设施之前，你需要知道你选择了正确的产品。你想要一个处于积极开发的产品，它有定期的安全更新和漏洞修复，同时在你有需求时，产品能有相应的更新。这最后一点也许比你想的还要重要：没错，解决方案一定是满足你的需求的。但是产品的需求随着市场的成熟以及你商业的发展在变化。如果该产品随之改变，在未来你需要花费很大的代价来进行迁移。

你怎么才能知道你没有正在把你的时间和资金投入到一个正在消亡的产品？在开源的世界里，你可以不选择一个只有卖家有话语权的供应商。你可以通过考虑发展速度以及社区健康程度来比较供应商。一到两年之后，一个更活跃、多样性和健康的社区将开发出一个更好的产品，这是一个重要的考虑因素。当然，就像这篇 关于企业开源软件的博文 指出的，供应商必须有能力处理由于项目发展创新带来的不稳定性。寻找一个有长支持周期的供应商来避免混乱的更新。

2、 来自独立性的长寿

福布斯杂志指出 90%的初创公司是失败的 ，而他们中不到一半的中小型公司能存活超过五年。当你不得不迁移到一个新的供应商时，你花费的代价是昂贵的。所以最好避免一些只有一个供应商支持的产品。

开源使得社区成员能够协同编写软件。例如 OpenStack 是由许多公司以及个人志愿者一起编写的，这给客户提供了一个保证，不管任何一个独立供应商发生问题，也总会有一个供应商能提供支持。随着软件的开源，企业会长期投入开发团队，以实现产品开发。能够使用开源代码可以确保你总是能从贡献者中雇佣到人来保持你的开发活跃。当然，如果没有一个大的、活跃的社区，也就只有少量的贡献者能被雇佣，所以活跃贡献者的数量是重要的。

3、 安全性

安全是一件复杂的事情。这就是为什么开源开发是构建安全解决方案的关键因素和先决条件。同时每一天安全都在变得更重要。当开发以开源方式进行，你能直接的校验供应商是否积极的在追求安全，以及看到供应商是如何对待安全问题的。研究代码和执行独立代码审计的能力可以让供应商尽可能早的发现和修复漏洞。一些供应商给社区提供上千的美金的漏洞奖金作为额外的奖励来鼓励开发者发现他们产品的安全漏洞，这同时也展示了供应商对于自己产品的信任。

除了代码，开源开发同样意味着开源过程，所以你能检查和看到供应商是否遵循 ISO27001、 云安全准则 及其他标准所推荐的工业级的开发过程。当然，一个可信组织外部检查提供了额外的保障，就像我们在 Nextcloud 与 NCC小组合作的一样。

4、 更多的顾客导向

由于用户和顾客能直接看到和参与到产品的开发中，开源项目比那些只关注于营销团队回应的闭源软件更加的贴合用户的需求。你可以注意到开源软件项目趋向于以“宽松”方式发展。一个商业供应商也许关注在某个特定的事情方面，而一个社区则有许多要做的事情并致力于开发更多的功能，而这些全都是公司或个人贡献者中的某人或某些人所感兴趣的。这导致更少的为了销售而发布的版本，因为各种改进混搭在一起根本就不是一回事。但是它创造了许多对用户更有价值的产品。

5、 更好的支持

专有供应商通常是你遇到问题时唯一能给你提供帮助的一方。但如果他们不提供你所需要的服务，或者对调整你的商务需求收取额外昂贵的费用，那真是不好运。对专有软件提供的支持是一个典型的 “柠檬市场”。 随着软件的开源，供应商要么提供更大的支持，要么就有其它人来填补空白——这是自由市场的最佳选择，这可以确保你总是能得到最好的服务支持。

6、 更佳的许可

典型的软件许可证充斥着令人不愉快的条款，通常都是强制套利，你甚至不会有机会起诉供应商的不当行为。其中一个问题是你仅仅被授予了软件的使用权，这通常完全由供应商自行决定。如果软件不运行或者停止运行或者如果供应商要求支付更多的费用，你得不到软件的所有权或其他的权利。像 GPL 一类的开源许可证是为保护客户专门设计的，而不是保护供应商，它确保你可以如你所需的使用软件，而没有专制限制，只要你喜欢就行。

由于它们的广泛使用，GPL 的含义及其衍生出来的其他许可证得到了广泛的理解。例如，你能确保该许可允许你现存的基础设施（开源或闭源）通过设定好的 API 去进行连接，其没有时间或者是用户人数上的限制，同时也不会强迫你公开软件架构或者是知识产权（例如公司商标）。

这也让合规变得更加的容易；使用专有软件意味着你面临着苛刻的法规遵从性条款和高额的罚款。更糟糕的是一些 开源内核 open core 的产品在混合了 GPL 软件和专有软件。这违反了许可证规定并将顾客置于风险中。同时 Gartner 指出，开源内核模式意味着你不能从开源中获利。纯净的开源许可的产品避免了所有这些问题。取而代之，你只需要遵从一个规则：如果你对代码做出了修改（不包括配置、商标或其他类似的东西），你必须将这些与你的软件分发随同分享，如果他们要求的话。

显然开源软件是更好的选择。它易于选择正确的供应商（不会被供应商锁定），加之你也可以受益于更安全、对客户更加关注和更好的支持。而最后，你将处于法律上的安全地位。

作者简介：

一个善于与人打交道的技术爱好者和开源传播者。Nextcloud 的销售主管，曾是 ownCloud 和 SUSE 的社区经理，同时还是一个有多年经验的 KDE 销售人员。喜欢骑自行车穿越柏林和为家人朋友做饭。点击这里找到我的博客。

via: https://opensource.com/article/17/10/6-reasons-choose-open-source-software

作者：Jos Poortvliet Feed 译者：ZH1122 校对：wxy

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

明确是避免许可歧义的关键所在。

在许可证的过去、当前和未来版本如何适用于软件程序方面，GPL 系列许可证在开源许可证中可谓独树一帜。如果不能完全理解其中独有的许可证特性，开源软件开发人员可能会无意中造成混淆。

GPL 许可证在其许可证的条款和条件中阐明了许可证版本如何适用于该程序。GPL v2（第 9 条）写到：

“每个版本都有一个独特的版本号，如果该程序指定了其适用的许可证的版本号以及‘任何更新的版本’，则可以选择遵循由 自由软件基金会 （ Free Software Foundation ） 发布的该版本或之后任何更新版本的条款和条件。如果该程序未指定许可证的版本号，则可以选择自由软件基金会以前发布的任何版本。”

GPL v3 第 14 条与 GPL v2 中的上述条款非常相似。

多年以来，我看到很多开源项目表示遵循 GPL 许可证，但却没有明确指出版本号，同时也没有将整个 GPL 许可证（例如，v2 或 v3）副本囊括在程序内。取决于您是许可人还是被许可人等因素，这其中造成的含混不清可能对您有益或有害。

许可证的模糊如何产生影响

例如，假设应用程序的许可证声明：“本程序遵循 GPL 许可证”，并且包含整个 GPL v3 许可证的副本。由于该项目没有明确说明适用该许可证的哪个版本号，所以合理的解释是自由软件基金会发布的所有版本 GPL 许可证都适用——v3、v2 甚至 v1！

依据 GPL v3 第 14 条的下述文本可以合乎情理地做出上述理解。

“如果该程序未指定 GNU GPL 的版本号，则可以选择由自由软件基金会发布的任何版本。”

另一方面，将 GPL 特定版本的完整副本（还可能包括许可证标题块中的 GPL 版本号）包含在程序中，可以被解释为在实质上传递了特定版本的许可证。在这个例子中，那就是 GPL v3 版本并且只有 GPL v3 版本，因为 v3 中没有“任何更新的版本”的条款。

如何避免许可歧义

为了避免这种许可歧义，您应该写得非常明确。如果您只想适用 GPL v3，应该明确地声明：“本程序仅遵循 GPL v3”，并提供整个 GPL v3 许可证副本。或者，如果您希望适用 GPL v3 或之后更新的版本，请明确声明：“本程序遵循 GPL v3 或其之后更新的版本”。最后，如果您真的想要适用任何版本的 GPL 许可证，您可以提供 GPL v3 许可证，并表示：“本程序遵循由自由软件基金会发布的任何版本的 GPL 许可证”。

无论您选择哪种授权方式，都应该非常明确，让每个人都能理解您的真正意图。

作者简介：Jeffrey R. Kaufman是全球领先的开源软件解决方案供应商Red Hat公司的开源知识产权律师，还担任托马斯杰斐逊法学院（Thomas Jefferson School of Law）的兼职教授。在任职Red Hat之前，Jeffrey曾担任高通公司（Qualcomm Incorporated）的专利顾问，为首席科学家办公室（Office of the Chief Scientist）提供开源事务咨询。

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

via: https://opensource.com/article/17/11/avoiding-gpl-confusion

作者：Jeffrey Robert Kaufman 译者：薛亮 校对：wxy

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

提要：Linux 社区的许多开发人员对 GPL 许可证牟利者 Patrick McHardy 的行为表示担忧，美国资深开源律师对一些常见问题进行解答，并对如何应对版权牟利行为提出了建议。

针对 Patrick McHardy 强制要求 Linux 分发者遵循 GPL 许可证的举动，开源社区许多人士表示了担忧。基于与 McHardy 行动相关的公开信息，以及开源合规维权的一些法律原则，美国资深开源律师对一些常见问题进行了解答。

Patrick Mchardy 是谁？ McHardy 是 Netfilter 核心开发团队的前任负责人。 Netfilter 是 Linux 内核中的一个实用程序，可以执行各种网络功能，例如改善网络地址转换（NAT），NAT 是将 Internet 协议地址转换为另一个 IP 地址的过程。对于维护 Linux 系统的安全性来说，控制网络流量至关重要。

McHardy 对 Linux 有多少贡献？

这不是一个容易回答的问题。首先，评估贡献的重要性并不容易；我们能做的就是查看 提交 （ commit ） 的数量和大小。其次，即使去跟踪提交，跟踪机制也不完美。 Git 有一个 blame 功能，跟踪谁在名义上向 Git 数据库提交了哪些代码行。Git 的 blame 功能可以使用诸如 cregit 这样的工具，以更具细粒度的水平来报告提交，从而在文件级别上对贡献度有一个更准确的认知。Git 的 blame 机制和 cregit 是非常实用的，因为它们都使用公开易得的信息，而信息只需要被正确解释。

结合 cregit 和 blame 进行分析可以帮助评估 McHardy 的潜在贡献。例如：

• 他的大部分贡献似乎是在 2006 年到 2008 年和 2012 年期间。
• 在 McHardy 包含其版权声明的大约 135 个文件中，只有 1/3 的文件是 McHardy 贡献了该文件代码的 50％ 或以上。
• 他的贡献看起来不到内核代码的 0.25％。

McHardy 的大部分贡献似乎都给了 Netfilter；然而，blame 机制可能并不总能还原全貌。例如，提交者可以 签入 （ check in ） 许多行代码，但只进行细微修改，也可以签入其他人编写或拥有的代码。由于这些原因，提交者的作者身份可能被过低或过多报告。

在 2002 年之前对内核贡献的记录对于识别贡献者来说不是特别有用，因为在当时，Linus Torvalds 签入了所有代码。 McHardy 的贡献直到 2004 年才开始。

Hellwig 诉 VMware 一案中出现了使用开发存储库的元数据确认版权所有权的困难。法院可能不愿意接受这样的信息来作为证明作者身份的证据。

McHardy 在 Linux 内核中拥有哪些版权？

大型项目（如 Linux 内核）的版权归属复杂。这就像一个拼凑的被子。当开发者对内核做出贡献时，他们不签署任何贡献协议或版权转让协议。GPL 涵盖了他们的贡献，软件副本的接收人根据 GPL 直接从所有作者获得许可。内核项目使用一个名为 “原始开发者证书” （ Developer Certificate of Origin ） 的文件，该文件不授予任何版权许可。贡献者的个人权利与在项目中的权利作为整体并存。 所以，像 McHardy 这样的作者一般都会拥有他所创作的作品的版权，但并不享有整个内核的版权。

什么是 “社区维权” （ community enforcement ） ？

由于大型项目（如 Linux 内核）的所有权常常分散在许多作者手中，所以个体所有者可以采取不符合社区目标的维权行动。虽然社区可能会对如何以最好的方式来鼓励遵守 GPL 条款有很多看法，但大多数人认为维权应该是非正式的（不是通过诉讼），而且主要目标应该是合规（而不是惩罚）。例如， 软件自由保护组织 （ Software Freedom Conservancy ） （SFC）已经颁布了一些社区维权原则，其中优选合规，而不是寻求诉讼或赔偿金。对于非正式行为何时应该成为诉讼，或维权者应该要求赔偿多少钱，没有明确的规定。然而，Linux 社区的大多数开发人员将诉讼视为最后的手段，并不愿意采取法律行动，而与真正希望合规的用户进行合作。

为什么这么多的开源诉讼在德国提交？

一些寻求进行开源许可证维权的原告已经向德国法院提交权利主张。在德国有一些在美国或其他 普通法 （ common law ） 国家没有能够确切与之类比的寻求法律诉讼的手段。

• Abmahnung（ “警告” （ warning ） ）：“警告”是索赔人要求被告停止做某事的要求。在版权语境下，这是版权所有者发出的一封信函，要求所述侵权人停止侵权。这些信件是由律师而不是法庭签发的，通常是德国版权维权行动的第一步。在美国，最接近的方式应该是 警告信 cease and desist letter 。
• Unterlassungserklaerung（ “停止声明” cease and desist declaration 或 “禁止声明” declaration of injunction ）：“警告”通常会附有“停止声明”。这种“声明”就像合同一样，签署的话会要求被告人承担其它并不存在的法律义务。特别是，该声明可能包含 GPL 本身并不要求的义务。在德国，这样一份文件通常包含针对不合规进行惩罚的内容。在美国，类似的做法是和解协议，但和解协议很少规定违约的处罚方式，事实上在美国，合同中的“处罚”可能无法强制执行。“声明”不是法院命令，但如果被告签字，可以获得法院命令的法定效力。所以，在征求律师法律意见之前签字往往不是一个好主意。在考虑如何应对寄出停止声明的原告时，还有其他方法，包括提出修改后的处罚或义务较少的声明。此外，由于停止声明可能包含不公开的要求，签署这些文件也可能产生额外的困难，例如限制原告寻求其他被告支持或向社区公开索赔人的权利主张。
  更多详情参见：abmahnung.org/unterlassungserklaerung/ 。
• Einstweilige Verfügung（“ 临时禁令 interim injunction ”或“ 初步禁令 preliminary injunction ”）：“临时禁令”是一项类似美国临时禁令的法院命令。虽然没有要求原告在向法院提出“临时禁令”之前发出“警告”，但在被告对“警告”或“声明”不作出回应时，鼓励原告寻求“临时禁令”。侵犯版权的临时禁令可以处以 25 万欧元罚款或 6 个月的监禁。相比之下，在美国，侵犯版权的刑事处罚极为罕见，必须由政府而不是私人机构追究。此外，在美国，法院也没有为未来的侵权行为提供补救措施，它们只是要求被告停止现行的侵权行为或者支付损害赔偿金。在德国， 单方 ex parte 也可以提出临时禁令，这意味着原告可以在没有被告听证的情况下向法院提出申请，而且可以在没有被告参与的情况下发出临时禁令。如果您收到“警告”，并怀疑原告可能会随之提出 “临时禁令”，可以向法院抢先提出 “异议” opposition 。
  更多详情参见：Abmahnung.org 。
• Widerspruch（ “异议” opposition 或 “反驳” contradiction ）：“异议”是被告向法院提出否决“临时禁令”的机会。
  更多详情参见：这篇德国法院命令的英文翻译 。

McHardy 发起了多少权利主张？

由于许多德国法庭案件缺乏公开记录，因此很难确定 McHardy 的确切行动数量。据说 McHardy 已经接触了超过 50 个维权目标。有关详细信息，请参阅 “源码控制” （ Source Code Control ） 和 《2016 年开源社区 7 个显著的法律进展》 （ 7 Notable Legal Developments in Open Source in 2016 ） 。这并不一定意味着有 50 起诉讼，而是可能意味着 50 起威胁要提起诉讼的要求。但是，很难用公开信息来核实这个说法。有关详细信息，请参阅 《开源生态系统的诉讼和合规》 （ Litigation and Compliance in the Open Source Ecosystem ） 。

为什么社区没有去阻止 McHardy？

包括软件自由保护组织在内的各种社区成员已经开始试图说服 McHardy 改变策略，但到目前为止还没有成功。 Netfilter 项目最近发布了一个许可问答，解决大家对 McHardy 行为担忧的问题。

我们可以做些什么来阻止 McHardy 和其他版权牟利者？

这个问题没有确定的答案，也许没有办法能完全阻止他们。但是，这些建议可能会减少版权牟利者的数量。

• 尽可能遵守开源许可证。目前有足够的资源来学习如何遵守许可证，以及如何在贵公司设立开源合规计划。例如：

  • Linux基金会发布了 《实用 GPL 合规手册》 （ Practical GPL Compliance ） 。
  • 软件自由法律中心发布了 《GPL 合规实用指南” （第二版） 》 （ A Practical Guide to GPL Compliance ） 。
  • OpenChain 项目发布了开源管理内部流程规范。
• 在寻求法律意见之前不要签署 “停止声明” （ Unterlassungserklärung ） 。如上所述，停止声明可能让您承担 GPL 身没有的义务和处罚。不要与版权牟利者合作。你可以使自己成为一个更难攻克的目标，并争取社区其他目标的帮助。
• 支持开源开发。作者不应该诉诸投机来谋生。使用开源软件的公司不应该期望开源开发人员免费开发软件，他们应该筹集资金支持重要项目。
• 学会识别版权牟利者。了解社区导向的 GPL 维权与版权勒索之间的一般差异。面向社区的维权一般旨在通过教育和帮助实现 GPL 合规，同时尊重用户的自由。相比之下，牟利行为可能侧重以不加考究和漫无目的的权力主张和威胁要提起法律诉讼来获得经济利益。注意确认优先考虑经济利益的权利主张，警惕不合理的损害赔偿金。
• 公开权利主张。如果你是一个牟利者的目标，并且可以选择公开其权利主张，那就公开它，通过阻碍对方的行动来帮助你和其他人。作为开源社区的成员，我们都有义务向那些企图以诉讼拖垮社区的牟利者们提出反对，因为问题能够以更恰当和更少争议的方式解决。

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

译者简介：张琳，集慧智佳知识产权咨询公司分析师，专业德语，辅修法律。

据自由软件基金会（FSF）报道，正在进行中的 GPL 合规案件 Artifex v. Hancom 近日产生了新的裁决，一项旨在提请简易判决的动议被法院驳回。

该案涉及一款遵循 GPL v3 及之后版本许可证的名为 Ghostscript 的软件，其来源于 Artifex 公司一个用于处理 PostScript、PDF 以及打印机的项目（GNU Ghostscript 是该项目的一个单独版本，并未涉及或牵连该案）。

FSF在之前的报道中表示：

在该诉讼中，基于 Hancom 公司对 Ghostscript 的使用情况，Artifex 公司提出了两项指控：（1）侵犯版权；以及（2）违反基于GPL许可证的合同。……虽然违反自由软件许可证将导致侵犯版权已经成为老生常谈，但是，违反 GPL 等许可证是否可以被视为违反合同，长期以来一直是许可专家们的讨论话题。

在之前的裁决中，本案的法官驳回了 Hancom 的撤案动议，让案件得以继续进行。现在诉讼已经到了下一步，其中包括一个主张 GPL 构成合同的 简易判决动议 （ Motion for summary judgment ） ，但是该动议日前也被法官驳回。在撤案动议中，法院假定所涉指控真实存在，并对所述指控是否真正提出了有效的合法权利主张做出了裁决。在简易判决动议中，法院会被要求去审视无可争议的事实，并确定该案件的结果是否如此明显，以至于不需要经过全面审判。类似动议虽然是例行的，但是如果通过了简易判决，意味着本案中合同理论的复苏问题依然存在（LCTT 译注：指是否被视为违法合同）。

Hancom 公司提出了一些否认 GPL 许可证构成合同的证据，其中一个特别有意思。Hancom 公司认为，如果 GPL 许可证构成合同的说法被接受，则只能考虑他们在初始违规日之前的损害赔偿。他们认为，由于违规造成了许可终止，合同也因此结束。法官指出：

GPL 许可证表明，在使用 Ghostscript 传播软件的权利被终止后，被告的义务依然存在，……因为每次传递“ 被覆盖作品 （ covered work ） ”，都需要提供源代码或承诺提供源代码，每次被告分发使用 Ghostscript 的产品，可以说随之而来的义务就是提供源代码或承诺提供源代码。

法官还发现，在这一点上没有足够的证据来对该问题做出裁决。所以，FSF 表示，目前还无法进行过多的解读。但是，法官对于违规行为之后 GPL 在什么条件下继续存在的看法，是随着本案进行，该问题如何发展的重要线索。虽然，为了保护用户自由， GPL 许可证并不需要作为合同进行维护（它作为版权许可已经成功运行了几十年）。不过，类似的程序性裁决显示了有更多的证据表明，GPL 许可证作为合同的主张在法院不容易站住脚或者容易被击败的说法并非毫无根据的造谣。

FSF 表示，随着简易判决动议被否，本案继续向前推进，并将变得更为有趣。

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

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

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

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

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

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

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

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

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

将来有一天您将必须提供您正在使用的开源软件的列表。及时维护该列表将会为您节约大量的时间和精力，因为潜在的投资者和收购方将会要求您提供该列表。大多数开源软件下载包中都包括一个 “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 分析、开源软件知识产权风险分析，致力于为互联网企业、高科技公司提供知识产权咨询服务。

对 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分析、开源软件知识产权风险分析，致力于为互联网企业、高科技公司提供知识产权咨询服务。