引言：“开源”与“自由”不等于否认知识产权
一、 什么是开源软件的版权声明义务
二、 宽松型开源许可证对版权声明的要求
BSD许可证
Apache许可证
三、 如何将开源版权声明等信息纳入软件发布
原始发布者
后续发布者
四、 建议：重视开源合规，加强版权信息管理
不从事软件知识产权实践的人士，很容易误解开源软件、自由软件与知识产权之间的关系，认为Richard Stallman、Linus Torvalds等软件工程师们所开创的开源软件、自由软件运动完全否定了知识产权（尤其版权）的规则。但是，正如笔者在很早之前就指出的，“开源”并不是全盘否认知识产权，它只是在特定的时代背景下，在特定的行业中，针对特定的现象提出的。这个特定的时代，就是我们今天的知识经济和信息经济的时代；这个特定的行业，就是处在信息行业浪头的软件行业；这个特定的对象，仅仅是指软件行业中由于封闭源代码而造成的种种不合理的现象。”[1]
开源软件所倡导的游戏规则并没有偏离知识产权法。就这点而言，在一线从事软件编程并经常跟开源代码和开源许可证打交道的工程师们，往往比法律人有更直观的感受。可以这么说，开源软件有一套属于自己的知识产权游戏规则，其借力打力的方式，深得版权保护之精髓，也因此得以不断壮大开源软件的疆域，并影响到整个软件行业的基础生态。
本文以宽松型的开源软件许可证的文本和实践为例，说明开源软件如何要求后来者们履行“版权声明”等信息告知义务，从而实现其追求的价值理念。一个合规的开源软件包，或者遵守开源合规的商业软件包，都会包含一个叫做“Notice”的版权声明文档，与Notice文档并列的往往是“License”许可文档和Readme文档。有时Notice和License文档也可能放在一个文件里。一个开源项目在对外发布其开源代码时，其表述可能是这样的：这个版权声明明显采用了MIT许可证模板[2]（如下），其起到的信息告知功能主要有三点：1. 表明软件作品的作者，或者声明版权人的身份（这里是Acme Corp）；2. 告知对本软件的许可使用的方式（这里包括使用、复制、修改、合并、分发、分许可、销售复制件等等）；3. 告知使用本软件的限制。值得注意的是，无论是“著佐型”（copyleft）的开源许可证例如GPL，还是“宽松型”开源许可证例如BSD、Apache、MIT许可证，都有类似的针对软件传播者的版权声明、许可声明的要求。因此，上文用红色圈出的非常简单的使用限制——“本软件或者其实质部分必须包含有上述版权声明以及许可声明”，虽然不像GPL那样具有开源“传染性”的强制要求，但构成了开源软件运动的最为基础的知识产权游戏规则。
开源软件许可证所设置的版权声明的义务是具有法律约束力的。因此，从事软件开发的企业千万不能认为，宽松型开源许可证之下的代码是没有知识产权的，可以任意拿来使用，不需要承担任何义务。实则，对在先开源代码开发者的身份性版权（具化为版权许可和限制性条件）的尊重，是最为基本的游戏规则。下文以BSD、Apache许可证为例子加以说明。BSD许可证是“伯克利软件发行”许可证的简称，其有所谓的“零条”、“两条”到“4条”等许可版本。[3]该许可证的规定相当简洁，唯一强调的就是“版权声明、条件列表和免责声明”必须时刻跟着开源代码进行传播。其表述如下： |
| Zero Clause BSD：Retain the copyright notice, list of conditions, and the disclaimer on all redistributions of the source code. 【保留所有重新分发源代码的版权声明、条件列表和免责声明。】 |
| 2-Clause BSD License：Reproduce the copyright notices, list of conditions, and the disclaimer on all documentation or any other material accompanying the distribution. 【在所有文档或随分发的任何其他材料上复制版权声明、条件列表和免责声明。】 |
| Not use the name of the organization or contributors in the copyright notice to endorse or promote products without written permission. 【未经书面许可，不得在版权声明中使用组织或贡献者的名称来背书或宣传产品。】 |
Apache许可证的要求更多，对使用依照Apache许可证发布的开源软件的后来者，提出了更加细致的合规要求。具体包括：（1）提供原来许可证的副本；（2）提供更改原开源软件的声明；（3）保留来自作品源形式的所有版权、专利、商标和归属声明；（4）在分发的软件的恰当位置，提供包括版权归属声明的可读副本。下面是Apache License 2.0的相关条款[4]，读者可以详细比较其与BSD许可证的区别。| Apache 4. Redistribution. （4. 再分发） |
| a. You must give any other recipients of the Work or Derivative Works a copy of this License; and 【您必须向作品或衍生作品的任何其他接收者提供本许可的副本；和】 |
| You must cause any modified files to carry prominent notices stating that You changed the files; and 【您必须使任何修改过的文件带有显著的声明，说明您更改了文件；和】 |
| You must retain, in the Source form of any Derivative Works that You distribute, all copyright, patent, trademark, and attribution notices from the Source form of the Work, excluding those notices that do not pertain to any part of the Derivative Works; and 【您必须在您分发的任何衍生作品的源形式中保留来自作品源形式的所有版权、专利、商标和归属声明，不包括与衍生作品任何部分无关的声明 ; 和】 |
| If the Work includes a "NOTICE" text file as part of its distribution, then any Derivative Works that You distribute must include a readable copy of the attribution notices contained within such NOTICE file, excluding those notices that do not pertain to any part of the Derivative Works, in at least one of the following places: within a NOTICE text file distributed as part of the Derivative Works; within the Source form or documentation, if provided along with the Derivative Works; or, within a display generated by the Derivative Works, if and wherever such third-party notices normally appear. The contents of the NOTICE file are for informational purposes only and do not modify the License. You may add Your own attribution notices within Derivative Works that You distribute, alongside or as an addendum to the NOTICE text from the Work, provided that such additional attribution notices cannot be construed as modifying the License. 【如果作品包括“声明”文本文件作为其分发的一部分，则您分发的任何衍生作品都必须包括此类声明文档中包含的版权归属声明的可读副本（不包括与该衍生作品任何部分无关的声明），且位于以下位置之一：在作为衍生作品一部分分发的声明文本文件中；在源表单或文档中，如果其与衍生作品一起提供；或者，在衍生作品生成的显示中，如果此类第三方通知通常出现以及在其出现之处。声明文件的内容仅供参考，不构成对许可证的修改。您可以在您分发的衍生作品中添加您自己的归属通知，与作品中的通知文本一起或作为附录，前提是此类额外的归属通知不能被解释为修改许可。】 |
| You may add Your own copyright statement to Your modifications and may provide additional or different license terms and conditions for use, reproduction, or distribution of Your modifications, or for any such Derivative Works as a whole, provided Your use, reproduction, and distribution of the Work otherwise complies with the conditions stated in this License.【您可以在您的修改中添加您自己的版权声明，并且可以为您的修改的使用、复制或分发或任何此类衍生作品的使用、复制或分发提供额外的或不同的许可条款和条件，前提是您使用、复制和分发的作品符合本许可证中规定的条件。】 |
不同的开源许可证有内容不同的约束性条款，例如Mozilla Public License Version 2.0 [5]第3.1-3条分别规定了用户以源代码形式、可执行代码形式或者“更大作品”形式发布的声明要求；第3.4条还特别规定了允许用户纠正已知的事实错误（篇幅所限，下文仅列举3.4）。
| Mozilla 2.0 - 3.4. NoticesYou may not remove or alter the substance of any license notices (including copyright notices, patent notices, disclaimers of warranty, or limitations of liability) contained within the Source Code Form of the Covered Software, except that You may alter any license notices to the extent required to remedy known factual inaccuracies.【您不得删除或更改受保护软件的源代码形式中包含的任何许可声明（包括版权、专利、免责声明或责任限制）的实质内容，除非是纠正已知的事实错误所需。】 |
原始发布者是指独立开发出不包含第三方版权的代码之后，向用户提供软件代码的当事人。代码的原始发布者可以参照各类许可证的版权声明和许可声明模板，向公众发行开源代码。例如下面的版权声明就参照了Apache许可证的模板。这种情况下一般不会出现合规的问题，当事人只要表明自己的版权人身份以及许可证信息即可。
容易出现版权合规纠纷的情况下是后续用户在使用开源软件之后进行了修改，或者将开源软件包含到自己新开发的软件包之中。这些情况是软件开发时的常见情况。如果软件开发商在开发软件时使用到开源软件的，就必须按照相应的开源软件许可证的要求，附上被利用到的开源软件（代码）的原有的版权声明等信息。值得注意的是，即便某些宽松型的开源许可证允许用户将开源代码进行商业化，例如改编成为商业软件并进行闭源，但前述涉及版权声明的义务依然没有被豁免。也即，利用他人的开源软件，不论后续是选择开源或闭源项目运作，都必须履行信息告知义务，向公众提供被利用的源代码的版权声明、许可声明等信息，使后来人知道其中的哪些代码是由谁贡献的，是按照什么开源许可证发行的，以便开源链条的延续。可以设想，如果软件项目很大，涉及众多开源代码，那么相应的版权声明、许可声明等信息，必然会非常冗长。但这就是开源软件必须遵循的规则和逻辑。感兴趣的读者可以移步到中兴公司有关手机的安卓开源项目ZTE Blade A31 Plus RU_Android 11(R GO)_kernel(4.14.193)，看看其开源许可条款（ZTE Open Source License Terms）[6]，以及开源代码的相关声明列表。这里仅借中兴的开源许可证条款为例加以说明。第一步：在诸如许可文档之中明确说明，本产品包含了开源代码（组件），并提醒用户查证和遵循相关的条款和声明，包括GPL许可证、Apache许可证的网址以及本地地址（如下图所示）。
第二步：提供使用到的开源代码（组件）的清单（如下图所示）。第三步：针对每个开源组件，提供相应的版权声明和许可证声明。以上图末端的“蓝牙”相关代码组件为例（位置是/system/bin/bluetoothd），ZTE在这份冗长的文档之中，就根据开源许可证的要求，提供了包括三个版权人（即Qualcomm 、Maxim Krasnyansky和Marcel Holtmann）的版权信息和许可证信息（GNU General Public License）的全文（如下图）。有些软件开发者为了简便Notice文档，减少篇幅，有时会出现下述做法：第一是仅提供开源许可证的链接，第二是不区分开源许可证的版本。第一种情况可能不符合开源许可证的要求。因为在没有互联网的情况下（尽管这种情况越来越少见），用户就无法阅读到许可证的内容了。第二种情况则明显违反了开源许可证的要求，因为开源许可证的版本更替可能会导致权利义务的实质性差异。因此，谨慎起见，在发布新软件时应该一并提供版本准确的开源许可证的全文。如果软件开发者在使用了开源软件之后，有意或者无意不公开相关的版权声明、许可声明等信息，甚至篡改了相关的信息（例如将版权人更改为自己），都属于违反了开源许可协议的行为。按照各国近几年司法裁判所确立的规则，这类违反许可协议的行为将导致许可协议失效，违反者使用开源代码的行为也将变成侵犯版权的行为。涉开源代码的软件项目的管理者如果着眼于产业未来的推广和成功，必须从项目一开始就关注开源合规，用心做好软件开发时所使用的开源代码的权利管理，按照相关许可证的要求，收集相关的版权、许可声明等信息，建立相关列表，尽可能详细向用户告知相关的信息。在跨国软件开发项目之中，这可能非常耗费心力，但却是开源软件合规的必经之途。
[1] 张韬略：开源软件的知识产权问题研究——制度诱因、规则架构及理论反思，北京大学硕士论文，2004年3月。
[2] See MIT License, https://mit-license.org/
[3] See BSD License, https://linuxreviews.org/BSD_licenses
[4] See Apache License 2.0，https://www.apache.org/licenses/LICENSE-2.0.html
[5] See Mozilla Public License Version 2.0，https://www.mozilla.org/en-US/MPL/2.0/
[6] ZTE Open Source License Terms，http://download.ztedevices.com/device/global/support/opensource/mobilephones/open_source_notice.html
排版/钱榕