按照评审意见，修正文档格式

Signed-off-by: Nkubigao <jean.gaoliang@huawei.com>

zh-cn/contribute/OpenHarmony社区开源合规规范及指导.md

@@ -2,15 +2,15 @@
 
 ## 目的
 
-本文档定义的规范使OpenHarmony社区能够从开源软件的使用中受益，同时确保OpenHarmony社区遵守开源软件许可条款和价值，并遵从第三方知识产权，本文档为整个组织提供了遵守开源软件合规的共同框架，目标是确保许可证合规性，并基于业界最佳实践，提升OpenHarmony社区开源合规治理能力，该策略将使社区成员了解如何使用开源软件以及为开源社区进行贡献。
+本文档定义的规范确保OpenHarmony社区遵守开源软件许可条款和价值，并遵从第三方知识产权，从开源软件的使用中受益。本文档提供了OpenHarmony社区遵守开源软件合规的共同框架确保许可证合规性，并基于业界最佳实践提升OpenHarmony社区开源合规治理能力，方便社区成员了解如何使用开源软件以及为开源社区进行贡献。
 
 ## 范围
 
-本指导适用于所有参与OpenHarmony社区的贡献者、适用范围上覆盖[OpenHarmony主线](https://gitee.com/openharmony)下代码仓和[OpenHarmony-SIG](https://gitee.com/openharmony-sig)下的代码仓所涉及的项目。
+本指导适用于所有参与OpenHarmony社区的贡献者，项目适用范围包含：[OpenHarmony主线](https://gitee.com/openharmony)下代码仓和[OpenHarmony-SIG](https://gitee.com/openharmony-sig)下的代码仓所涉及的项目。
 
 ## 本文的改进和修订说明
 
-1. 本文档由OpenHarmony 合规SIG主导起草和维护。本文档的最新版本总可以在 [这里](https://gitee.com/openharmony/docs/blob/ef1b57b55dddba840d62803e8ee6f3e576e70c8d/zh-cn/contribute/%E5%BC%80%E6%BA%90%E5%90%88%E8%A7%84%E7%AD%96%E7%95%A5%E5%8F%8A%E6%8C%87%E5%AF%BC.md)找到。
+1. 本文档由合规SIG主导起草和维护。最新版本可以在 [这里](./OpenHarmony社区开源合规规范及指导.md)找到。
 2. 任何对于本文中涉及的规则的增加，修改，删除都必须可追溯 。
 3. 最终规则经过社区充分的讨论后，由PMC评审定稿。
 
@@ -25,24 +25,24 @@
 
 #### 开源软件许可证使用及评审规范
 
-1. [OpenHarmony项目代码许可证规则与特殊许可证评审指导](https://gitee.com/openharmony/docs/blob/master/zh-cn/contribute/%E8%AE%B8%E5%8F%AF%E8%AF%81%E4%B8%8E%E7%89%B9%E6%AE%8A%E8%AE%B8%E5%8F%AF%E8%AF%81%E8%AF%84%E5%AE%A1%E6%8C%87%E5%AF%BC.md)
+1. [OpenHarmony项目代码许可证规则与特殊许可证评审指导](./许可证与特殊许可证评审指导.md)
 
 2. [OpenHarmony社区项目已使用代码许可协议说明](https://gitee.com/openharmony#%E8%AE%B8%E5%8F%AF%E5%8D%8F%E8%AE%AE)
  
 #### 第三方开源软件开源引入及退出
 
-[第三方开源软件引入及退出指导](https://gitee.com/openharmony/docs/blob/master/zh-cn/contribute/%E7%AC%AC%E4%B8%89%E6%96%B9%E5%BC%80%E6%BA%90%E8%BD%AF%E4%BB%B6%E5%BC%95%E5%85%A5%E6%8C%87%E5%AF%BC.md)
+[第三方开源软件引入及退出指导](./第三方开源软件引入指导.md)
 
 
 ### 开发阶段
 
 #### 开源开发许可证、版权、元数据合规规范
 
-1. [代码仓许可证与版权声明规范](https://gitee.com/openharmony/docs/blob/master/zh-cn/contribute/%E8%AE%B8%E5%8F%AF%E8%AF%81%E4%B8%8E%E7%89%88%E6%9D%83%E8%A7%84%E8%8C%83.md)
+1. [代码仓许可证与版权声明规范](./许可证与版权规范.md)
 
 2. [SPDX信息声明规范]()
 
-3. 第三方开源软件中补充[上游开源软件元数据声明文件README.OpenSource规范](https://gitee.com/openharmony/docs/blob/c2cfb198e35d5e0eb0f18606935f7276b47a40c4/zh-cn/contribute/%E7%AC%AC%E4%B8%89%E6%96%B9%E5%BC%80%E6%BA%90%E8%BD%AF%E4%BB%B6%E4%B8%8A%E6%B8%B8%E8%BD%AF%E4%BB%B6%E5%85%83%E6%95%B0%E6%8D%AEREADMEOpenSource%E6%96%87%E4%BB%B6%E8%A7%84%E8%8C%83.md)
+3. 第三方开源软件中补充[上游开源软件元数据声明文件README.OpenSource规范](./第三方开源软件上游软件元数据READMEOpenSource文件规范.md)
 
 #### 开源开发合规门禁规范
 
@@ -52,14 +52,14 @@
 
 #### 参与上游社区贡献规范
 
-[OpenHarmony社区上游开源项目贡献最佳实践及建议](https://gitee.com/openharmony/docs/blob/20b5af01b3124d86bbce9cd15b0397df8b48e06b/zh-cn/contribute/%E4%B8%8A%E6%B8%B8%E7%A4%BE%E5%8C%BA%E8%B4%A1%E7%8C%AE%E5%BC%80%E6%BA%90%E5%90%88%E8%A7%84%E6%8C%87%E5%AF%BC.md)
+[OpenHarmony社区上游开源项目贡献最佳实践及建议](./上游开源项目贡献最佳实践及建议.md)
                                                                                                                                                               
 
 ### 发布阶段
 
 #### 开源义务履行
 
-[开源合规交付制品管理规范及指导](https://gitee.com/openharmony/docs/blob/b56f671f5ec3c02c18cefe4de6eccd0b14c41662/zh-cn/contribute/%E5%BC%80%E6%BA%90%E4%B9%89%E5%8A%A1%E5%B1%A5%E8%A1%8C%E5%90%88%E8%A7%84%E4%BA%A4%E4%BB%98%E5%88%B6%E5%93%81%E7%AE%A1%E7%90%86%E8%A7%84%E8%8C%83%E5%8F%8A%E6%8C%87%E5%AF%BC.md)
+[开源合规交付制品管理规范及指导](./开源义务履行合规交付制品管理规范及指导.md)
 
 #### 软件物料清单（SBOM）规范
 
@@ -80,19 +80,19 @@
 
 ## 开源合规类issue管理流程
 
-[OpenHarmony社区开源合规issue管理流程指导](https://gitee.com/openharmony/docs/blob/master/zh-cn/contribute/%E5%BC%80%E6%BA%90%E5%90%88%E8%A7%84%E7%B1%BB%E9%97%AE%E9%A2%98%E7%AE%A1%E7%90%86.md)
+[OpenHarmony社区开源合规issue管理流程指导](./开源合规类问题管理.md)
 
 ## 开源合规角色和责任
 
-[《开源合规角色职责及能力要求》](https://gitee.com/openharmony/docs/blob/b56f671f5ec3c02c18cefe4de6eccd0b14c41662/zh-cn/contribute/%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)
+[《开源合规角色职责及能力要求》](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)
 
 ## 开源合规培训资源及要求
 
-[《开源合规培训计划》](https://gitee.com/openharmony/docs/blob/b56f671f5ec3c02c18cefe4de6eccd0b14c41662/zh-cn/contribute/%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)
+[《开源合规培训计划》](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)
 
 ## 未能遵守的后果
 
-必须遵守此政策，这一点很重要。不这样做可能会导致： 
+必须遵守此规范，这一点很重要。不这样做可能会导致： 
 - 使用的代码中的版权或其他知识产权持有人提出法律索赔； 
 - 代码的接收者提出的索赔； 
 - 无意中发布了不允许发布的代码； 
@@ -101,10 +101,10 @@
 - 资金损失； 
 - 违反合约。
 
-因此，我们会严肃对待违反本政策的行为，任何违反本政策的个人都可能会受到纪律处分。
+因此，我们会严肃对待违反本规范的行为，任何违反本政策的个人都可能会受到纪律处分。
 
 ## 开源合规负面事件响应策略
-《社区开源合规负面事件响应策略》，请参照法务与合规组策略
+《社区开源合规负面事件响应策略》，请参照法务与合规组策略。
 
 ## 参考文档
 

zh-cn/contribute/上游开源项目贡献最佳实践及建议.md

 # 上游开源项目贡献最佳实践及建议
 
 ## Upstream First 原则
-OpenHarmony 社区软件版本在特性开发过程中遵照业界最佳实践，会引入第三方开源软件做为OpenHarmony 软件版本的一部分（第三方开源软件引入要求，指导见[这里](https://gitee.com/openharmony/docs/blob/master/zh-cn/contribute/%E7%AC%AC%E4%B8%89%E6%96%B9%E5%BC%80%E6%BA%90%E8%BD%AF%E4%BB%B6%E5%BC%95%E5%85%A5%E6%8C%87%E5%AF%BC.md)）。
+OpenHarmony 社区软件版本在特性开发过程中遵照业界最佳实践，会引入第三方开源软件做为OpenHarmony 软件版本的一部分（参见[第三方开源软件引入指导](./第三方开源软件引入指导.md)）。
 
-在OpenHarmony社区中我们建议社区开发者优先采用业界最佳实践 “**Upstream First**”，即上游优先的方式来对引入的第三方开源软件进行维护.
+在OpenHarmony社区中我们建议社区开发者优先采用业界最佳实践 “**Upstream First**”，即上游优先的方式来对引入的第三方开源软件进行维护。
 
 ## 第三方开源软件贡献及维护
 
@@ -11,9 +11,9 @@ OpenHarmony 社区软件版本在特性开发过程中遵照业界最佳实践
 
 若因版本节奏，交付计划等原因，需要优先在OpenHarmony社区代码仓内合入的内容，应由合入人制定合理的向上游回合的计划，以保障修改内容尽可能合入上游项目（若经评估，无法被上游接纳的除外）。
 
-社区开发者向上游社区贡献时，可能被要求签署DCO（原创证明）、CLA（贡献者许可协议）或其他文件，由于相关代码版权归属于贡献者本人或贡献者所在公司或单位，涉及法务问题建议咨询对应组织法务；若仍有疑问，您也可以向OpenHarmony[法务与合规组](https://www.openharmony.cn/GLA)咨询
+社区开发者向上游社区贡献时，可能被要求签署DCO（原创证明）、CLA（贡献者许可协议）或其他文件，由于相关代码版权归属于贡献者本人或贡献者所在公司或单位，涉及法务问题建议咨询对应组织法务；若仍有疑问，您也可以向OpenHarmony[法务与合规组](https://www.openharmony.cn/GLA)咨询。
 
 ## 第三方开源项目安全漏洞处理要求
-针对涉及第三方开源软件漏洞修复等安全相关活动，请遵照[OpenHarmony社区安全漏洞处理流程](https://www.openharmony.cn/security/vulnerability-process)
+针对涉及第三方开源软件漏洞修复等安全相关活动，请遵照[OpenHarmony社区安全漏洞处理流程](https://www.openharmony.cn/security/vulnerability-process)。
 
 

zh-cn/contribute/开源义务履行合规交付制品管理规范及指导.md

 # 开源义务履行合规交付制品管理规范及指导
 
 ## 概述
-开源合规交付制品，源自与社区在引入第三方开源软件时对应开源许可证所带来的开源软件使用义务履行的要求，开发者应按照对应开源软件许可证的条款要求履行相应的义务。常见的开源义务：开源使用声明义务，代码对外开源义务，修改声明义务。
+社区开发者在引入和使用和再次分发第三方开源软件时，需要依据开源软件所包含的开源许可证中的条款要求，履行相应的开源义务，以满足开源合规要求。常见的开源义务分为：开源使用声明义务，代码对外开源义务，修改声明义务。 开源义务履行时所需的交付件，统称为开源合规交付制品。 本规范重点说明社区开源合规交付制品的规则和要求。 
 
 ## 开源软件使用声明义务履行合规制品管理规范
 履行开源软件使用声明，业界常见方式为在版本发布时随版本发布NOTICE文档，在该文档中写明其中所使用的开源软件名、版权信息和许可证信息，并附上免责声明。
@@ -237,13 +237,13 @@ License: Apache License 2.0
 ## 代码对外开源义务履行合规制品管理规范
 
 1. 由于OpenHarmony版本是由OpenHarmony开源社区发布，代码本身已在OpenHarmony社区开源，因此无需额外提供开源软件包；[开源软件包生成](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)
-主要提供一种下游集成时需要自动生成的OH所涉及开源软件包的辅助工具和参考实现，OpenHarmony社区不对最终下游产品开源义务履行负责。
+主要提供一种下游集成时需要自动生成的OpenHarmony所涉及的开源软件包的辅助工具和参考实现，OpenHarmony社区不对最终下游产品开源义务履行负责。
 2. 针对开源许可证中条款，应满足对应许可证规则的义务要求，如：开源代码必须能够编译通过，且编译结果与分发软件制品中开源部分一致；在开源软件包中应附上编译指导，说明编译所需要的环境、工具及操作步骤，确保用户可以根据指导完成编译操作等。
 
 
 ## 修改声明履行合规制品管理规范
 
-修改声明是指对修改过的开源软件就修改时间，修改的代码及修改过的文件做出声明。 若社区开发者对开源软件进行了修改，则须在修改的源码文件头附上修改声明，说明修改人、修改时间、修改内容等信息。
+修改声明义务是按照部分开源许可证条款要求开发者对开源软件进行修改后，需对修改时间，修改的代码及修改过的文件做出声明的要求。
 
 1. 若对开源软件的已有文件进行了修改，在被修改的文件头上附上修改声明，可参考以下模板。
 

zh-cn/contribute/第三方开源软件上游软件元数据READMEOpenSource文件规范.md

@@ -2,7 +2,7 @@
 
 ## 目的
 
-为更好追溯第三方开源软件的原始上游信息，特在[《第三方开源软件引入指导》](https://gitee.com/openharmony/docs/blob/master/zh-cn/contribute/%E7%AC%AC%E4%B8%89%E6%96%B9%E5%BC%80%E6%BA%90%E8%BD%AF%E4%BB%B6%E5%BC%95%E5%85%A5%E6%8C%87%E5%AF%BC.md)》中对相关信息进行了要求 “新引入的开源软件必须在其根目录提供README.OpenSource文件，在该文件中准确描述其软件名、许可证、许可文件位置、版本、对应版本的上游社区地址、软件的维护Owner、功能描述以及引入的原因。” 但社区开发者常见问题是对于README.OpenSource 写作要求和规范并不清晰，对于其中多License情况，多开源软件情况等场景如何规范填写并不清晰，因此，本文旨在规范化README.OpenSource文件的写作要求，并将相关要求基线化，在工程能力成熟后，README.OpenSource文件可按照本规范，在选型引入时，自动基于引入的信息由IT系统生成此文件。
+为更好追溯第三方开源软件的原始上游信息，特在[《第三方开源软件引入指导》](./第三方开源软件引入指导.md)中对相关信息进行了要求 “新引入的开源软件必须在其根目录提供README.OpenSource文件，在该文件中准确描述其软件名、许可证、许可文件位置、版本、对应版本的上游社区地址、软件的维护Owner、功能描述以及引入的原因。” 但社区开发者常见问题是对于README.OpenSource 写作要求和规范并不清晰，对于其中多License情况，多开源软件情况等场景如何规范填写并不清晰，因此，本文旨在规范化README.OpenSource文件的写作要求，并将相关要求基线化，在工程能力成熟后，README.OpenSource文件可按照本规范，在选型引入时，自动基于引入的信息由IT系统生成此文件。
 
 ## 范围
 
@@ -10,7 +10,7 @@
 
 ## 本文的改进和修订说明
 
-1. 本文档由OpenHarmony 合规SIG主导起草和维护。本文档的最新版本总可以在 [这里](https://gitee.com/openharmony/docs/blob/c2cfb198e35d5e0eb0f18606935f7276b47a40c4/zh-cn/contribute/%E7%AC%AC%E4%B8%89%E6%96%B9%E5%BC%80%E6%BA%90%E8%BD%AF%E4%BB%B6%E4%B8%8A%E6%B8%B8%E8%BD%AF%E4%BB%B6%E5%85%83%E6%95%B0%E6%8D%AEREADMEOpenSource%E6%96%87%E4%BB%B6%E8%A7%84%E8%8C%83.md)找到。
+1. 本文档由OpenHarmony合规SIG主导起草和维护。本文档的最新版本总可以在 [这里](./第三方开源软件上游软件元数据READMEOpenSource文件规范.md)找到。
 2. 任何对于本文中涉及的规则的增加，修改，删除都必须被追踪，请进入该追踪系统 。
 3. 最终规则经过社区充分的讨论后，由PMC评审定稿。
 
@@ -24,10 +24,10 @@ README.OpenSource 样例
     {
         "Name": "linux",                   # 上游开源软件名全称
         "License": "GPL-2.0+",             # 上游开源软件中包含的许可证信息
-        "License File": "COPYING",         # 许可所在文件
+        "License File": "COPYING",         # 许可证所在文件路径
         "Version Number": "5.10.93",       # 该软件的版本
-        "Owner": "xxx@xxx.com",            # 开源软件OpenHarmony 维护人及邮箱
-        "Upstream URL": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/log/?h=linux-5.10.y",   # 上游软件包发布地址
+        "Owner": "xxx@xxx.com",            # 开源软件在OpenHarmony组织下对应的维护人及邮箱
+        "Upstream URL": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/snapshot/linux-5.10.93.tar.gz",   # 上游软件包发布地址
         "Description": "XXXXXXX"           # 开源软件功能描述
     },
     {
@@ -38,15 +38,18 @@ README.OpenSource 样例
 
 1. **Name** : 在本代码仓中**包含源码**的上游开源软件全称。若有多个软件，则写个{}进行描述。
 
-注意：假设A软件依赖B软件，若通过将B软件源码放置在本仓库中，来满足A对B的依赖关系，即A*包含依赖*B， **则A、B软件均需要声明**； 若B软件已在OpenHarmony组织下建立其专属代码仓，仅在编译构建时通过GN指定其他代码仓目录进行依赖，不是以**源码形式**存放在本代码仓库的，即A开源软件*编译依赖*B软件，则不用在此处声明。
+注意：
+假设A软件依赖B软件，若通过将B软件源码放置在本仓库中，来满足A对B的依赖关系，即A*包含依赖*B， **则A、B软件均需要声明**； 若B软件已在OpenHarmony组织下建立其专属代码仓，仅在编译构建时通过GN指定其他代码仓目录进行依赖，不是以**源码形式**存放在本代码仓库的，即A开源软件*编译依赖*B软件，则不用在此处声明。
 
 2. **License** : 上游开源软件中包含的许可证信息此处不可随意填写，需使用SPDX Identitifer简写，每次只能写一个许可证信息； 若存在许可证二选一的情况，在此明确具体选择了哪个许可证； 若代码仓存在多许可证共存的情况，则需要在本文件的最外层数组[]中，再增加一组开源软件元数据的{}描述，对其他许可证及其对应的文件路径进行描述。
 
 3. **License File** : 许可证文件和本代码仓根目录的相对路径，包含最终的文件名。 多个许可证文件的处理方式，参考**License**字段的处理规则，配合完成。
 
-4. **Version Number** : 上游软件正式发布的版本号。
+4. **Version Number** : 上游软件正式发布的版本号，应与上游版本号的文本内容保持完全一致。
 
-5. **Upstream URL**： 源码引入时上游软件对应版本的源码包的发布地址。
+5. **Owner** : 该开源软件在本代码对应组织下的维护者，注：此Owner仅表示在本仓的软件维护者，不同于软件的实际作者。
 
-6. **Description** : 开源软件功能的简要描述。
+6. **Upstream URL** ： 源码引入时上游软件对应版本的源码包的发布地址。
+
+7. **Description** : 开源软件功能的简要描述。