Nextcloud Server 文件授权声明指南：SPDX 头规范与 DCO 提交签核实践

Nextcloud server 采用「双许可文本（AGPL-3.0-only 与 AGPL-3.0-or-later）+ SPDX 文件头 + DCO 提交签核」的授权管理体系，不要求贡献者签署 CLA。本文围绕仓库中的 如何添加许可证指南 展开，完整覆盖新文件 SPDX 头写法、存量文件头更新规则、REUSE 清单机制以及 Developer Certificate of Origin（DCO）签核要求，并逐一给出仓库内真实文件作为参照，帮助你在为 Nextcloud server 提交代码前独立完成合规的版权标注与提交签名。

授权体系总览：双 AGPL 许可文本与无 CLA 政策

指南开头说明了 Nextcloud 的许可证沿革：项目最初使用 GNU AGPLv3 only，自 2016 年 6 月 16 日起切换为「GNU AGPLv3 or any later version」，目的是提升长期可维护性并加强法律层面的确定性。同时明确：Nextcloud 不要求 CLA（Contributor License Agreement），版权归属于每一位贡献者本人。

在仓库中可以找到这套政策的落地文件：

• COPYING：GNU AGPL 第 3 版完整许可文本，是所有文件的默认许可依据；
• COPYING-README：声明「Nextcloud 中的文件默认采用 AGPLv3（全文见 COPYING）或其后续版本，另有标注的除外」，并指出署名信息见 AUTHORS 文件；
• AUTHORS：贡献者署名列表，文件头部自身也带有 SPDX 头（AGPL-3.0-or-later，含 Nextcloud GmbH 与 ownCloud, Inc. 两条版权行）。

值得注意的是，仓库中的文件实际并存两种许可标识：AGPL-3.0-or-later（新代码）与 AGPL-3.0-only（较早的存量代码）。例如 version.php 头部为 SPDX-License-Identifier: AGPL-3.0-only，而 core/BackgroundJobs/CleanupBackgroundJobsJob.php 头部为 AGPL-3.0-or-later。这解释了为何指南要求修改存量文件时必须「保留原有头」——随意把旧文件的 -only 改成 -or-later 会改变法律语义。

为新文件添加 SPDX 许可证头

指南要求：创建新文件时使用 SPDX 许可证头，年份填创建年份，邮箱地址可选。按文件类型，仓库实际采用的注释风格如下。

前端源码（.js、.ts、.css 等）

指南给出的模板：

/**
 * SPDX-FileCopyrightText: [year] [your name] [<your email address>]
 * SPDX-License-Identifier: AGPL-3.0-or-later
 */

仓库中的真实示例，如 core/src/public-page-menu.ts：

/**
 * SPDX-FileCopyrightText: 2024 Nextcloud GmbH and Nextcloud contributors
 * SPDX-License-Identifier: AGPL-3.0-or-later
 */

可以看到机构贡献者使用「Nextcloud GmbH and Nextcloud contributors」作为署名；个人贡献者则写自己的姓名与（可选的）邮箱。

.vue 文件

由于 <template> 结构不适合块注释，指南规定 .vue 文件使用 HTML 注释：

<!--
  - SPDX-FileCopyrightText: [year] [your name] [<your email address>]
  - SPDX-License-Identifier: AGPL-3.0-or-later
-->

仓库实例见 core/src/components/AppIcon.vue，其头部完全符合该格式，注释之后紧跟 <template> 块。

后端源码（.php）

PHP 文件与 JS 前端使用同一种 docblock 风格：

/**
 * SPDX-FileCopyrightText: [year] [your name] [<your email address>]
 * SPDX-License-Identifier: AGPL-3.0-or-later
 */

实例见 core/BackgroundJobs/CleanupBackgroundJobsJob.php（declare(strict_types=1); 之后紧跟 SPDX docblock）。

头元素说明

元素	取值规则	备注
SPDX-FileCopyrightText	创建年份 + 姓名，可附 <email>	邮箱可选；多个权利人行时按年逐行累加
SPDX-License-Identifier	AGPL-3.0-or-later	新代码的标准标识；存量 -only 文件见下节

修改存量文件时如何更新版权头

指南对存量文件的核心原则是：保留原有许可证头不动，仅追加自己的版权行。分两种情况：

1. 文件已是「泛化头」（generic header），例如 2024 Nextcloud GmbH and Nextcloud contributors 这类组织级署名——此时不必改文件头，只需把自己的姓名加入署名列表文件（指南文字写作 AUTHORS.md，本仓库根目录实际维护的署名文件是 AUTHORS）；
2. 文件头是具体个人的版权行——直接在头中新增一行，指南给出的 diff 示例：

/**
 * SPDX-FileCopyrightText: 2022 Alice <[e-mail]>
 * SPDX-FileCopyrightText: 2023 Bob <[e-mail]>
+* SPDX-FileCopyrightText: [year] [your name] [<your email address>]
 * SPDX-License-Identifier: AGPL-3.0-or-later
 */

仓库中的多版权行实例见 lib/private/Group/Group.php：

/**
 * SPDX-FileCopyrightText: 2016-2024 Nextcloud GmbH and Nextcloud contributors
 * SPDX-FileCopyrightText: 2016 ownCloud, Inc.
 * SPDX-License-Identifier: AGPL-3.0-only
 */

这里可以观察到两个细节：一是年份可写成区间（2016-2024）表示持续维护的年份跨度；二是历史 ownCloud 时代文件保留着 AGPL-3.0-only 标识与 ownCloud, Inc. 的版权行——这正是不动旧头的实际效果。

配套机制：REUSE 清单与 LICENSES 目录

指南末尾提示 SPDX 头的完整规范以 REUSE 项目与 SPDX 官方规范为准（此处不再列出外部链接，可直接阅读仓库内文件自行对照）。仓库对 SPDX 的落地是 REUSE 合规模式，证据如下：

• REUSE.toml：REUSE 清单（version = 1，SPDX-PackageName = "nextcloud"），为无法内嵌头的文件（生成的 l10n 翻译文件、字体、图标、第三方 stub 等）批量声明 SPDX-FileCopyrightText 与 SPDX-License-Identifier，并大量使用 precedence = "aggregate"；
• LICENSES/ 目录：存放所有许可全文，包含 AGPL-3.0-only.txt、AGPL-3.0-or-later.txt，以及各类商标类自定义标识（如 LicenseRef-AppleAppStoreBadge.txt、LicenseRef-DCO.txt 等）。

REUSE.toml 中大量 LicenseRef-* 标识说明：对商标素材等不便采用标准 SPDX 标识的文件，项目通过自定义 LicenseRef- 标识 + LICENSES/ 下对应全文的方式完成合规标注。普通贡献者提交的源码文件一般只需按前两节的模板写文件头，无需触碰清单文件。

DCO：提交签核（Sign-off）要求

指南最后一节要求所有贡献满足 DCO（Developer Certificate of Origin），完整文本见 contribute/developer-certificate-of-origin（Linux 基金会 V1.1 版本），其 .license 附件以 LicenseRef-DCO 标识自我标注。DCO 的核心是贡献者对以下声明的背书：贡献由本人创作或有权提交、基于已许可的先前作品、由他人直接提供且未修改，以及理解贡献记录（含签核信息）将被永久保留并随项目分发。

具体操作在 .github/CONTRIBUTING.md 的「Sign your work」一节中有明确规定：

• 每个 git commit 消息中追加一行：Signed-off-by: 姓名 <邮箱>；
• 必须使用真实姓名，不接受匿名或化名提交；
• 配置好 user.name 与 user.email 后，可用 git commit -s 自动追加签核行；
• 可以设置别名简化操作，如 git config --global alias.ci 'commit -s'，之后用 git ci 提交即自动签核。

同一文件中的「Apply a license」小节反向链接到本文档，说明在仓库工作流里，许可证头规范（本文）与 DCO 签核是提交前的两道并列检查项。

提交前自检清单

1. 新文件：按语言选择注释风格（JS/TS/CSS 与 PHP 用 /** */ 块注释，.vue 用 HTML 注释），写入创建年份、署名与 SPDX-License-Identifier: AGPL-3.0-or-later；
2. 存量文件：只追加自己的 SPDX-FileCopyrightText 行，不改年份区间、不改动原有 SPDX-License-Identifier（尤其注意 -only 与 -or-later 的区别）；
3. 若文件是组织级泛化头，改为在 AUTHORS 中添加自己；
4. 每个提交携带 Signed-off-by: 真实姓名 <邮箱>（推荐 git commit -s）；
5. 生成的翻译文件、图标等无需逐一手写头，其归属由 REUSE.toml 统一管理，贡献时保持原状即可。

按以上清单操作，即可在不签署任何 CLA 的前提下，以版权归属个人的方式合规地向 Nextcloud server 贡献代码。