# OpenHarmony项目代码许可证与特殊许可证评审指导 ## 目的 本指导明确了OpenHarmony社区中的项目代码所采用的许可证，以及接纳的特殊许可证及相关评审流程和规范。 ## 范围 本指导仅适用于OpenHarmony社区中分发的项目代码，不适用于将OpenHarmony项目应用于个人或企业以开发其它产品的场景，也不适用单独分发第三方开源软件的场景。 ## 定义 OpenHarmony项目：OpenHarmony是由开放原子开源基金会（OpenAtom Foundation）孵化及运营的开源项目，目标是面向全场景、全连接、全智能时代，搭建一个智能终端设备操作系统的框架和平台，促进万物互联产业的繁荣发展。 OpenHarmony项目的社区托管地址：https://gitee.com/openharmony。 OpenHarmony项目贡献代码：贡献者向OpenHarmony项目贡献的其拥有版权的代码，并由OpenHarmony项目在项目的社区托管地址上分发。 OpenHarmony项目第三方依赖：OpenHarmony项目依赖的第三方开源代码，并由OpenHarmony项目在项目的社区托管地址上再分发。 ## 贡献代码采用的许可证白名单 原则上，OpenHarmony项目贡献代码均应提供源代码，并采用开源促进会OSI批准的开源许可证进行分发。 由于开源许可证繁多，OpenHarmony项目建议OpenHarmony项目贡献代码优先采用如下许可证白名单中的许可证进行分发。 OpenHarmony项目贡献代码许可证白名单包括： - Apache License 2.0 (Apache-2.0)（适用于用户态代码） - 3-clause BSD License (BSD-3-Clause)（适用于LiteOS Kernel代码） - GNU General Public License version 2 (GPL-2.0)（适用于Linux Kernel代码） ## OpenHarmony项目第三方依赖可接纳和不可接纳的许可证名单 OpenHarmony项目还可能引入或依赖不同的第三方开源软件，这些第三方开源软件采用的许可证的种类和样式可能是多种多样的，为了确保项目的开源属性，要求依赖的第三方开源软件必须具有清晰定义的上游开源社区，且引入第三方开源软件不会引起许可证兼容性法律问题。 ### 可接纳的第三方依赖的许可证白名单 与Apache-2.0许可证相兼容的许可证可以被接纳，OpenHarmony项目建议可优先接纳采用如下许可证的第三方依赖： - Academic Free License 3.0 (AFL-3.0) - Apache License 2.0 (Apache-2.0) - Apache Software License 1.1. Including variants: - PHP License 3.01 - MX4J License - Boost Software License (BSL-1.0) - BSD License: - 3-clause BSD License - 2-clause BSD License - DOM4J License - PostgreSQL License - ISC - ICU - MIT License (MIT) / X11 - MIT No Attribution License (MIT-0) - Mulan Permissive Software License v2 (MulanPSL-2.0) - The Unlicense - W3C License (W3C) - University of Illinois/NCSA - X.Net - zlib/libpng - FSF autoconf license - DejaVu Fonts (Bitstream Vera/Arev licenses) - OOXML XSD ECMA License - Microsoft Public License (MsPL) - Python Software Foundation License - Python Imaging Library Software License - Adobe Postcript(R) AFM files - Boost Software License Version 1.0 - WTF Public License - The Romantic WTF public license - UNICODE, INC. LICENSE AGREEMENT - DATA FILES AND SOFTWARE - Zope Public License 2.0 - ACE license - Oracle Universal Permissive License (UPL) Version 1.0 - Open Grid Forum License - Google "Additional IP Rights Grant (Patents)" file - Historical Permission Notice and Disclaimer ### 不建议接纳的第三方依赖的许可证名单 原则上，不支持商用的许可证，以及其它包含不合理限制或义务的许可证不建议被接纳，OpenHarmony项目不建议接纳采用如下许可证的第三方依赖： - Intel Simplified Software License - JSR-275 License - Microsoft Limited Public License - Amazon Software License (ASL) - Java SDK for Satori RTM license - Redis Source Available License (RSAL) - Booz Allen Public License - Confluent Community License Version 1.0 - Any license including the Commons Clause License Condition v1.0 - Creative Commons Non-Commercial variants - Sun Community Source License 3.0 - GNU GPL 3 - GNU Affero GPL 3 - BSD-4-Clause/BSD-4-Clause (University of California-Specific) - Facebook BSD+Patents license - NPL 1.0/NPL 1.1 - The Solipsistic Eclipse Public License - The "Don't Be A Dick" Public License - JSON License ## 引入特殊许可证的规则 原则上，OpenHarmony项目需要根据上述第4章节规定的许可证白名单接纳OpenHarmony项目贡献代码，以及根据上述第5章节规定的许可证白名单引入的第三方依赖。如果需要接纳上述白名单之外的许可证（后称“特殊许可证”，非本指导定义的上述白名单许可证之内的许可证即为特殊许可证），必须经过OpenHarmony项目代码特殊许可证的评审并遵守相关规定。 ### OpenHarmony项目的特殊许可证评审流程 #### 特殊许可证评审的组织 特殊许可证评审由OpenHarmony合规SIG组织，参与人员至少需要PMC代表、法务代表、合规SIG代表。 #### 特殊许可证评审的触发 拟采用特殊许可证的软件模块主动上报申请 代码开发过程中预备采用特殊许可证可主动向合规SIG申报进行特殊许可证评审，特殊许可证申请材料至少需包括以下材料： 软件模块名称、业务场景描述、涉及的特殊许可证名称及相关信息（第三方依赖需包含直接依赖和间接依赖使用的许可证）、许可证合规扫描工具对代码的检查报告（如OAT扫描报告）。 合规SIG定期汇总门禁检查结果获取采用特殊许可证的软件模块情况并组织评审 合规SIG基于工具检查结果，发现代码或将采用特殊许可证（三方依赖采用非白名单许可证、贡献代码采用专有许可证或仅提供二进制码或目标码的情况等），即可组织特殊许可证评审。 #### 特殊许可证评审的结论 通过特殊许可证评审是采用特殊许可证的软件模块在OpenHarmony项目中代码合规检查的必要条件，未经过特殊许可证评审的软件模块不能被合入OpenHarmony主干，该软件模块的特殊许可证评审结论需作为其在OpenHarmony QA SIG准出评审/孵化毕业评审的必要条件。 ### 特殊许可证评审规则 - **规则一**：用户态的贡献代码应优先选用Apache-2.0许可证以确保许可证的归一性，如用户态的贡献代码选用非Apache-2.0许可证需要有正当理由，用户态的贡献代码所选用的特殊许可证应避免有开放源代码义务的许可证。 - **规则二**：贡献代码或第三方依赖所采用的特殊许可证需满足开源许可证基本的可分发与兼容性原则，即特殊许可证必须支持下游用户再分发相关代码，且特殊许可证不应与已接纳的现有项目代码的许可证存在兼容性问题。 - **规则三**：贡献代码或第三方依赖所采用的特殊许可证不能包含不合理的限制，如：特殊许可证包含无法履行或不易履行的开源许可证义务不能被接纳，例如广告条款，啤酒条款；特殊许可证包含不合理的限制或约束条款不能被接纳，例如商用限制条款，使用领域限制条款、歧视特别技术域条款或针对特定产品的条款。 - **规则四**：第三方依赖所采用的特殊许可证，需确保该第三方依赖不会影响或改变相关代码的已有许可证。 - **规则五**：如涉及非源码形式（二进制码或目标码）贡献或引入第三方依赖，应确保该非源码形式的代码采用开源许可证且满足上述规则，如果非源码形式提供且采用自拟许可证，必须经PMC审批同意（原则上仅可接纳必要硬件的相关算法或其特别实现采用特殊许可证，如GPU、WIFI固件、硬件编解码算法等），若PMC审批同意，需进一步经OpenHarmony法务合规小组审核并同意相应的自拟许可证。