Thank you for your proposal, Xinwei. I cc’d community and infra groups in case they may be interested in this topic. Please find my comments inline. One cent. Fred 李永乐 From: Xiehong (Cynthia) via Tc [mailto:tc@openeuler.org] Sent: Saturday, January 11, 2020 17:27 To: Huxinwei <huxinwei@huawei.com> Cc: tc@openeuler.org Subject: [Tc] 答复: [discu] openEuler软件包接纳策略讨论 /approve ☺ 发件人: Huxinwei via Tc [mailto:tc@openeuler.org] 发送时间: 2020年1月11日 15:00 收件人: tc@openeuler.org<mailto:tc@openeuler.org> 主题: [Tc] [discu] openEuler软件包接纳策略讨论 Hi all: 起草了openEuler软件包策略，请大家在大纲和具体内容上发表意见。 openEuler软件包策略手册 版本 · 2020-01-11 Initial Draft by Xinwei Hu 关于本文档 范围 本文档定义了openEuler软件包所需要遵从的策略要求。所以提交到openEuler的软件包需要满足本手册中定义的技术要求。 作者与改进流程 本文档由openEuler技术委员会 （Technical Committee）起草和维护。 本文档的最新版本总可以在 XXXXXX [URL] 上找到。 所有对本文档的修改意见可以通过邮件列表 XXXXX 反馈和讨论。 [Fred] /s/XXXXX/tc@openeuler.org [Fred] 是否需要分两类，ISO内的，以及extra的软件包，分别有不同的要求，比如质量要求不完全一样。 目标 openEuler是一个致力于创建开放操作系统的合作组织。我们希望openEuler l 尽可能集成多的软件组件 l 鼓励所有人使用openEuler，并可以在openEuler上开发软件 l 使能任何人，在不违反license，进出口管制或其他相关法律的前提下，可以容易的制作安装介质 openEuler遵从 Open Source Definition<https://opensource.org/docs/osd> ，满足这一定义的软件，被openEuler社区认同为开源软件。 [Fred] 感觉这里是想说，openEuler只接纳开源软件的意思，开源软件需要符合OSD。如果是这个意思，可以直接说明。 openEuler接纳要求 版权要求 每一个软件包需要license，这个license需要是openEuler社区已知并认同的开源或者商用license。如果是全新的license，需要由openEuler的法务人员审视并接纳成为社区认同的 license。 [Fred] 是否需要列出已经认可的License清单？商用License是否不应该包含？ 软件包管理要求 所有被openEuler接纳的软件包，需要满足openEuler的包管理系统技术要求。 基础软件要求 基础软件是构成openEuler的核心开源软件，也被认为是 openEuler的一部分。基础软件是自包含的。 openEuler社区中的任何人都可以共享、修改或者再分发基础软件。为此，技术上要求： · 基础软件的构建与运行不允许依赖非基础软件 · 必须满足openEuler社区的质量要求。因为质量问题而无法被支持的软件不允许成为基础软件。 [Fred] 建议质量要求也需要有个说明。 共享软件要求 共享软件也必须是开源软件。但共享软件的构建或者运行可以依赖openEuler基础软件之外的软件组件。为此，技术上要求： · 必须满足openEuler社区的质量要求。因为质量问题而无法被支持的软件不允许成为基础软件。 受限软件要求 所有非开源软件，或者有其他法律合规性限制的软件，被看做受限软件。技术上要求： · 必须满足openEuler社区的质量要求。因为质量问题而无法被支持的软件不允许成为基础软件。 [Fred] 不推荐非开源软件被openEuler社区直接接纳。这类软件可以在自己的供应商处或者第三方平台提供可适配openEuler的软件包。 参考 ISO openEuler社区会定期发布参考ISO，来验证安装介质的制作流程。原则上，openEuler ISO会包含所有基础软件包。共享软件与受限软件，在openEuler获得重分发授权，并且和XXX不冲突的前提下，也会作为独立的参考ISO。

Hi Guodong, Thank you for your information. Have a good day. Fred 李永乐 From: Guodong Xu [mailto:guodong.xu@linaro.org] Sent: Tuesday, January 14, 2020 08:56 To: Liyongle (Fred) <liyongle@huawei.com> Cc: tc@openeuler.org; community@openeuler.org; infra@openeuler.org Subject: Re: [Community] Re: [discu] openEuler软件包接纳策略讨论 On Mon, Jan 13, 2020 at 9:39 PM Liyongle (Fred) via Community <community@openeuler.org<mailto:community@openeuler.org>> wrote: Thank you for your proposal, Xinwei. I cc’d community and infra groups in case they may be interested in this topic. Please find my comments inline. One cent. Fred 李永乐 From: Xiehong (Cynthia) via Tc [mailto:tc@openeuler.org<mailto:tc@openeuler.org>] Sent: Saturday, January 11, 2020 17:27 To: Huxinwei <huxinwei@huawei.com<mailto:huxinwei@huawei.com>> Cc: tc@openeuler.org<mailto:tc@openeuler.org> Subject: [Tc] 答复: [discu] openEuler软件包接纳策略讨论 /approve ☺ 发件人: Huxinwei via Tc [mailto:tc@openeuler.org] 发送时间: 2020年1月11日 15:00 收件人: tc@openeuler.org<mailto:tc@openeuler.org> 主题: [Tc] [discu] openEuler软件包接纳策略讨论 Hi all: 起草了openEuler软件包策略，请大家在大纲和具体内容上发表意见。 openEuler软件包策略手册 版本 • 2020-01-11 Initial Draft by Xinwei Hu 关于本文档 范围 本文档定义了openEuler软件包所需要遵从的策略要求。所以提交到openEuler的软件包需要满足本手册中定义的技术要求。 作者与改进流程 本文档由openEuler技术委员会 （Technical Committee）起草和维护。 本文档的最新版本总可以在 XXXXXX [URL] 上找到。 所有对本文档的修改意见可以通过邮件列表 XXXXX 反馈和讨论。 [Fred] /s/XXXXX/tc@openeuler.org<mailto:tc@openeuler.org> [Fred] 是否需要分两类，ISO内的，以及extra的软件包，分别有不同的要求，比如质量要求不完全一样。 目标 openEuler是一个致力于创建开放操作系统的合作组织。我们希望openEuler • 尽可能集成多的软件组件 • 鼓励所有人使用openEuler，并可以在openEuler上开发软件 • 使能任何人，在不违反license，进出口管制或其他相关法律的前提下，可以容易的制作安装介质 openEuler遵从 Open Source Definition<https://opensource.org/docs/osd> ，满足这一定义的软件，被openEuler社区认同为开源软件。 [Fred] 感觉这里是想说，openEuler只接纳开源软件的意思，开源软件需要符合OSD。如果是这个意思，可以直接说明。 openEuler接纳要求 版权要求 每一个软件包需要license，这个license需要是openEuler社区已知并认同的开源或者商用license。如果是全新的license，需要由openEuler的法务人员审视并接纳成为社区认同的 license。 [Fred] 是否需要列出已经认可的License清单？商用License是否不应该包含？ Here is a list of licenses. FYR. https://opensource.org/licenses 软件包管理要求 所有被openEuler接纳的软件包，需要满足openEuler的包管理系统技术要求。 基础软件要求 基础软件是构成openEuler的核心开源软件，也被认为是 openEuler的一部分。基础软件是自包含的。 openEuler社区中的任何人都可以共享、修改或者再分发基础软件。为此，技术上要求： • 基础软件的构建与运行不允许依赖非基础软件 • 必须满足openEuler社区的质量要求。因为质量问题而无法被支持的软件不允许成为基础软件。 [Fred] 建议质量要求也需要有个说明。 共享软件要求 共享软件也必须是开源软件。但共享软件的构建或者运行可以依赖openEuler基础软件之外的软件组件。为此，技术上要求： • 必须满足openEuler社区的质量要求。因为质量问题而无法被支持的软件不允许成为基础软件。 受限软件要求 所有非开源软件，或者有其他法律合规性限制的软件，被看做受限软件。技术上要求： • 必须满足openEuler社区的质量要求。因为质量问题而无法被支持的软件不允许成为基础软件。 [Fred] 不推荐非开源软件被openEuler社区直接接纳。这类软件可以在自己的供应商处或者第三方平台提供可适配openEuler的软件包。 参考 ISO openEuler社区会定期发布参考ISO，来验证安装介质的制作流程。原则上，openEuler ISO会包含所有基础软件包。共享软件与受限软件，在openEuler获得重分发授权，并且和XXX不冲突的前提下，也会作为独立的参考ISO。 _______________________________________________ Community mailing list -- community@openeuler.org<mailto:community@openeuler.org> To unsubscribe send an email to community-leave@openeuler.org<mailto:community-leave@openeuler.org>

# openEuler 软件引入策略原则 ## 版本 - 2020-01-11 Initial Draft by Xinwei Hu - 2020-01-21 Integrate input from Liang Chengye, Wang Lingzhuo, Guodong Xu and Yang Li ## 关于本文档 ### 范围 本文档定义了openEuler软件包所需要遵从的策略要求。所以提交到openEuler的软件包需要满足本手册中定义的技术要求。 ### 作者与改进流程 本文档由openEuler技术委员会 （Technical Committee）主导起草和维护。 本文档的最新版本总可以在 XXXXXX [URL] 上找到。 所有对本文档的修改意见可以通过邮件列表 XXXXX 反馈和讨论。 ## 目标 openEuler是一个致力于创建开放操作系统的合作组织。我们希望openEuler - 尽可能集成多的软件组件 - 鼓励所有人使用openEuler，并可以在openEuler上开发软件 - 使能任何人，在不违反license，进出口管制或其他相关法律的前提下，可以容易的制作安装介质 openEuler遵从 [Open Source Definition](https://opensource.org/docs/osd) ，满足这一定义的软件，被openEuler社区认同为开源软件。 提供适度，高质量的开源软件是openEuler主要目标之一。openEuler努力为其所提供的开源软件在生命周期内提供高质量的支持服务。开源软件自由众多，质量不一。本着提供高质量开源软件的宗旨，特别拟定本规则指南。本规则的中**必须**，**必须不能**，**应该**，**应该不能**的含义参考rfc2119。 ## 规则的制订过程 任何对于本规则的增加，修改，删除都**必须**被追踪。 目前[https://gitee.com/openeuler/community/issues](https://gitee.com/openeuler/community/issues) 是这个追踪系统。 最终规则的经过充分的讨论后，由技术委员会定稿。 ## 选型规则定义 选型规则约束一个软件(项目)是否可以被引入到src-openeuler.yaml文件中，并在src-openeuler中作为一个目录维护。 ## 选型过程定义 一个软件的选型指的是一个软件(项目)从用户库被申请引入到官方库，依照本文件描述的规则讨论，进而满足规则要求，最终引入官方库的过程。 升级一个官方库中已存在的软件包的规则不在本规则的覆盖范围内。 整个引入的过程都**必须**可被追踪。目前 [https://gitee.com/src-openeuler/openEuler-repos/issues](https://gitee.com/src-openeuler/openEuler-repos/issues) 是这个追踪系统。 ## 选型的两个基本前置条件 凡是需要引入到openEuler的开源软件(项目)，**必须**有唯一的ID。这个ID是openEuler中管理开源项目的元数据库中的ID。 第一步 在元数据库中创建一个item。 第二步 以元数据库的ID做为标识来讨论的软件(项目)。 ## openEuler软件接纳原则 基于证据的可信贯穿于选型的整个过程。在一个软件包被引入的每一步都需要有记录，这些记录被作为可信过程的证据。 * 一次**必须**只能引入一个软件。 * 软件**应该**有明确的引入理由。 * 软件**应该**是开源软件，开源软件的定义参考[https://opensource.org/osd.html](https://opensource.org/osd.html) 。如果非开源软件，经由technical committ讨论后决定。 * 软件**应该**是源码包，二进制**不应该**被引入。如果需要引入二进制，经由technical committ讨论后决定。 * 原则上，该软件**应该**在openEuler上可以被正确构建。当软件有尚未被引入的依赖关系，或者软件的运行或者构建依赖一个绝不可能引入openEuler的组件，此等例外，经由technical committ讨论后决定。 * 原则上，openEuler不引入**rootkit**或者其他类似存在可信问题的软件。 * 存在于**黑名单**的软件**必须不能**引入。 * 每一个软件的引入决定，都作为案例，作为后续类似软件引入决策的参考。Technical Committ对软件引入原则的一致性负责。 ## 黑名单 Technical Committ讨论后，可以将被拒绝引入的软件被记录到一个软件黑名单，作为证据，作为证据减少重复劳动。 https://gitee.com/src-openeuler/openEuler-repos/software-blacklist.md ## 元数据的存储 鉴于目前openEuler采用RPM作为包管理系统，同时考虑到对元数据的需求，本规则定义的元数据需要考虑兼容RPM SPEC的前提下作为单独的一份文件存储于RPM SRC包中。 该独立的文件名字是meta.json，并采用json的数据格式。 ## 元数据库中的 Identification ### 目的 唯一识别该软件 ### 强制性 * **必须** ### 作用 引入的软件**必须**有唯一的ID。ID可以用来描述不同软件包之间的关系，所以ID的唯一性很重要。 ### 格式 #### RPM SPEC ```SPEC Name: openssl ``` RPM 包的名字，在整个REPO具有唯一性，可以作为ID。 #### Json ORG style org id, 代表该软件包项目的组织ID，类似namespace的作用。 art id, 代表该项目的ID json的表达格式实例 ```json "id": { "org": "org.openssl", "art": "openssl" } ``` 推荐，如果同时提供RPM SPEC的方式和Json ORG style两种，**应该**考虑名字的一致性。 ## 元数据库中的 主页地址 ### 目的 一个开源项目的真正的实质。它和ID在一起作为元数据库中跟实际项目的binding。 不同的ID的项目**应该不能**一样。一个项目只能由一个官方主页。 ### 强制性 * **必须** ### 格式 #### RPM SPEC ```SPEC URL: https://www.openssl.org/ ``` #### JSON style 软件包的 主页地址，任何一个开源软件都需要有一个主页，如果没有正式的官方主页，那可以认为软件的发布页为主页，比如github的项目主页。 json的表达格式的实例 ```json "official": "https://www.openssl.org/" ``` ## 元数据库中的 REPO地址 ### 目的 保存该开源项目的repo地址。可以有多个。 ### 强制性 * **可选** ### 格式 #### JSON style ```JSON style "repo": [ "git://git.openssl.org/openssl.git", "https://github.com/openssl/openssl.git" ] ``` ## 元数据库中的 LANG ### 目的 说明该项目使用的主要编程语言。 ### 强制性 * **可选** ### 格式 #### JSON style ```JSON style "lang": [ "c" ] ``` ## 元数据库中的 TAG ### 目的 说明该项目主要的应用领域的其它属性。 ### 强制性 * **可选** ### 格式 #### JSON style ```JSON style "tag": [ "protocol", "tls" ] ``` ## 元数据库中的 LISENCE ### 目的 说明该项目用来描述该项目使用的LISENCE，LISENCE需要使用SPDX定义的ID。 ### 强制性 * **必须** ### 格式 #### JSON style 为兼容SPDX，使用来自SPDX标准的命名。 ```JSON style "lisence": [ "SPDX-License-Identifier: OpenSSL" ] ``` ## 元数据库中的 项目关系 ### 目的 说明该项目用来描述该项目之间关系。这个关系可用分析项目直接的关系，其中requires的关系可以直接推导出运行时的依赖关系。 ### 强制性 * **可选** ### 格式 #### RPM SPEC ```SPEC Requires: coreutils perl ca-certificates crypto-policies ``` #### JSON style 为兼容SPDX，使用来自SPDX标准的命名。 ```JSON style "related": { "HAS_PREREQUISITE": ["org.gnu.coreutils", "org.perl.perl", "ca-certificates", "crypto-policies"] } ``` #### 软件(项目)关系的定义列表见附件 ## 选型过程 request 每次选型如果的请求都应该被记录，都应该可追溯。 ```text https://gitee.com/organizations/src-openeuler/issues ``` ### requester 提出该次选型入库申请的申请人。该申请人**应该**是被申请包的作者。 ### reason 申请的理由，描述这个软件(项目)为什么应该存在于官方的repo中。 ### result 描述这次选型入库的申请是否通过。 #### 取值 * accepted **应该**有reason。 * rejected **应该**有reason。 ## 附带软件的选型入库 引入一个软件有可能附带引入其它软件(项目)，根据一次引入一个软件的原则，分别为每个软件提交请求，并且附带软件的引入原因需要体现被附带引入这个情况。 ## 软件是否存在于公开的语言库 **TODO** 比如 Marven，PIP，Python，NPM，Ruby等等， 如果有**应该**提供在所在语言库的链接。 ## 项目关系列表 为兼容SPDX，使用来自SPDX标准的命名。 | relation | description | | -------- | ------------| | HAS_PREREQUISITE | 该软件需要其它的软件支持其运行，所有的被依赖软件都**应该**被列举。 相当于 RPM SPEC 中 Requires | | PREREQUISITE_FOR | 该软件支撑了其它软件的运行，不能被完全列举。 | | HEEDS_BUILD_TOOL | 该软件构建时需要那些软件的支持。相当于 RPM SPEC 中 BuildRequires | From: 杨丽 via Tc [mailto:tc@openeuler.org] Sent: Tuesday, January 14, 2020 11:51 AM To: Liyongle (Fred) <liyongle@huawei.com> Cc: guodong.xu@linaro.org; tc@openeuler.org; community@openeuler.org; infra@openeuler.org Subject: [Tc] 回复：[Infra] Re: [Community] Re: [discu] openEuler软件包接纳策略讨论 非开源软件原则上说，是不应该进入开源社区的。除非已经完全不存在法律风险。 否则，用开源软件的人也会受到法律问题的影响。 请各位参考fedora社区对软件包进入社区的要求和申请，里面有一些处理方式我认为是可以借鉴的。 https://docs.fedoraproject.org/en-US/packaging-guidelines/what-can-be-packag... [图像已被发件人删除。] 杨丽 工程师 华为技术有限公司 rainbow1981@163.com 签名由 网易邮箱大师<https://mail.163.com/dashi/dlpro.html?from=mail81> 定制 在2020年1月14日 08:57，Liyongle (Fred) via Infra<infra@openeuler.org><mailto:infra@openeuler.org> 写道： Hi Guodong, Thank you for your information. Have a good day. Fred 李永乐 From: Guodong Xu [mailto:guodong.xu@linaro.org<mailto:guodong.xu@linaro.org>] Sent: Tuesday, January 14, 2020 08:56 To: Liyongle (Fred) <liyongle@huawei.com<mailto:liyongle@huawei.com>> Cc: tc@openeuler.org<mailto:tc@openeuler.org>; community@openeuler.org<mailto:community@openeuler.org>; infra@openeuler.org<mailto:infra@openeuler.org> Subject: Re: [Community] Re: [discu] openEuler软件包接纳策略讨论 On Mon, Jan 13, 2020 at 9:39 PM Liyongle (Fred) via Community <community@openeuler.org<mailto:community@openeuler.org>> wrote: Thank you for your proposal, Xinwei. I cc’d community and infra groups in case they may be interested in this topic. Please find my comments inline. One cent. Fred 李永乐 From: Xiehong (Cynthia) via Tc [mailto:tc@openeuler.org<mailto:tc@openeuler.org>] Sent: Saturday, January 11, 2020 17:27 To: Huxinwei <huxinwei@huawei.com<mailto:huxinwei@huawei.com>> Cc: tc@openeuler.org<mailto:tc@openeuler.org> Subject: [Tc] 答复: [discu] openEuler软件包接纳策略讨论 /approve ☺ 发件人: Huxinwei via Tc [mailto:tc@openeuler.org] 发送时间: 2020年1月11日 15:00 收件人: tc@openeuler.org<mailto:tc@openeuler.org> 主题: [Tc] [discu] openEuler软件包接纳策略讨论 Hi all: 起草了openEuler软件包策略，请大家在大纲和具体内容上发表意见。 openEuler软件包策略手册 版本 • 2020-01-11 Initial Draft by Xinwei Hu 关于本文档 范围 本文档定义了openEuler软件包所需要遵从的策略要求。所以提交到openEuler的软件包需要满足本手册中定义的技术要求。 作者与改进流程 本文档由openEuler技术委员会 （Technical Committee）起草和维护。 本文档的最新版本总可以在 XXXXXX [URL] 上找到。 所有对本文档的修改意见可以通过邮件列表 XXXXX 反馈和讨论。 [Fred] /s/XXXXX/tc@openeuler.org<mailto:tc@openeuler.org> [Fred] 是否需要分两类，ISO内的，以及extra的软件包，分别有不同的要求，比如质量要求不完全一样。 目标 openEuler是一个致力于创建开放操作系统的合作组织。我们希望openEuler • 尽可能集成多的软件组件 • 鼓励所有人使用openEuler，并可以在openEuler上开发软件 • 使能任何人，在不违反license，进出口管制或其他相关法律的前提下，可以容易的制作安装介质 openEuler遵从 Open Source Definition<https://opensource.org/docs/osd> ，满足这一定义的软件，被openEuler社区认同为开源软件。 [Fred] 感觉这里是想说，openEuler只接纳开源软件的意思，开源软件需要符合OSD。如果是这个意思，可以直接说明。 openEuler接纳要求 版权要求 每一个软件包需要license，这个license需要是openEuler社区已知并认同的开源或者商用license。如果是全新的license，需要由openEuler的法务人员审视并接纳成为社区认同的 license。 [Fred] 是否需要列出已经认可的License清单？商用License是否不应该包含？ Here is a list of licenses. FYR. https://opensource.org/licenses 软件包管理要求 所有被openEuler接纳的软件包，需要满足openEuler的包管理系统技术要求。 基础软件要求 基础软件是构成openEuler的核心开源软件，也被认为是 openEuler的一部分。基础软件是自包含的。 openEuler社区中的任何人都可以共享、修改或者再分发基础软件。为此，技术上要求： • 基础软件的构建与运行不允许依赖非基础软件 • 必须满足openEuler社区的质量要求。因为质量问题而无法被支持的软件不允许成为基础软件。 [Fred] 建议质量要求也需要有个说明。 共享软件要求 共享软件也必须是开源软件。但共享软件的构建或者运行可以依赖openEuler基础软件之外的软件组件。为此，技术上要求： • 必须满足openEuler社区的质量要求。因为质量问题而无法被支持的软件不允许成为基础软件。 受限软件要求 所有非开源软件，或者有其他法律合规性限制的软件，被看做受限软件。技术上要求： • 必须满足openEuler社区的质量要求。因为质量问题而无法被支持的软件不允许成为基础软件。 [Fred] 不推荐非开源软件被openEuler社区直接接纳。这类软件可以在自己的供应商处或者第三方平台提供可适配openEuler的软件包。 参考 ISO openEuler社区会定期发布参考ISO，来验证安装介质的制作流程。原则上，openEuler ISO会包含所有基础软件包。共享软件与受限软件，在openEuler获得重分发授权，并且和XXX不冲突的前提下，也会作为独立的参考ISO。 _______________________________________________ Community mailing list -- community@openeuler.org<mailto:community@openeuler.org> To unsubscribe send an email to community-leave@openeuler.org<mailto:community-leave@openeuler.org>