In OpenHarmony, software that meets [The Open Source Definition](https://opensource.org/docs/osd) is recognized as open-source software.
Providing easy-to-use and quality open-source software for developers across the globe from a wide range of backgrounds is an important goal of the OpenHarmony community. To ensure the overall quality of the OpenHarmony project, this guide is specially formulated for the contributors' reference.
## Scope
This guide applies to all third-party open-source software to be introduced to the OpenHarmony project.
## Improvements and Revisions
1. This document is drafted and maintained by the OpenHarmony SIG QA. What you are reading now is the latest version of this document.
2. Any addition, modification, or deletion of the principles mentioned in this document can be traced in the tracing system.
3. The PMC reviews and finalizes the principles after thorough discussion in the community.
## Software Introduction and Introduction Principles
### What Is Software Introduction?
Software introduction refers to the act of introducing a piece of software to the OpenHarmony project to meet certain service requirements of a SIG in OpenHarmony. For details about the software introduction process, see [SIG Management Regulations](https://gitee.com/openharmony/community/tree/master/sig). The entire process must be traceable.
### Basic Principles for Software Introduction
For easier maintenance and evolution, comply with the following principles when introducing third-party open-source software:
1. Make sure the software comes from a clearly defined upstream community.
2. Provide a sound reason for software introduction. If the software to be introduced already exists in the OpenHarmony project, reuse it to avoid maintenance complexity caused by coexistence of multiple versions.
3. Introduce the software in the form of source code, rather than binary files. If a piece of software needs to be introduced in the form of binary files, the PMC should review the request and make a decision.
4. Make sure the software can be correctly built on the OpenHarmony project. If the software has dependency software that has not been introduced, or the running or build of the software depends on a component that cannot be introduced, the PMC should review the request and make a decision.
5. Place the software in an independent code repository or directory and name it in the format of **third_party_*****softwareName***, where *softwareName* must be an official name.
6. Retain the directory structure, license, and copyright information of the official code repository of the software. Do not modify the original license and copyright information.
7. Do not introduce any software version that has not been officially released, for example, the Beta version.
8. Do not introduce any software version that has high-risk vulnerabilities and does not provide solutions.
9. If you need to modify the software, place the new code in the software repository and ensure that the new code meets the license requirements of the software. Retain the original license for the modified files, and use the same license for the new files (recommended).
10. Provide the **README.OpenSource** file in the root directory of the software repository. Include the following information in the file: software name, license, license file location, version, upstream community address of the corresponding version, software maintenance owner, function description, and introduction reason.
11. Make sure the software to introduce will be under the custody of a domain SIG. In principle, the PMC will deny the introduction of a piece of software without the confirmation of the SIG QA and the corresponding domain SIG. When introducing multiple pieces of software at a time, you can ask the PMC to hold a temporary review meeting between SIGs for faster introduction. If you want to introduce a piece of software but fail to meet the preceding requirements, send an email to law@openatom.org.
### Software Introduction Process
#### Check Before Software Introduction
| Check Item| Description|
| :----- | :----- |
| Normalization| Check whether the software exists in the OpenHarmony community. In principle, a piece of software is introduced to the OpenHarmony only once.|
| Source| Check whether the software is downloaded from its official website or source specified on the official website.|
| Community activeness| 1. Do not introduce software from a community or organization that notifies users of software maintenance termination by releasing a bullet, modifying the software repository status, or moving the software repository in a specified directory.<br>2. Do not introduce software from an individual, a small community, or an organization that has not released a version (either official or test version) within two years, does not have a clear version roadmap, or does not respond to any valid bug or pull request in the community.<br>3. Do not introduce software from a community that is not longer maintained or does not respond to any operating status related issue or email for more than half a year.|
| Security vulnerability| 1. Search for disclosed security vulnerabilities in the industry, and check whether solutions are provided if there are high-risk vulnerabilities in the software.|
| Software name| 1. Name the repository in the format of **third_party_*****softwareName***, where *softwareName* must be the same as the official name.<br>2. Do not use the sub-module name of the software as the software name.<br>3. If the software has development libraries in multiple languages, add prefixes such as **python-** to the official software name for standardized management.|
| Official website information| 1. Describe the official website of the software in the request. If there is no official website, provide the project URL on a mainstream code hosting platform. Dot not use the hosting library addresses such as Maven, mvnrepository, and SpringSource.<br>2. Provide the official download address of the software version source package for traceability. If a binary package is required, provide the official download address of the binary package.|
| License| 1. Check whether the software to be introduced has a license.<br>2. Check whether the imported license is consistent with the license of the corresponding version on the official website of the software.<br>3. Exercise caution when introducing open-source software with high-risk licenses. Before introducing the software, fully evaluate the risk and attach the analysis conclusion in the request.|
#### Submitting a Request
Follow the process described in the [SIG Management Regulations](https://gitee.com/openharmony/community/tree/master/sig). In addition, include the following information in the request:
1. Self-check list
| Check Item| Description| Self-Check Result Example|
| :----- | :----- | :----- |
| Software name| Provide the official name of the software and the repository name to which the software is introduced. The repository name is in the format of **third_party_*****softwareName***.| third_party_*softwareName*|
| Official website| Provide the official website link of the software.| https://softwaresite |
| Software version| Provide the version number of the software to be introduced. The version number must be an official version number released by the community. Do not modify the version number or introduce a version that is not officially released.| 1.0.0 |
| Software version release date| Provide the official release date of the software version.| 2021.01.01 |
| Software version address| Provide the official download URL of the version. Note that the URL must be able to locate the release package of the specific version.| https://gitee.com/softwarecodesite/v1.0.0.zip |
| Software license| Provide the official license name of the version and the relative path of the license file. If there are multiple licenses, list them all and describe their relationship, for example, And, Or, or different licenses for different directories.| Apache-2.0 |
| Software lifecycle| Describe whether the software has an LTS version, how frequent a version is released, code submitted to the community in the last year, issue resolution status, and whether end of maintenance or evolution is notified.| No LTS version; one version released every six months; 10 code submissions in the last six months|
| Security vulnerabilities| List disclosed security vulnerabilities in the software, including the vulnerability number, severity, link, and whether patches or solutions are available.| No disclosed vulnerabilities.|
| Service scenario| Describe the repositories where the software is used and the service scenarios where the software is used.| Used by the static link of the *XX* repository to improve the *YYY* capability.|
| Normalization| Describe whether the likes of the software exist in the OpenHarmony community, what similar software is in the industry, and why the software or version is introduced.| This software has not been introduced to the OpenHarmony community. Similar software in the industry includes B and C. Only this software is license-friendly and has a good ecosystem. Companies such as *X* and *Y* are also using this software.|
| License compatibility| 1. Describe the processes that use the software, the license of each process, and whether these licenses are compatible with the license of the software to be introduced.<br>2. Use the OAT tool to scan the source code of the software. Attach the scanning report (with all found errors rectified) and the **LicenseFile.txt** file in the request.| 1. This software is used in the user-mode *X* process in static link mode. The process is licensed under Apache-2.0, which is consistent with the software license. There is no compatibility issue.<br>2. **Result.txt** generated by the OAT tool and **LicenseFile.txt**<br> |
| Owner| Provide the name of the SIG responsible for the software management and the Gitee username and email address of the maintenance owner.| SIG XXX, James, James@example.com|
Note:
- For details about how to use the OAT tool, see [OSS Audit Tool](https://gitee.com/openharmony-sig/tools_oat). If you have any suggestions on the tool, submit an issue in the community. You can also fork the repository and improve the tool through pull requests.
- In principle, the OAT report should contain no errors. The format is as follows:
```
Invalid File Type Total Count: 0
License Not Compatible Total Count: 0
License Header Invalid Total Count: 0
Copyright Header Invalid Total Count: 0
No License File Total Count: 0
No Readme.OpenSource Total Count: 0
No Readme Total Count: 0
```
- The **LicenseFile.txt** file is located in the **log** directory of the OAT tool running directory. This file records all suspected license files in the scan directory. The format is as follows:
Confirm the issues found by the OAT tool and configure the **OAT.xml** file. For details, see [OSS Audio Tool](https://gitee.com/openharmony-sig/tools_oat/blob/master/README.md). Attach the file in the request. If no issue needs to be confirmed, you do not have to configure the file.
3.**README.OpenSource** file of the repository. The format is as follows:
}// If there are multiple licenses, list them one by one.
]
```
#### PMC Review
Refer to the [SIG Management Regulations](https://gitee.com/openharmony/community/tree/master/sig). The PMC will arrange the SIG request review and repository construction based on the received PR.
### License Requirements for Third-Party Open-Source Software
1. The software license must be clearly defined by the [Open Source Initiative (OSI)](https://opensource.org/osd-annotated).
2. The software license must be compatible with the license for the code repository.
3. The following licenses for third-party open-source software are recommended in the OpenHarmony project:
* Apache License 2.0
* Mulan Permissive Software License, Version 2
* BSD 2-clause
* BSD 3-clause
* DOM4J License
* PostgreSQL License
* Eclipse Distribution License 1.0
* MIT
* ISC
* ICU
* University of Illinois/NCSA
* W3C Software License
* zlib/libpng
* Academic Free License 3.0
* Python Software Foundation License
* Python Imaging Library Software License
* Boost Software License Version 1.0
* WTF Public License
* UNICODE, INC. LICENSE AGREEMENT - DATA FILES AND SOFTWARE
* Zope Public License 2.0
4. The following licenses for third-party open-source software are not recommended in the OpenHarmony project:
* GNU GPL 1, 2, 3
* GNU Affero GPL 3
* GNU LGPL 2, 2.1, 3
* QPL
* Sleepycat License
* Server Side Public License (SSPL) version 1
* Code Project Open License (CPOL)
* 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
* Binary Code License (BCL)
* 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
* Creative Commons Non-Commercial
* Sun Community Source License 3.0
* Common Development and Distribution Licenses: CDDL 1.0 and CDDL 1.1
* Common Public License: CPL 1.0
* Eclipse Public License: EPL 1.0
* IBM Public License: IPL 1.0
* Mozilla Public Licenses: MPL 1.0, MPL 1.1, and MPL 2.0
* Sun Public License: SPL 1.0
* Open Software License 3.0
* Erlang Public License
* UnRAR License
* SIL Open Font License
* Ubuntu Font License Version 1.0
* IPA Font License Agreement v1.0
* Ruby License
* Eclipse Public License 2.0: EPL 2.0
If you want to introduce the software that complies with the unrecommended licenses listed in **4** or other licenses that are not mentioned, send an email to law@openatom.org.
## Software Exit and Exit Principles
### What Is Software Exit?
1. Software exit refers to the process in which a piece of software (project) is removed as requested from the OpenHarmony project according to the principles described in this document.
2. The SIG responsible for the software management should submit an exit topic to the PMC for review.
### Software Exit Principles
When the following two conditions are met, the software exit request is executed immediately, and the corresponding file is directly deleted from the project:
1. The software license is changed or the current version is affected by laws and regulations. Due to legal risks imposed by software license changes, laws, or regulations, the OpenHarmony project cannot continue to integrate the software.
2. Malicious code or serious security risks exist and cannot be fixed by the OpenHarmony community.
In other scenarios, OpenHarmony implements process-based management on software exit.
1. Due to outdated technologies or architecture, the software can no longer meet the requirements of existing scenarios and needs to be replaced by other software.
2. The version integrated by OpenHarmony is too old, and an upgrade to the new version is impossible because of the license of the new version or other legal and regulatory restrictions.
3. For software that comes from well-known communities or organizations, the communities or organizations notify users of the software maintenance termination by releasing bulletins, modifying the software repository status, and moving the software repository to a specified directory.
4. For software that comes from individuals, small communities, or organizations, no version (either official or test versions) is released within two years, no clear version plan is available, or no response is provided to any valid bug or PR for more than half a year.
5. The operating status of the community is not clear, and the community does not respond to any operating status related issue or email for more than half a year or replies that the maintenance is terminated.
If the software meets any of the preceding conditions, the PMC and SIG analyze the dependency and usage of the software in the OpenHarmony community.
1. If a dependency exists in the OpenHarmony community and cannot be removed within a short period of time, it is recommended that the SIG create a branch code repository and proactively perform community maintenance.
2. If no dependency exists in the OpenHarmony community or the dependency can be removed in a short period of time, the responsible SIG removes the software from the OpenHarmony official release and describes the reason and impact of the removal in the corresponding Release Notes.
This document describes how code contributors, committers, and PMC members in the OpenHarmony community handle the license and copyright statements of repositories and source code files. It covers the following parts:
1. License file
2. NOTICE file
3. Copyright and license header
## Scope
This document applies only to the OpenHarmony community. It is not applicable to the scenario where the OpenHarmony project is used by individuals or enterprises to develop their products or the scenario where third-party open-source software is introduced. For details, see [Introducing Third-Party Open-Source Software](introducing-third-party-open-source-software.md).
## Improvements and Revisions
1. This document is drafted and maintained by the OpenHarmony PMC. What you are reading now is the latest version of this document.
2. Any addition, modification, or deletion of the principles mentioned in this document are traced in the tracing system.
3. The PMC finalizes the principles after thorough discussion in the community.
## License File
1. Each open-source repository must have a license file that is clearly documented and comply with the overall license principles in the OpenHarmony community. For example, a user-mode open-source repository uses Apache License 2.0, and a LiteOS kernel-mode open-source repository uses BSD 3-clause.
2. The license file of each open-source repository must be in plain text format and stored in the root directory of the code repository. The file must contain the full text of the license and be named **LICENSE**, without the file name extension .txt or .md.
3. If the source code of an open-source repository uses multiple licenses, describe the main license in the file named **LICENSE**. For other licenses, name them in the format of **LICENSE-*LicenseType*-*Remarks*** and place them in the root directory of the code repository or the root directory of the source code corresponding to the license. Describe the location and application scenarios of each license file in the main license.
4. The license file of each open-source software repository must cover all files in the repository. Ensure that the description of each license is accurate and concise, and do not contain unnecessary information such as licenses of source code that is not released in the repository. For example, the license of the dependent software to be downloaded separately should not be included in the repository and license.
5. If the open-source repository is released in binary mode, ensure that the license file is stored in a common location of the release format, for example, the top directory of the release folder or compressed package. For a .jar file, the license file can be stored in the **META-INF** directory.
## NOTICE File
1. If the distributed binary files contain third-party open-source software, provide a file named **NOTICE**. Include the following information in plain text in this file: name, version, rights holder statements, and license information of every third-party open-source software.
2. The **NOTICE** file is usually stored in the top directory of the release folder or compressed package. For a .jar file, the license file can be stored in the **META-INF** directory.
## Copyright and License Header
1. In principle, all files in the open-source repository must contain appropriate copyright and license header statements, except in the following scenarios:
* Adding the copyright and license header statement affects the functions of the file. For example, JSON files do not support comments, and therefore you should not add the copyright and license header to a JSON file.
* A file that is generated by the tool and contains the description indicating the automatic generation.
* A brief description file for users to read. Adding the copyright and license header affects the readability of the file, for example, **README**.
2. The format of the copyright and license header is as follows:
```
Copyright (C) [Year of the first release]-[Year of the current release] [Copyright holder]
The license header is subject to the specific license content. Example:
Apache License Version 2.0 license header:
Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.
BSD 3-Clause license header:
Redistribution and use in source and binary forms, with or without modification,
are permitted provided that the following conditions are met:
1. Redistributions of source code must retain the above copyright notice, this list of
conditions and the following disclaimer.
2. Redistributions in binary form must reproduce the above copyright notice, this list
of conditions and the following disclaimer in the documentation and/or other materials
provided with the distribution.
3. Neither the name of the copyright holder nor the names of its contributors may be used
to endorse or promote products derived from this software without specific prior written
permission.
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
"AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO,
THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR
CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS;
OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY,
WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF
ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
```
3. The year in the copyright header indicates the year when the work is released. If this is the first release, enter [Year of the first release]. If this is not the first release, enter [Year of the first release]-[Year of the current release].
4. The copyright holder is a legal entity, which can be an individual or a company. If the copyright holder contributes code on behalf of a company, enter the legal entity of the company.
5. The license header information must be consistent with the license information of the open-source repository. If a file is a dual license, the license header must clearly describe the application conditions of each license and include the license header description defined by each license.
| Hi3516 mini system solution - LiteOS (binary)| 3.1 Release | [Download](https://repo.huaweicloud.com/harmonyos/os/3.1-Release/hispark_taurus.tar.gz)| [Download](https://repo.huaweicloud.com/harmonyos/os/3.1-Release/hispark_taurus.tar.gz.sha256)|
| Hi3516 mini system solution - Linux (binary) | 3.1 Release | [Download](https://repo.huaweicloud.com/harmonyos/os/3.1-Release/hispark_taurus_linux.tar.gz)| [Download](https://repo.huaweicloud.com/harmonyos/os/3.1-Release/hispark_taurus_linux.tar.gz.sha256)|
| Standard system SDK package (macOS) | 3.1 Release | [Download](https://repo.huaweicloud.com/harmonyos/os/3.1-Release/ohos-sdk-mac.tar.gz)| [Download](https://repo.huaweicloud.com/harmonyos/os/3.1-Release/ohos-sdk-mac.tar.gz.sha256)|
| Standard system SDK package (Windows/Linux) | 3.1 Release | [Download](https://repo.huaweicloud.com/harmonyos/os/3.1-Release/ohos-sdk.tar.gz)| [Download]((https://repo.huaweicloud.com/harmonyos/os/3.1-Release/ohos-sdk.tar.gz.sha256)|
| Standard system SDK package (Windows/Linux) | 3.1 Release | [Download](https://repo.huaweicloud.com/harmonyos/os/3.1-Release/ohos-sdk.tar.gz)| [Download](https://repo.huaweicloud.com/harmonyos/os/3.1-Release/ohos-sdk.tar.gz.sha256)|
| Standard system SDK package | 3.2 Canary | Loaded only by using HUAWEI DevEco Studio| NA |
