二次开源需要注明来源吗？

本文目录导读：

1. 必须注明来源的情况（绝大多数情况）
2. 可以不注明来源的极少数情况
3. 实际操作的几个关键步骤

“二次开源”通常指的是在他人开源代码的基础上进行修改、扩展或衍生出新的项目，并再次以开源形式发布，这种情况下，是否需要注明来源，答案是明确的：通常需要，且这既是法律要求，也是开源社区的基本准则。

具体取决于你所使用的原始代码采用的开源许可证类型,以下是基于不同许可证的详细说明：

必须注明来源的情况（绝大多数情况）

大多数主流开源许可证都明确要求保留原作者版权声明和许可信息。

1. 强互惠型许可证（如 GPL 2.0/3.0, AGPL 3.0）：

   • 要求：必须注明原始项目来源、作者、版权声明，并遵守相同的开源许可证（即你的衍生项目也必须采用 GPL 或兼容许可证）。
   • 示例：如果你基于一个 GPL 协议的软件进行了二次开发，在发布的代码文件、软件“页面或文档中，必须清晰说明该软件基于某个原始项目,并附上原始项目的版权和许可信息。

2. 弱互惠型许可证（如 LGPL, MPL 2.0）：

   • 要求：对于修改过的库文件本身，必须注明来源和版权，如果以静态链接方式使用,需要提供修改后的库源码。
   • 示例：修改了某个 LGPL 协议的库,你需要确保修改后的库文件头部保留了原作者的版权声明。

3. 宽松型许可证（如 MIT, Apache 2.0, BSD）：

   • 要求：必须保留原始版权声明和许可文本,这是这些许可证最核心的义务。
   • 示例：你从 GitHub 上找到一个 MIT 协议的项目，修改后发布了，你需要在你的项目代码的 LICENSE 文件或代码文件的头部，明确包含：“This project is based on [原项目名称] by [原作者]，licensed under the MIT License.”,并附上原作者的版权信息。
   • 特别注意：Apache 2.0 许可证还要求，如果你修改了代码，需要标注“Modified”字样，并保留原作者的 NOTICE 文件。

4. 公共领域/放弃版权（如 Unlicense, CC0）：

   • 情况：理论上不需要注明来源,因为原作者已放弃所有权利。
   • 建议：强烈建议注明，注明来源是学术诚信和对他人工作的尊重，即使法律上不强制,社区和用户也会期望你这样做。

可以不注明来源的极少数情况

• 许可协议明确允许不署名：几乎没有主流开源许可证会这么规定，即使是 MIT 协议，它也要求“上述版权声明和本许可声明应包含在软件的所有副本或主要部分中”。
• 极小体量或非核心代码的引用：你只是从某个开源项目里借鉴了 3-5 行代码，且不属于核心逻辑或创意，但为了避免争议,建议还是在注释中写明来源。

实际操作的几个关键步骤

无论使用哪种许可证,正确的做法至少包括：

1. 保留原 LICENSE 文件：不要删除或修改项目根目录下的 LICENSE、LICENSE.txt 等文件。
2. 保留代码头部的版权声明：很多代码文件头部有 /* Copyright (c) [Year] [Author] */ 这样的注释,不要删除。
3. 在你的项目中明确引用：在你的项目的 README.md、NOTICE 文件或“致谢”部分，写明：
   • 原始项目的名称和链接。
   • 原始作者的姓名或组织。
   • 原始项目的许可证类型。
   • 你做了哪些修改（尤其是对于 Apache 2.0 等有明确要求的许可证）。
4. 使用兼容的许可证：你的“二次开源”项目选择一个能与上游许可证兼容的许可证，你基于 GPL 项目，你的项目也必须用 GPL，你基于 MIT 项目，你可以用 MIT、Apache 2.0 或 GPL等,但需要遵守高冲突规则。

核心答案：是的，二次开源通常必须注明来源。

为什么必须？

• 法律合规：违反许可证条款（如未注明来源）可能导致版权侵权，原作者有权要求你停止发布、删除项目甚至索赔。
• 社区道德：匿名化他人工作是“剽窃”行为，会受到开源社区的严厉批评和抵制,失去信誉和合作机会。
• 技术责任：注明来源可以让用户追溯代码质量、安全更新和问题修复的来源,也有助于你获得上游的更新和反馈。

总结建议：无论原始代码使用何种许可证（甚至是公共领域），注明来源都是一个好习惯。 你只需要在项目文档或代码中简洁、清晰地写明“此项目基于 [原项目名] 进行二次开发，原项目许可证为 [许可证名]，版权归 [原作者] 所有。” 这既能确保你合法合规,也体现了你对开源贡献者的尊重。