保留简略的版权声明即可，无需投入过多资源维护。

版权声明 （ Copyright Notice ） 在源代码中的应用并不一致且维护不善，结果导致它无法成为良好的信息来源。那是否应该投入更多资源来维护版权声明呢？答案是不需要。

版权声明是单行字符串，通常包括单词“版权”（或某些替代词，如 ©）、名称（通常是个人或公司）和年份。

在本文中，我不关注许可证或许可证声明（有时可能包括版权声明）。我关于版权声明维护的资源投入应该保持低优先级的建议不适用于许可证信息。许可证信息应清晰呈现并保持准确。如果你邀请其他人使用你的软件并对其进行操作，请通过提供并维护清晰的许可证信息来明确其授予的权限。

再说回版权声明：它们的法律意义是什么呢？如果你认为版权声明符合法律要求或至少提供了重要的法律权益，请三思。此类声明在开源软件中的法律意义是如此之小，以至于人们可以轻易地找到超出其法律意义的实际做法。

尽管此类声明可能看起来很重要，但它们在当今源代码中的存在很大程度上是过去美国版权法的残余影响。曾经有一段时间，如果未在已出版的材料中包含版权声明，依据美国版权法，版权人可能会完全丧失权利；当美国最终加入《伯尔尼公约》并成为缔约国时，情况发生了变化（美国于 1988 年 11 月 16 日加入该条约，并于 1989 年 3 月 1 日在美国生效）。

如果开源软件中的此类声明要想具备实效，则一个项目可以采用能够以更少的投入来维护并且仍然获得一些实用价值的约定，不必为了满足美国对“版权声明”的法定要求而去维护版权声明。

由于美国版权法一直是推动版权声明使用的重要因素，因此我将在此进行更深入的探讨。美国版权局发布了名为《通函-3号-版权声明》的指导文件，包括：

“在 1989 年 3 月 1 日之前首次出版的所有作品都必须放置版权声明，但下面讨论的某些情况例外。如果省略了该声明或在使用该声明时出现了错误，则通常该作品在美国将失去版权保护。版权声明对于 1989 年 3 月 1 日或之后出版的作品、未出版的作品和外国作品是可选的；但是，将版权声明包括在你的作品中将享有法律权益。”

上面我加粗强调的那句话清楚地表明，在 1988 年的美国，版权声明就非常重要。但是，当美国与其他许多国家一起加入《伯尔尼公约》时，美国法律对版权声明的关键作用被消除了。公约规定：“享有和行使这些权利不需经过任何手续……”

麻省理工学院的软件项目（The X Window System）和加州大学伯克利分校的软件项目（Berkeley Software Distribution）中诞生了早期的开源许可证文本，彼时严格的“放置版权声明否则丧失权利”要求仍然有效（或至少在为这些许可证文本做出贡献的人们心中是明确的）。诞生于这种时机的结果是，许可证文本中仍存在有关复制版权声明的明确描述。

随着基于早期文本的许可证的继续广泛使用，大多数开源软件开发人员已经看到，版权声明似乎在许可证中显得很重要。但是这些文本是在考虑较早的法律制度的情况下创建的。现在，距《伯尔尼公约》（大多数其他国家已经接受）的“无需手续性要求”规定首次适用于美国的时间已经过去 30 年了。要了解《伯尔尼公约》的通过程度，请参阅管理该公约的世界知识产权组织维护的缔约方清单。

你可能想知道上面引用中提到的那些“法律权益”具体指什么，答案在 3 号通函的末尾：

尽管对于未出版的作品、外国作品或于1989年3月1日或之后出版的作品，版权声明是可选的，但使用版权声明具有以下好处：

• 版权声明使潜在用户意识到该作品拥有版权。
• 对于已发表的作品，版权声明可能会阻止版权侵权诉讼中的被告试图减轻其基于无辜侵权辩护的损害赔偿或禁令救济的责任。
• 版权声明标识了在首次发布作品时版权所有者的权利，供寻求使用该作品的许可方使用。
• 版权声明标识首次出版的年份，对于匿名作品、假名作品或出租作品而言，可用于确定版权保护期限。
• 版权声明可能会通过标识版权所有者并设定版权期限来防止其成为孤儿作品。

上面就是所谓的那些“法律权益”。

我引用了美国版权局第 3 号通函，因为与基本法规相比，它对要求的措辞更具可读性。美国联邦一级的成文法被编入所谓的《美国法典》，该法典被组织为一组 “卷” （ Title ） 。第 17 卷是版权。版权声明的详细信息位于该卷的第 401-406 部分。可以从 17 USC 401 开始。在版权声明中需包含三个要素描述的有关法规要求，请参见 17 USC 401（b）。如果要查看“疏忽对无辜侵权者的影响”的详细信息，请参见 17 USC 405（b）。

为了提供更准确的信息，为什么不清理代码库中的版权声明？尴尬的是，17 USC 506（c）（欺诈性版权声明）、17 USC 506（d）（欺诈性删除版权声明）和 17 USC 1202（a）（虚假版权管理信息）提供了一些不利因素（即使仅限于不良意图）。由于价值较低且存在一定风险（如果在进行更改时出错），因此难怪没有更多资源用于维护版权声明。

有些人和一些公司强调将详细的版权声明放入根据开源许可证提供的代码中。其他人则没有。随着开源项目的发展，某些贡献中可能包含版权声明，而其他贡献则没有。即使文件的内容与原始版本相比发生了很大的变化，文件也可以包含原始版权声明，而不包含其他版权声明。或者以后的贡献者可以向以前没有版权声明的文件中添加一个版权声明。那作为版权声明要素的“该作品的首次出版年份”呢？这意味着什么？不同的人有不同的做法。已更新？那其他贡献提交之后呢？

至于从挖掘版权声明数据中得出结论，要谨慎。期望值不要那么高。

那开源项目应该怎么做呢？

请提供并维护清晰、准确的许可证信息。

对于版权声明来说，很难证明为维护版权声明的详细信息而进行的投入是合理的。但是有些人可能希望会出现版权声明。至于“软件的起源”，也许仅仅参考项目本身而不是尝试捕获更细粒度的内容可能会更有用和更准确。公开年份？手动维护源文件中的麻烦程度导致其不大值得；源管理工具以较低的资源成本提供了更准确的信息。

有关实用方法的更多详细信息，我建议你将注意力集中在对版权声明实践的重新思考上，可以参考 Steve Winslow 于 2020 年 1 月 10 日发布的《开源软件项目中的版权声明》。

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

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

对于让开源软件变得如此出色的协作开发来说，开源软件许可以其不同于常规软件许可的方式提供了诸多支持。

人们在使用常规软件许可时产生的实践和期望，也许会让他们在面对开源软件时感到沮丧。“请给我看下许可证”这种简单的要求，可能得不到令人满意的答复。尽管有的时候这种答复非常简单，但开源软件的许可信息通常更为复杂，达不到常规软件许可所设定的那种期望。

这是怎么回事儿呢？开源软件许可是否出毛病了？然而并没有。许可条款类型以及软件开发方式的差异，都会导致软件许可信息的传送方式不同。律师便利性和开发人员便利性之间的折衷是造成这种状况的部分原因。

如果只是说开源软件可以“协作”开发，那还没有弄清楚开源开发活动与常规许可软件之间可能存在的差别程度。尽管有像常规许可软件一样由一个人或一个固定的小团体来维护的开源项目，但是在开源项目上的协作可能会在广泛的潜在贡献者之间进行。例如，根据 GitHub 的“2019 年 Octoverse 报告” ，有超过 35 万人对前 1000 个项目做出了贡献。但是，开源软件开发与常规许可软件开发的不同之处不仅仅是贡献者数量。除了被发现对该开源项目拥有某些共同兴趣，为开源项目做出贡献的人们之间可能没有任何联系。人们的参与情况可能会随着时间的推移而变化。原始开发人员可能会离开，留下其他人继续进行项目开发。所有这一切都可能在没有规划或总体治理组织的情况下发生。

除了遵循规范性的治理规则，开源协作活动还是轻量级的，而且可以比常规许可软件更加灵敏地响应。有关开源许可信息的实践与这种协作开发方式相适应。

1. 针对二进制文件以及源代码，开源许可中的条款通过提供所需的权限（包括复制、修改和分发）促进了协作开发。事实证明， “开源定义” （ Open Source Definition ） （OSD）有助于将注意力集中在满足其要求的许可上。
2. 开源软件的许可信息嵌入在源代码中。当获得源代码时，就会接收到相应的许可信息。想象一下每年以百万计的贡献规模，单独的许可管理是否完全可行呢？同样，通过将许可信息嵌入源代码中，可以反映与许可相关的详细信息，而这些细节在某些单独管理的许可流程中不可行。例如，将许可信息嵌入源代码，使得指示哪些许可条款适用于软件的哪些部分变得切实可行。

为了说明开源许可实践所能实现的效果，请考虑以下示例性软件项目：

该项目始于 5 年前；到目前为止，已有 50 位贡献者做出了贡献；通过改编其他项目中的部分软件，增加了一些功能；原始代码的开发者在三年后离开；几家商业企业已经在其内部或一部分产品中依赖该软件；如果考虑到其他软件和计算机世界方面相关的变化，则该软件未来可能还会有 5-10 年的发展。

在开源项目中现有和常用的表示许可信息的方法，很容易适应这样一个项目的过程。没有预先规划，贡献者可以从项目中来来去去；项目的各个部分遵循不同的许可条款；如果与其他公司的合作破裂，商业企业可以继续以很少的管理开销成本分担软件维护工作，同时保持完全独立开发其软件分支的能力。

相反，传统的软件许可方法将如何支持这种开发呢？甚至这样的合作有可能发生吗？我们是否将拥有一个完整的许可基础结构来跟踪数千个“主软件开发和分发协议”的适用性？我们是否要通过让某些公司控制一切来简化许可？

让我们回到“是什么许可？”这个问题。我谈论开源开发特征的目的，是说明存在重要的影响开源许可信息如何表示的非法律因素。开源软件中许可信息的表示形式通常不符合常规软件许可的期望。但是，存在差异并不代表系统出毛病了。相反，对于支持过去二十年中已被证明有效的大规模协作开发这种软件构建方法来说，差异的作用非常强大。

开源许可信息是什么样的呢？

通常，人们会考虑每个“软件组件”的许可条款。软件组件可能作为应用程序对用户可见，或者对于用户来说可能不那么明显，例如与大型程序结合使用时可提供某些功能的库。

对于许多软件组件而言，许可很简单：组件中的所有软件适用数十种最常见的开源许可证中的一种。除了最常见的许可证之外，还有很多文本有所变动的不经常使用的许可证。但是，在“开源定义”的指导下，开源许可条款中的权限和限制仍保持在一定范围内。

如果要进行将开源软件集成到其他软件中的软件开发，那么你需要了解适用于所集成软件的所有 “左版” （ Copyleft ） 条款（例如著名的 GPL 系列许可证）。

由于从我对开源软件开发方式的讨论中揭示的显而易见的原因，许可信息可能比单个许可证更为复杂。

1. 尽管一个软件组件可能有一个主要的“项目许可”，但可能有一部分软件遵循其他许可证。这可能会导致在源代码的各个部分中出现不同的许可声明。
2. 一些项目的做法是在每个源文件中放置版权声明。其他项目主要依靠放置包含许可文本的一个或多个文件。
3. 版权声明指示谁可能是该软件部分的版权拥有者（但是，鉴于版权声明实践的多样性，该指示的作用可能微不足道）。
4. 用来构建软件组件的源代码可以包括未反映在所得组件中的软件，例如与测试或构建相关的文件。这对于使用无 GPL 规则（项目中可能包含遵循 GPL 许可证的文件，但用于生成可执行程序的文件不得包含遵循GPL许可证的文件）的人可能很重要。

因为许多细节都与某些许可信息涉及的软件部分有关，这种细粒度的许可信息在源代码中最有效地进行了传达。在最详细的级别上，源代码即许可证。当许可信息在源代码中时，可以用与源代码相同的方式（例如在版本控制系统中）来维护该许可信息，并且该信息固有地可用于获得源代码的任何人。

从源代码中提取许可信息并创建许可条款概要似乎很简单。但是，对于一个人或一个公司来说足够了的摘要，可能对于另一个人或公司是不足的。不同的人可能关注不同的许可信息细节。一些人可能想确切地知道该软件的哪些组件遵循“左版”条款。其他人可能并不关心所有组件的许可条款概要。还有的人可能需要包括每个不同的版权声明在内的所有许可声明。

你想查看哪些许可信息的细节呢？在软件开发中有大量的工具可以使用。扫描、提取和报告现有许可信息的工具是持续开发的活跃主题。现在，“是什么许可？”可能会改写为“向我显示许可信息报告”，该报告可能包括一系列程度不同的详细信息，具体取决于对请求报告的人的重要性。在最详细的级别上，源代码即许可证。

因为软件可以采用不同的方式构建出来，常规软件许可和开源软件许可分别适用于不同的领域。两者之间可能存在差异，对于这一点要做好准备。

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

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

提要：传统观点认为，Apache 许可证拥有“真正”的专利许可，那 MIT 许可证呢？

我经常听到说，MIT 许可证中没有专利许可，或者它只有一些“默示”专利许可的可能性。如果 MIT 许可证很敏感的话，那么它可能会因为大家对其较为年轻的同伴 Apache 许可证的不断称赞而产生自卑感，传统观点认为，Apache 许可证拥有“真正”的专利许可。

这种区分经常重复出现，以至于人们认为，在许可证文本中是否出现“专利”一词具有很大的法律意义。不过，对“专利”一词的强调是错误的。1927 年，美国最高法院表示：

“专利所有人使用的任何语言，或者专利所有人向其他人展示的任何行为，使得其他人可以从中合理地推断出专利所有人同意他依据专利来制造、使用或销售，便构成了许可行为，并可以作为侵权行为的辩护理由。”

MIT 许可证无疑拥有明示许可。该许可证不限于授予任何特定类型的知识产权。但其许可证声明里不使用“专利”或“版权”一词。您上次听到有人表示担心 MIT 许可证仅包含默示版权许可是什么时候了？

既然授予权利的文本中没有“版权”和“专利”，让我们来研究一下 MIT 许可证中的字眼，看看我们能否了解到哪些权利被授予。

没有任何信息会导致人们认为，许可人会保留对使用专利所有人创造的软件的行为起诉专利侵权的权利，并允许其他人“无限制地处理本软件”。

为什么说这是默示专利许可呢？没有充足的理由这么做。我们来看一个默示专利许可的案例。Met-Coil Systems Corp. 诉Korners Unlimited 的专利纠纷涉及专利的默示许可（美国专利 4,466,641，很久以前已过期），该专利涉及用于连接供暖和空调系统中使用的金属管道段。处理该专利纠纷上诉的美国法院认定，专利权人（Met-Coil）出售其成型机（一种不属于专利保护主体的机器，但用于弯曲金属管道端部的法兰，使其作为以专利方式连接管道的一部分）授予其客户默示专利许可；因此，所谓的专利侵权者（Korners Unlimited）向这些客户出售某些与专利有关的部件（与 Met-Coil 机器弯曲产生的法兰一起使用的特殊角件）并不促成专利的侵权，因为客户被授予了许可（默示许可）。

通过销售其目的是在使用受专利保护的发明中发挥作用的金属弯曲机，专利权人向机器的购买者授予了专利许可。在 Met-Coil 案例中，可以看到需要谈论“默示”许可，因为根本不存在书面许可；法院也试图寻找由行为默示的许可。

现在，让我们回到 MIT 许可证。这是一个明示许可证。这个明示许可证授予了专利许可吗？事实上，在授予“无限制地处理软件”权限的情况下，MIT 许可证的确如此。没有比通过直接阅读授予许可的文字来得出结论更有效的办法了。

“明示专利许可”一词可以用于两种含义之一：

• 包括授予专利权利的明示许可证，或
• 明确提及专利权利的许可证。

其中第一项是与默示专利许可的对比。如果没有授予专利权利的明示许可，人们可以在分析中继续查看是否默示了专利许可。

人们经常使用第二个含义“明示专利许可”。不幸的是，这导致一些人错误地认为缺乏这样的“明示专利许可”会让人寻找默示许可。但是，第二种含义没有特别的法律意义。没有明确提及专利权利并不意味着没有授予专利权利的明示许可。因此，没有明确提及专利权利并不意味着仅受限于专利权利的默示许可。

说完这一切之后，那它究竟有多重要呢？

并没有多重要。当个人和企业根据 MIT 协议贡献软件时，他们并不希望稍后对那些使用专利所有人为之做出贡献的软件的人们主张专利权利。这是一个强有力的声明，当然，我没有直接看到贡献者的期望。但是根据 20 多年来我对依据 MIT 许可证贡献代码的观察，我没有看到任何迹象表明贡献者认为他们应该保留后续对使用其贡献的代码的行为征收专利许可费用的权利。恰恰相反，我观察到了与许可证中“无限制”这个短语一致的行为。

本讨论基于美国法律。其他司法管辖区的法律专家可以针对在其他国家的结果是否有所不同提出意见。

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

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

提要：对于开源软件来说，其许可证信息内嵌在源代码中。为了降低复杂性，您可以生成不同的视图。

您可以通过查看源代码找到开源软件的许可证信息。为了满足不同的需求，可以生成关于该许可证信息的不同视图或报告。

尽管直接在源代码中提供许可证信息并不是开源软件的必要条件，但是这样做的实际好处显而易见。由于开源许可证促进了软件的传播，与代码一起传输的许可证信息简化了管理过程，即使代码接收人通过间接方式获得代码，也可以使他随时可以获得权限声明。

什么是许可证条款？

在源码树中嵌入许可证信息的价值被低估了。让我们暂停一下，反思一下这种常见做法是多么有用。

什么是许可证条款呢？ 对于许多开源软件来说，有一个简单的答案：一个许可证文本包含整个软件的所有许可证信息。但是开源的力量在于，它推动了其他开发者在这个起点之上进行构建，而这个过程会使许可证信息复杂化。

开源软件可以被扩展、再利用，或者与其他软件结合使用。与机械设备不同，不同群体之间的合作更具挑战性，复杂软件从许多人的工作中受益是切实可行的。开源许可证提供了促进这种开发动态的权限。具有复杂历史的软件也可能具有复杂的许可证信息。

考虑下面的例子：有人写了一个新的程序，在每个源文件中包含一个版权声明，声明该软件根据 Apache 2.0 版许可证进行许可，并且在源码树的根目录中包含 Apache 许可证文本。之后，添加了一个具有不同的版权声明的文件，以及一个 BSD 2 句版许可证副本的文件。然后，添加了一个新的子目录，其中文件具有 Apache 许可证声明，但具有标识不同版权所有者的版权声明。再之后，一个 MIT 许可证的副本添加到了新的子目录中，该子目录包含了版权声明与 MIT 许可证文件中相同的文件，但没有任何其他许可证指示信息。

这个例子表明，嵌入在源码树中的许可证信息可能很复杂而且很详细。根目录和/或各个子目录中都可能有许可证文本。一些源文件可能有许可证通知；其他源文件可能不会有。也许会有版权声明来识别各种版权所有者。但是，在不丢失信息的前提下将法律文本从代码中分离出来似乎是不可能的。因此，源代码即是许可证。

从源码树的角度来看，上面例子中对许可证信息的解释是非常简单的。但是，要在简单、明确的独立声明中获取许可证信息将是一件困难的事情。截取了源代码中所有许可证信息的许可证声明会比源代码更短，但这将是不方便的——谁会希望得到如此高度详细的单独声明？大多数用户可能会更喜欢一个概要，虽然不完整，但其获取的关键点符合自己的特定意图和敏感性要求。

用视图来概括许可证信息

对于“许可证条款是什么”这个问题，用整个源码树副本来回答可能没什么用，因为它过于庞杂和分散。大多数人只想要一个概要。但这面临一个挑战：当许可证信息比较复杂时，人们需要不同的概要，因为他们对于什么是重要的有不同的定义。

对于某些人来说，对以下问题回答“是”可能是足够的：该软件 1）是否根据一个或多个开源许可证获得许可，2）其被组装和许可后是否使得其分发和使用与所有这些许可证一致？ 其他人可能需要所有许可证的列表，或者他们可能想要查看哪个软件组件对应于哪个许可证。还有一些人可能想要一个逐个组件的列表来标识任何 左版 （ copyleft ） 许可证（也许自己要做深入的左版合规研究）。 有些人可能有兴趣看到所有版权声明和软件组件的相关列表。

单一的概要可能不会满足所有人的利益。简单地将概要具体化可能会减少它对一些人的效用，而对其他人则显得不足。因此，需要将源代码中包含的许可证信息展现为不同的 “视图” （ views ） 。这里使用的“视图”术语可以视为与在数据库中使用它相似。或者，您也可以将“视图”看作是 “报告” （ reports ） 。

考虑将源代码作为许可证有一个优势，并且可以从中提取多个不同的视图。

您可能会尝试创建一个“全能”概要，从中可以创建其他较短的概要。但是以中间状态表达许可证信息至少有三个缺点：

1. 时机：主概要的维护人员可能无法按计划进行更新。
2. 版本：主概要可能基于与您使用的软件不同的版本。
3. 质量：您的视图继承了主概要的错误和评判性。

因此，根据需要直接从您使用的源码树版本生成您的首选视图是有价值的。

有工具可以生成视图。按需视图的生成取决于工具。许可证信息展示的清晰（或混乱）程度会促进（或妨碍）该工具的功效。我们不需要许可证信息的特定机器编码，但是我们应该充分利用众多经验来源，以既可以被人读取，也可以被机器提取的方式来表达信息。

Jeff Kaufman 在他的文章《开源软件许可证合规的经济高效模型》中指出：由于源代码包含许可证信息，因此分发源代码是满足某些许可证要求的有效方式。

将所有许可证信息嵌入到源码树中是最佳实践。如果您发现源码树中没有显示许可证信息，请考虑通过提交错误报告来改进该项目，建议将该信息添加到源码树中。

源代码即是许可证。从完整的记录中，可以生成许可证信息的视图。工具可以将许可证信息提取到各种报告中，以满足特定需求或敏感性要求。

为了获得这个愿景的全部好处，我们还有工作要做。您对工具状态以及许可证信息展现有什么看法呢？

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

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