开源与标准：为什么对待专利如此不同？

制定标准规范和开源软件的开发有许多共同之处：两者都是竞争者可以合作的机制；两者都可以促进互操作性；两者都可用于促进新技术的采用；两者都可用于聚合或协调成熟技术。

一项技术可以同时使用标准和开源：有时一个先于另一个；在其他情况下，它们可以并行进行。它们越来越多地使用类似的工具和流程实践（例如，细粒度版本控制；利用问题跟踪器一起推动某些开发讨论）。

相似程度可能导致过度概括，错误地暗示一切都是可互换的（混合与搭配），在这儿选择一种做法；在那儿将它与一个过程相结合。实际上，获取在一个领域中获得的经验并查看它提供的好处是否可以在其他环境中获得，可能是有价值的。但是，对于某些实践而言，背景更为重要。

虽然有相似之处，但也存在显著差异。在前面的文章《没有规则的治理：复刻潜力如何帮助项目》中，我讨论了在利用 复刻 （ forking ） 潜力作为一种可以促进轻量级治理的力量方面，开源软件开发和标准开发治理能力的不同。另一个不同之处在于专利规则的选择。

如何对待专利

参与者专利权的处理通常在开源软件开发和标准开发中以不同方式排列。这种差异有一个理由。而且，这种差异会对构建开发过程产生影响。

• 开源：在为开源项目做出贡献时授予的专利许可通常由每个贡献者的贡献确定。
• 标准：参与者在标准制定方面做出的专利承诺通常由整个最终规范确定。

开源项目：基于贡献的专利规则

基于贡献的专利规则是什么意思？如果专利所有者提供软件，由于软件添加到项目中，项目软件侵犯了该贡献者拥有的专利，那么贡献者不应该返回来期望获得使用它所贡献的软件的专利许可费。当然，有许多不同的许可文本可以让我们忙于分析每个许可的解释，并讨论情况中的不确定性和细微差别。在另一篇文章中，我在 MIT 许可协议的背景下谈到了这个问题（《为什么 MIT 的专利许可不讨人喜欢？》）。我认为，基本上来说，开源开发中的共同期望就像我上面所描述的那样：当你为开源做出贡献时，你将为你提供的软件提供所有必需的权限，之后你将无法返回来再要求获得使用你所贡献软件的许可费。

标准制定：基于标准规范的专利规则

相比之下，在制定标准时，通常会有更高的期望：参与者应对专利做出承诺，这些专利对整个最终规范至关重要，而不仅仅是对其贡献。这些专利承诺并不取决于确定谁对规范提出了什么想法；对于那些参与开发规范的人来说，他们的承诺是整个标准规范。

包括在其中的专利

确定相关专利的分析在软件和规范之间也有所不同。软件通常包括与相应的标准规范相比不需要的实现细节；在提供软件时，将包括对这些细节使用任何专利的许可。相反，规范开发的专利承诺仅限于对规范“必要”或“必需”的专利。当然，这取决于规范的内容。对于互操作性标准，规范应仅包括实现互操作性所需的详细级别，从而允许实现细节在标准的竞争性实现之间有所不同。对必要专利的承诺不包括实施细节方面的专利，这些专利可用作竞争优势。

专利规则差异的基础

为什么在专利处理方面存在这种差异？鉴于标准和开源软件的开发方式存在差异，这种不同的处理方式很有意义。

更有限的与贡献范围相关的专利符合大多数协作软件开发的渐进式、开放式特性。开源项目经常持续发展，其方向可能会随着时间的推移而演化。虽然可以设置路线图和里程碑并发布快照版本，但这些不太常见，并且比标准项目中常见的范围限制和版本目标具有更少的限制性影响。

可以看出，考虑到标准规范开发结构的差异，标准开发的更高期望值（整个最终规范，不仅仅是贡献）是有意义的。标准规范通常采用具有明确范围的强版本导向演进。规范开发通常适用于特定的快照版本。标准开发活动通常具有一组目标功能（通常在诸如章程之类的文档中表示）。与许多软件开发活动的情况相比，这为可能应用到标准开发活动的技术范围提供了更清晰的公共的进展预期。这种范围的明确性有助于潜在参与者在开始参与时评估参与标准制定项目的专利影响。相比之下，开源软件开发项目更为开放，通常不会排除采用任何特定技术的可能性。

对开源项目和标准管理的影响

这些对待专利的不同措施需要不同的项目管理方法。

开源项目通常准备接受来自新贡献者的补丁。贡献者可能会随着时间的推移而来去。一些贡献者留下来。其他人可能会为该项目来解决一个有限的问题。通过软件贡献，可以更容易地了解谁贡献了什么软件，而不是准确理解谁以一种更抽象的方式“参与”。

另一方面，参与标准制定活动通常具有大量的正式手续。而且，在涉及专利承诺时，这种参与的正式性非常重要。当一个人参与该规范的大部分开发时，对最终规范的专利承诺是有意义的。标准制定过程是否可以从提供单一、有限贡献的人那里获得完整的最终规范承诺？重要的是要有一个过程，以便清楚地了解谁参与谁，谁不参与。需要明确参与者以支持来自实际专利所有者的专利承诺，实际专利所有者通常是由坐在桌旁（比喻，尽管这可能涉及实际的谈判桌）的个人所代表的公司。

如何获得基于规范的承诺？软件标准中典型的免许可费专利承诺最常被作为获得标准组织成员资格或负责规范开发的特定委员会成员资格的条件。为了使这一机制发挥作用，成员资格必须是一个定义明确的概念，以便有一个明确的成员资格决策点（即，用于触发专利承诺的明确行动）和承诺的受益人可以依赖的明确的记录文件。除了参与清晰度之外，为了促进持怀疑态度的专利参与者的参与，项目需要具有明确的范围和明确的开始和结束（明确指出专利承诺将适用的“最终规范”）。这种参与模式与典型的开源项目有很大不同，典型的开源项目可能有一个连续的参与，其范围包括维护几个主要的驱动程序到只提交一个补丁。

专利政策

虽然我所描述的差异通常是这种情况，但某些特定活动遵循不同模式可能有一些原因。例如，考虑作为标准开发活动附带的参考实现的软件。可能有一个强有力的理由期望参与者对完整的最终参考实施提供承诺，而不仅仅是限定于他们对它的贡献。当然，可能存在其他边缘情况；可能存在严格安排的开源开发；可能会有连续的、随心所欲的规范开发。

标准制定的专利政策可分为合理和非歧视（RAND）或免许可费（RF）：基本上来说，实施标准的专利许可费包括需要交（RAND）或不需要交（RF）。制定与软件相关的标准（本文的重点）更多地使用免许可费政策。关于专利许可费预期问题是许可或承诺范围政策之外的另一个维度。

结论

标准的制定和开源软件的开发通常具有不同的参与者专利期望范围（仅限于贡献或整个最终可交付成果）。这些不同的选择基于通常如何进行开发的显著差异，而不是任意差异。

作者简介：Scott Peterson 是红帽公司法律团队成员。很久以前，一位工程师就一个叫做 GPL 的奇怪文件向 Scott 征询法律建议，这个致命的问题让 Scott 走上了探索包括技术标准和开源软件在内的协同开发法律问题的纠结之路。

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

本文转载来自 Linux 中国: https://github.com/Linux-CN/archive