标准与开源:为什么专利待遇不同?

这种差异对我们如何构建开发过程产生影响。
372 位读者喜欢这篇文章。
a magnifying glass looking at a brain illustration

Opensource.com

标准规范的制定和开源软件的开发有很多共同之处:两者都是竞争对手可以协作的机制;两者都可以促进互操作性;两者都可以用于促进新技术的采用;两者都可以用于使成熟技术具体化或协调一致。

一项技术可以同时使用标准和开源:有时一个先于另一个;在其他情况下,它们可能会并行进行。 越来越多地,它们可能会使用类似的工具和流程实践(例如,细粒度的版本控制;通过问题跟踪器驱动某些开发讨论)。

相似性的程度可能导致过度概括,错误地暗示一切都是可互换的——混合搭配——在这里选择一种实践;在那里将其与一个过程结合起来。 实际上,借鉴在一个领域获得的经验,看看它提供的益处是否可以在其他环境中获得可能是有价值的。 但是,对于某些实践,上下文比可能看起来更重要。

虽然存在相似之处,但也存在显着差异。 在之前的一篇文章(没有规则的治理:分叉的潜力如何帮助项目)中,我讨论了开源软件开发和标准开发的治理在利用分叉潜力作为可以促进轻量级治理的力量方面的差异。 另一个差异与专利规则的选择有关。

专利待遇

参与者专利权的待遇在开源软件开发和标准开发中通常以不同的方式安排。 这种差异是有其道理的。 而且,这种差异对构建开发过程产生影响。

  • 开源: 贡献给开源项目时授予的专利许可通常以每个贡献者的贡献为范围。
  • 标准: 标准开发参与者做出的专利承诺通常以整个最终规范为范围。

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

我所说的以贡献为范围的专利规则是什么意思? 如果专利所有者贡献软件,使得由于软件添加到项目中,项目软件侵犯了该贡献者拥有的专利,那么贡献者不应该回来并期望因使用其贡献的软件而收取专利许可费。 当然,有很多不同的许可文本可以让我们忙于分析每个许可的解释,并讨论情况中的不确定性和细微差别。 在另一篇文章中,我在 MIT 许可证的背景下讨论了这个问题(为什么 MIT 许可证中的专利授权如此不受欢迎?)。 我认为,基本上,开源开发中的共同期望正如我上面所描述的那样:当您为开源做出贡献时,您正在为您贡献的软件提供所有需要的权限,并且您以后不会回来要求为使用您贡献的软件支付许可费。

标准开发:基于规范的专利规则

相比之下,在标准制定中,通常有更高的期望:参与者预计会对整个最终规范(而不仅仅是他们的贡献)所必需的专利做出承诺。 这些专利承诺不取决于确定谁为规范贡献了什么想法;对于那些参与规范制定小组的人来说,他们的承诺是针对整个规范的。

包含的专利

确定相关专利的分析在软件和规范之间也有些不同。 与相应的标准规范相比,软件通常会包含不需要的实现细节;贡献软件时将包括使用这些细节上的任何专利的许可。 相比之下,规范开发的专利承诺仅限于对规范“必要”或“必不可少”的专利。 当然,这取决于规范的内容。 对于互操作性标准,规范应仅包含实现互操作性所需的详细程度,允许实现细节在标准的竞争实现之间有所不同。 对必要专利的承诺不包括实施细节的专利,实施细节可用作竞争差异化因素。

专利规则差异的基础

为什么专利待遇存在这种差异? 考虑到标准和开源软件的开发方式的差异,这种不同的待遇是有道理的。

关于专利的更有限的、基于贡献的期望符合大多数协作软件开发的增量演进、开放式性质。 开源项目通常会进行持续开发,其方向可能会随着时间的推移而演变。 虽然可以设置路线图和里程碑并拍摄快照,但这些不如标准项目常见的范围限制和版本目标那么常见,也没有那么严格的影响。

考虑到标准规范的开发结构方式的差异,人们可以理解标准开发的典型较高期望(整个最终规范,而不仅仅是贡献)是有道理的。 标准规范通常经历强版本导向的演进,并具有明确的范围。 规范开发通常致力于特定的快照版本。 标准开发活动通常会有一组目标功能(通常在诸如章程之类的文档中表达)。 与许多软件开发活动的情况相比,这为潜在参与者在开始参与时评估参与标准开发项目的专利影响提供了更清晰的共同预先期望。 将此与更开放式的开源软件开发项目进行对比,该项目通常不会排除合并任何特定技术的可能性。

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

这些不同的专利方法需要在项目管理中采用不同的方法。

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

另一方面,参与标准开发活动通常具有更大的正式性。 而且,当涉及到专利承诺时,这种参与的正式性很重要。 当一个人参与了该规范的大部分开发时,对最终规范的专利承诺是有意义的。 标准开发过程能否期望从提供单一、狭隘贡献的人那里获得完整的最终规范承诺? 重要的是要有一个流程,能够清楚地了解谁在参与,谁没有参与。 需要参与的清晰度来支持来自实际专利所有者的专利承诺,这些专利所有者通常是由坐在桌子旁(比喻地讲;尽管这可能涉及实际的桌子)的个人代表的公司。

如何获得规范范围内的承诺? 软件标准的典型免版税专利承诺最常见的实施方式是作为标准组织会员资格或负责规范开发的特定委员会会员资格的条件。 为了使这种机制发挥作用,会员资格必须是一个明确的概念,以便存在明确的会员资格决策点(即,将用于触发承担专利承诺的明确行动)以及受益人可以依赖的明确记录。 除了参与的清晰度之外,为了促进持怀疑态度的专利所有者参与,项目需要具有明确的范围以及明确的开始和结束(并明确承诺将适用的“最终规范”)。 这种参与模式与典型的开源项目显着不同,开源项目可能具有从少数主要驱动因素到可能仅提交单个补丁的人员的连续参与。

专利政策

虽然我描述的差异通常是这种情况,但特定活动可能有理由遵循不同的模式。 例如,考虑作为标准开发活动的参考实现的软件。 期望参与者对完整的最终参考实现做出承诺,而不仅仅是对其贡献做出承诺,可能存在充分的理由。 当然,可能存在其他边缘情况;可能存在严格计划的开源开发;可能存在持续的、自由放任的规范开发。

标准开发的专利政策可以分为合理且非歧视性 (RAND) 或免版税 (RF):本质上,实施标准的专利许可费是否被认为是可以接受的 (RAND) 或不可接受的 (RF)。 与软件相关的标准(本文的重点)的开发更常使用免版税政策。 专利许可费是否被期望收取的问题是政策的一个独立维度,与许可或承诺的范围无关。

结论

标准开发和开源软件开发通常对参与者的专利期望范围不同(仅限于贡献或整个最终交付成果)。 这些不同的选择并非任意差异,而是有其道理的,这是基于开发方式的显着差异。

标签
User profile image.
Scott Peterson 是 Red Hat 法律团队的成员。 很久以前,一位工程师就一份名为 GPL 的奇怪文件向 Scott 寻求法律建议。 那个命运攸关的问题开启了探索协作开发法律方面的曲折道路,包括技术标准和开源软件。

1 条评论

合适的文章

© 2025 open-source.net.cn. All rights reserved.