1# Licenses and Special License Review 2 3## Purpose 4 5This document lists the acceptable licenses for the code used in the OpenHarmony community. It also describes the review process and rules for special licenses. 6 7## Scope 8 9This document applies only to the code distributed in the OpenHarmony community. It does not apply to the scenario where the OpenHarmony project is used by individuals or enterprises to develop new products, or the scenario where third-party open-source software is distributed independently 10 11## Definition 12 13OpenHarmony is an open-source project launched by the OpenAtom Foundation. The purpose of this project is to build an open, distributed operating system (OS) framework for smart IoT devices in the full-scenario, full-connectivity, and full-intelligence era. 14 15The OpenHarmony project is hosted on the website https://gitee.com/openharmony. 16 17Code contributed: A contributor commits copyrighted code to the OpenHarmony project, and the project further distributes the code on the hosted website. 18 19Third-party dependency: A third-party open source code that the OpenHarmony project depends. It will be further distributed by the project on the hosted address. 20 21## License Trustlist for Code Contributed 22 23In principle, the code contributed to the OpenHarmony project must be source code, and its distribution must be carried out under an open source license approved by the Open Source Initiative (OSI). 24 25It is recommended that the code contributed to the OpenHarmony project be distributed using a license in the license trustlist, which includes: 26 27- Apache License 2.0 (Apache-2.0) (applicable to user-mode code) 28- 3-clause BSD License (BSD-3-Clause) (applicable to LiteOS kernel code) 29- GNU General Public License version 2 (GPL-2.0) (applicable to Linux kernel code) 30 31## Licenses for Third-Party Dependencies 32 33In addition to the code contributed, the OpenHarmony project may introduce or depend on third-party open source software, which uses a variety of licenses. To ensure the open source attributes, the dependent third-party open source software must have clearly defined upstream open source communities, and the introduction of the third-party open source software does not cause legal issues related to license compatibility. 34 35### Licenses for Acceptable Third-Party Dependencies 36 37Licenses compatible with Apache License 2.0 can be accepted. The OpenHarmony project recommends that third-party dependencies using the following licenses be preferentially accepted: 38 39- Academic Free License 3.0 (AFL-3.0) 40 41- Apache License 2.0 (Apache-2.0) 42 43- Apache Software License 1.1. Including variants: 44 45 - PHP License 3.01 46 - MX4J License 47 48- Boost Software License (BSL-1.0) 49 50- BSD License: 51 52 - 3-clause BSD License 53 - 2-clause BSD License 54 - DOM4J License 55 - PostgreSQL License 56 57- ISC 58 59- ICU 60 61- MIT License (MIT) / X11 62 63- MIT No Attribution License (MIT-0) 64 65- Mulan Permissive Software License v2 (MulanPSL-2.0) 66 67- The Unlicense 68 69- W3C License (W3C) 70 71- University of Illinois/NCSA 72 73- X.Net 74 75- zlib/libpng 76 77- FSF autoconf license 78 79- DejaVu Fonts (Bitstream Vera/Arev licenses) 80 81- OOXML XSD ECMA License 82 83- Microsoft Public License (MsPL) 84 85- Python Software Foundation License 86 87- Python Imaging Library Software License 88 89- Adobe Postcript(R) AFM files 90 91- Boost Software License Version 1.0 92 93- WTF Public License 94 95- The Romantic WTF public license 96 97- UNICODE, INC. LICENSE AGREEMENT - DATA FILES AND SOFTWARE 98 99- Zope Public License 2.0 100 101- ACE license 102 103- Oracle Universal Permissive License (UPL) Version 1.0 104 105- Open Grid Forum License 106 107- Google "Additional IP Rights Grant (Patents)" file 108 109- Historical Permission Notice and Disclaimer 110 111### Licenses for Unacceptable Third-Party Dependencies 112 113In principle, the OpenHarmony project will not accept third-party dependencies that use the following licenses, since these licenses do not support commercial use or contain unreasonable restrictions or obligations: 114 115- Intel Simplified Software License 116- JSR-275 License 117- Microsoft Limited Public License 118- Amazon Software License (ASL) 119- Java SDK for Satori RTM license 120- Redis Source Available License (RSAL) 121- Booz Allen Public License 122- Confluent Community License Version 1.0 123- Any license including the Commons Clause License Condition v1.0 124- Creative Commons Non-Commercial variants 125- Sun Community Source License 3.0 126- GNU GPL 3 127- GNU Affero GPL 3 128- BSD-4-Clause/BSD-4-Clause (University of California-Specific) 129- Facebook BSD+Patents license 130- NPL 1.0/NPL 1.1 131- The Solipsistic Eclipse Public License 132- The "Don't Be A Dick" Public License 133- JSON License 134 135## Rules for Introducing Special Licenses 136 137The OpenHarmony project accepts code contributed and third-party dependencies that use a license in their respective license trustlist. To accept the code or third-party dependency that uses a special license (a license not in the trustlist), a special license review must be carried out by the OpenHarmony project and related rules must be complied with. 138 139### Special License Review Process 140 141#### Organizing a Special License Review 142 143The OpenHarmony compliance SIG is responsible for organizing the special license review. At least the PMC representative, legal affairs representative, and compliance SIG representative are required to participate in the review. 144 145#### Triggering a Special License Review 146 147If your software module or code plans to use a special license, proactively provide a review request to the compliance SIG. 148 149The review request must include at least the following information: software module name, service scenario description, names of involved special licenses and related information (licenses used for direct and indirect dependencies in the third-party dependency introduction scenario), and code check reports (such as OAT scanning reports) provided by the license compliance scanning tool. 150 151The compliance SIG regularly summarizes the gated check-in results, obtains the software modules that use special licenses, and organizes reviews. 152 153Based on the tool check results, the compliance SIG can organize a special license review if it finds that the code will use a special license (a non-trustlist license is used for a third-party dependency, a dedicated license is used for the code contributed, or only binary code or object code is provided). 154 155#### Conclusion of Special License Review 156 157For software modules that use special licenses in the OpenHarmony project, passing the special license review is a prerequisite for theirs code compliance check, and the review conclusion is a prerequisite for the exit review/incubation graduation review carried out by the OpenHarmony QA SIG. Software modules that fail the special license review cannot be incorporated into the OpenHarmony trunk. 158 159### Special License Review Rules 160 161- **Rule 1**: Apache License 2.0 is preferred for user-mode code to ensure license normalization. If a license other than Apache License 2.0 is used, a proper reason is required. If a special license is required for user-mode code, a license with open source obligations should be avoided. 162 163- **Rule 2**: The special licenses used by the code contributed or third-party dependencies should meet the basic distribution and compatibility principles of the open source licenses. That is, the special licenses should support downstream users to distribute related code, and they should not be incompatible with the licenses used by the existing code in the project. 164 165- **Rule 3**: The special licenses used by the code contributed or third-party dependencies should not contain unreasonable restrictions (such as commercial restrictions, domain restrictions, discrimination against special technical domains, or product-specific restrictions) or open source license obligations that cannot be fulfilled or are difficult to fulfill. 166 167- **Rule 4**: The introduction of third-party dependencies should not affect or change the existing licenses of the related code. 168 169- **Rule 5**: The non-source code (binary code or object code), if involved, should use an open source license and meet the preceding rules. The use of a self-prepared license should be approved by the PMC and further reviewed and approved by the OpenHarmony legal compliance team. (In principle, only special licenses for algorithms and special implementation related to necessary hardware, such as GPU, Wi-Fi firmware, and hardware codec algorithms, can be accepted.) 170