From 01feaa44958121603fdfb8db8936166230072156 Mon Sep 17 00:00:00 2001 From: jalenchen0214 Date: Mon, 29 Mar 2021 19:09:27 +0800 Subject: [PATCH 01/13] =?UTF-8?q?=E5=88=B7=E6=96=B0=E5=BC=95=E5=85=A5?= =?UTF-8?q?=E5=8E=9F=E5=88=99?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- ...25\345\205\245\346\214\207\345\257\274.md" | 36 +++++++++++++------ 1 file changed, 26 insertions(+), 10 deletions(-) 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 cf99ed6d91f..5546c015f4c 100644 --- "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" @@ -1,24 +1,42 @@ # 第三方开源软件引入指导 ## 目的 +OpenHarmony遵从 [Open Source Definition](https://opensource.org/docs/osd) ，满足这一定义的软件，被OpenHarmony社区认同为开源软件。 提供易用、高质量的开源软件是OpenHarmony的重要目标，因第三方开源软件数量多，而社区开发人员同样数量多、分布广，为确保OpenHarmony项目的整体质量，特别拟定本指南，供社区贡献者参考。 ## 范围 本指导适用于所有引入到OpenHarmony项目中的第三方开源软件。 -## 规则 +## 本文的改进和修订说明 +1. 本文档由OpenHarmony PMC主导起草和维护。本文档的最新版本总可以在 [这里](https://gitee.com/openharmony/docs/blob/36955109ed21d73afe09fcb5a5bc7067ad6ce18b/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) 找到。 +2. 任何对于本文中涉及的规则的增加，修改，删除都必须被追踪，请进入该追踪系统 。 +3. 最终规则经过社区充分的讨论后，由PMC定稿。 -### 基本要求 -为便于第三方开源软件的维护与演进，在引入第三方开源软件时请参考如下原则：
+## 软件引入与引入原则 +### 什么是软件引入 +1. 一个软件的引入指的是一个软件(项目)申请被引入到OpenHarmony项目中，依照本文件描述的规则讨论，进而满足规则要求，最终在OpenHarmony中建立相应repo的过程。 +2. 整个引入的过程都必须可被追踪。目前 [https://gitee.com/openharmony/community/issues](https://gitee.com/openharmony/community/issues) 是这个过程的追踪系统。 +3. PMC通过对引入申请(Pull Request)的评审，管理软件引入。 -1. 若需要使用的开源软件在OpenHarmony项目中已存在，请使用OpenHarmony项目中维护的版本。 -2. 引入新的第三方开源软件到OpenHarmony项目时，请将其放置到单独的代码仓或目录中，并且软件名称和其官网保持一致。 -3. 第三方开源软件仓应当完整保留该开源软件官方代码仓的目录结构、许可证及Copyright信息。 -4. 不建议引入未发布正式版本（如只发布Beta版本）的开源软件。 -5. 若需针对引入的开源软件进行修改，请将修改的代码放在该开源软件仓中，并确保满足该开源软件的许可证要求。 +### 软件引入的基本要求 +为便于第三方开源软件的维护与演进，在引入第三方开源软件时请参考如下原则： +1. 软件必须有明确的来源，引入到OpenHarmony的软件必须有清晰定义的上游社区。 +2. 软件应该有明确的引入理由。 +3. 软件应该是源码包，原则上二进制不应该被引入，应从源码构建。如果需要引入二进制，经由PMC讨论后决定。 +4. 软件应该在OpenHarmony上可以被正确构建，若该软件有尚未被引入的依赖软件，或者软件的运行或者构建依赖一个绝不可能引入OpenHarmony的组件，需由PMC讨论后决定。 +5. 若需要引入的软件在OpenHarmony项目中已存在，请使用OpenHarmony项目中已存在的版本，避免多版本共存增加维护的复杂性。 +6. 引入新软件到OpenHarmony项目时，请将其放置到单独的代码仓或独立的目录中，并且软件名称和其官网保持一致。 +7. 引入的新软件应当完整保留该开源软件官方代码仓的目录结构、许可证及Copyright信息。 +8. 不建议引入未发布正式版本（如只发布Beta版本）的开源软件。 +9. 若需针对引入的开源软件进行修改，请将修改的代码放在该开源软件仓中，并确保满足该开源软件的许可证要求。 +10. 存在于黑名单的软件必须不能引入。 +11. 引入新软件到OpenHarmony时必须有对应的SIG负责管理，原则上如果没有相应SIG maintainer的确认，PMC不批准相应软件包的引入。当要批量引入多个软件时，可以求助PMC主持发起SIG间的临时评审会议，提升协调效率。 如因特殊原因不能满足上述要求但又需要引入，请请联系邮箱：law@openatom.org。 +### 黑名单机制 +PMC讨论后，可以将被拒绝引入的软件被记录到一个软件[黑名单]()，避免重复评估。 + ### 第三方开源软件许可证要求 1. 第三方开源软件许可证类型必须是[OSI](https://opensource.org/osd-annotated) 明确定义的。 2. 第三方开源软件许可证必须与使用该开源软件的代码仓许可证兼容。 @@ -85,5 +103,3 @@ 如要引入其它类型License或上述（4）所列License，请联系邮箱：law@openatom.org。 -## 本指导的改进及修订说明 -本指导的变更由PMC维护，随着OpenHarmony的演进该指导可能不断刷新、完善，请社区贡献者关注最新版本的指导。 \ No newline at end of file -- Gitee From 52f581ecff4ecc588789d0343bf9611fbe2069cb Mon Sep 17 00:00:00 2001 From: jalenchen0214 Date: Mon, 29 Mar 2021 19:32:23 +0800 Subject: [PATCH 02/13] =?UTF-8?q?=E8=A1=A5=E5=85=85=E9=80=80=E5=87=BA?= =?UTF-8?q?=E5=8E=9F=E5=88=99?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- ...25\345\205\245\346\214\207\345\257\274.md" | 23 +++++++++++++++++++ 1 file changed, 23 insertions(+) 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 5546c015f4c..1aba735fbca 100644 --- "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" @@ -103,3 +103,26 @@ PMC讨论后，可以将被拒绝引入的软件被记录到一个软件[黑名 如要引入其它类型License或上述（4）所列License，请联系邮箱：law@openatom.org。 + +## 软件退出与退出原则 +### 什么是软件退出 +1. 一个软件的退出指的是一个软件(项目)申请从OpenHarmony项目中删除，依照本文件描述的规则讨论，进而满足规则要求，最终在OpenHarmony中移除的过程。 +2. PMC通过提交PR(Pull Request)来评审，管理软件退出。 + +### 软件包退出原则 +当满足以下两个条件时，OpenHarmony软件包的退出申请可以被立即执行，对应文件将从项目中直接删除。 + +1. 软件的License变化，或者其他法律法规影响了目前正在使用的版本，导致OpenHarmony因为法务风险，不能继续集成该软件。 +2. 存在恶意代码或严重安全隐患且OpenHarmony社区无能力修复的，要求软件被立即移除。 + +除以上描述两种场景外，其它场景OpenHarmony对软件包的退出实行过程化管理： + +1. 随着技术演进与发展，软件因技术陈旧或架构落后，不能满足现有的应用场景被其他更优秀的软件所取代。 +2. OpenHarmony已经集成的版本过于老旧，且软件新版本License或其他法律法规限制导致OpenHarmony不能升级新版本。 +3. 软件来自知名社区或组织，社区或组织通过发布公告、修改软件仓库状态、将仓库放到特定目录下等方式告知停止维护的。 +4. 软件来自个人、小型社区或组织，两年内未发布版本（含正式版本与测试版本），无明确版本计划，社区提交了有效的Bug或PR，社区半年以上未响应的。 +5. 社区运营状态不明确，通过Issue或者邮件等方式询问社区是否继续维护，社区半年以上未响应或者答复停止维护的。 + +如果软件符合以上任何一条退出条件，PMC与相应SIG的maintainer将首先分析该软件在当前OpenHarmony社区中被依赖、被使用的情况。 +1. 如果OpenHarmony中存在依赖关系，且短时间内不能解除，我们建议SIG新建分支代码仓，并主动进行社区维护动作。 +2. 如果OpenHarmony中不存在依赖关系，或者短时间内可以解除，则PMC通知发行团队将软件包从OpenHarmony正式发行中移出，并在相应的release notes中标识。 \ No newline at end of file -- Gitee From e03d2eda4f86d1fbaf417d0eb781fc90923597e7 Mon Sep 17 00:00:00 2001 From: jalenchen0214 Date: Mon, 29 Mar 2021 19:37:18 +0800 Subject: [PATCH 03/13] =?UTF-8?q?=E8=A1=A5=E5=85=85=E9=80=80=E5=87=BA?= =?UTF-8?q?=E5=8E=9F=E5=88=99?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- ...\273\266\345\274\225\345\205\245\346\214\207\345\257\274.md" | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) 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 1aba735fbca..b38927ae38b 100644 --- "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,7 +31,7 @@ OpenHarmony遵从 [Open Source Definition](https://opensource.org/docs/osd) ， 8. 不建议引入未发布正式版本（如只发布Beta版本）的开源软件。 9. 若需针对引入的开源软件进行修改，请将修改的代码放在该开源软件仓中，并确保满足该开源软件的许可证要求。 10. 存在于黑名单的软件必须不能引入。 -11. 引入新软件到OpenHarmony时必须有对应的SIG负责管理，原则上如果没有相应SIG maintainer的确认，PMC不批准相应软件包的引入。当要批量引入多个软件时，可以求助PMC主持发起SIG间的临时评审会议，提升协调效率。 +11. 引入新软件到OpenHarmony时必须有对应的SIG负责管理，原则上如果没有相应SIG的确认，PMC不批准相应软件包的引入。当要批量引入多个软件时，可以求助PMC主持发起SIG间的临时评审会议，提升协调效率。 如因特殊原因不能满足上述要求但又需要引入，请请联系邮箱：law@openatom.org。 ### 黑名单机制 -- Gitee From a014b9473228a5e3cdbf5ce27fdb2e0b05792f72 Mon Sep 17 00:00:00 2001 From: jalenchen0214 Date: Mon, 29 Mar 2021 20:15:43 +0800 Subject: [PATCH 04/13] =?UTF-8?q?=E8=A1=A5=E5=85=85=E8=BD=AF=E4=BB=B6?= =?UTF-8?q?=E5=BC=95=E5=85=A5=E5=89=8D=E6=A3=80=E6=9F=A5=E9=A1=B9?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- ...5\274\225\345\205\245\346\214\207\345\257\274.md" | 12 ++++++++++++ 1 file changed, 12 insertions(+) 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 b38927ae38b..39deac19112 100644 --- "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" @@ -103,6 +103,18 @@ PMC讨论后，可以将被拒绝引入的软件被记录到一个软件[黑名 如要引入其它类型License或上述（4）所列License，请联系邮箱：law@openatom.org。 +### 软件引入前检查 + +| 检查点 | 说明 | +| :----- | :----- | +| 归一化 | 1、原则上一款软件只在OpenHarmony中引入一次。 | +| 来源可靠 | 1、开源软件都应该从开源软件官网获取或官网指定的代码托管地址获取。 | +| 规范化软件名称 | 1、 软件名称必须和官网/社区保持一致，不可随意命名。
2、 不允许以软件包中的子模块作为软件名。
3、 当软件是某个语言的开发库时，我们允许追加python-、perl-等前缀予以规范化管理。 | +| 社区运营状态检查 | 1、软件来自知名社区或组织，社区或组织通过发布公告、修改软件仓库状态、将仓库放到特定目录下等方式告知停止维护的，不建议引入。
2、软件来自个人、小型社区或组织，两年内未发布版本（含正式版本与测试版本），无明确版本计划，社区提交了有效的Bug或PR，但是半年以上未响应的，不建议引入。
3、社区运营状态不明确，通过Issue 或者邮件等方式询问社区是否继续维护，半年以上未响应或者答复停止维护的，不建议引入。| +| 官网必填 | 1、软件官方网址填写规范，使用软件供应商提供的网址，或者无单独正式官网的情况下，提供主流代码托管商上面对应的项目网址。
2、不能使用maven、mvnrepository、springsource等托管库作为官方网址 | +| 软件包信息提供 | 1、必须提供官方提供的源代码包的下载地址，以达到可溯源。
2、如果有需要二进制包，需要提供官方的二进制包下载地址。 | +| License检查 | 1、待引入软件是否有license。
2、入库时填写的license是否和官网保持一致；是否和软件包中license保持一致；高风险license的开源软件谨慎引入 | +| copyright检查 | 1、通过官网、社区、代码托管网站、源码包、发布件中等地方获取并提供copyright信息 | ## 软件退出与退出原则 ### 什么是软件退出 -- Gitee From 009f327615a67e3b21fe9aa69d85d377d0077413 Mon Sep 17 00:00:00 2001 From: jalenchen0214 Date: Mon, 29 Mar 2021 20:17:53 +0800 Subject: [PATCH 05/13] =?UTF-8?q?=E8=A1=A5=E5=85=85=E8=BD=AF=E4=BB=B6?= =?UTF-8?q?=E5=BC=95=E5=85=A5=E5=89=8D=E6=A3=80=E6=9F=A5=E9=A1=B9?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- ...\266\345\274\225\345\205\245\346\214\207\345\257\274.md" | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) 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 39deac19112..165293a1e8f 100644 --- "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" @@ -111,10 +111,10 @@ PMC讨论后，可以将被拒绝引入的软件被记录到一个软件[黑名 | 来源可靠 | 1、开源软件都应该从开源软件官网获取或官网指定的代码托管地址获取。 | | 规范化软件名称 | 1、 软件名称必须和官网/社区保持一致，不可随意命名。
2、 不允许以软件包中的子模块作为软件名。
3、 当软件是某个语言的开发库时，我们允许追加python-、perl-等前缀予以规范化管理。 | | 社区运营状态检查 | 1、软件来自知名社区或组织，社区或组织通过发布公告、修改软件仓库状态、将仓库放到特定目录下等方式告知停止维护的，不建议引入。
2、软件来自个人、小型社区或组织，两年内未发布版本（含正式版本与测试版本），无明确版本计划，社区提交了有效的Bug或PR，但是半年以上未响应的，不建议引入。
3、社区运营状态不明确，通过Issue 或者邮件等方式询问社区是否继续维护，半年以上未响应或者答复停止维护的，不建议引入。| -| 官网必填 | 1、软件官方网址填写规范，使用软件供应商提供的网址，或者无单独正式官网的情况下，提供主流代码托管商上面对应的项目网址。
2、不能使用maven、mvnrepository、springsource等托管库作为官方网址 | +| 官网必填 | 1、软件官方网址填写规范，使用软件供应商提供的网址，或者无单独正式官网的情况下，提供主流代码托管商上面对应的项目网址。
2、不能使用maven、mvnrepository、springsource等托管库作为官方网址。 | | 软件包信息提供 | 1、必须提供官方提供的源代码包的下载地址，以达到可溯源。
2、如果有需要二进制包，需要提供官方的二进制包下载地址。 | -| License检查 | 1、待引入软件是否有license。
2、入库时填写的license是否和官网保持一致；是否和软件包中license保持一致；高风险license的开源软件谨慎引入 | -| copyright检查 | 1、通过官网、社区、代码托管网站、源码包、发布件中等地方获取并提供copyright信息 | +| License检查 | 1、待引入软件是否有license。
2、入库时填写的license是否和官网保持一致；是否和软件包中license保持一致；高风险license的开源软件谨慎引入。 | +| copyright检查 | 1、通过官网、社区、代码托管网站、源码包、发布件中等地方获取并提供copyright信息。 | ## 软件退出与退出原则 ### 什么是软件退出 -- Gitee From bcf885e1a5c07921a7026a53c7c9a992c7b48482 Mon Sep 17 00:00:00 2001 From: jalenchen0214 Date: Mon, 29 Mar 2021 20:21:53 +0800 Subject: [PATCH 06/13] =?UTF-8?q?=E8=A1=A5=E5=85=85=E8=BD=AF=E4=BB=B6?= =?UTF-8?q?=E5=BC=95=E5=85=A5=E5=89=8D=E6=A3=80=E6=9F=A5=E9=A1=B9?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- ...\266\345\274\225\345\205\245\346\214\207\345\257\274.md" | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) 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 165293a1e8f..3c5e3d6f461 100644 --- "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" @@ -114,11 +114,11 @@ PMC讨论后，可以将被拒绝引入的软件被记录到一个软件[黑名 | 官网必填 | 1、软件官方网址填写规范，使用软件供应商提供的网址，或者无单独正式官网的情况下，提供主流代码托管商上面对应的项目网址。
2、不能使用maven、mvnrepository、springsource等托管库作为官方网址。 | | 软件包信息提供 | 1、必须提供官方提供的源代码包的下载地址，以达到可溯源。
2、如果有需要二进制包，需要提供官方的二进制包下载地址。 | | License检查 | 1、待引入软件是否有license。
2、入库时填写的license是否和官网保持一致；是否和软件包中license保持一致；高风险license的开源软件谨慎引入。 | -| copyright检查 | 1、通过官网、社区、代码托管网站、源码包、发布件中等地方获取并提供copyright信息。 | +| Copyright检查 | 1、通过官网、社区、代码托管网站、源码包、发布件中等地方获取并提供Copyright信息。 | ## 软件退出与退出原则 ### 什么是软件退出 -1. 一个软件的退出指的是一个软件(项目)申请从OpenHarmony项目中删除，依照本文件描述的规则讨论，进而满足规则要求，最终在OpenHarmony中移除的过程。 +1. 一个软件的退出指的是一个软件(项目)申请从OpenHarmony项目中删除，依照本文件描述的规则讨论，最终在OpenHarmony中移除的过程。 2. PMC通过提交PR(Pull Request)来评审，管理软件退出。 ### 软件包退出原则 @@ -135,6 +135,6 @@ PMC讨论后，可以将被拒绝引入的软件被记录到一个软件[黑名 4. 软件来自个人、小型社区或组织，两年内未发布版本（含正式版本与测试版本），无明确版本计划，社区提交了有效的Bug或PR，社区半年以上未响应的。 5. 社区运营状态不明确，通过Issue或者邮件等方式询问社区是否继续维护，社区半年以上未响应或者答复停止维护的。 -如果软件符合以上任何一条退出条件，PMC与相应SIG的maintainer将首先分析该软件在当前OpenHarmony社区中被依赖、被使用的情况。 +如果软件符合以上任何一条退出条件，PMC与相应SIG首先分析该软件在当前OpenHarmony社区中被依赖、被使用的情况。 1. 如果OpenHarmony中存在依赖关系，且短时间内不能解除，我们建议SIG新建分支代码仓，并主动进行社区维护动作。 2. 如果OpenHarmony中不存在依赖关系，或者短时间内可以解除，则PMC通知发行团队将软件包从OpenHarmony正式发行中移出，并在相应的release notes中标识。 \ No newline at end of file -- Gitee From 98f2a8b60f5a2387a843d321a85638c4ca90eaa3 Mon Sep 17 00:00:00 2001 From: jalenchen0214 Date: Tue, 13 Apr 2021 14:39:48 +0800 Subject: [PATCH 07/13] =?UTF-8?q?=E7=BB=93=E5=90=88=E8=AF=84=E5=AE=A1?= =?UTF-8?q?=E6=84=8F=E8=A7=81=E5=88=B7=E6=96=B0=E6=8F=8F=E8=BF=B0?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- ...25\345\205\245\346\214\207\345\257\274.md" | 24 +++++++++---------- 1 file changed, 12 insertions(+), 12 deletions(-) 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 3c5e3d6f461..e294467b0a7 100644 --- "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" @@ -30,19 +30,19 @@ OpenHarmony遵从 [Open Source Definition](https://opensource.org/docs/osd) ， 7. 引入的新软件应当完整保留该开源软件官方代码仓的目录结构、许可证及Copyright信息。 8. 不建议引入未发布正式版本（如只发布Beta版本）的开源软件。 9. 若需针对引入的开源软件进行修改，请将修改的代码放在该开源软件仓中，并确保满足该开源软件的许可证要求。 -10. 存在于黑名单的软件必须不能引入。 -11. 引入新软件到OpenHarmony时必须有对应的SIG负责管理，原则上如果没有相应SIG的确认，PMC不批准相应软件包的引入。当要批量引入多个软件时，可以求助PMC主持发起SIG间的临时评审会议，提升协调效率。 +10. 存在于拒绝软件清单的软件必须不能引入。 +11. 引入新软件到OpenHarmony时必须有对应的SIG负责管理，原则上如果没有相应SIG的确认，PMC不批准相应软件的引入。当要批量引入多个软件时，可以求助PMC主持发起SIG间的临时评审会议，提升协调效率。 如因特殊原因不能满足上述要求但又需要引入，请请联系邮箱：law@openatom.org。 -### 黑名单机制 -PMC讨论后，可以将被拒绝引入的软件被记录到一个软件[黑名单]()，避免重复评估。 +### 拒绝软件清单机制 +PMC讨论后，可以将不符合引入标准的软件记录到拒绝软件清单中，避免重复评估。 ### 第三方开源软件许可证要求 1. 第三方开源软件许可证类型必须是[OSI](https://opensource.org/osd-annotated) 明确定义的。 2. 第三方开源软件许可证必须与使用该开源软件的代码仓许可证兼容。 3. 如下类型许可证可以引入到OpenHarmony项目中： * Apache License 2.0 -* Mulan Permissive Software License，Version 2 +* Mulan Permissive Software License, Version 2 * BSD 2-clause * BSD 3-clause * DOM4J License @@ -109,11 +109,11 @@ PMC讨论后，可以将被拒绝引入的软件被记录到一个软件[黑名 | :----- | :----- | | 归一化 | 1、原则上一款软件只在OpenHarmony中引入一次。 | | 来源可靠 | 1、开源软件都应该从开源软件官网获取或官网指定的代码托管地址获取。 | -| 规范化软件名称 | 1、 软件名称必须和官网/社区保持一致，不可随意命名。
2、 不允许以软件包中的子模块作为软件名。
3、 当软件是某个语言的开发库时，我们允许追加python-、perl-等前缀予以规范化管理。 | +| 规范化软件名称 | 1、 软件名称必须和官网/社区保持一致，不可随意命名。
2、 不允许以软件中的子模块作为软件名。
3、 当软件是某个语言的开发库时，我们允许追加python-、perl-等前缀予以规范化管理。 | | 社区运营状态检查 | 1、软件来自知名社区或组织，社区或组织通过发布公告、修改软件仓库状态、将仓库放到特定目录下等方式告知停止维护的，不建议引入。
2、软件来自个人、小型社区或组织，两年内未发布版本（含正式版本与测试版本），无明确版本计划，社区提交了有效的Bug或PR，但是半年以上未响应的，不建议引入。
3、社区运营状态不明确，通过Issue 或者邮件等方式询问社区是否继续维护，半年以上未响应或者答复停止维护的，不建议引入。| | 官网必填 | 1、软件官方网址填写规范，使用软件供应商提供的网址，或者无单独正式官网的情况下，提供主流代码托管商上面对应的项目网址。
2、不能使用maven、mvnrepository、springsource等托管库作为官方网址。 | -| 软件包信息提供 | 1、必须提供官方提供的源代码包的下载地址，以达到可溯源。
2、如果有需要二进制包，需要提供官方的二进制包下载地址。 | -| License检查 | 1、待引入软件是否有license。
2、入库时填写的license是否和官网保持一致；是否和软件包中license保持一致；高风险license的开源软件谨慎引入。 | +| 软件信息提供 | 1、必须提供官方提供的源代码包的下载地址，以达到可溯源。
2、如果有需要二进制包，需要提供官方的二进制包下载地址。 | +| License检查 | 1、待引入软件是否有license。
2、入库时填写的license是否和官网保持一致；是否和软件中license保持一致；高风险license的开源软件谨慎引入。 | | Copyright检查 | 1、通过官网、社区、代码托管网站、源码包、发布件中等地方获取并提供Copyright信息。 | ## 软件退出与退出原则 @@ -121,13 +121,13 @@ PMC讨论后，可以将被拒绝引入的软件被记录到一个软件[黑名 1. 一个软件的退出指的是一个软件(项目)申请从OpenHarmony项目中删除，依照本文件描述的规则讨论，最终在OpenHarmony中移除的过程。 2. PMC通过提交PR(Pull Request)来评审，管理软件退出。 -### 软件包退出原则 -当满足以下两个条件时，OpenHarmony软件包的退出申请可以被立即执行，对应文件将从项目中直接删除。 +### 软件退出原则 +当满足以下两个条件时，OpenHarmony中软件的退出申请可以被立即执行，对应文件将从项目中直接删除。 1. 软件的License变化，或者其他法律法规影响了目前正在使用的版本，导致OpenHarmony因为法务风险，不能继续集成该软件。 2. 存在恶意代码或严重安全隐患且OpenHarmony社区无能力修复的，要求软件被立即移除。 -除以上描述两种场景外，其它场景OpenHarmony对软件包的退出实行过程化管理： +除以上描述两种场景外，其它场景OpenHarmony对软件的退出实行过程化管理： 1. 随着技术演进与发展，软件因技术陈旧或架构落后，不能满足现有的应用场景被其他更优秀的软件所取代。 2. OpenHarmony已经集成的版本过于老旧，且软件新版本License或其他法律法规限制导致OpenHarmony不能升级新版本。 @@ -137,4 +137,4 @@ PMC讨论后，可以将被拒绝引入的软件被记录到一个软件[黑名 如果软件符合以上任何一条退出条件，PMC与相应SIG首先分析该软件在当前OpenHarmony社区中被依赖、被使用的情况。 1. 如果OpenHarmony中存在依赖关系，且短时间内不能解除，我们建议SIG新建分支代码仓，并主动进行社区维护动作。 -2. 如果OpenHarmony中不存在依赖关系，或者短时间内可以解除，则PMC通知发行团队将软件包从OpenHarmony正式发行中移出，并在相应的release notes中标识。 \ No newline at end of file +2. 如果OpenHarmony中不存在依赖关系，或者短时间内可以解除，则PMC通知发行团队将软件从OpenHarmony正式发行中移出，并在相应的release notes中标识。 \ No newline at end of file -- Gitee From 7f888c38325657e3494f526a202e564b71b07397 Mon Sep 17 00:00:00 2001 From: jalenchen0214 Date: Tue, 13 Apr 2021 15:56:13 +0800 Subject: [PATCH 08/13] Modify rule list --- ...25\345\205\245\346\214\207\345\257\274.md" | 34 +++++++++---------- 1 file changed, 17 insertions(+), 17 deletions(-) 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 e294467b0a7..7e4e083b124 100644 --- "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" @@ -14,7 +14,7 @@ OpenHarmony遵从 [Open Source Definition](https://opensource.org/docs/osd) ， ## 软件引入与引入原则 ### 什么是软件引入 -1. 一个软件的引入指的是一个软件(项目)申请被引入到OpenHarmony项目中，依照本文件描述的规则讨论，进而满足规则要求，最终在OpenHarmony中建立相应repo的过程。 +1. 一个软件的引入指的是一个软件(项目)申请被引入到OpenHarmony项目中，依照本文件描述的规则讨论，进而满足规则要求，最终在纳入OpenHarmony相应repo的过程。 2. 整个引入的过程都必须可被追踪。目前 [https://gitee.com/openharmony/community/issues](https://gitee.com/openharmony/community/issues) 是这个过程的追踪系统。 3. PMC通过对引入申请(Pull Request)的评审，管理软件引入。 @@ -22,15 +22,15 @@ OpenHarmony遵从 [Open Source Definition](https://opensource.org/docs/osd) ， 为便于第三方开源软件的维护与演进，在引入第三方开源软件时请参考如下原则： 1. 软件必须有明确的来源，引入到OpenHarmony的软件必须有清晰定义的上游社区。 -2. 软件应该有明确的引入理由。 -3. 软件应该是源码包，原则上二进制不应该被引入，应从源码构建。如果需要引入二进制，经由PMC讨论后决定。 -4. 软件应该在OpenHarmony上可以被正确构建，若该软件有尚未被引入的依赖软件，或者软件的运行或者构建依赖一个绝不可能引入OpenHarmony的组件，需由PMC讨论后决定。 -5. 若需要引入的软件在OpenHarmony项目中已存在，请使用OpenHarmony项目中已存在的版本，避免多版本共存增加维护的复杂性。 -6. 引入新软件到OpenHarmony项目时，请将其放置到单独的代码仓或独立的目录中，并且软件名称和其官网保持一致。 -7. 引入的新软件应当完整保留该开源软件官方代码仓的目录结构、许可证及Copyright信息。 -8. 不建议引入未发布正式版本（如只发布Beta版本）的开源软件。 -9. 若需针对引入的开源软件进行修改，请将修改的代码放在该开源软件仓中，并确保满足该开源软件的许可证要求。 -10. 存在于拒绝软件清单的软件必须不能引入。 +2. 必须有明确的引入理由，若需要引入的软件在OpenHarmony项目中已存在，请重用该版本，避免多版本共存增加维护的复杂性。 +3. 软件应该以源码方式引入，原则上二进制不应该被引入，应从源码构建。如果需要引入二进制，经由PMC讨论后决定。 +4. 软件应该在OpenHarmony上可以被正确构建，若该软件有尚未被引入的依赖软件，或者软件的运行或者构建依赖一个不能引入OpenHarmony的组件，需由PMC讨论后决定。 +5. 引入软件到OpenHarmony项目中必须将其放置到单独的代码仓或独立的目录，并且软件名称和其官网保持一致。 +6. 应当完整保留引入软件的官方代码仓目录结构、许可证及Copyright信息。 +7. 不建议引入未发布正式版本（如只发布Beta版本）的开源软件。 +8. 若需针对引入的开源软件进行修改，请将修改的代码放在该开源软件仓中，并确保满足该开源软件的许可证要求。 +9. 存在于拒绝软件清单的软件不能被引入。 +10. 新引入的开源软件必须在其根目录提供README.OpenSource文件，在该文件中准确描述其软件名、许可证、许可文件位置、版本、对应版本的上游社区地址、功能描述以及引入的原因。 11. 引入新软件到OpenHarmony时必须有对应的SIG负责管理，原则上如果没有相应SIG的确认，PMC不批准相应软件的引入。当要批量引入多个软件时，可以求助PMC主持发起SIG间的临时评审会议，提升协调效率。 如因特殊原因不能满足上述要求但又需要引入，请请联系邮箱：law@openatom.org。 @@ -107,15 +107,15 @@ PMC讨论后，可以将不符合引入标准的软件记录到拒绝软件清 | 检查点 | 说明 | | :----- | :----- | -| 归一化 | 1、原则上一款软件只在OpenHarmony中引入一次。 | -| 来源可靠 | 1、开源软件都应该从开源软件官网获取或官网指定的代码托管地址获取。 | -| 规范化软件名称 | 1、 软件名称必须和官网/社区保持一致，不可随意命名。
2、 不允许以软件中的子模块作为软件名。
3、 当软件是某个语言的开发库时，我们允许追加python-、perl-等前缀予以规范化管理。 | -| 社区运营状态检查 | 1、软件来自知名社区或组织，社区或组织通过发布公告、修改软件仓库状态、将仓库放到特定目录下等方式告知停止维护的，不建议引入。
2、软件来自个人、小型社区或组织，两年内未发布版本（含正式版本与测试版本），无明确版本计划，社区提交了有效的Bug或PR，但是半年以上未响应的，不建议引入。
3、社区运营状态不明确，通过Issue 或者邮件等方式询问社区是否继续维护，半年以上未响应或者答复停止维护的，不建议引入。| -| 官网必填 | 1、软件官方网址填写规范，使用软件供应商提供的网址，或者无单独正式官网的情况下，提供主流代码托管商上面对应的项目网址。
2、不能使用maven、mvnrepository、springsource等托管库作为官方网址。 | -| 软件信息提供 | 1、必须提供官方提供的源代码包的下载地址，以达到可溯源。
2、如果有需要二进制包，需要提供官方的二进制包下载地址。 | -| License检查 | 1、待引入软件是否有license。
2、入库时填写的license是否和官网保持一致；是否和软件中license保持一致；高风险license的开源软件谨慎引入。 | +| 归一化 | 1、检查该软件在OpenHarmony中是否已存在，原则上一款软件只在OpenHarmony中引入一次。 | +| 来源可靠 | 1、应该从开源软件官网获取或官网指定的代码托管地址获取。 | +| 社区活跃 | 1、软件来自知名社区或组织，社区或组织通过发布公告、修改软件仓库状态、将仓库放到特定目录下等方式告知停止维护的，不建议引入。
2、软件来自个人、小型社区或组织，两年内未发布版本（含正式版本与测试版本），无明确版本计划，社区提交了有效的Bug或PR，但是半年以上未响应的，不建议引入。
3、社区运营状态不明确，通过Issue 或者邮件等方式询问社区是否继续维护，半年以上未响应或者答复停止维护的，不建议引入。| +| 规范化软件名称 | 1、 软件名称必须和官网/社区保持一致。
2、 不允许以软件的子模块作为软件名。
3、 当软件是某个语言的开发库时，可以追加python-、perl-等前缀予以规范化管理。 | +| 官网信息 | 1、在申请引入请求中准确描述该软件官方网址，如无正式官网则提供主流代码托管商上面对应的项目网址，不能使用maven、mvnrepository、springsource等托管库地址。
2、必须同时提供要引入版本的官方源代码包下载地址，以达到可溯源，如需要二进制包，请提供官方的二进制包下载地址。 | +| License检查 | 1、待引入软件是否有license。
2、入库的License是否和官网对应版本的License保持一致。
3、高风险license的开源软件谨慎引入，在引入前请充分评估并在申请时附上分析结论。 | | Copyright检查 | 1、通过官网、社区、代码托管网站、源码包、发布件中等地方获取并提供Copyright信息。 | + ## 软件退出与退出原则 ### 什么是软件退出 1. 一个软件的退出指的是一个软件(项目)申请从OpenHarmony项目中删除，依照本文件描述的规则讨论，最终在OpenHarmony中移除的过程。 -- Gitee From 9e67cbacbf83dfd8307541a3c5fbc2c4e8f4a453 Mon Sep 17 00:00:00 2001 From: jalenchen0214 Date: Tue, 13 Apr 2021 15:57:24 +0800 Subject: [PATCH 09/13] Modify rule list --- ...4\273\266\345\274\225\345\205\245\346\214\207\345\257\274.md" | 1 - 1 file changed, 1 deletion(-) 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 7e4e083b124..0b3502974cf 100644 --- "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" @@ -113,7 +113,6 @@ PMC讨论后，可以将不符合引入标准的软件记录到拒绝软件清 | 规范化软件名称 | 1、 软件名称必须和官网/社区保持一致。
2、 不允许以软件的子模块作为软件名。
3、 当软件是某个语言的开发库时，可以追加python-、perl-等前缀予以规范化管理。 | | 官网信息 | 1、在申请引入请求中准确描述该软件官方网址，如无正式官网则提供主流代码托管商上面对应的项目网址，不能使用maven、mvnrepository、springsource等托管库地址。
2、必须同时提供要引入版本的官方源代码包下载地址，以达到可溯源，如需要二进制包，请提供官方的二进制包下载地址。 | | License检查 | 1、待引入软件是否有license。
2、入库的License是否和官网对应版本的License保持一致。
3、高风险license的开源软件谨慎引入，在引入前请充分评估并在申请时附上分析结论。 | -| Copyright检查 | 1、通过官网、社区、代码托管网站、源码包、发布件中等地方获取并提供Copyright信息。 | ## 软件退出与退出原则 -- Gitee From 6d519f04ecdcca15f82e59a909f4d73a62d7c830 Mon Sep 17 00:00:00 2001 From: jalenchen0214 Date: Sun, 25 Apr 2021 17:30:04 +0800 Subject: [PATCH 10/13] Add license and notice rules --- ...10\346\235\203\350\247\204\350\214\203.md" | 58 +++++++++++++++++++ 1 file changed, 58 insertions(+) create mode 100644 "zh-cn/contribute/\350\256\270\345\217\257\350\257\201\344\270\216\347\211\210\346\235\203\350\247\204\350\214\203.md" diff --git "a/zh-cn/contribute/\350\256\270\345\217\257\350\257\201\344\270\216\347\211\210\346\235\203\350\247\204\350\214\203.md" "b/zh-cn/contribute/\350\256\270\345\217\257\350\257\201\344\270\216\347\211\210\346\235\203\350\247\204\350\214\203.md" new file mode 100644 index 00000000000..1092c88c2fc --- /dev/null +++ "b/zh-cn/contribute/\350\256\270\345\217\257\350\257\201\344\270\216\347\211\210\346\235\203\350\247\204\350\214\203.md" @@ -0,0 +1,58 @@ +# 许可证与版权规范 + +## 目的 +本规范明确了OpenHarmony社区的代码贡献者、Committer、PMC成员如何处理Repo及源代码文件的许可与版权声明，包括如下几个部分 +1. LICENSE文件 +2. NOTICE文件 +3. 源文件许可头 +4. 源文件版权头 + +## 范围 +本规范仅适用于OpenHarmony社区，不适用于将OpenHarmony项目应用于个人或企业以开发其它产品的场景，也不适用分发第三方开源软件的场景（该场景参见[第三方开源软件引入指导](第三方开源软件引入指导.md)）。 + +## 本文的改进和修订说明 +1. 本文档由OpenHarmony PMC主导起草和维护。本文档的最新版本总可以在 [这里](许可证与版权规范.md) 找到。 +2. 任何对于本文中涉及的规则的增加，修改，删除都必须被追踪，请进入该追踪系统。 +3. 最终规则经过社区充分的讨论后，由PMC定稿。 + +## LICENSE文件 +1. 每个开源仓必须有清晰描述的许可证信息，且许可证必须与OpenHarmony整体许可证规则一致，如用户态开源仓使用Apache License 2.0许可协议,LiteOS内核态开源仓使用BSD 3-clause许可协议。 +2. 每个开源仓的许可证文件必须为纯文本格式，放置于代码仓的根目录，里面包含该许可的全文，并且以”LICENSE“命名，不用带".txt",".md"等后缀。 +3. 如果开源仓的不同源码包含多种许可证，请将主许可证描述在以”LICENSE“命名的文件中，其它许可证请以”LICENSE-许可证类型-备注“命名并放置于仓的根目录或该许可证对应源码的根目录，同时在主许可证中描述各许可证文件位置及其适用的范围与场景。 +4. 每个开源仓的许可证文件必须要涵盖该仓下所有文件，确保各许可证的涵盖范围描述准确、精简，并且不要包含不在本仓发布的其它源代码许可等不必要的信息，比如要单独下载的依赖软件的许可不要包含在仓和许可证信息中。 +5. 如果开源仓在发布时以二进制形式发布，请确保许可证文件位于其发布格式的常规位置，如对于".jar"格式的文件，许可证位于META-INF目录。 + +## NOTICE文件 +1. 如分发的二进制文件中包含有第三方开源软件，请提供以“NOTICE”命名的文件，NOTICE文件以纯文本格式描述包含的所有第三方开源软件名称、软件版本、权利人声明、License信息，模板如下： +``` +THIRD PARTY 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 SOFTWARE 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. + +Copyright Notice and License Texts + +Software: abc 1.0.0 +Copyright notice: +... +License: Apache License Version 2.0 + +Software: def 1.0.0 +Copyright notice: +... +License: Apache License Version 2.0 +``` +2. NOTICE文件通常放置在发布文件夹的根目录，如对于".jar"格式的文件，NOTICE文件可放置于META-INF目录。 + +## 源文件许可头 + + +### 软件引入前检查 + +| 检查点 | 说明 | +| :----- | :----- | +| 归一化 | 1、检查该软件在OpenHarmony中是否已存在，原则上一款软件只在OpenHarmony中引入一次。 | +| 来源可靠 | 1、应该从开源软件官网获取或官网指定的代码托管地址获取。 | + -- Gitee From 48127ee82d5aa6cbda6f698e637e01aa9b678ae7 Mon Sep 17 00:00:00 2001 From: jalenchen0214 Date: Mon, 26 Apr 2021 09:30:10 +0800 Subject: [PATCH 11/13] Modify 3rd license rule descriptions --- ...\266\345\274\225\345\205\245\346\214\207\345\257\274.md" | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) 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 0b3502974cf..5c83e06813c 100644 --- "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" @@ -26,9 +26,9 @@ OpenHarmony遵从 [Open Source Definition](https://opensource.org/docs/osd) ， 3. 软件应该以源码方式引入，原则上二进制不应该被引入，应从源码构建。如果需要引入二进制，经由PMC讨论后决定。 4. 软件应该在OpenHarmony上可以被正确构建，若该软件有尚未被引入的依赖软件，或者软件的运行或者构建依赖一个不能引入OpenHarmony的组件，需由PMC讨论后决定。 5. 引入软件到OpenHarmony项目中必须将其放置到单独的代码仓或独立的目录，并且软件名称和其官网保持一致。 -6. 应当完整保留引入软件的官方代码仓目录结构、许可证及Copyright信息。 +6. 应当完整保留引入软件的官方代码仓目录结构、许可证及Copyright信息，不要修改第三方开源软件的原始许可证与Copyright信息。 7. 不建议引入未发布正式版本（如只发布Beta版本）的开源软件。 -8. 若需针对引入的开源软件进行修改，请将修改的代码放在该开源软件仓中，并确保满足该开源软件的许可证要求。 +8. 若需针对引入的开源软件进行修改，请将修改的代码放在该开源软件仓中，并确保满足该开源软件的许可证要求，修改的文件应当保持其原始许可证条款，新增的文件也建议采用相同的许可证条款。 9. 存在于拒绝软件清单的软件不能被引入。 10. 新引入的开源软件必须在其根目录提供README.OpenSource文件，在该文件中准确描述其软件名、许可证、许可文件位置、版本、对应版本的上游社区地址、功能描述以及引入的原因。 11. 引入新软件到OpenHarmony时必须有对应的SIG负责管理，原则上如果没有相应SIG的确认，PMC不批准相应软件的引入。当要批量引入多个软件时，可以求助PMC主持发起SIG间的临时评审会议，提升协调效率。 @@ -136,4 +136,4 @@ PMC讨论后，可以将不符合引入标准的软件记录到拒绝软件清 如果软件符合以上任何一条退出条件，PMC与相应SIG首先分析该软件在当前OpenHarmony社区中被依赖、被使用的情况。 1. 如果OpenHarmony中存在依赖关系，且短时间内不能解除，我们建议SIG新建分支代码仓，并主动进行社区维护动作。 -2. 如果OpenHarmony中不存在依赖关系，或者短时间内可以解除，则PMC通知发行团队将软件从OpenHarmony正式发行中移出，并在相应的release notes中标识。 \ No newline at end of file +2. 如果OpenHarmony中不存在依赖关系，或者短时间内可以解除，则PMC通知发行团队将软件从OpenHarmony正式发行中移出，并在相应的Release Notes中说明移除的原因及影响。 \ No newline at end of file -- Gitee From c0cd2121b73c4b85f3babfdb4a5f6cf92c535056 Mon Sep 17 00:00:00 2001 From: jalenchen0214 Date: Mon, 26 Apr 2021 13:07:52 +0800 Subject: [PATCH 12/13] Add license and copyright headers --- ...10\346\235\203\350\247\204\350\214\203.md" | 67 ++++++++++++++++--- 1 file changed, 56 insertions(+), 11 deletions(-) diff --git "a/zh-cn/contribute/\350\256\270\345\217\257\350\257\201\344\270\216\347\211\210\346\235\203\350\247\204\350\214\203.md" "b/zh-cn/contribute/\350\256\270\345\217\257\350\257\201\344\270\216\347\211\210\346\235\203\350\247\204\350\214\203.md" index 1092c88c2fc..15904653cb3 100644 --- "a/zh-cn/contribute/\350\256\270\345\217\257\350\257\201\344\270\216\347\211\210\346\235\203\350\247\204\350\214\203.md" +++ "b/zh-cn/contribute/\350\256\270\345\217\257\350\257\201\344\270\216\347\211\210\346\235\203\350\247\204\350\214\203.md" @@ -4,8 +4,7 @@ 本规范明确了OpenHarmony社区的代码贡献者、Committer、PMC成员如何处理Repo及源代码文件的许可与版权声明，包括如下几个部分 1. LICENSE文件 2. NOTICE文件 -3. 源文件许可头 -4. 源文件版权头 +3. 版权和许可头 ## 范围 本规范仅适用于OpenHarmony社区，不适用于将OpenHarmony项目应用于个人或企业以开发其它产品的场景，也不适用分发第三方开源软件的场景（该场景参见[第三方开源软件引入指导](第三方开源软件引入指导.md)）。 @@ -20,7 +19,7 @@ 2. 每个开源仓的许可证文件必须为纯文本格式，放置于代码仓的根目录，里面包含该许可的全文，并且以”LICENSE“命名，不用带".txt",".md"等后缀。 3. 如果开源仓的不同源码包含多种许可证，请将主许可证描述在以”LICENSE“命名的文件中，其它许可证请以”LICENSE-许可证类型-备注“命名并放置于仓的根目录或该许可证对应源码的根目录，同时在主许可证中描述各许可证文件位置及其适用的范围与场景。 4. 每个开源仓的许可证文件必须要涵盖该仓下所有文件，确保各许可证的涵盖范围描述准确、精简，并且不要包含不在本仓发布的其它源代码许可等不必要的信息，比如要单独下载的依赖软件的许可不要包含在仓和许可证信息中。 -5. 如果开源仓在发布时以二进制形式发布，请确保许可证文件位于其发布格式的常规位置，如对于".jar"格式的文件，许可证位于META-INF目录。 +5. 如果开源仓在发布时以二进制形式发布，请确保许可证文件位于其发布格式的常规位置，如发布文件夹或压缩包的顶层目录，对于".jar"格式的文件，许可证可位于META-INF目录。 ## NOTICE文件 1. 如分发的二进制文件中包含有第三方开源软件，请提供以“NOTICE”命名的文件，NOTICE文件以纯文本格式描述包含的所有第三方开源软件名称、软件版本、权利人声明、License信息，模板如下： @@ -44,15 +43,61 @@ Copyright notice: ... License: Apache License Version 2.0 ``` -2. NOTICE文件通常放置在发布文件夹的根目录，如对于".jar"格式的文件，NOTICE文件可放置于META-INF目录。 +2. NOTICE文件通常放置在发布文件夹或压缩包的顶层目录，对于".jar"格式的文件，许可证可位于META-INF目录。 -## 源文件许可头 +## 版权和许可头 +1. 开源仓中的文件原则上都应当包含合适的版权和许可头声明，除非是如下几种场景： +* 添加版权和许可声明会影响到该文件的功能，如JSON文件因不支持注释，可不添加版权和许可头。 +* 工具生成的文件且包含说明该文件是由工具自动生成的描述信息。 +* 简短的供用户阅读的说明文件，添加版权许可头会影响其可读性和，如README等。 -### 软件引入前检查 - -| 检查点 | 说明 | -| :----- | :----- | -| 归一化 | 1、检查该软件在OpenHarmony中是否已存在，原则上一款软件只在OpenHarmony中引入一次。 | -| 来源可靠 | 1、应该从开源软件官网获取或官网指定的代码托管地址获取。 | +2. 版权声明形式如下： +``` +Copyright (C) [第一次发布年份]-[当前版本发布年份] [版权所有者] + +许可证头，以具体的许可证内容为准，如： + +Apache License Version 2.0许可头： +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 许可头： +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. +``` +2. 版权头中的年份注意是作品对外发布的年份，如果是第一次发布则写发布年份即可，如果不是第一次发布，则写 "第一次发布年份-当前版本发布年份"。 +3. 版权所有者是法律实体，可以是个人或者公司，若代表公司贡献代码，请写公司法律实体。 +4. 许可头信息必须与该开源仓的许可证信息一致，如果某文件是双重许可证，则其许可头要清晰地说明各许可证的适用条件，并在文件许可头中包含各许可证定义的许可头描述。 -- Gitee From 78578138c279beac51e9ea43246c448bd85ad111 Mon Sep 17 00:00:00 2001 From: jalenchen0214 Date: Mon, 26 Apr 2021 14:44:55 +0800 Subject: [PATCH 13/13] Add license and copyright headers --- ...\270\216\347\211\210\346\235\203\350\247\204\350\214\203.md" | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git "a/zh-cn/contribute/\350\256\270\345\217\257\350\257\201\344\270\216\347\211\210\346\235\203\350\247\204\350\214\203.md" "b/zh-cn/contribute/\350\256\270\345\217\257\350\257\201\344\270\216\347\211\210\346\235\203\350\247\204\350\214\203.md" index 15904653cb3..f29fed0d736 100644 --- "a/zh-cn/contribute/\350\256\270\345\217\257\350\257\201\344\270\216\347\211\210\346\235\203\350\247\204\350\214\203.md" +++ "b/zh-cn/contribute/\350\256\270\345\217\257\350\257\201\344\270\216\347\211\210\346\235\203\350\247\204\350\214\203.md" @@ -52,7 +52,7 @@ License: Apache License Version 2.0 * 工具生成的文件且包含说明该文件是由工具自动生成的描述信息。 * 简短的供用户阅读的说明文件，添加版权许可头会影响其可读性和，如README等。 -2. 版权声明形式如下： +2. 版权和许可头声明形式如下： ``` Copyright (C) [第一次发布年份]-[当前版本发布年份] [版权所有者] -- Gitee