1# OpenHarmony项目代码许可证与特殊许可证评审指导 2 3## 目的 4 5本指导明确了OpenHarmony社区中的项目代码所采用的许可证，以及接纳的特殊许可证及相关评审流程和规范。 6 7## 范围 8 9本指导仅适用于OpenHarmony社区中分发的项目代码，不适用于将OpenHarmony项目应用于个人或企业以开发其它产品的场景，也不适用单独分发第三方开源软件的场景。 10 11## 定义 12 13OpenHarmony项目：OpenHarmony是由开放原子开源基金会（OpenAtom Foundation）孵化及运营的开源项目，目标是面向全场景、全连接、全智能时代，搭建一个智能终端设备操作系统的框架和平台，促进万物互联产业的繁荣发展。 14 15OpenHarmony项目的社区托管地址：https://gitee.com/openharmony。 16 17OpenHarmony项目贡献代码：贡献者向OpenHarmony项目贡献的其拥有版权的代码，并由OpenHarmony项目在项目的社区托管地址上分发。 18 19OpenHarmony项目第三方依赖：OpenHarmony项目依赖的第三方开源代码，并由OpenHarmony项目在项目的社区托管地址上再分发。 20 21## 贡献代码采用的许可证白名单 22 23原则上，OpenHarmony项目贡献代码均应提供源代码，并采用开源促进会OSI批准的开源许可证进行分发。 24 25由于开源许可证繁多，OpenHarmony项目建议OpenHarmony项目贡献代码优先采用如下许可证白名单中的许可证进行分发。 26 27OpenHarmony项目贡献代码许可证白名单包括： 28 29- Apache License 2.0 (Apache-2.0)（适用于用户态代码） 30- 3-clause BSD License (BSD-3-Clause)（适用于LiteOS Kernel代码） 31- GNU General Public License version 2 (GPL-2.0)（适用于Linux Kernel代码） 32 33## OpenHarmony项目第三方依赖可接纳和不可接纳的许可证名单 34 35OpenHarmony项目还可能引入或依赖不同的第三方开源软件，这些第三方开源软件采用的许可证的种类和样式可能是多种多样的，为了确保项目的开源属性，要求依赖的第三方开源软件必须具有清晰定义的上游开源社区，且引入第三方开源软件不会引起许可证兼容性法律问题。 36 37### 可接纳的第三方依赖的许可证白名单 38 39与Apache-2.0许可证相兼容的许可证可以被接纳，OpenHarmony项目建议可优先接纳采用如下许可证的第三方依赖： 40 41- Academic Free License 3.0 (AFL-3.0) 42 43- Apache License 2.0 (Apache-2.0) 44 45- Apache Software License 1.1. Including variants: 46 47 - PHP License 3.01 48 - MX4J License 49 50- Boost Software License (BSL-1.0) 51 52- BSD License: 53 54 - 3-clause BSD License 55 - 2-clause BSD License 56 - DOM4J License 57 - PostgreSQL License 58 59- ISC 60 61- ICU 62 63- MIT License (MIT) / X11 64 65- MIT No Attribution License (MIT-0) 66 67- Mulan Permissive Software License v2 (MulanPSL-2.0) 68 69- The Unlicense 70 71- W3C License (W3C) 72 73- University of Illinois/NCSA 74 75- X.Net 76 77- zlib/libpng 78 79- FSF autoconf license 80 81- DejaVu Fonts (Bitstream Vera/Arev licenses) 82 83- OOXML XSD ECMA License 84 85- Microsoft Public License (MsPL) 86 87- Python Software Foundation License 88 89- Python Imaging Library Software License 90 91- Adobe Postcript(R) AFM files 92 93- Boost Software License Version 1.0 94 95- WTF Public License 96 97- The Romantic WTF public license 98 99- UNICODE, INC. LICENSE AGREEMENT - DATA FILES AND SOFTWARE 100 101- Zope Public License 2.0 102 103- ACE license 104 105- Oracle Universal Permissive License (UPL) Version 1.0 106 107- Open Grid Forum License 108 109- Google "Additional IP Rights Grant (Patents)" file 110 111- Historical Permission Notice and Disclaimer 112 113### 不建议接纳的第三方依赖的许可证名单 114 115原则上，不支持商用的许可证，以及其它包含不合理限制或义务的许可证不建议被接纳，OpenHarmony项目不建议接纳采用如下许可证的第三方依赖： 116 117- Intel Simplified Software License 118- JSR-275 License 119- Microsoft Limited Public License 120- Amazon Software License (ASL) 121- Java SDK for Satori RTM license 122- Redis Source Available License (RSAL) 123- Booz Allen Public License 124- Confluent Community License Version 1.0 125- Any license including the Commons Clause License Condition v1.0 126- Creative Commons Non-Commercial variants 127- Sun Community Source License 3.0 128- GNU GPL 3 129- GNU Affero GPL 3 130- BSD-4-Clause/BSD-4-Clause (University of California-Specific) 131- Facebook BSD+Patents license 132- NPL 1.0/NPL 1.1 133- The Solipsistic Eclipse Public License 134- The "Don't Be A Dick" Public License 135- JSON License 136 137## 引入特殊许可证的规则 138 139原则上，OpenHarmony项目需要根据上述第4章节规定的许可证白名单接纳OpenHarmony项目贡献代码，以及根据上述第5章节规定的许可证白名单引入的第三方依赖。如果需要接纳上述白名单之外的许可证（后称“特殊许可证”，非本指导定义的上述白名单许可证之内的许可证即为特殊许可证），必须经过OpenHarmony项目代码特殊许可证的评审并遵守相关规定。 140 141### OpenHarmony项目的特殊许可证评审流程 142 143#### 特殊许可证评审的组织 144 145特殊许可证评审由OpenHarmony合规SIG组织，参与人员至少需要PMC代表、法务代表、合规SIG代表。 146 147#### 特殊许可证评审的触发 148 149拟采用特殊许可证的软件模块主动上报申请 150 151代码开发过程中预备采用特殊许可证可主动向合规SIG申报进行特殊许可证评审，特殊许可证申请材料至少需包括以下材料： 152 153软件模块名称、业务场景描述、涉及的特殊许可证名称及相关信息（第三方依赖需包含直接依赖和间接依赖使用的许可证）、许可证合规扫描工具对代码的检查报告（如OAT扫描报告）。 154 155合规SIG定期汇总门禁检查结果获取采用特殊许可证的软件模块情况并组织评审 156 157合规SIG基于工具检查结果，发现代码或将采用特殊许可证（三方依赖采用非白名单许可证、贡献代码采用专有许可证或仅提供二进制码或目标码的情况等），即可组织特殊许可证评审。 158 159#### 特殊许可证评审的结论 160 161通过特殊许可证评审是采用特殊许可证的软件模块在OpenHarmony项目中代码合规检查的必要条件，未经过特殊许可证评审的软件模块不能被合入OpenHarmony主干，该软件模块的特殊许可证评审结论需作为其在OpenHarmony QA SIG准出评审/孵化毕业评审的必要条件。 162 163### 特殊许可证评审规则 164 165- **规则一**：用户态的贡献代码应优先选用Apache-2.0许可证以确保许可证的归一性，如用户态的贡献代码选用非Apache-2.0许可证需要有正当理由，用户态的贡献代码所选用的特殊许可证应避免有开放源代码义务的许可证。 166 167- **规则二**：贡献代码或第三方依赖所采用的特殊许可证需满足开源许可证基本的可分发与兼容性原则，即特殊许可证必须支持下游用户再分发相关代码，且特殊许可证不应与已接纳的现有项目代码的许可证存在兼容性问题。 168 169- **规则三**：贡献代码或第三方依赖所采用的特殊许可证不能包含不合理的限制，如：特殊许可证包含无法履行或不易履行的开源许可证义务不能被接纳，例如广告条款，啤酒条款；特殊许可证包含不合理的限制或约束条款不能被接纳，例如商用限制条款，使用领域限制条款、歧视特别技术域条款或针对特定产品的条款。 170 171- **规则四**：第三方依赖所采用的特殊许可证，需确保该第三方依赖不会影响或改变相关代码的已有许可证。 172 173- **规则五**：如涉及非源码形式（二进制码或目标码）贡献或引入第三方依赖，应确保该非源码形式的代码采用开源许可证且满足上述规则，如果非源码形式提供且采用自拟许可证，必须经PMC审批同意（原则上仅可接纳必要硬件的相关算法或其特别实现采用特殊许可证，如GPU、WIFI固件、硬件编解码算法等），若PMC审批同意，需进一步经OpenHarmony法务合规小组审核并同意相应的自拟许可证。