一、基础概念篇 (Core Concepts)
| 名称 (Term) | 中文名称 | 社区/领域专业术语 | 描述 (Description) |
|---|---|---|---|
| Copyleft | 著佐权 | 传染性、病毒式许可、左权、强保护 | 与Copyright（版权/著作权）相对。要求修改后的衍生作品必须使用相同的许可证发布，确保代码及其衍生品保持开源。根据"传染"强度分为强/弱Copyleft。 |
| Permissive | 宽松式许可 | 商业友好、零义务、允许闭源、公共域友好 | 允许用户任意使用、修改、闭源分发，通常只需保留版权声明和免责条款。是商业化集成首选（如MIT, BSD, Apache-2.0）。 |
| Derivative Work | 衍生作品 | 二开、修改版、魔改、衍生代码 | 基于原软件修改或组合后形成的新作品。这是判断是否触发Copyleft义务的最关键法律界定，定义常存灰色地带。 |
| Distribution / Conveyance | 分发/传播 | 交付、发布、售卖、传输 | 触发许可证义务的核心动作。将软件副本（源码或二进制）交给第三方。GPLv3用"Conveyance"更精确地定义此行为。 |
| SaaS Loophole | SaaS漏洞 | 云服务漏洞、ASP漏洞、网络服务漏洞 | 指通过网络提供服务而不分发软件副本，从而绕过GPL等协议开源要求的漏洞。AGPL专门为此设计。 |
| Dual Licensing | 双重许可 | 双轨制、商业/开源双选、开源变现 | 作者同时提供开源协议（如GPL）和商业协议。用户可选择：遵守GPL开源衍生作品，或购买商业许可以闭源商用。 |
| Public Domain | 公共领域 | 放弃版权、无保留、彻底自由 | 作者放弃所有权利，任何人可做任何事（如CC0, Unlicense）。但需注意某些法域不承认这种放弃，常用"公共领域等同"许可。 |
| Open Source Definition (OSD) | 开源定义 | 开源十诫 | 由OSI（开源倡议组织）维护的开源软件必须满足的10条标准，是判断许可证是否为"开源许可证"的黄金准则。 |
| Free Software Definition | 自由软件定义 | 四大自由 | 由FSF（自由软件基金会）维护的自由软件必须满足的4项自由（使用、学习、分发、改进）。更强调伦理和用户自由。 |
| Source Code vs. Object Code | 源代码 vs. 目标代码 | 源码 vs. 二进制、人类可读 vs. 机器码 | 许可证通常要求提供"人类可读"的源代码，而不仅仅是机器可执行的二进制文件。这是开源的基础。 |
| License Compatibility | 许可兼容性 | 协议打架、能否混编 | 指不同许可证的代码能否合法合并发布。基本原则：宽松许可证可并入Copyleft项目，但Copyleft代码不能并入更宽松项目。 |
| Aggregation vs. Combination | 聚合 vs. 组合 | 打包 vs. 融合、独立作品 vs. 衍生作品 | 关键区分：聚合是将独立作品打包在同一媒介分发（如DVD合集），不触发传染；组合是将代码融合成一个作品，可能触发传染。 |
| Propagation | 传播 | GPLv3的广泛定义 | GPLv3中定义的比"分发"更广泛的行为，包括任何使他人能制作或接收副本的活动，旨在覆盖新的技术传播形式。 |
二、权利与义务篇 (Rights & Obligations)
| 名称 (Term) | 中文名称 | 社区/领域专业术语 | 描述 (Description) |
|---|---|---|---|
| Grant of Copyright License | 版权许可授予 | 授权、使用许可、法律基础 | 许可证的法律基础：版权所有者授予他人复制、修改、分发等权利。没有此授权，使用代码即侵权。 |
| Attribution / Notice | 署名/归属 | 保留版权声明、贴牌子、鸣谢 | 几乎所有许可证的最基础义务。要求在使用或分发时，保留原作者的版权声明、许可证文本和贡献者名单。 |
| Source Code Availability | 源码提供义务 | 开源义务、回馈社区、GPL核心 | 强Copyleft协议的核心要求。分发的形式、获取方式和提供期限（如随分发提供或书面提供）需按许可证规定执行。 |
| State Changes | 变更声明 | 修改记录、修改标注 | 要求在修改过的文件中明确注明修改内容、日期和修改者。这是GPL等协议的常见要求。 |
| Linkage | 链接 | 静态/动态链接、依赖引用、结合方式 | 代码结合方式。静态链接通常被视为创建衍生作品；动态链接在LGPL等协议下有特殊豁免条款。 |
| Corresponding Source | 对应源代码 | 完整构建包、GPL的灵魂、构建材料 | GPL要求提供的不仅是源码文件，还包括构建脚本、配置文件、接口定义等一切能从源码构建出相同二进制文件所需的材料。 |
| Cure Period | 补救期 | 宽限期、改过自新期、纠正机会 | 一些现代许可证（如Apache-2.0, GPLv3）规定，违规者在收到通知后有一定时间（通常30天）纠正违规，避免授权被永久终止。 |
| Include Interface | 接口包含 | Header File、API调用、头文件使用 | 仅包含头文件或调用API。通常不被视为创建衍生作品（在LGPL或带例外条款的GPL中）。 |
| Collective Work | 集体作品 | 作品集、合集 | 将多个独立作品集合成一个整体分发，但各作品保持独立。与衍生作品的关键法律区分。 |
| Fair Use | 合理使用 | 法定例外、有限使用 | 版权法中的例外原则，允许在不经许可的情况下有限使用受版权保护的作品。在开源合规中不能依赖此原则。 |
三、特殊条款篇 (Clauses & Compatibility Killers)
| 名称 (Term) | 中文名称 | 社区/领域专业术语 | 描述 (Description) |
|---|---|---|---|
| Patent Grant | 专利授权 | 专利许可、自带专利防护、法律护甲 | 明确授予用户使用代码中包含的专利技术的权利（如Apache-2.0第3节）。现代企业级协议的核心优势。 |
| Patent Termination | 专利终止 | 专利反制、专利报复条款、核威慑、专利报复 | 兼容性杀手。规定：若你起诉本项目侵犯专利，则你获得的所有授权（包括专利授权）自动终止。导致与GPLv2等无此条款的协议不兼容。 |
| Warranty Disclaimer | 免责声明 | 后果自负、AS-IS条款、不担保 | 几乎所有开源协议的标准条款："软件按'原样'提供，不提供任何明示或默示担保"。 |
| Limitation of Liability | 责任限制 | 免赔条款、责任上限、风险自担 | 规定作者/贡献者不对因使用软件造成的任何直接、间接损失负责。是商业使用的标准风险分配条款。 |
| Indemnification | 赔偿/担保条款 | 连带赔偿、Hold Harmless、责任转移 | 兼容性杀手。要求被许可方赔偿许可方因软件使用引发的索赔损失。某些协议因要求单方面过度赔偿而与GPL冲突。 |
| Advertising Clause | 广告条款 | 宣传署名要求、历史包袱 | 历史遗留兼容性杀手。要求在所有广告材料中提及原开发者（如旧版BSD-4）。已被现代社区抛弃，因其造成"署名堆叠"灾难。 |
| Non-Endorsement | 禁止背书 | 禁止借名宣传、撇清关系、名称保护 | 禁止未经书面许可使用贡献者名称推广衍生产品。保护项目不被滥用进行商业背书。 |
| Tivoization | 替沃化 | 硬件锁定、反破解、防篡改、设备限制 | 指硬件厂商使用开源软件，但通过技术手段（如签名校验）阻止用户运行修改后的版本。GPLv3引入"反替沃化"条款，要求提供安装信息。 |
| Installation Information | 安装信息 | GPLv3的反制武器、修改密钥 | GPLv3要求，如果设备预装GPLv3软件，厂商必须向用户提供修改和重新安装软件所需的签名密钥、硬件密钥等信息。 |
| Choice of Law / Venue | 法律选择/管辖地 | 司法管辖条款、专属管辖 | 兼容性杀手。规定纠纷适用特定国家/州法律或在特定法院诉讼。GPL认为这是额外限制，因此包含此类条款的协议（如CDDL）与GPL不兼容。 |
| Non-Commercial | 非商业性 | NC条款、禁止商用、限制商业 | 本身就不符合OSD，因此不被视为开源许可证。限制商业使用，常见于CC-NC系列，与开源理念冲突。 |
| Reciprocity | 互惠性 | 网络互惠、弱化版Copyleft、云传染 | 一些新兴协议（如SSPL， Elastic License）要求：如果你将软件作为云服务提供，必须开源服务本身的修改部分。争议较大，常被称为"伪开源"。 |
| GPLv2 vs. GPLv3 | GPL第二版 vs. 第三版 | 代际差异、专利条款差异 | 关键区别：1) GPLv3有明确专利授权；2) 反替沃化条款；3) 与Apache-2.0兼容；4) 更广泛的传播定义。许多项目仍停留在GPLv2。 |
| License Version Auto-Upgrade | 许可证版本自动升级 | "或任何更新版本"条款、未来兼容 | 一些许可证允许用户选择"按当前版本或任何后续版本"使用。提供对未来版本的自动兼容，但也带来不确定性。 |
四、例外条款篇 (Exceptions & Special Permissions)
| 名称 (Term) | 中文名称 | 社区/领域专业术语 | 描述 (Description) |
|---|---|---|---|
| Classpath Exception | Classpath 例外 | GPL链接例外、Java生态基石、模块隔离 | 对GPL v2的豁免。允许用户将该库与独立的、非衍生的模块进行链接（无论是静态还是动态），而无需将这些模块开源。是OpenJDK等项目的法律基础。 |
| GCC Runtime Library Exception | GCC运行时库例外 | GCC RLE、编译器例外、C++生态基石 | 允许用GCC编译的程序链接其运行时库（libgcc, libstdc++等），而不被视为GPL的衍生作品。没有它，几乎所有C/C++程序都要被GPL传染。 |
| LLVM Exception | LLVM例外 | Apache-2.0兼容补丁、桥梁条款 | 附加在Apache-2.0上的条款。核心目的：明确允许LLVM/Clang编译器生成的代码不受Apache-2.0许可证约束，并且允许LLVM与GPLv2代码链接。 |
| System Library Exception | 系统库例外 | GPL的"安全区"、操作系统豁免 | GPL中的通用例外：定义"系统库"为与操作系统主要组件一同分发或用于生成可执行文件的通用库。与这些库链接不触发GPL传染。 |
| Font Exception | 字体例外 | 嵌入例外、文档友好、显示豁免 | 常见于GPL发布的字体（如GPL+FE）。规定：将字体嵌入文档（如PDF）用于显示，不会强制该文档开源。保护文档的自由。 |
| Autoconf Exception | Autoconf例外 | 构建工具例外、脚本豁免 | 规定由Autoconf生成的configure脚本可以按用户意愿分发，不受GPL约束。确保构建工具的产出物不"带毒"。 |
| Bison Exception | Bison例外 | 解析器生成例外、生成代码豁免 | 类似Autoconf，允许Bison生成的解析器代码（如parser.c）作为用户程序的一部分分发，而不传染用户的业务逻辑代码。 |
| Bootloader Exception | 引导加载程序例外 | U-Boot例外、启动豁免、硬件启动 | 允许专有操作系统通过开源的Bootloader（如U-Boot）启动，两者在内存中的交互不被视为创建衍生作品。 |
| Linux Kernel Exception | Linux内核例外 | 系统调用接口豁免、用户空间保护 | Linux内核在GPLv2下，但Linus Torvalds明确声明：用户空间程序通过系统调用接口使用内核，不被视为衍生作品。这是整个生态的基石。 |
| Linking Exception | 通用链接例外 | 隔离声明、传染防火墙、边界划定 | 统称。任何在Copyleft协议后附加的、允许与特定库或按特定方式链接的声明。其核心作用是明确划定"传染"的边界。 |
| Firmware Exception | 固件例外 | 硬件微码例外、驱动程序豁免 | 允许将开源代码与专有的硬件微码（Firmware）捆绑分发，常见于驱动程序场景，承认硬件厂商对底层微码的控制权。 |
| OpenSSL Exception | OpenSSL链接例外 | 库绑定例外、历史兼容补丁 | 专门用于解决 GPL与OpenSSL（旧版） 不兼容的问题。GPL项目作者显式声明："允许本程序链接OpenSSL库"，从而豁免了OpenSSL广告条款导致的冲突。 |
五、许可协议篇（Licenses & Families）
| 名称 (Term) | 中文名称 | 社区/领域专业术语 | 描述 (Description) |
|---|---|---|---|
| GNU GPL | GNU通用公共许可证 | 最强传染、病毒式许可、Copyleft标杆 | 由自由软件基金会（FSF）维护的经典Copyleft协议。有v2、v3等版本。核心是"分发即开源"。 |
| GNU AGPL | GNU Affero通用公共许可证 | 最强病毒、堵SaaS漏洞、网络版GPL | GPL的"网络版"。核心是：通过网络提供服务（SaaS）即视为分发，必须公开对应源码，彻底封堵SaaS漏洞。 |
| GNU LGPL | GNU宽通用公共许可证 | 库友好、弱传染、链接豁免、动态库保护 | 为库设计的Copyleft协议。核心是允许通过动态链接的方式与闭源软件结合使用，而不会"传染"主程序。 |
| MIT License | MIT许可证 | 最宽松、极致简单、最流行 | 宽松许可证的代表。核心义务仅为"保留版权和许可声明"，几乎无任何限制，是商业化最友好的协议之一。 |
| Apache-2.0 | Apache许可证2.0 | 带专利护甲的商业友好协议、企业首选 | 宽松许可证，但比MIT多了明确的专利授权和专利反制条款，提供了更强的法律保护，是现代企业首选之一。 |
| BSD Licenses | BSD许可证家族 | 学院派、去广告条款、简洁宽松 | 宽松许可证家族。主要有三句版（BSD-3-Clause）和二句版（BSD-2-Clause）。现代版本已移除有争议的广告条款。 |
| MPL-2.0 | Mozilla公共许可证 | 文件级弱传染、混编友好、Firefox协议 | 弱Copyleft（或"中Copyleft"）代表。传染性以单个源代码文件为边界。允许将MPL代码与专有代码在同一项目中以不同文件的形式混合。 |
| EPL-2.0 / CPL | Eclipse / 通用公共许可证 | 企业级弱传染、Eclipse生态 | 类似MPL的弱Copyleft协议，由Eclipse基金会和IBM推动。在专利条款和责任限制上可能包含企业偏好的特定表述。 |
| Unlicense / CC0 | 无条件放弃 | 极致公共领域、放弃一切权利、彻底自由 | 不是"许可证"，而是作者主动放弃版权及相关权利，将作品置于公共领域的声明/工具。使用前需确认当地法律是否承认这种放弃。 |
| Weak Copyleft Family | 弱Copyleft家族 | 中传染、库友好协议群 | 包括LGPL、MPL、EPL等。传染性弱于GPL，通常允许与闭源代码以特定方式（如动态链接、文件隔离）结合。 |
| GPL Compatibility Matrix | GPL兼容性矩阵 | 协议兼容表、许可证关系网 | FSF和OSI维护的表格，明确显示各许可证与GPLv2/v3的兼容关系。是许可证混编的重要参考。 |
| Source Available Licenses | 源码可用许可证 | 伪开源、限制性源码访问 | 如BSL、SSPL、Elastic License等，提供源码但不完全符合OSD（通常限制SaaS使用）。不是真正的开源许可证。 |
六、社区与流程篇 (Community & Processes)
| 名称 (Term) | 中文名称 | 社区/领域专业术语 | 描述 (Description) |
|---|---|---|---|
| CLA (Contributor License Agreement) | 贡献者许可协议 | 版权收割机、企业控制工具 | 贡献者将代码版权授权给项目方（通常是公司），便于项目方统一管理许可证和进行法律维权。 |
| DCO (Developer Certificate of Origin) | 开发者原创声明 | 轻量认证、版权保留、Linux方式 | 贡献者声明自己有权按项目现有许可证提交代码，更轻量，保留了作者版权。被Linux内核、GitHub等广泛采用。 |
| Inbound=Outbound | 流入即流出 | 许可证一致性原则、贡献策略 | 社区常见策略：规定所有贡献（Inbound）默认接受，且将按项目的主许可证（Outbound）向外分发。简化了多源贡献的许可证管理。 |
| Copyright Assignment | 版权转让 | 卖身契、彻底转移 | 比CLA更进一步，贡献者直接将代码的版权所有权转移给项目方（如FSF）。现在已较少使用，DCO成为主流。 |
| License Proliferation | 许可证泛滥 | 选择困难症、协议过多问题 | 指开源许可证数量过多，导致开发者理解困难、项目兼容性复杂的问题。OSI和FSF都鼓励使用主流许可证。 |
| OSI-Approved | OSI认证 | 官方认证的开源、标准合规 | 经开源倡议组织审核，符合其"开源定义"的许可证。使用此类许可证是软件被称为"开源"的行业标准。 |
| FOSS / FLOSS | 自由与开源软件 | 统称、大帐篷 | Free and Open Source Software 或 Free/Libre and Open Source Software。泛指自由软件和开源软件。 |
| Upstream / Downstream | 上游 / 下游 | 源头与分流、项目流向 | 上游：指项目的原始社区或主要开发源。下游：指获取上游代码并进行分发、定制或集成的各方（如发行版、商业产品）。许可证义务通常从上游流向下游。 |
| Fork | 分叉 | 另立山头、分裂、独立发展 | 复制一个开源项目的代码库并独立发展，通常因开发理念、许可证变更或社区分歧导致。分叉后的项目需遵守原项目的许可证。 |
| Contributor vs. Licensor | 贡献者 vs. 许可方 | 代码提交者 vs. 权利授予者 | 贡献者：提交代码的人；许可方：拥有版权并授予许可的人（可能是贡献者本人或项目法人）。在CLA模式下两者可能不同。 |
| SPDX Identifier | SPDX标识符 | 许可证身份证、机器可读标识 | Linux基金会SPDX项目定义的标准许可证短标识符（如MIT、GPL-2.0-only），用于自动化许可证声明和扫描。 |
| Software Bill of Materials (SBOM) | 软件物料清单 | 成分清单、依赖清单 | 列出软件所有组件的结构化数据，包含名称、版本、许可证、供应链等信息。是软件供应链安全的基础。 |
七、合规与风险篇 (Compliance & Risk Management)
| 名称 (Term) | 中文名称 | 社区/领域专业术语 | 描述 (Description) |
|---|---|---|---|
| Software Audit | 软件审计 | 合规体检、清点家底、许可证扫描 | 对企业内部使用的软件（特别是开源软件）进行系统性识别、清单管理和许可证合规性检查的过程。 |
| Notice File | 声明文件 | 开源成分清单、NOTICE文件、鸣谢文件 | 通常指在分发软件时，随附的一个文件（如 NOTICE.txt），其中集中列出了所包含开源软件的版权声明、许可证文本和必要的归属信息。 |
| Source Code Escrow | 源码托管 | 源码保险柜、第三方保管 | 在某些商业许可中，将源代码交由可信第三方保管，在特定条件（如供应商破产）下释放给客户。与开源的分发义务不同。 |
| License Stacking | 许可证堆叠 | 多层许可、组合拳、混合许可证 | 指一个软件产品中包含了多种不同许可证的开源组件。合规时需要满足所有许可证的要求，取最严格的义务集合。 |
| Implied License / Patent | 默示许可 / 专利 | 法律推定、潜规则、非明示授权 | 即使许可证没有明确写出，但根据行为或行业惯例，可能被法律推定存在的许可。风险极高，应依赖明示授权。 |
| Export Control | 出口管制 | 合规红线、国际制裁 | 许多开源许可证（如Apache-2.0）会提醒用户，软件可能受国家出口管制条例约束（如美国的EAR）。这是企业必须独立评估的法律义务。 |
| SCA Tools | 软件成分分析工具 | 许可证扫描器、依赖分析工具 | 自动识别代码中开源组件及其许可证的工具（如Black Duck, FOSSA, Snyk）。是现代开发流程的必备工具。 |
| Compliance Program | 合规流程 | 内控体系、开源治理 | 企业为确保开源合规建立的制度、工具和流程的统称，包括策略制定、工具链集成、培训、审计等环节。 |
| Ethical Licenses | 道德条款许可证 | 价值观约束、非OSD合规 | 如Hippocratic License，限制软件被用于侵犯人权等特定用途。不符合OSD，不被认为是开源许可证。 |
| Fiduciary License Agreement | 受托许可协议 | FSF的版权管理 | FSF使用的特殊CLA形式，贡献者将版权委托给FSF管理，确保软件永远保持自由。 |
| Community-Oriented vs. Corporate-Oriented | 社区导向 vs. 企业导向 | 理念差异、治理模式 | 社区导向：强调自由和协作（如GPL）；企业导向：强调商业友好和专利保护（如Apache-2.0）。两种不同的开源哲学。 |
