1269 Terminology and overview
本文件界定了信息技术开源相应术语和定义，给出了开源综述。
本文件适用于各类组织和个人对开源领域的概念理解和信息交流，为开源标准提供了术语基础。
本文件没有规范性引用文件。
下列术语和定义适用于本文件。
贡献者许可协议 Contributor License Agreement；CLA
用于约束开源项目（3.2.5）和贡献者之间关系的一份法律文件。[反馈]
开源 open source
在软硬件开发、数据与信息共享中广泛采用的开放式协作模式，协作的产出物符合开源许可证（3.1.3）条款的要求。[反馈]
开源许可证 open source license
一种具有法律效力的格式合同，定义用户（3.4.22）自由使用、修改、复制或分发开源许可作品（3.2.19）的权利和义务。[反馈]
开源治理 open source governance
专注于开源（3.1.2）活动体系及其绩效和风险管理的治理规则，由领导关系、组织结构和过程组成。[反馈]
开源治理要素 open source governance element
实施开源治理（3.1.4）需关注的关键治理对象或过程。[反馈]
开源治理域 open source governance domain
治理要素按照特定层次、功能划分的治理范围。[反馈]
开源治理框架 open source governance framework
在开源组织（3.4.9）中定义角色、运作策略、决策结构和责任制的规则与惯例。[反馈]
开源治理能力 open source capability
完成任务或履行角色职责所需知识、技能、经验及其它相关资源的组合。[反馈]
开源项目准则 open source project guidelines
由开源项目（3.2.5）维护者制定的规则。[反馈]
注：通常包括开源贡献者如何提交代码、禁止对项目其他成员产生负面影响等。
开源许可义务 open source licensing obligation
许可方和被许可方明确或隐含地包含在开源许可证（3.1.3）中的责任。[反馈]
著作权 copyright
版权
著作权人对其作品依法享有的权利。[反馈]
[来源：GB/T 21374-2008,3.4.1]
准据法 lexcausae
经冲突规范指定援用来调整涉外民事法律关系双方当事人权利与义务的特定国家的法律。[反馈]
注：特定的许可证中约定了准据法条款，其主要用于许可证的解释和争议解决。
补丁 patch
<开源>项目修补文件。[反馈]
注：通常有两种展现形式，一种是patch文件，指将补丁文件合并到当前开源项目（3.2.5）的代码中。另一种是代码修改前后的对比文件包，该对比文件包可以让贡献者快速看到特定时刻修改的上下文。
变更请求 change request
请求将代码合并入原始代码仓库。[反馈]
注：在不同的代码托管平台（3.3.2）上名称可能不一致，包括拉取请求（pull request）、合并请求（merge request）等。
分叉 fork
基于最初开源项目（3.2.5）的新项目，通常在修改项目或彻底更改项目以达到个人使用目的时，被用户创建。[反馈]
贡献作品 contribution work
根据开源许可证（3.1.3）授权的计算机软件或其他作品（3.2.19）。[反馈]
开源项目 open source project
项目团队为实现特定目标，围绕开源对象研究、精心设计，通过共享合作的方式开发而来的项目，具有一定的管理机制。[反馈]
开源分支 open source branch
当前处于版本控制中的代码或代码段的副本，能够在不影响主要开源（3.1.2）源代码的情况下进行更改。[反馈]
开放数据 open data
任何人都可以免费使用、重新发布和分析而不会侵犯版权的数据。[反馈]
蓝图设计 blueprints
开源项目（3.2.5）功能开发的一种设计规范。[反馈]
注：用于描述功能变化存在的问题、用户用例、需要作出的变更、产生的影响等。
提交记录 commit
开源项目（3.2.5）完成的一次记录。[反馈]
注：包含本次提交目的，以及对代码和功能发生变化等信息。
提交说明 commit message
用于记录提交记录（3.2.5）提交的目的，以及对代码、功能发生的变化做出的说明。[反馈]
特性需求 feature request
用户（3.4.22）或开发者对于项目在功能、性能等方面的具体需求。[反馈]
项目缺陷 project defect
开源项目（3.2.5）中存在的影响或可能影响到计算机软件、系统正常运行的缺陷。[反馈]
衍生作品 derivative work
基于许可作品（3.2.19）二次创作的作品。[反馈]
元数据 metadata
定义和描述其他数据的数据。[反馈]
[来源：GB/T 18391.1-2009,3.2.16]
元数据元素 metadata element
元数据的基本单元。[反馈]
注1：元数据元素在元数据实体中是唯一的。
注2：与UML术语中的属性同义。
[来源：GB/T 19710-2005,4.6]
元数据实体 metadata entity
一组说明数据相同特性的元数据元素。[反馈]
注1：可以包含一个或一个以上元数据实体。
注2：与UML术语中的类同义。
[来源：GB/T 19710-2005,4.7]
元数据子集 metadata section
元数据的子集合，由相关的元数据实体和元素组成。[反馈]
注：与UML术语中的包同义。
[来源：GB/T 19710-2005,4.8]
议题 issue
特定开源项目（3.2.5）或者仓库下面对开源项目提出的需求、缺陷等事项的记录。[反馈]
作品 work
在文学、艺术和科学领域内创作的具有独创性并能以某种有形形式复制的智力成果。[反馈]
[来源：GB/T 21374-2008,3.4.4]
专利 patent
专利权所保护的技术方案或设计，包括发明、实用新型和外观设计。[反馈]
注：在特定情形下，专利也作为专利权的简称。
[来源：GB/T 21374-2008,3.2.1]
自述文件 readme
包含在每个开源项目（3.2.5）中的描述文件，含有开源项目目标、使用说明、参与说明、维护说明等开源项目所需的基本信息。[反馈]
版本管理工具 version control
辅助代码软件开发的代码管理工具，用以完成代码、文档修改的提交，并记录开源项目（3.2.5）的变化历史。[反馈]
代码托管平台 code hosting platform
提供代码托管服务的平台。[反馈]
注：代码托管平台通常还提供开源开发全生命周期所需的扩展服务。
分发媒体 delivery medium
提供指定位置下载权限，支持服务器下载和端到端传输的设备等。[反馈]
注：分发媒体包括但不限于网络传输、物理媒体和嵌入物理设备。
开源技术 open source technology
用于生产、获取，处理，存储，传播和使用开源（3.1.2）软件或其他数字产品等资源的方式。[反馈]
开源软件生态系统 open source software ecosystem
行为者（企业和个人）、软件应用程序、驱动和组件构成的统一整体，开源（3.1.2）软件及其相关对象在一定时期处于平衡状态。[反馈]
开源上游 open source upstream
可被分叉（3.2.3）而形成分支的开源项目（3.2.5）或其组织。[反馈]
成员 member
<开源>在特定开源项目（3.2.5）上的积极贡献者。[反馈]
注：通过积极贡献提交记录、议题等参与开源项目（3.2.5）贡献，受到项目团队核心成员认可的贡献者。
代码级贡献 code contribution
贡献者在开源社区（3.4.10）中进行的所有与代码直接相关的贡献行为。[反馈]
注：代码级贡献包括但不限于包括代码提交、代码合并和代码审阅。
代码审查 code review
在软件开发过程中，为确保代码质量对源代码进行的系统性检查。[反馈]
贡献 contribution
<开源>进行某种有助于开源项目（3.2.5）发展的行为。[反馈]
注：贡献包括但不限于代码提交、使用开源（3.1.2）、报告安全缺陷/漏洞、翻译、撰写文档、活动组织，宣传推广等。
贡献者 contributor
提供贡献从而促进开源项目（3.2.5）发展的任何个人或法人实体。[反馈]
活跃度贡献 activity contribution
在开源社区（3.4.10）中提高开源（3.1.2）影响力、扩大传播范围等相关的贡献行为。[反馈]
注：活跃度贡献包括但不限于在开源社区中发帖、评论、分享和组织活动。
核心审查者 core reviewer
开源项目（3.2.5）上的核心贡献者，拥有对开源项目上所提交内容接受或拒绝的权力，了解开源项目架构、目标和发展策略，能够对开源项目上提交的patch、commit、issue/bug等内容进行审核，掌握该开源项目核心技术的贡献者。[反馈]
注：部分社区也称核心贡献者为approver。
技术委员会 Technical Committee；TC
<开源>开源社区（3.4.10）技术发展方向的决策者。[反馈]
注：技术委员会负责包括开源项目开放性、透明性、通用性、质量和开源项目集成情况的决策，针对受影响的开源项目（3.2.5）提供技术决策和监督等。
开源组织 open source organization
具有职责、权限和关系以管理开源项目（3.2.5）、帮助和推动实现其目标功能、推动开源（3.1.2）文化、促进开源协作的群体。[反馈]
注：组织的概念包括但不限于单一交易者、公司、企业、机构、合伙企业、慈善机构和研究机构，可以为其一部分或组合（无论是否成立），无论是公共的还是私人的。
开源社区 open source community
开源共同体
一种具有共同目标、愿景、与价值观的开源组织（3.4.9）。[反馈]
开源社区干系人 open source community stakeholder
与开源社区（3.4.10）构成共同价值关系的个人或组织。[反馈]
开源基金会 open source foundation
管理和执行可供成员和公众使用的非差异化开源项目（3.2.5）的非营利组织。[反馈]
开源治理主体 open source governance body
评估、指导、监督组织开源治理（3.1.4）的人或团体。[反馈]
开源社区运营 open source community operation
从开源社区（3.4.10）视角出发，为实现社区的价值而进行的一系列活动。[反馈]
开源基金会董事 open source foundation director
依据开源基金会（3.4.12）章程，通过直接任命和公开选举的方式产生的领导成员。[反馈]
注：用于推动开源社区（3.4.10）及开源项目（3.2.5）的发展，协助开源项目建设开源生态。
开源基金会董事会 open source foundation directorate
由开源基金会董事（3.4.15）组成的委员会，能够协助开源基金会（3.4.12）推动开源项目（3.2.5）的开发、发行和应用，为开发者、用户（3.4.22）以及整个生态的建设提供目标和方向，负责管理基金会战略、财务及人员。[反馈]
任务级贡献 issue contribution
贡献者在开源社区（3.4.10）中进行的所有与开发任务相关的贡献行为。[反馈]
注：任务级贡献包括但不限于软件缺陷和特性需求。
社区影响力 community influence
开源团队或个人在开源项目（3.2.5）贡献过程中获得的地位及声誉。[反馈]
团队健康度 team health
开源项目（3.2.5）开发与维护团队的规模、稳定性、合理性等。[反馈]
项目级贡献 project contribution
贡献者在开源社区（3.4.10）中进行的所有与开源项目（3.2.5）相关的贡献行为。[反馈]
注：项目级贡献包括但不限于发起开源项目（3.2.5）、参与开源项目和开源项目应用传播。
项目管理者 project leader
<开源>特定开源项目（3.2.5）的负责人。[反馈]
注1：项目管理者对开源项目架构、目标和发展规划具有清晰的认知，拥有提名核心审查者及其对开源项目内容审核的权力。
注2：也称项目管理者为maintainer。
用户 user
<开源>行使开源许可证（3.1.3）所授予权限的个人或法律实体。[反馈]
注：在许可证实例中一般称为“您”及“接收者”。
影响力贡献 influence contribution
贡献者在开源社区（3.4.10）中通过自身能力而间接提升开源社区影响力的相关贡献行为。[反馈]
开源是参与主体在基础设施之上针对对象在遵循一定规则下的一种开放式协作模式，其目的是为了能产生公开复用的产出物。使用者通过许可证的方式，在遵守许可限制的条件下，可自由获取源代码等，并可使用、复制、修改和再发布。[反馈]
开源主要包含：
- 开源规则。开源规则是维持开源相关活动运转的基石。开源规则包括但不限于开源许可证、开源硬件设计规范、开源知识产权、开源治理框架和应用评价体系等。
- 开源对象（内容/目标）。开源对象是开源群智化创新的内核。开源对象包括但不限于软件、硬件、数据等。
- 开源基础设施。开源基础设施是开展开源技术开发交流的载体，是指以服务开源项目、开源社区、开源生态为目标提供的软、硬件类平台、工具和服务。开源基础设施包括但不限于开源托管平台、网站、论坛、邮件列表、即时通讯工具、会议工具等。
- 参与主体。开源参与主体是推进开源不断向前发展的源动力。开源参与主体包括但不限于：
- 贡献者：参与开源对象贡献的个人和企业，参与方式包括但不限于：代码提交、使用开源、报告安全缺陷/漏洞、翻译、撰写文档等。
- 使用者：最终使用开源对象的用户，也是特殊的贡献者。
- 运营者：参与和开源对象相关的组织或管理事宜的组织和个人。包含但不限于活动组织，宣传推广等。
- 合作者：参与对开源对象进行法律支持、监管、商业合作和生态建设等的组织和个人。
[1] GB/T 5271.14—2008 信息技术词汇
[2] GB/T 18391.1-2009 信息技术 元数据注册系统(MDR) 第1部分：框架
[3] GB/T 19710-2005 地理信息 元数据
[4] GB/T 21374-2008 知识产权文献与信息 基本词汇