The policy defined in this document enables the OpenHarmony community to comply with the license terms and values of open-source software and respect third-party intellectual property rights while benefiting from the use of these open-source software. This document provides a common framework for open-source software compliance for the OpenHarmony community, with the goal of ensuring license compliance. It also improves the open-source compliance governance capability of OpenHarmony based on the best practices in the industry, helping community members understand how to use open-source software and contribute to the community.
## Scope
This document applies to all contributors to the OpenHarmony community, including the code repositories under [OpenHarmony](https://gitee.com/openharmony) and those under [OpenHarmony-SIG](https://gitee.com/openharmony-sig).
## Improvements and Revisions
- This document is drafted and maintained by the Compliance SIG. What you are reading now is the latest version of this document.
- Any addition, modification, or deletion of the specifications mentioned in this document can be traced.
- The PMC reviews and finalizes the specifications after thorough discussion in the community.
## Terms and Abbreviations
[Open-Source Compliance Terms and Abbreviations]()
## Phase-specific Compliance Policy
### Introduction Phase
#### License Usage and Review Specifications of Open-Source Software
-[Licenses and Special License Review](licenses-and-special-license-review.md)
#### Specifications for Participation in Upstream Communities
[Best Practices and Suggestions for Contributions to Upstream Open-Source Projects](best-practices-and-suggestions-for-contributions-to-upstream-open-source-projects.md)
### Release Phase
#### Open-Source Obligation Fulfillment
[Management Policy for Open-Source Compliance Artifacts](management-policy-for-open-source-compliance-artifacts.md)
#### Software Bill of Material (SBOM) Specifications
-[SBOM Generation and Delivery Description]()
-[SBOM Review and Problem Handling Rules]()
#### Open-Source Compliance Requirements for Community Version Release and SIG Incubation Graduation
-[Open-Source Compliance Requirements for SIG Incubation Graduation](https://gitee.com/openharmony/community/blob/master/sig/sig_qa/guidance_for_incubation_project_graduation.md#graduation-review-checklist)
-[Open-Source Compliance Requirements for Community Version Release](https://gitee.com/openharmony/community/blob/master/sig/sig_qa/%E7%89%88%E6%9C%AC%E8%B4%A8%E9%87%8F%E8%A6%81%E6%B1%82.md)
## Binary Compliance Specifications
[Binary Compliance Specifications]()
## Open-Source Compliance Issue Management Process
## Open-Source Compliance Roles and Responsibilities
[Open-Source Compliance Role and Capability Requirements](https://gitee.com/openharmony/community/blob/master/sig/sig_compliance/docs/%E5%BC%80%E6%BA%90%E5%90%88%E8%A7%84%E8%A7%92%E8%89%B2%E8%81%8C%E8%B4%A3%E5%8F%8A%E8%83%BD%E5%8A%9B%E8%A6%81%E6%B1%82.md)
## Open-Source Compliance Training Resources and Requirements
[Open-Source Compliance Training Plan](https://gitee.com/openharmony/community/blob/master/sig/sig_compliance/docs/%E5%BC%80%E6%BA%90%E5%90%88%E8%A7%84%E5%9F%B9%E8%AE%AD%E8%AE%A1%E5%88%92.md)
## Consequences of Incompliance
It is important to comply with this policy. Failure to do so may result in:
- Claims raised by copyright holders or intellectual property holders for the code you use
- Claims raised by the recipient of the code
- Inadvertently releasing code that is not supposed to be released
- Fines caused by violation of regulatory obligations
- Loss of reputation
- Fund loss
- Breach of contracts
Any individual who violates this policy may be subject to disciplinary actions.
## Response Policies for Negative Events of Open-Source Compliance
For details, see the policy released by OpenHarmony GLA.
## References
Linux Foundation Compliance Program: Generic FOSS Policy
# Best Practices and Suggestions for Contributions to Upstream Open-Source Projects
## Upstream First
During feature development, software versions in OpenHarmony community may introduce third-party open-source software as part of themselves. For details, see [Introducing Open-Source Software](introducing-open-source-software.md).
To maintain the third-party open-source software introduced, you are advised to use the best practice in the industry, **Upstream First**.
## Maintenance of Third-Party Open-Source Software
Preferentially incorporate bugfixes and new features into the upstream communities to reduce the fork differences and reduce the risk of technical debt caused by the incremental content. After the incorporation, upgrade the third-party open-source software in the OpenHarmony community.
If you are required to incorporate the content first into the OpenHarmony code repository due to reasons such as the version pace, make a reasonable plan for incorporating the content to the upstream as much as possible (except for the content that cannot be accepted by the upstream after evaluation).
You may be required to sign the Developer Certificate of Origin (DCO), Contributor License Agreement (CLA), or other documents when contributing to an upstream community. As the copyright of related code belongs to yourself or your organization, you are advised to consult the legal affairs department of your organization for legal issues. If you have any questions, contact OpenHarmony [GLA](https://www.openharmony.cn/GLA).
## Security Vulnerability Handling Requirements for Open-Source Projects
For details about security-related activities, such as fixing vulnerabilities in third-party open-source software, see [OpenHarmony Security Vulnerability Handling Process](https://www.openharmony.cn/security/vulnerability-process).
# Management Policy for Open-Source Compliance Artifacts
## Overview
When introducing, using, and redistributing third-party open-source software, you must fulfill open-source obligations in the software license. Common open-source obligations are classified into obligations to declare the use of open-source software, obligations to declare the code open-source, and obligations to declare modifications to the code. Deliverables required for fulfilling open-source obligations are collectively referred to as open-source compliance artifacts. This document focuses on the specifications for these artifacts in the OpenHarmony community.
## Managing Artifacts for Declaring the Use of Software
The common method in the industry for declaring the use of a piece of open-source software is to provide a **NOTICE** file with the version release. The **NOTICE** file specifies the name, copyright, and license information of the open-source software used, as well as a disclaimer.
### Usage Scenarios of NOTICE
If the binary file contains third-party open-source software, provide a file named **NOTICE** to declare the use of the software.
### Requirements on the NOTICE Content
The **NOTICE** file must describe all third-party open-source software used in the code, including their names, software versions, copyrights, and license information in plain text.
### Generation Rules for NOTICE
See [Automatic Generation and Collection Policy of OpenHarmony Open-Source Software NOTICE](https://gitee.com/openharmony/build/blob/master/docs/%E5%BC%80%E6%BA%90%E8%BD%AF%E4%BB%B6Notice%E6%94%B6%E9%9B%86%E7%AD%96%E7%95%A5%E8%AF%B4%E6%98%8E.md).
### Storage Location of NOTICE
#### For OS Device Images
- The **NOTICE** file is stored as **NOTICE.txt** under **system.img > system/etc** in the standard device OS image package ( .tar file).
- The **NOTICE** file is stored as **NOTICE.txt** under **/system/etc** in the system.
#### For Applications
The **NOTICE** file is usually stored in the top directory of the release folder or compressed package. For a .jar file, the **NOTICE** is generally stored in the **META-INF** directory.
### Lifecycle of NOTICE
The lifecycle of the **NOTICE** file is the same as that of the binary file. According to the [OpenHarmony Version Lifecycle Rules](https://gitee.com/openharmony/release-management/blob/master/openHarmony-version-lifecycle-management.md), the lifecycle of the **NOTICE** file matches that of the LTS and Release versions.
### NOTICE Template
A complete **NOTICE** file should contain the following content:
```
OPEN SOURCE SOFTWARE NOTICE
Please note we provide an open source software notice for the third party open source software along with this software and/or this software component (in the following just "this SOFTWARE"). The open source software licenses are granted by the respective right holders.
Warranty Disclaimer
THE OPEN SOURCE SOFTWARE IN THIS PRODUCT IS DISTRIBUTED IN THE HOPE THAT IT WILL BE USEFUL, BUT WITHOUT ANY WARRANTY, WITHOUT EVEN THE IMPLIED WARRANTY OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. SEE THE APPLICABLE LICENSES FOR MORE DETAILS.
(except as stated in this section) patent license to make, have made,
use, offer to sell, sell, import, and otherwise transfer the Work,
where such license applies only to those patent claims licensable
by such Contributor that are necessarily infringed by their
Contribution(s) alone or by combination of their Contribution(s)
with the Work to which such Contribution(s) was submitted. If You
institute patent litigation against any entity (including a
cross-claim or counterclaim in a lawsuit) alleging that the Work
or a Contribution incorporated within the Work constitutes direct
or contributory patent infringement, then any patent licenses
granted to You under this License for that Work shall terminate
as of the date such litigation is filed.
4. Redistribution. You may reproduce and distribute copies of the
Work or Derivative Works thereof in any medium, with or without
modifications, and in Source or Object form, provided that You
meet the following conditions:
(a) You must give any other recipients of the Work or
Derivative Works a copy of this License; and
(b) You must cause any modified files to carry prominent notices
stating that You changed the files; and
(c) 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
(d) 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.
5. Submission of Contributions. Unless You explicitly state otherwise,
any Contribution intentionally submitted for inclusion in the Work
by You to the Licensor shall be under the terms and conditions of
this License, without any additional terms or conditions.
Notwithstanding the above, nothing herein shall supersede or modify
the terms of any separate license agreement you may have executed
with Licensor regarding such Contributions.
6. Trademarks. This License does not grant permission to use the trade
names, trademarks, service marks, or product names of the Licensor,
except as required for reasonable and customary use in describing the
origin of the Work and reproducing the content of the NOTICE file.
7. Disclaimer of Warranty. Unless required by applicable law or
agreed to in writing, Licensor provides the Work (and each
Contributor provides its Contributions) on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
implied, including, without limitation, any warranties or conditions
of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A
PARTICULAR PURPOSE. You are solely responsible for determining the
appropriateness of using or redistributing the Work and assume any
risks associated with Your exercise of permissions under this License.
8. Limitation of Liability. In no event and under no legal theory,
whether in tort (including negligence), contract, or otherwise,
unless required by applicable law (such as deliberate and grossly
negligent acts) or agreed to in writing, shall any Contributor be
liable to You for damages, including any direct, indirect, special,
incidental, or consequential damages of any character arising as a
result of this License or out of the use or inability to use the
Work (including but not limited to damages for loss of goodwill,
work stoppage, computer failure or malfunction, or any and all
other commercial damages or losses), even if such Contributor
has been advised of the possibility of such damages.
9. Accepting Warranty or Additional Liability. While redistributing
the Work or Derivative Works thereof, You may choose to offer,
and charge a fee for, acceptance of support, warranty, indemnity,
or other liability obligations and/or rights consistent with this
License. However, in accepting such obligations, You may act only
on Your own behalf and on Your sole responsibility, not on behalf
of any other Contributor, and only if You agree to indemnify,
defend, and hold each Contributor harmless for any liability
incurred by, or claims asserted against, such Contributor by reason
of your accepting any such warranty or additional liability.
END OF TERMS AND CONDITIONS
```
## Managing Artifacts for Declaring Code Open-Source
The code released in the OpenHarmony community is automatically open-sourced, and therefore no additional open-source software package is required. The tool described in [Generating an Open-Source Software Package](https://gitee.com/openharmony/build/blob/master/docs/%E7%94%9F%E6%88%90%E5%BC%80%E6%BA%90%E8%BD%AF%E4%BB%B6%E5%8C%85.md) enables automatic generation of the open-source software packages involved in OpenHarmony during the integration of downstream products. It also provides the reference implementation. The OpenHarmony community is not responsible for the fulfillment of open-source obligations of downstream products.
The obligations specified in the license clauses must be fulfilled. For example, the open-source code can be compiled, and the compilation result is consistent with the open-source part in the distributed software artifact; a build guide is included in the open-source software package to describe the build environment, tools, and operation procedures.
## Managing Artifacts for Declaring Modifications to Software
According to some open-source license clauses, after modifying a piece of open-source software, you must declare the modification time, modified code, and modified files.
If an existing file of the open-source software is modified, attach the modification statement to the header of the modified file. For details, see the following template.
```
* 20XX.XX.XX - XXXXX (modification time and brief description of the modification)
Copyright(c)20XX. XXXXXXX (Copyright statement of the modifier, with the year when the modification occurs.)
```
If a file is added to the open-source software, attach the copyright statement of the new contributor, license, and disclaimer to the file header.
To better trace the original information about third-party open-source software, the following principle is stipulated in [Introducing Open-Source Software](introducing-open-source-software.md): "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." However, developers often raise questions about how to write a **README.OpenSource** file. This document aims to standardize the writing requirements of the **README.OpenSource** file. In the near future, the **README.OpenSource** file can be automatically generated based on the imported information during the introduction of the third-party open-source software.
## Scope
This document applies to all contributors to the OpenHarmony community, especially when they want to introduce third-party open-source software to an OpenHarmony project.
## Improvements and Revisions
- This document is drafted and maintained by the OpenHarmony Compliance SIG. What you are reading now is the latest version of this document.
- Any addition, modification, or deletion of the specifications mentioned in this document can be traced in the tracing system.
- The PMC reviews and finalizes the specifications after thorough discussion in the community.
## Rules for Fields in README.OpenSource
README.OpenSource example
```
[
{
"Name": "linux", # Full name of the upstream open-source software
"License": "GPL-2.0+", # License information contained in the upstream open-source software
"License File": "COPYING", # Path of the license file
"Version Number": "5.10.93", # Version of the upstream open-source software
"Owner": "xxx@xxx.com", # Maintenance personnel and email address of the open-source software in the OpenHarmony community
"Upstream URL": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/snapshot/linux-5.10.93.tar.gz", # URL of the upstream open-source software package
"Description": "XXXXXXX" # Description of the upstream open-source software
},
{
...
}
]
```
-**Name**: full name of the upstream open-source software, of which the source code is contained in the current code repository. If there are multiple pieces of software, describe them one by one in a pair of braces ({}). Each pair contains a group of metadata about the open-source software.
> **NOTE**
>
> Assume that software A depends on software B. If the source code of software B is stored in the repository of software A (A and B form an include dependency tree), both software A and B must be declared. If a dedicated code repository has been created for software B under the OpenHarmony community and GN is used to specify the dependencies through code repository directories during build (A and B form a build dependency tree), you do not need to declare software B.
-**License**: Use the standard short identifier provided in the SPDX License List. Include one license only. If either license can be used, specify the license selected. If the code repository uses multiple licenses, describe them one by one in a pair of braces ({}).
-**License File**: path of the license file relative to the root directory of the code repository, including the file name. If there are multiple license files, the rules are the same as those for the **License** field.
-**Version Number**: officially released version number of the open-source software. The version number must be the same as the text of the upstream version number.
-**Owner**: maintenance personnel of the open-source software in the OpenHarmony code repository, not the author of the software.
-**Upstream URL**: URL of the source package of the upstream software.
-**Description**: brief description about the open-source software.
