diff --git "a/zh-cn/contribute/OpenHarmony-TPC\345\274\200\346\272\220\350\275\257\344\273\266Notice\350\207\252\345\212\250\347\224\237\346\210\220\345\217\212\346\224\266\351\233\206\347\255\226\347\225\245\350\257\264\346\230\216.md" "b/zh-cn/contribute/OpenHarmony-TPC\345\274\200\346\272\220\350\275\257\344\273\266Notice\350\207\252\345\212\250\347\224\237\346\210\220\345\217\212\346\224\266\351\233\206\347\255\226\347\225\245\350\257\264\346\230\216.md" new file mode 100755 index 0000000000000000000000000000000000000000..7818c73d4bc976c2bc6d562425848b50a0b6ca6f --- /dev/null +++ "b/zh-cn/contribute/OpenHarmony-TPC\345\274\200\346\272\220\350\275\257\344\273\266Notice\350\207\252\345\212\250\347\224\237\346\210\220\345\217\212\346\224\266\351\233\206\347\255\226\347\225\245\350\257\264\346\230\216.md" @@ -0,0 +1,20 @@ +# OpenHarmony-TPC开源软件Notice自动生成及收集策略说明 + +## 收集目标 + +收集所有打包到har包里面的模块对应的License。 + +最终合并的NOTICE.txt要体现出har包中每个文件都是用了哪些License。 + +最终合并的NOTICE.txt文件在har包顶层目录下。 + +## 收集规则 + +### 按照优先级收集License + +1. 编译脚本会在三方库的根目录中查找Readme.OpenSource文件，解析该文件，找出该文件中声明的license，将其作为软件的License。 + + **如果Readme.OpenSource文件中配置的license文件不存在，直接报错。** + +2. 如果Readme.OpenSource文件不存在，编译脚本默认查找仓库的License/Copyright/Notice三个文件，如果找到，则将其作为软件的License。 +3. 如果上面的方式都未找到license，则使用默认的license作为该仓库的license；默认license是Apache2.0 License。 diff --git "a/zh-cn/contribute/OpenHarmony-TPC\350\256\270\345\217\257\350\257\201\344\275\277\347\224\250\350\257\264\346\230\216.md" "b/zh-cn/contribute/OpenHarmony-TPC\350\256\270\345\217\257\350\257\201\344\275\277\347\224\250\350\257\264\346\230\216.md" new file mode 100755 index 0000000000000000000000000000000000000000..16509761fb508cb33924d69ed09e0dbc78d53d52 --- /dev/null +++ "b/zh-cn/contribute/OpenHarmony-TPC\350\256\270\345\217\257\350\257\201\344\275\277\347\224\250\350\257\264\346\230\216.md" @@ -0,0 +1,16 @@ +# OpenHarmony-TPC许可证使用指导 + +## 目的 + +本指导明确了OpenHarmony-TPC社区中的项目代码所采用的许可证。 + +## 范围 + +本指导仅适用于OpenHarmony-TPC社区中分发第三方开源软件的场景。 + +## 贡献代码许可证使用指导 + +1. 针对贡献者自己编写的源码软件，建议使用Apache-2.0。 +2. 针对在上游软件基础上进行适配或新增特性的软件，建议使用上游软件的license。 +3. 针对由上游软件通过语言改写的软件，建议使用上游软件的license。 +4. 对于由多个上游软件适配的软件，源码文件建议使用对应上游软件的license。 diff --git "a/zh-cn/contribute/OpenHarmony\347\244\276\345\214\272\345\274\200\346\272\220\345\220\210\350\247\204\350\247\204\350\214\203\345\217\212\346\214\207\345\257\274.md" "b/zh-cn/contribute/OpenHarmony\347\244\276\345\214\272\345\274\200\346\272\220\345\220\210\350\247\204\350\247\204\350\214\203\345\217\212\346\214\207\345\257\274.md" index 46c535211e9f1e7bb2e08d769c53bfbf9ad81972..73c89ee01169d9e76276f6a2d23af45e9279254a 100644 --- "a/zh-cn/contribute/OpenHarmony\347\244\276\345\214\272\345\274\200\346\272\220\345\220\210\350\247\204\350\247\204\350\214\203\345\217\212\346\214\207\345\257\274.md" +++ "b/zh-cn/contribute/OpenHarmony\347\244\276\345\214\272\345\274\200\346\272\220\345\220\210\350\247\204\350\247\204\350\214\203\345\217\212\346\214\207\345\257\274.md" @@ -6,7 +6,7 @@ ## 范围 -本指导适用于所有参与OpenHarmony社区的贡献者，项目适用范围包含：[OpenHarmony主线](https://gitee.com/openharmony)下代码仓和[OpenHarmony-SIG](https://gitee.com/openharmony-sig)下的代码仓所涉及的项目。 +本指导适用于所有参与OpenHarmony社区的贡献者，项目适用范围包含：[OpenHarmony主线](https://gitee.com/openharmony)下代码仓、[OpenHarmony-TPC主线](https://gitee.com/openharmony)下代码仓和[OpenHarmony-SIG](https://gitee.com/openharmony-sig)下的代码仓所涉及的项目。 ## 本文的改进和修订说明 @@ -14,7 +14,6 @@ 2. 任何对于本文中涉及的规则的增加，修改，删除都必须可追溯 。 3. 最终规则经过社区充分的讨论后，由PMC评审定稿。 - ## 术语和缩略语 [开源合规术语与缩略语参考]() @@ -26,14 +25,13 @@ #### 开源软件许可证使用及评审规范 1. [OpenHarmony项目代码许可证规则与特殊许可证评审指导](许可证与特殊许可证评审指导.md) - 2. [OpenHarmony社区项目已使用代码许可协议说明](https://gitee.com/openharmony#%E8%AE%B8%E5%8F%AF%E5%8D%8F%E8%AE%AE) - +3. [OpenHarmony-TPC社区许可证使用指导](OpenHarmony-TPC许可证使用说明.md) + #### 第三方开源软件开源引入及退出 [第三方开源软件引入及退出指导](第三方开源软件引入指导.md) - ### 开发阶段 #### 开源开发许可证、版权、元数据合规规范 @@ -71,8 +69,9 @@ 1. [SIG 孵化项目毕业开源合规标准](https://gitee.com/openharmony/community/blob/master/sig/sig_qa/guidance_for_incubation_project_graduation_cn.md#sig%E5%AD%B5%E5%8C%96%E9%A1%B9%E7%9B%AE%E6%AF%95%E4%B8%9A%E8%AF%84%E5%AE%A1%E6%A3%80%E6%9F%A5%E9%A1%B9) -2. [版本发布开源合规标准](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) +2. [OpenHarmony版本发布开源合规标准](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) +3. [OpenHarmony-TPC版本发布开源合规标准](https://gitee.com/zhong-luping/docs/blob/task_docs/contribute/rules/OpenHarmony-TPC%E7%89%88%E6%9C%AC%E5%91%BD%E5%90%8D%E6%8C%87%E5%AF%BC.md) ## 二进制合规规范 diff --git "a/zh-cn/contribute/\345\274\200\346\272\220\344\271\211\345\212\241\345\261\245\350\241\214\345\220\210\350\247\204\344\272\244\344\273\230\345\210\266\345\223\201\347\256\241\347\220\206\350\247\204\350\214\203\345\217\212\346\214\207\345\257\274.md" "b/zh-cn/contribute/\345\274\200\346\272\220\344\271\211\345\212\241\345\261\245\350\241\214\345\220\210\350\247\204\344\272\244\344\273\230\345\210\266\345\223\201\347\256\241\347\220\206\350\247\204\350\214\203\345\217\212\346\214\207\345\257\274.md" index e8794a18679fed4fbf2e2158743bb2e4ecf57002..599ab5d7019c26ff7775247d5291933871800d9e 100644 --- "a/zh-cn/contribute/\345\274\200\346\272\220\344\271\211\345\212\241\345\261\245\350\241\214\345\220\210\350\247\204\344\272\244\344\273\230\345\210\266\345\223\201\347\256\241\347\220\206\350\247\204\350\214\203\345\217\212\346\214\207\345\257\274.md" +++ "b/zh-cn/contribute/\345\274\200\346\272\220\344\271\211\345\212\241\345\261\245\350\241\214\345\220\210\350\247\204\344\272\244\344\273\230\345\210\266\345\223\201\347\256\241\347\220\206\350\247\204\350\214\203\345\217\212\346\214\207\345\257\274.md" @@ -16,7 +16,8 @@ ### 开源软件NOTICE生成规则及要求 -[OpenHarmony开源软件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) +- [OpenHarmony开源软件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) +- [OpenHarmony-TPC开源软件Notice自动生成及收集策略说明](./OpenHarmony-TPC%E5%BC%80%E6%BA%90%E8%BD%AF%E4%BB%B6Notice%E8%87%AA%E5%8A%A8%E7%94%9F%E6%88%90%E5%8F%8A%E6%94%B6%E9%9B%86%E7%AD%96%E7%95%A5%E8%AF%B4%E6%98%8E.md) ### 开源软件NOTICE存放位置 @@ -27,7 +28,7 @@ 2. 系统中存放在/system/etc/NOTICE.txt。 #### 应用软件存放位置要求 -NOTICE文件通常放置在发布文件夹或压缩包的顶层目录，对于".jar"格式的文件，许可证可位于META-INF目录。 +NOTICE文件通常放置在发布文件夹或压缩包的顶层目录，对于".jar"格式的文件，许可证可位于META-INF目录；对于".har"格式的文件，许可证位于顶层目录。 ### 开源软件NOTICE的生命周期 NOTICE文件的生命周期，跟随发布二进制的生命周期，按照[OpenHarmony生命周期规则](https://gitee.com/openharmony/release-management/blob/master/OpenHarmony%E7%94%9F%E5%91%BD%E5%91%A8%E6%9C%9F%E5%8F%91%E5%B8%83%E5%85%AC%E5%91%8A.md)，支撑LTS、Release等版本。 diff --git "a/zh-cn/contribute/\347\254\254\344\270\211\346\226\271\345\274\200\346\272\220\350\275\257\344\273\266\345\274\225\345\205\245\346\214\207\345\257\274.md" "b/zh-cn/contribute/\347\254\254\344\270\211\346\226\271\345\274\200\346\272\220\350\275\257\344\273\266\345\274\225\345\205\245\346\214\207\345\257\274.md" index de66c81d8fc19562452aae76b357a8162420e55f..39e3ff738f4fd5d6727a97588a5cad031ad31f18 100755 --- "a/zh-cn/contribute/\347\254\254\344\270\211\346\226\271\345\274\200\346\272\220\350\275\257\344\273\266\345\274\225\345\205\245\346\214\207\345\257\274.md" +++ "b/zh-cn/contribute/\347\254\254\344\270\211\346\226\271\345\274\200\346\272\220\350\275\257\344\273\266\345\274\225\345\205\245\346\214\207\345\257\274.md" @@ -31,16 +31,17 @@ OpenHarmony遵从 [Open Source Definition](https://opensource.org/docs/osd) ， 3. 软件应该以源码方式引入，原则上二进制不应该被引入，应从源码构建。如果需要引入二进制，经由PMC评审后决定。 4. 软件应该在OpenHarmony上可以被正确构建，若该软件有尚未被引入的依赖软件，或者软件的运行或者构建依赖一个不能引入OpenHarmony的组件，需由SIG-Architecture评审后决定。 5. 引入软件到OpenHarmony项目中必须将其放置到单独的代码仓，命名统一为**third_party**_**软件名称**，其中软件名称和其官网保持一致。 -6. 应当完整保留引入软件的官方代码仓目录结构、许可证及Copyright信息，不要修改第三方开源软件的原始许可证与Copyright信息。 -7. 不建议引入未发布正式版本（如只发布Beta版本）的开源软件。 -8. 不能引入有高危漏洞且无解决方案的版本。 -9. 若需针对引入的开源软件进行修改，请将修改的代码放在该开源软件仓中，并确保满足该开源软件的许可证要求，修改的文件应当保持其原始许可证条款，新增的文件也建议采用相同的许可证条款。 -10. 新引入的开源软件必须在其根目录提供README.OpenSource文件，在该文件中准确描述其软件名、许可证、许可文件位置、版本、对应版本的上游社区地址、软件的维护Owner、功能描述以及引入的原因。 -11. 引入新软件到OpenHarmony时必须有对应的SIG负责管理，原则上如果没有SIG-Compliance以及相应SIG的确认，SIG-Architecture不批准相应软件的引入。当要批量引入多个软件时，可以求助SIG-Architecture主持发起SIG间的临时评审会议，提升协调效率。如因特殊原因不能满足上述要求但又需要引入，请联系邮箱：oh-legal@openatom.io。 -12. 引入新的开源软件存在依赖其他开源软件时，不允许将被动依赖软件嵌套在引入的新的开源软件子目录中，必须剥离所有依赖软件项，并将其分别放置到单独的代码仓，命名统一为third_party_依赖软件名称，原因是嵌套放置依赖软件可能导致多同一款软件多版本、旧版本安全漏洞无法及时修复、开源义务履行合规的风险问题。 +6. 针对引入到OpenHarmony-TPC社区中需托管源码的软件，必须将其放置到单独的代码仓，仓库命名延用原软件名称(如若该软件在社区存在多平台版本，如XXX-android,XXX-IOS等，则需在软件名称前添加ohos_)。 +7. 应当完整保留引入软件的官方代码仓目录结构、许可证及Copyright信息，不要修改第三方开源软件的原始许可证与Copyright信息。 +8. 不建议引入未发布正式版本（如只发布Beta版本）的开源软件。 +9. 不能引入有高危漏洞且无解决方案的版本。 +10. 若需针对引入的开源软件进行修改，请将修改的代码放在该开源软件仓中，并确保满足该开源软件的许可证要求，修改的文件应当保持其原始许可证条款，新增的文件也建议采用相同的许可证条款。 +11. 新引入的开源软件必须在其根目录提供README.OpenSource文件，在该文件中准确描述其软件名、许可证、许可文件位置、版本、对应版本的上游社区地址、软件的维护Owner、功能描述以及引入的原因。 +12. 引入新软件到OpenHarmony时必须有对应的SIG负责管理，原则上如果没有SIG-Compliance以及相应SIG的确认，SIG-Architecture不批准相应软件的引入。当要批量引入多个软件时，可以求助SIG-Architecture主持发起SIG间的临时评审会议，提升协调效率。如因特殊原因不能满足上述要求但又需要引入，请联系邮箱：oh-legal@openatom.io。 +13. 引入新的开源软件存在依赖其他开源软件时，不允许将被动依赖软件嵌套在引入的新的开源软件子目录中，必须剥离所有依赖软件项，并将其分别放置到单独的代码仓，命名统一为third_party_依赖软件名称，原因是嵌套放置依赖软件可能导致多同一款软件多版本、旧版本安全漏洞无法及时修复、开源义务履行合规的风险问题。 - 依赖软件在编译构建部件命名，将新引入的主软件名作为依赖软件部件前缀命名，例如 part_name = "新引入主软件名_依赖软件名" - 新引入软件和依赖软件分别独立构建，通过external_deps来解决部件间依赖。 -13. OpenHarmony对引入三方开源软件的归档目录要求： +14. OpenHarmony对引入三方开源软件的归档目录要求： - 原则上如果您没有真正充分的理由将其存储在其他地方，且满足OpenHarmony许可证引入要求三方开源软件，统一归属于third_party根目录下； - 针对开发板引入且无法纳入OpenHarmony系统平台的三方开源软件，可以申请在以下位置存档，要求以上游开源软件名创建目录，并在对应目录下归档README.OpenSource说明文档；采取BUILD.gn方式独立构建，支撑开源义务声明信息的自动收集。 @@ -50,13 +51,19 @@ OpenHarmony遵从 [Open Source Definition](https://opensource.org/docs/osd) ， vendor/$(PRODUCT_COMPANY)/third_party ``` -14. OpenHarmony平台版本或版本构建中用到的预编译二进制或工具链，需提供如下信息： +15. OpenHarmony平台版本或版本构建中用到的预编译二进制或工具链，需提供如下信息： - 预编译二进制或工具链对应的源码，需要在OpenHarmony社区托管对应的源代码，并提供对应的构建指导，开源义务履行遵从指导； - 预编译二进制或工具链中引入的开源三方软件，需要遵从原则1~13; - [预编译二进制或工具链的说明文档](./prebuilts-readme-template.md):包括源码获取地址、构建指导、更新方法，随OpenHarmony版本或工具链归档到对应模块的根目录中； - 预编译的二进制或工具链对应的根目录需要提供完整开源义务履行声明文档； - 如果预编译文件来源于上游社区托管平台的二进制（譬如npm包等）。我们需要在归档二进制的地方提供以下信息，首先我们需要提供一个命名为**README**概要性描述文件，内容包括引入的背景描述和其官方托管地址；其次我们需要提供一个命名为**NOTICE**的开源义务履行声明的描述文件，内容包括其中涉及的没一个开源软件名称、版本号、以及对应的开源许可协议。 +16. 针对通过上游软件适配的软件，建议遵循以下原则： + + - 新适配的软件建议保留原上游许可证信息。 + - 新适配的软版权头填写改写者信息，但需要在版权头上增加base on(原上游软件版权信息)。 + - 当新适配的软件由多个上游软件组成的，各软件间的许可证需是可兼容的，且适配的代码建议使用对应原上游软件的许可证信息。 + ### 软件引入流程 #### 软件引入前检查