openJiuwen 许可证与版权规范：LICENSE、NOTICE 与版权许可头的落地实务指南

文档开源治理【免费下载链接】communityopenJiuwen community承载社区章程、社区规范、CLA签署等社区运作类相关信息项目地址https://gitcode.com/openJiuwen/community点击查看免费下载本文基于 openJiuwen 社区的《License and Copyright Guidelines》英文原文中文版本系统讲解社区对代码贡献者、Committer 与 PMC 成员在仓库许可证文件LICENSE、第三方软件声明文件NOTICE以及源码文件版权许可头Copyright License Headers三个层面的规范要求。读完本文你能够按照社区标准完成开源仓库的许可证落位、多许可证组织、二进制发布物声明与逐文件版权头编写并理解这些规则在 openJiuwen 社区仓中的真实落地形态。一、规范的目的、适用范围与修订机制目的该规范明确了 openJiuwen 社区的代码贡献者、Committer、PMC 成员如何处理 Repo 及源代码文件的许可与版权声明覆盖以下三个部分LICENSE 文件——仓库级许可证文件的命名、放置与覆盖范围规则NOTICE 文件——二进制发布物中第三方开源软件信息的声明规则版权和许可头——源代码文件级版权声明与许可证头的格式要求。适用范围重要边界规范仅适用于 openJiuwen 社区内部的代码仓库管理场景明确排除两类场景个人或企业将 openJiuwen 项目应用于开发其它产品的场景分发第三方开源软件的场景。也就是说该规范约束的是社区仓库里放了什么、怎么标注而不是约束下游用户如何使用 openJiuwen 构建自己的产品。修订与定稿机制本规范由openJiuwen PMC主导起草和维护最新版本始终可在规范原文处获取中文对照版见许可证与版权规范任何对规范涉及规则的增加、修改、删除都必须被追踪需进入社区的追踪系统记录变更最终规则须经社区充分讨论后由 PMC 定稿。二、LICENSE 文件仓库级许可证的五条规则LICENSE 文件是开源仓库向外界声明本仓库代码以什么协议授权的第一入口。规范要求如下许可证清晰且与社区整体规则一致。每个开源仓必须有清晰描述的许可证信息且必须与 openJiuwen 整体许可证规则一致。例如 agentcore 开源仓使用的是 Apache License 2.0。结合社区配套的许可证与特殊许可证评审指导可知项目对贡献代码设有许可证白名单其中推荐优先使用 Apache License 2.0Apache-2.0以保证全社区许可证统一纯文本格式、置于仓根、不带后缀。许可证文件必须为纯文本格式放置于代码仓的根目录包含该许可的全文且文件名固定为LICENSE不得带.txt、.md等后缀多许可证场景的组织方式。如果开源仓的不同源码包含多种许可证主许可证描述在名为LICENSE的文件中其它许可证以LICENSE-许可证类型-备注的形式命名放置于仓根目录或该许可证对应源码的根目录主许可证文件中必须描述各许可证文件的位置及其适用的范围与场景。覆盖范围必须准确且精简。许可证文件必须涵盖该仓下所有文件各许可证的涵盖范围描述要准确、精简不得包含不在本仓发布的其它源代码许可等无关信息——例如需要单独下载的依赖软件的许可不应包含在仓库和许可证信息中二进制发布物的许可证落位。如果开源仓以二进制形式发布许可证文件必须位于其发布格式的常规位置发布文件夹或压缩包的顶层目录对于.jar文件许可证可位于META-INF目录。社区仓的实例印证当前 community 仓库本身就遵循了这些规则可以直接作为参照仓根目录存在纯文本的 LICENSE 文件无后缀包含 CC BY 4.0 协议全文用于覆盖社区文档与资料体系内容仓根同时提供 COPYRIGHT英文与 COPYRIGHT_zh中文版权文件声明为Copyright (c) Huawei Technologies Co., Ltd. 2025. All rights reserved.——这正是下文版权所有者为法律实体规则的体现开源合规类问题管理 将 License、Copyright、开源片段引用、开源义务履行等问题统一纳入合规 issue 分类由合规 SIG 例行看护闭环与许可证治理形成配套流程。此外社区的各仓资料体系治理规范 在目录六规则中同样明确要求LICENSE 放在仓根目录并将License列为仓库资料体系中必有的一项明确标注开源许可证。两条规则相互印证LICENSE 文件的根目录落位是社区治理的硬性要求而非建议。三、NOTICE 文件第三方开源软件的声明要求当以二进制形式分发的软件中包含第三方开源软件时仅靠 LICENSE 文件是不够的——还需要一个专门声明第三方组件的文件。规范要求NOTICE 文件的内容要求。提供以NOTICE命名的文件以纯文本格式描述所包含的所有第三方开源软件的软件名称软件版本权利人声明Copyright noticeLicense 信息。放置位置。NOTICE 文件通常放置在发布文件夹或压缩包的顶层目录对于.jar格式的文件可位于META-INF目录——与 LICENSE 文件的二进制落位规则保持一致。仓库中的真实 NOTICE 形态community 仓库根目录下的 Open Source Software Notice.txt 提供了一个完整的对照样本该文件随产品/固件一起分发代表的是二进制发布场景下的声明文件形态。其开头声明了开源许可的效力优先原则The open source software licenses are granted by the respective right holders. And the open source licenses prevail all other license information with regard to the respective open source software contained in the product...随后以逐组件的固定结构展开每个组件包含四段信息例如Software: aiohttp 3.12.15 Copyright notice: No copyright notice found in source files of this software License: Apache License V2.0 Apache License Version 2.0, January 2004 ...Software: pydantic 2.11.3 Copyright notice: No copyright notice found in source files of this software License: MIT License The MIT License ...对照规范要求可以看到每个条目都给出了软件名版本号如aiosignal 1.4.0、SQLAlchemy 2.0.40、Copyright notice 段找不到时如实写No copyright notice found in source files of this software、License 段附协议全文或对前文已列协议的全局引用Please see above。这正对应 NOTICE 规则中名称、版本、权利人声明、License 信息四项必备要素。需要注意的边界NOTICE 机制服务于二进制分发物场景。对于源码仓本身规范明确提醒不要把需要单独下载的依赖软件的许可写进仓库的 LICENSE 信息见上文 LICENSE 规则第 4 条——源码仓与发布物的第三方声明职责是分离的。四、版权和许可头文件级声明的原则、例外与模板基本原则与三类例外原则上开源仓中的所有文件都应当包含合适的版权和许可头声明除非属于以下三类场景例外场景说明典型例子添加声明会影响文件功能文件格式不支持注释加头会破坏解析JSON 文件不支持注释工具自动生成的文件文件本身已包含由工具自动生成的描述信息代码生成器输出、构建产物简短的用户阅读类说明文件加头会显著影响可读性且信息量小README 等短文档这三条例外覆盖了加头会破坏文件有效性和加头收益小于成本两类情况其余文件一律应带头。版权声明格式版权声明的格式为Copyright (C) [第一次发布年份]-[当前版本发布年份] [版权所有者]两个要点年份语义版权头中的年份是作品对外发布的年份不是代码修改年份。如果是最初发布只写发布年份如果不是第一次发布则写成第一次发布年份-当前版本发布年份的区间形式如Copyright 2013-2019 Nikolay Kim and Andrew Svetlov这类区间写法版权所有者是法律实体可以是个人或公司。若代表公司贡献代码应写公司的法律实体名称。这一点在 CONTRIBUTING_zh.md 的版权规范部分也有呼应用户提交的代码必须是原创内容、不得侵犯他人知识产权贡献代码须遵守许可证与版权规范新贡献代码涉及第三方开源软件引入或片段引用时须遵守特殊许可证评审要求。许可证头模板以具体许可证内容为准规范给出了两类许可证的标准头部文本。文件许可头必须与所在仓库的许可证信息一致模板原文如下Apache License Version 2.0 许可头Licensed under the Apache License, Version 2.0 (the License); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an AS IS BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.BSD-3-Clause 许可头Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: 1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. 2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. 3. Neither the name of the copyright holder nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission. THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS AS IS AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.双重许可文件的处理规则规范对文件级许可头还有一条一致性约束许可头信息必须与该开源仓的许可证信息一致。如果某个文件处于双重许可证之下其许可头必须清晰说明各许可证的适用条件即选择哪一个许可证在什么前提下生效在文件许可头中完整包含各许可证所定义的许可头描述不能只写其一。五、配套治理从规范到闭环的工程实践许可证与版权规范不是孤立文档它与社区内其他治理文档构成完整的合规闭环许可证白名单与特殊许可证评审。配套的许可证与特殊许可证评审指导规定了贡献代码优先使用 Apache-2.0、第三方依赖的许可白名单与不推荐清单以及白名单之外许可证特殊许可证的评审流程由 openJiuwen Compliance SIG 组织参与者至少包含 PMC 代表、法律代表与合规 SIG 代表通过评审是采用特殊许可证的软件模块通过代码合规检查、合入主分支以及 QA SIG 出口评审/孵化毕业评审的强制前置条件。开源合规 issue 管理。开源合规类问题管理 将 License、Copyright、开源片段引用、开源义务履行等问题分为代码仓专属合规整改问题与公共合规类问题两类分别提交至归属代码仓或 community 仓的 issue 列表标题以【合规】开头由合规 SIG 组会例行审视原则上在问题提交后 14 个工作日内完成答复并看护各仓专属整改问题在版本发布前解决完毕。仓库资料体系治理。各仓资料体系治理规范 要求仓库 README 的七段内容中包含 License 段且 LICENSE 文件必须位于仓根目录与本文第二节的规则形成文档层面的交叉校验。贡献入口的引用。CONTRIBUTING_zh.md 在 License 部分声明贡献代码采用 Apache License 2.0并在版权规范中直接引用本规范与特殊许可证评审指导使新贡献者在提交代码的入口就能定位到完整规则。六、落地检查清单结合规范全文可以整理出如下可核对的落地清单LICENSE 文件仓根目录存在纯文本LICENSE文件无.txt/.md后缀含协议全文许可证与 openJiuwen 整体许可证规则一致贡献代码推荐 Apache-2.0多许可证时次级许可证命名为LICENSE-许可证类型-备注且主 LICENSE 中说明了各文件位置与适用范围许可覆盖范围覆盖仓内所有文件且未混入仓外依赖如单独下载的依赖软件的许可信息二进制发布时LICENSE 位于发布包顶层目录.jar可位于META-INF。NOTICE 文件分发的二进制包含第三方开源软件时提供了NOTICE文件每个第三方组件均包含名称、版本、权利人声明、License 信息四要素NOTICE 位于发布文件夹/压缩包顶层目录.jar可位于META-INF。版权和许可头非例外场景JSON 等无注释格式、工具生成文件、README 等短说明文件的文件均带版权与许可头版权声明符合Copyright (C) [首次发布年份]-[当前版本发布年份] [法律实体]格式年份为对外发布年份而非修改年份代表公司贡献时写公司法律实体名称许可头与仓库许可证一致双重许可文件写明了各许可证适用条件并包含全部许可头描述。通过上述三部分的规则遵循与配套评审、issue 治理机制的协作openJiuwen 社区保证了从文件级到仓库级、从源码到发布物的许可证与版权声明在形式上统一、在流程上可追溯、在合规上可闭环。赞分享文档开源治理【免费下载链接】communityopenJiuwen community承载社区章程、社区规范、CLA签署等社区运作类相关信息项目地址https://gitcode.com/openJiuwen/community点击查看免费下载相关推荐Tock 项目的许可证与版权政策解读从 TRD 4 规范到 license-checker 落地实践Tock 项目的许可证与版权政策解读从 TRD 4 规范到 license checker 落地实践 导读 本文基于 Tock 项目 Core 工作组制定的技操作系统嵌入式嵌入式OSAnkiDroid 版权头Copyright Headers贡献规范与 SPDX 许可证合规实践指南AnkiDroid 版权头Copyright Headers贡献规范与 SPDX 许可证合规实践指南 本指南基于 AnkiDroid 仓库的 docs/co移动开发教育如何快速部署LTX-Video5个高效配置秘诀实现实时AI视频生成如何快速部署LTX Video5个高效配置秘诀实现实时AI视频生成 LTX Video是一款革命性的开源AI视频生成工具基于先进的DiT架构设计能够实现3人工智能大模型媒体生成视频多模态创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考