名词与生态导览¶
理解开源不能只记住“源代码公开”。本页是第一节的名词入口：先给出学习目标与内容地图，再提供一份覆盖生态、许可证与治理的核心术语表，最后用常见误解与自测题检验理解。
学习目标¶
学完本小节后，你应当能够：
- 用开源定义（OSD）的十条标准判断一份许可证是否属于开源许可证，并解释“源代码可见”“免费软件”“开源软件”三者的区别。
- 区分 permissive、copyleft 与 source-available 三类授权方式，说明它们对衍生作品与分发行为的不同要求。
- 针对一个具体项目，查到它的许可证标识符、治理结构（BDFL / PMC / TSC）与贡献协议（CLA / DCO），并说明这些信息如何影响你的参与方式。
本小节内容地图¶
| 页面 | 一句话内容 | 预计阅读时长 |
|---|---|---|
| 开源生态系统 | 社区、企业与基金会如何围绕项目协作，附生态角色分析工作表与许可证变更引发分叉的案例。 | 40 分钟 |
| 开源许可证详解 | 常见许可证的义务与兼容性、许可证选择方法，以及合规注意事项。 | 30 分钟 |
建议顺序：先读生态系统，建立“谁在参与、谁在治理”的整体认识；再读许可证一页，理解参与和分发的边界。
核心术语表¶
| 术语（英文，缩写） | 一句话定义 |
|---|---|
| 开源定义（The Open Source Definition，OSD） | OSI 提出的十条标准，用来判断一份许可证是否属于开源许可证。 |
| OSD 十条 | 自由再分发、提供源代码、允许衍生作品、保护作者源码完整性、不歧视个人或群体、不歧视使用领域、许可证随软件分发、许可证不特定于某个产品、不限制其他软件、技术中立。 |
| 自由及开源软件（Free and Open Source Software，FOSS） | 同时满足自由软件主张与开源定义要求的软件的统称。 |
| 自由/自由开源软件（Free/Libre and Open Source Software，FLOSS） | FOSS 的另一种写法，“Libre”用于强调自由（自由权）而非免费（价格）。 |
| 宽松许可证（permissive license） | 对衍生作品几乎不附加限制的许可证（如 MIT、Apache-2.0、BSD 系列），通常只要求保留版权与许可声明。 |
| 著佐权许可证（copyleft） | 要求衍生作品在分发时采用相同或兼容许可证的授权方式，如 GPL 系列、AGPL。 |
| 源码可见许可（source-available） | 源代码可以查看，但许可条款不满足 OSD（如限制商业使用或云服务运营），因此不属于开源许可证。 |
| 衍生作品（derivative work） | 基于原作品修改、扩展或与其结合后形成的新作品；分发衍生作品通常触发许可证义务。 |
| 分发（distribution） | 把软件副本提供给他人（发布、销售、通过网络提供等）的行为，多数许可证的义务由分发触发。 |
| SPDX 标识符（SPDX identifier） | SPDX 标准为每个许可证规定的机器可读短标识符，如 MIT、Apache-2.0、GPL-3.0-only。 |
| 上游与下游（upstream / downstream） | 上游指你依赖或贡献的原始项目，下游指基于它构建的发行版、产品或最终用户。 |
| 贡献者许可协议（Contributor License Agreement，CLA） | 贡献者与项目或其基金会签署的协议，用于明确贡献的版权与专利授权范围。 |
| 开发者原创证书（Developer Certificate of Origin，DCO） | 贡献者通过提交信息中的 Signed-off-by 声明自己有权提交该代码并同意证书条款；Linux 内核等项目采用这种方式。 |
| 仁慈独裁者（Benevolent Dictator For Life，BDFL） | 由创始人长期保留最终决策权的治理模式，早期 Python 与 Linux 内核的运作方式常被引为例证。 |
| 项目管理委员会（Project Management Committee，PMC） | Apache 等基金会项目中的治理机构，负责发布投票、提交者晋升与项目方向。 |
| 技术指导委员会（Technical Steering Committee，TSC） | 部分基金会或大型项目设立的技术决策机构，负责跨子项目的技术方向与争议裁决。 |
| 特别兴趣小组（Special Interest Group，SIG） | 围绕特定技术方向（如网络、存储、文档）组织的常设协作小组，Kubernetes 等社区广泛采用。 |
| 分叉（fork） | 复制项目代码后另起分支独立发展；许可证通常允许分叉，但分叉往往意味着治理分歧或上游停滞。 |
| 行为准则（Code of Conduct，CoC） | 社区对参与者行为的公开规范，包含适用范围、举报渠道与处理流程，多采用 Contributor Covenant。 |
| 软件物料清单（Software Bill of Materials，SBOM） | 列出软件全部组件、依赖及其版本与许可证的清单，用于供应链安全与合规审计。 |
| 双授权（dual licensing） | 同一软件同时提供两种许可（如 GPLv2 与商业许可），使用者可按自身场景选择其一。 |
| 专利报复条款（patent retaliation） | 部分许可证（如 Apache-2.0）中的条款：若使用者就该项目发起专利诉讼，其已获得的专利授权自动终止。 |
| 贡献者 / 提交者 / 维护者（contributor / committer / maintainer） | 依次对应提交补丁、拥有合并权限、负责项目方向与社区健康的角色，权限通常按持续贡献逐级获得。 |
| 上游优先（upstream first） | 把修复与改进先提交给上游项目，而不是长期维护本地补丁的做法。 |
常见误解¶
| 常见误解 | 实际情况 |
|---|---|
| 开源就是免费 | 开源指许可证授予的使用、修改与分发权利，与价格无关；开源软件可以合法收费，免费软件也不必然是开源软件。 |
| 开源就是没有版权 | 开源软件仍受版权保护。许可证是版权人授予的许可，违反许可证可能同时构成侵权与违约。 |
| 源代码可见就是开源 | 可见不等于可自由使用。BUSL、SSPL 等 source-available 许可限制商业使用或云服务运营，不满足 OSD。 |
| 开源就没有专利风险 | 许可证对专利的处理不同：Apache-2.0 含明示专利授权与报复条款，MIT 未明示；开源不等于专利免费或免责。 |
| 用了开源代码就必须把全部代码开源 | 义务取决于许可证类型、是否构成衍生作品以及是否发生分发；MIT 类许可证通常只需保留版权与许可声明。 |
| 只有写代码才算贡献 | 文档、翻译、测试、Issue 复现、社区支持、活动组织都属于贡献，且常常是项目更稀缺的投入。 |
| 许可证与学生无关 | 把代码推送到公开仓库即属于分发行为，同样需要遵守许可证、保留声明并注意依赖的许可证兼容性。 |
| 项目进了基金会就与商业无关 | 基金会提供中立治理，但不等于没有商业动机。判断中立性要看贡献者构成、赞助方与决策记录。 |
| 改写或重写代码后就不再受原许可证约束 | 是否属于衍生作品取决于代码来源与实质相似程度，改写本身不会自动脱离原许可证。 |
| 所有项目都要求签 CLA | 部分项目（尤其 Apache 系）要求 CLA，Linux 内核等则使用 DCO；具体以项目 CONTRIBUTING 为准。 |
自测题¶
1. 一个仓库公开可读，但许可证写明“仅允许个人非商业使用”。它是开源项目吗？
不是。OSD 第 6 条要求许可证不得歧视使用领域，禁止商业使用违反该条，因此它属于 source-available，而不是开源。
2. MIT 与 GPL 最核心的区别是什么？
区别在于对衍生作品的约束强度。MIT 属宽松许可证，只要求保留版权与许可声明；GPL 属 copyleft，要求分发的衍生作品采用相同或兼容的许可证，从而保证后续使用者享有同样的自由。
3. 为什么必须区分 GPL-2.0-only 与 GPL-2.0-or-later？
两者授予的权利范围不同：-only 表示仅适用该版本，-or-later 允许使用者按后续版本条款使用。这一区别直接影响与其它许可证的兼容性判断，因此 SPDX 标识符必须写准确。
4. 一个项目的贡献者几乎全部来自同一家公司，但它已捐赠给某基金会。判断它的中立性还需要看什么？
至少要看四项信息：治理文档规定的决策方式与席位分配、基金会项目页披露的赞助方与成员、提交与评审是否由单一公司主导、以及许可证是否稳定（是否发生过 source-available 化的变更）。基金会托管是必要条件，但不足以证明中立。
5. 你要给 Linux 内核提交补丁，需要签 CLA 吗？提交信息里要写什么？
不需要 CLA。Linux 内核采用 DCO，你需要在提交信息中加上 Signed-off-by: 姓名 <邮箱> 行，声明自己有权提交该代码并同意开发者原创证书的条款；具体格式要求见内核的 submitting-patches 文档。