开源项目法律合规实战指南许可证选择、变更与贡献者协议opensource.guide 解读【免费下载链接】opensource.guide Community guides for open source creators项目地址: https://gitcode.com/gh_mirrors/op/opensource.guide开源项目的开放并非天然存在而是建立在版权法默认规则之上、通过许可证显式授予的法律状态。本文以 opensource.guide 仓库中《The Legal Side of Open Source》一文_articles/fr/legal.md英文原版见 _articles/legal.md为核心系统讲解开源许可证的运作原理、permissive 与 copyleft 许可证的差异、项目许可证的变更路径、贡献者协议CLA/DCO的取舍以及企业法务团队在开源发布中需要关注的知识产权要点帮助维护者从零建立可落地的开源法律合规方案。阅读本文后你将能够为自己的项目选择合适许可证、评估许可证变更可行性并理解企业与个人在开源活动中的法律边界。本文仅为技术性知识整理不构成法律意见。在做出任何法律决策前请阅读仓库的 notices.md 免责声明并咨询你自己的法律顾问。为什么开源如此依赖法律机制当你创作一份作品无论是文字、图形还是代码时法律默认其自动获得排他性版权。也就是说法律假定作为作者的你对他人如何使用你的作品拥有决定权。一般情况下这意味着未经授权任何人都不能使用、复制、分发或修改你的作品否则将面临下架要求、敲诈或诉讼风险。开源是一种非常规状态作者希望他人使用、修改并分享作品。但由于法律默认仍是排他性版权你必须通过许可证显式授予这些权限。这一点同样适用于贡献者在没有许可证或其他协议的情况下任何人对项目的贡献都归贡献者本人独占所有——这意味着包括你在内的任何人都不能使用、复制、分发或修改这些贡献。此外你的项目还可能带有你没意识到的许可要求项目依赖项各自带有许可证条款社区或雇主的政策也可能要求项目使用特定的开源许可证。这些情况下文都会逐一覆盖。一个直观的实证本仓库自身就是一套开源授权体系。其 LICENSE 采用 CC-BY-4.0署名 4.0 国际版notices.md 则明确说明正文内容以 CC-BY-4.0 发布、代码以 CC0-1.0 发布并列出 Django、Vagrant 等第三方截图的授权许可——这正是依赖项合规 内容再许可的完整样例。公开不等于开源GitHub 公共仓库的许可证真相在 GitHub 上创建新仓库时你可以选择仓库为私有private或公开public。但必须明确一个高频误解将 GitHub 项目设为公开与为项目添加许可证是两件完全不同的事。公开项目受 GitHub 服务条款约束允许他人查看和 fork 你的项目但除此之外你的作品不附带任何使用许可。换句话说任何人——即使项目是公开的——都不能合法地将你项目的任何部分用于自己的代码中除非你明确授予此权利。因此若希望他人能够使用、分发、修改或回馈你的项目就必须在项目中包含一份开源许可证。项目创建时的许可证选项如上图所示在 GitHub 创建仓库的界面中Choose a license选择许可证下拉框提供了许可证选项其说明文字明确写道许可证告诉他人他们能用你的代码做什么、不能做什么。新建项目时你也会被提示添加许可证。若选择None项目就处于有公开可见性但无任何法律授权的状态——这正是许多维护者无意间制造的法律灰色地带。仓库的另一篇姊妹文档 _articles/starting-a-project.md 中Choosing a license一节给出了同样的结论并补充了一个实用观点开源许可证保证他人可以无后顾之忧地使用、复制、修改并回馈你的项目同时保护你免于陷入棘手的法律纠纷——发布开源项目时你必须包含许可证。启动新项目必备的文档清单许可证、README、贡献指南、行为准则中许可证排在首位因为它们共同保护每个人的法律权利包括你自己的。保护项目的最简方案直接选用标准许可证好消息是今天的开源许可证已经高度标准化、易于使用你完全可以直接把现成的许可证文本复制粘贴到项目中。MIT、Apache 2.0、GPLv3 是最主流的开源许可证当然还有其他选择。在创建 GitHub 新项目时你会被询问是否添加许可证。若想查看其他选项可以借助 choosealicense.com 为项目寻找合适的许可证——即使你的项目不是软件例如文档、数据集也有对应的许可证可选。正如开源维护者 Ben Balter 所言标准化的许可证是缺乏法律训练者的代理——他们无需精通法律就能确切知道自己能对软件做什么、不能做什么。除非绝对必要应避免自定义、修改或非标准的条款因为那会成为代码下游使用的障碍。哪种开源许可证适合我的项目如果你从空白项目起步MIT 许可证几乎不会出错它篇幅短、极易理解允许任何人做任何事只要保留一份包含版权声明的许可证副本。即便将来需要你也能改换其他许可证。否则选择合适的开源许可证取决于你的目标。决策主要围绕三类因素展开。依赖项的许可证类型决定你的选择空间你的项目极可能有或将有依赖项。例如开源一个 Node.js 项目你几乎必然用到 npm 上的库而每个库都带有自己的开源许可证。宽松式permissive许可证如 MIT、Apache 2.0、ISC、BSD。它们授予公众使用、修改、分享的权限且不向下游强加许可证条件。如果你的所有依赖都是宽松式的那么你的项目可以任意选择许可证。强 copyleft 许可证如 GPLv2、GPLv3、AGPLv3。它们同样授予公众上述权限但条件是你的项目必须使用相同或兼容的许可证。只要项目中包含任何强 copyleft 库你的项目整体就需选择相同或兼容的许可证。你希望吸引的社区决定许可证调性考虑你希望哪些人使用和贡献你的项目希望项目被其他项目当作依赖使用最好采用相关社区中最流行的许可证。例如 MIT 是 npm 库中最流行的许可证。希望项目吸引大企业大企业通常期望获得所有贡献者的明示专利授权。这种情况下Apache 2.0 能同时覆盖你和它们。希望项目吸引不希望贡献被用于闭源软件的贡献者GPLv3 很合适若他们也不希望贡献用于闭源服务则 AGPLv3 更佳。公司政策可能另有强制要求你的公司可能对开源项目有特定的许可证要求例如要求宽松式许可证以便公司将你的项目整合进其闭源产品也可能强制使用强 copyleft 许可证并附加贡献者协议使只有公司自己能在闭源软件中使用该项目还可能出于标准、社会责任或透明度需求要求特定的许可策略。这种情况应与公司法律部门沟通见下文公司法律团队需要知道什么。在 GitHub 创建新项目时你可以选择许可证——包含上述任一许可证都会让你的 GitHub 项目真正成为开源项目。仓库的 _articles/starting-a-project.md 也展示了 GitHub 仓库初始化界面中的许可证选择器repository-license-picker.png并提醒在仓库根目录放置LICENSE文件GitHub 会自动识别并在页面上向读者展示。如何更改项目的许可证大多数项目终生无需更换许可证但环境会变项目成长后新增了依赖或用户、公司战略调整都可能要求不同的许可证。此外如果你从一开始就忽略了授权那么补加许可证在效果上等同于更换许可证。更改或添加许可证时有三件根本性的事需要考量。更改许可证是复杂的确定许可证的兼容性与合规性、厘清谁持有版权会很快变得复杂而令人困惑。为新版本和新贡献切换到新的但兼容的许可证与重新授权所有既有贡献是两回事。一旦萌生任何换证念头第一件事就是让法务团队介入。即使你已获得或能获得版权持有者的换证许可也要考虑变更对项目其他用户和贡献者的影响。建议把换证当作一次项目治理事件与项目利益相关方清晰沟通、充分协商过程会更顺畅——这也是从一开始就选用合适许可证的又一理由。现有许可证是否兼容如果项目现有许可证与你想要更换的许可证兼容你可以直接开始使用新许可证。原理在于若许可证 A 与许可证 B 兼容则你在遵守 A 条款的同时也能遵守 B 的条款反之则不一定。因此如果你当前用的是宽松式许可证如 MIT只要保留 MIT 许可证副本及所有相关版权声明即继续满足 MIT 的最低条件就可以换到条件更多的许可证。但如果当前许可证不是宽松式的例如 copyleft或你根本没有许可证且你不是唯一版权持有者就不能直接把项目许可证换成 MIT。本质上宽松式许可证的版权持有者等于预先给出了换证许可。谁是你项目的现有版权持有者如果你是该项目的唯一贡献者那么你或你的公司就是唯一版权持有者可以随意添加或更换任何许可证。否则更换许可证需要其他版权持有者的同意。谁是他们项目中有提交记录的人是良好的起点但某些情况下版权由这些人的雇主持有。而且不存在低于若干行代码的贡献不受版权约束的绝对规则——哪怕很小的贡献也可能涉及版权。实操建议因项目而异对相对年轻的小项目可以尝试在 issue 或 pull request 中让所有现有贡献者同意换证对庞大而长寿的项目你可能需要逐一寻找众多贡献者甚至他们的继承人——Mozilla 花了数年2001—2006才完成 Firefox、Thunderbird 及相关软件的重新授权。替代方案是通过额外贡献者协议见下文让贡献者预先同意特定条件下的某些换证行为。这会把换证的一部分复杂性前置转移但你需要更多律师的早期介入并在执行换证时依然与利益相关方清晰沟通。我的项目需要额外贡献者协议CLA吗大概率不需要。对绝大多数开源项目而言开源许可证本身就同时充当入站许可来自贡献者与出站许可面向其他贡献者与用户。如果你的项目在 GitHub 上GitHub 服务条款将inbound outbound入站即出站设为明确的默认行为——贡献者在提交时即按仓库许可证授权。额外贡献者协议——通常称为贡献者许可协议CLA——会给维护者带来行政负担。负担大小取决于项目与实现方式简单的协议可能只要求贡献者一键确认我有权在项目开源许可证下贡献复杂的协议则可能要求法律审查、并由贡献者的雇主签字批准。此外若这份文书被视为不必要、难以理解或不公平例如协议受让方获得了比贡献者或公众通过项目开源许可证更多的权利额外贡献者协议会被社区视为不友好。Node.js 维护者 Bryan Cantrill 的经验之谈是我们取消了 Node.js 的 CLA这降低了 Node.js 贡献者的准入门槛从而扩大了贡献者基础。什么情况下值得考虑 CLA以下是可能需要额外贡献者协议的几种典型场景律师坚持让所有贡献者明示接受在线或离线签署贡献条款——即使他们认为开源许可证本身已经足够。如果这是唯一顾虑一份确认项目开源许可证的贡献者协议就够了jQuery 的个人贡献者许可协议就是轻量协议的范例。某些项目则选择用Developer Certificate of OriginDCO作为替代要求开发者声明每次提交都经过授权。你的项目使用不含明示专利授权的开源许可证如 MIT而你需要所有贡献者的专利授权——尤其当某些贡献者就职于拥有庞大专利组合、可能针对你或项目其他贡献者与用户发起诉讼的公司。Apache 个人贡献者许可协议是常用的方案其专利授权条款与 Apache 2.0 许可证中的专利条款一致。项目采用 copyleft 许可证但你还需要分发项目的专有版本。此时需要每个贡献者把版权转让给你或授予你而非公众宽松式许可。MongoDB 贡献者协议是此类协议的例子。你预计项目在生命周期内可能需要换证希望贡献者预先同意此类变更。如果确实需要使用额外贡献者协议可考虑接入 CLA assistant 之类的自动化集成把对贡献者的干扰降到最低。仓库文档建议的轻量替代方案是 DCO它由贡献者逐次提交声明授权可配合自动化机器人如 DCO Probot执行。公司法律团队需要知道什么如果你以公司雇员身份发布开源项目首先要让法务团队知道你在开源一个项目。即便只是个人项目也建议告知他们——无论好坏。你很可能与公司签有员工知识产权协议赋予公司对你项目的某种控制权尤其当项目与公司业务相关或你使用了公司资源开发项目时。公司应当轻易地给予许可也许通过员工友好的知识产权协议或公司政策已经做到。否则你可以协商例如说明项目服务于公司对你的专业学习与发展目标或者干脆在找到更合适的公司之前先搁置项目。为公司开源项目时需要审查的要点如果你为公司开源一个项目务必告知法务。公司法律团队通常已有关于使用何种开源许可证以及是否需要额外贡献者协议的政策其依据是公司业务需求以及确保项目依赖项合规的专业能力。如果没有法务团队应当乐于与你一起厘清。以下是需要共同思考的几个要点第三方材料项目是否有他人创建的依赖项或包含/使用了他人代码若这些材料是开源的你需要遵守其开源许可证——这始于选择一份与第三方开源许可证兼容的许可证。若项目修改或分发第三方开源材料法务团队还需确认你履行了其他条件例如保留版权声明。若项目使用了没有开源许可证的他人代码你可能需要请第三方维护者添加开源许可证若无法获得就应停止在项目中使用其代码。商业秘密审查项目中是否有公司不愿公之于众的内容。若有可以先把要保密的材料剥离出来再开源项目的其余部分。专利公司是否正在申请一项专利而开源你的项目会构成公开披露遗憾的是你可能被要求等待或公司会重新考虑申请的价值。如果你期待来自专利大户公司员工的贡献法务团队可能希望你使用带明示专利授权的许可证如 Apache 2.0 或 GPLv3或使用额外贡献者协议。商标双重检查项目名称不与现有商标冲突参见 _articles/starting-a-project.md 中的Avoiding name conflicts一节商标冲突可能导致公司要求你下架项目甚至采取法律行动并可使用 WIPO 全球品牌数据库检索。如果你在项目中使用了公司自己的商标确认不会引发冲突。隐私你的项目是否收集用户数据、是否向公司服务器回传法务团队可帮助你遵守公司政策与外部法规。长期视角法务团队可以做得更多如果你是公司首个开源项目的发布者以上内容已足够应对不过放心大多数项目不应引发重大担忧。从长远看公司法律团队还能做更多帮助公司从开源参与中获益并保持安全员工贡献政策考虑制定公司政策规定员工如何参与开源项目。清晰的策略能减少员工困惑帮助他们在工作中或业余时间以公司最佳利益参与开源。Rackspace 的Model IP and Open Source Contribution Policy是一个良好范例。正如开源维护者 vanl 所说释放与补丁相关的知识产权能建立员工的知识库与声誉展现公司对员工成长的投入带来赋权与自主感进而提升士气与员工留存。发布什么几乎一切都可以开源如果法务团队理解并投入于公司的开源战略他们最能帮助而非阻碍你的努力。合规即使公司不发布任何开源项目它也在使用他人的开源软件。建立合规意识与流程可以预防头疼、产品延期和法律诉讼。开源律师 Heather Meeker 强调组织必须有一套同时适配permissive与copyleft两大类的许可与合规策略首先要持续记录你所使用开源软件的许可条款——包括子组件与依赖项。仓库自身就是范例notices.md 为指南正文的每个截图与第三方素材逐一标注了版权与许可如 Django 的 BSD 许可证、Vagrant 的 MIT 许可证、CC-BY-4.0 授权的照片这正是记录第三方材料授权的可操作模板。专利公司可能希望加入 Open Invention Network——一个共享的防御性专利池用于保护成员对主要开源项目的使用或探索其他替代性专利许可方案。治理尤其是当把项目移交到公司之外的法律实体变得有意义时。具体可参考 _articles/leadership-and-governance.md除非涉及资金处理否则你并不需要一个法律实体来支撑开源项目——若要接受捐赠可以设置捐赠按钮但在美国只有符合资质的非营利组织501c3才能享受税收抵扣否则可考虑 Software Freedom Conservancy、Apache 基金会、Eclipse 基金会、Linux 基金会、Open Collective 等财政赞助fiscal sponsor机构。结语把法律合规纳入项目启动清单开源的法律问题并非高深莫测——它的核心只是一条简单规则没有许可证就没有授权。在 _articles/starting-a-project.md 的发布前检查清单中法律相关条目被明确列为第一优先级项目需包含开源许可证的 LICENSE 文件、名称不得侵犯商标、个人/组织都应与法务部门沟通并理解公司的知识产权与开源政策。将这些动作内化为发布流程的一部分你的项目才能在开放协作的同时为自己和所有参与者守住清晰、可预期的法律边界。【免费下载链接】opensource.guide Community guides for open source creators项目地址: https://gitcode.com/gh_mirrors/op/opensource.guide创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
