微认证 openEuler社区开源贡献实践

1. 开源与开源社区

Richard Matthew Stallman，1983年9月推出GNU项目，并发起自由软件运动(free software movement或free/opensource software movement，简称FSM或FOSSM)，推广用户有使用、复制、研究、修改和分发软件等权利。
同时开创了Copyleft的概念，它使用著作权法的原则来保护使用修改和分发自由软件的权利，并且是描述这些术语的自由软件许可证的主要作者。最为人所称道的是GPL(最广泛使用的自由软件协议)
1985年10月成立自由软件基金会(FreeSoftware Foundation FSF)，致力于推广自由软件。

开放源代码促进会(Open Source Initiative，缩写:OSl)于1998年2月创建，旨在推动开源软件发展，首次正式提出开源软件(open source software)的概念:

一种源代码可以任意获取的计算机软件，这种软件的著作权持有人在软件协议的规定之下保留一部分权利并允许用户学习、修改以及以任何目的间任何人分发该软件。开源协议通常符台开放源代码的定义的要求。

License是游戏规则，是开源软件许可证。在开源软件代码仓/包中，通常在COPYING，LICENSE,NOTICE，COPYRIGHT，AUTHOR，README说明其采用的开源许可证。

开源软件使用遵从义务:按照开源软件软件许可证规定开源软件使用者需要覆行的义务

**开源使用声明义务:**在产品发布时，随产品附上一份文档Open Source Software Note在该文档中写明产品所有使用的开源软件及其版权和许可证信息，并附上免责声明。

代码对外开源义务:按照开源许可证要求，将一定范围内的代码对外开源，开源范围视具体许可证的要求和使用方式而定。

修改声明义务:做出对修改的开源软件就修改时间，修改的代码以及修改过的文件做出具体的声明。

1. Apache License 2.0
2. BSD 3-Clause “New” or “Revised” license
3. BSD 2-Clause “Simplified” or “FreeBSD” license
4. GNU General Public License (GPL)
5. GNU Library or “Lesser” General Public License (LGPL)
6. MIT license
7. Mozilla Public License 2.0
8. Common Development and Distribution License
9. Eclipse Public License version 2.0
10. Mulan Permissive Software License v2(MulanPSL-2.0)
    https://opensource.org/licenses

GPL(Gnu Public License)
GPL许可证的核心含义是，允许任何人观看、修改，并散播程序软件里的原始程序码，条件是如果你要发布修改后的版本就要连源代码一起公布。
GPL V2许可说明
允许各种链接，但被链接的整个产品需要开源
允许修改，但被修改的部分及整个产品均需要开源通过pipes,sockets的命令行参数与GPL软件进行通讯，不会导致私有软件被传染仅原则性声明专利应免费许可，无详细规定
LGPL V2许可说明
允许各种链接，动态链接无开源义务，静态链接需要开放与之链接私有软件的.0文件与makefile允许修改再链接到私有软件，但是个性增加的功能实现不能依赖私有软件的数据功能允许不受限制的使用头文件中数值参数，数据结构布局，存取，小宏，内联参数，十行以内的模板仅原则性声明专利应免费许可，无详细规定

木兰宽松许可证(MulanPSL v2)
https://license.coscl.org.cn/MulanPsL2/index.htm!
2020年2月14日，“木兰宽松许可证”第2版(MulanPSLv2)经过严格审批，正式通过开源促进会(OSI)认证，被批准为国际类别开源许可证(International licenses)。意味着其正式具有国际通用性，可被任一国际开源基金会或开源社区支持采用，并为任一开源项目提供服务。
与众多开源协议相比，Mulan PSL在其它协议的基础上进行了以下优化:

• 许可证内容以中英文双语表述，中英文版本具有同等法律效力，方便更多的开源参与者阅读使用，简化了中国使用者进行法律解释时的复杂度。
• 明确授予用户永久性、全球性、免费的、非独占的、不可撤销的版权和专利许可，并针对目前专利联盟存在的互诉漏洞问题，明确规定禁止“贡献者”或“关联实体”直接或间接地(通过代理、专利被许可人或受让人)进行专利诉讼或其它维权行动，否则终止专利授权。
• 明确不提供对“贡献者”的商品名称、商标、服务标志等的商标许可，保护“贡献者”的切身利益。
• 木兰协议经技术专家和法律专家共同修订，在明确合同双方行为约束的前提下尽可能地精简条款、优化表述，降低产生法律纠纷的风险。

1991年芬兰大学生Linus Torvalds在GNU通用公共许可证下发布了最初是为自己创作的Linux操作系统内核，最初这只是他的一项兴趣爱好。随后，这项兴趣爱好便逐步演变成了拥有最大用户群的操作系统。
如今，它不仅是服务器上最常用的操作系统也广泛应用在嵌入式系统上，如手机、平板电脑、路由器、电视、电子游戏机等。只要遵循GNU 通用公共许可证(GPL)，任何个人和机构都可以自由地使用Linux的所有底层源代码，也可以自由地修改和再发布。
并逐渐发展成为世界上最为活跃的开源基金会Linux Foundation,吸引了来自世界各地的超过500家公司的超过235k开发者参与。

2. openEuler 社区概述

openEuler脱胎于EulerOS，EulerOS是华为公司自2010年起研发使用的服务器操作系统，Linux发行版之一，名字来源于著名数学家莱昂哈德·欧拉(Leonhard Euler);2019年9月，EulerOS正式开源，命名为openEuler2021年9月25日，openEuler全新发布，升级为统一的面向数字基础设施的开源操作系统，通过一套操作系统架构，南向支持多样性设备，北向覆盖全场景应用，横向对接鸿蒙通过能力共享实现生态互通。
2021年11月openEuler正式捐献至开放原子开源基金会

社区版本号按照交付年份月份命名。
长期支持版本：
发布周期为2年，提供4年社区支持。
社区创新版本：
每隔6个月发布一个社区创新版本，提供6个月社区支持。

SlG 是Special Interest Group 的缩写openEuler 社区的开发活动按照不同的SiG 来组织，以便于更好的管理和改善工作流程。SIG 组均是开放的，欢迎任何人来参与。
https://www.openeulerorg/zh/sig/sig-list/

3.参与openEuler社区贡献

角色	职责范围	要求
Contributor	项目的贡献者	签署CLA并产生社区贡献
Committer	审核其他成员的贡献	SIG的积极贡献者，经验丰富，愿意投入精力参与到审核工作
Maintainer	项目Owner	经验丰富，富有责任心、出色的技术能力和管理能力

组织	职责范围
技术委员会(Technical Committee)	负责社区技术决策和技术资源的协调。当期TC委员(含主席)经过扩选，为19人，任期一年。
安全委员会(Security Committee)	接收和响应openEuler产品安全问题报告、提供社区安全指导，开展安全治理等活动提升社区产品的安全性,为openEuler用户提供最安全的产品和开发环境
Release Management	社区协调各SIG的Maintainer、QA等各个团队，完成openEuler社区版本的发布工作。

4.openEuler软件包开发

Linux软件管理——源码编译

Tarball 文件:将软件的所有源码文件以 tar 打包，然后再压缩(通常是gzip)，所以 tarbal 文件一般的扩展名为 *.tar.gz 或是简写为 *tgz。不过近来由于 bzip2 与 xz 的压缩率较佳，因此它对应的后缀名为 .tar.bz2..tar.XZ 。
所以，tarball 是一个软件包，将它解压之后，里面的文件通常会有

• 源代码文件
• 检测程序(可能是 configure 或 config)
• 本软件的简易说明与安装说明(INSTALL或 README)
• 其中重要的是 INSTALL或 README 文件，通常只要能参考这两个文件，Tarball 软件的安装是很简单的

虽然使用源码进行软件编译可以具有定制化的设置，但是对于 Linuxdistribution 的发布商来说，则有软件管理不易的问题，毕竟不是每个人都会进行源码编译
如果能预先在相同的硬件与操作系统上编译好才发布的话，就可以让相同的distribution 具有完全一致的软件版本了，再加上简易的安装、移除、管理等机制的话，对于软件管理就容易多了
RPM 与 YUM/DNF 就是实现这样的目标

RPM

简单易用，以软件包为中心: RPM以软件包为单位进行操作，而不是操作单个文件。·软件包的可升级性: 一旦软件包使用rpm安装后，可以使用rpm对该软件包进行升级。·解析软件包依赖:RPM软件包中保存了所有该软件包需要的依赖。·查询功能:RPM软件管理器可以用来查询所有本机已通过RPM进行安装的软件包。验证: RPM可以对RPM软件包进行验证，确保软件包可信

name-version-release.architecture.rpm
kernel-smp-2.6.32.9-3.x86 64.rpmrootfiles-7.2-1.noarch.rpm

RPMBUild Spec:Preamble

Name	pkg的名称，需要与Spec文件名一致
Version	软件源代码的版本
Release	这个软件包被制作成rpm的次数，从1开始递增
Summary	软件包的简要描述
License	软件所使用的(开源)协议
URL	软件的项目网站，方便用户获得更多内容
Source0~xx	项目源代码压缩包的存储路径或URL，可以依次指定多个Source，如source0，source1,source2 …
Patch0~xx	构建过程中需要用到的patch文件，可依次指定多个patch，如patch1，patch2patch3 …
BuildArch	构建架构:x86 64，aarch64,power64等，若采用跨平台语言(e.g.纯python)则可以指定noarch
BuildRequires	软件构建过程中所需要的依赖
Requires	软件运行过程中所需要的依赖
ExcludeArch	软件不能运行的平台

RPMBuild Spec:Body

%description	软件包的简要描述
%prep	执行软件build之前的准备工作，如解压Source文件，打patch等操作
%build	Build软件包的执行步骤
%install	安装软件包的执行步骤
%check	检查步骤，主要用于测试
%files	软件包所产生的文件列表
%changelog	Spec的修改记录

基本格式:rpmbuild [options] [spec文档|tarball包(或者压缩包-以.gz或.xz或.bz2结尾的)|源码包]

options有下面的几种选择

1.-bp :只执行spec的%pre段(解开源码包并打补丁,即只做准备)

2.-bc :执行spec的%pre和%build 段(准备并编译)

3.-bi :执行spec中%pre,%build与%install(准备,编译并安装)

4.-bl :检查spec中的%file段(查看文件是否齐全)

5.-ba :建立源码与二进制包(常用):即编译后做成*.rpm和*.src.rpm

6.-bb :只建立二进制包(常用):即编译后做成*.rpm*

7.-bs :只建立源码包:即只做成.src.rpm