创作权益、署名与归属于你的部分

你应该能够使用他人创作的优秀作品，而不必成为许可证方面的专家，也不必悄悄抹去创作者的名字。因此，Lolly 会记录它所引用的每一件作品的来源，读取为其记录的许可证，弄清楚该许可证对你实际所做的这一次使用提出了什么要求，完成程序能够完成的部分，并指出只有你才能完成的部分。

这些都不是法律意见，也不是对你项目的裁定。Lolly 记录事实，套用一小套从许可证本身法律文本中读取的规则，并展示其推演过程。带条件的许可证是一种正常、被允许的选择，绝不会被当作有问题的素材呈现。

三个彼此独立的事实

“CC BY 4.0”、“这次使用需要署名”和“署名已经在你刚下载的文件里”是三种不同的陈述，Lolly 会将它们分开处理：

• 证据是来源方所声明的内容，按照发现时的原样记录下来，并注明是谁说的、在哪里读到的。之后的导入永远不会覆盖更早的记录。
• 义务是经过审核的规则，针对某一次使用、某一条交付路径和某一群受众，从这份证据推导出的结果。在你私下工作期间，需要分享时才适用的条件仍然只是有条件的。
• 交付是成品字节实际携带的内容，通过回读来衡量。只有在读取程序在交付的文件中确实找到署名之后，Lolly 才会说署名已经包含在内。

你最先在哪里遇到它

表情符号集是最常见的情形。Twemoji 采用 CC BY 4.0，因此带有表情符号的标题导出时会自动附上作品署名，你无需再做任何事。两套 OpenMoji 都采用 CC BY-SA 4.0，因此以品牌处理效果为其中一个字形重新上色，属于一份演绎作品，分享这份演绎作品时，需要你选择一次兼容的许可证。选择表情符号集本身永远不会被阻止，而且在你做选择的位置，选集控件会注明许可证。同样的规则也适用于目录插图、LUT、字体以及其他任何已记录的作品。

Lolly 使用的措辞

同一套措辞贯穿导出面板、验证、命令行和机器可读结果。

Lolly 不会使用“版权已验证”“法律上安全”“完全清晰”或“权利已清理”这类说法，产品中任何地方都没有一枚统一的绿色许可证徽章。这些说法会宣称一些任何程序都无法核实的事情。

Lolly 已经审核过的许可证

规则版本为 rights-rules-2026-09-13.2。以下每一条规则都摘自许可证本身的法律文本，其出处章节在 engine/src/rights-profiles.ts 中和本页都有标注。版本号和移植版本都会按记录原样保留：一份 CC BY 3.0 声明会保留其自身的版本号，而不会因为应用的选择器更偏好 4.0 就被报告成 4.0。

已记录，尚未解读

CC BY-NC、CC BY-ND，以及 NC-SA 和 NC-ND 的组合都能被识别，它们的条件也会被列出，但这里没有任何规则去解读它们。它们会报告 licence.unknown，并附上一行说明具体条件的文字。是否属于商业场景，无法单凭价格或账户判断，每一种组合文本在被规则处理之前，都需要单独审核。

还有三种同样诚实的回答，但它们都不代表许可：

• 一个 LicenseRef- 标识符会原样返回。它指向一份保存下来的定义，而不会仅凭拼写就被判定为专有许可证。
• 一份任何规则都无法识别的声明会以未解析的状态返回，原始文字会保留在旁边。
• A OR B 是权利人给出的一个选择，因此每一个备选项都会被返回，且不会自动选定其中之一。A AND B 是累加关系，这些规则只会记录下来，而不会把两份档案合并解读。

缺失的许可证信息，绝不会被当作这件作品可以自由转发的证据。

Lolly 为你做了什么

• 在目录中。 一件作品的详情页会显示其来源与创作者、标准许可证名称（原始标签保留在下方）、已记录时可供复制的署名，以及一行说明使用它需要满足什么要求的文字。磁贴只陈述要求，绝不会声称某次导出已经完成。
• 在导出面板中。 一旦某次渲染用到了已记录的作品，就会出现一张来源署名卡片。它会显示状态、藏在“详情”后面的署名文字、一个复制署名按钮，以及在还有决定要做时出现的一张内嵌卡片。这个决定绝不会以阻断式对话框的形式出现：即便还有事项待处理，下载依然会继续进行，私下使用的作品也始终可用。
• 在文件中。 只要某次导出放置了已记录的作品，就会为每一件不同的作品写入一条 Content Credentials 来源成分，并与其原始字节在其公开地址上绑定，其中带有创作者、许可证及其链接、来源、版本以及改动说明。Lolly 只会为它自己观察到的事实签名，绝不会代表上游创作者签署一项声明，而“验证”会说明这两者之中究竟发生了哪一种。
• 写入之后。 在任何提示说署名已包含在内之前，交付的字节都会先被回读一遍。未通过验证的凭证，不算作已交付的署名。
• 在可编辑的 .lolly 文件中。 只有当经过审核的许可证记录了转发来源的权限时，字节才会随文件一起流转，而该包内的 CREDITS.txt 会列出流转了什么内容、依据哪份许可证，以及哪些内容被扣留以及扣留的原因。未记录许可证的内容会被扣留。你依然可以有意地包含这些被扣留的内容，署名文件会记录下这是你自己的选择。
• 在“验证”中。 来源面板会列出该文件记录的每一个来源，包括一份自动生成的摘要、署名、一个复制署名按钮、一个只有在你要求时才会打开的打开来源链接，以及说明检查范围的文字。只有当你选定一种使用方式时，系统才会提出“检查这种用途”的问题，而回答这个问题不会去获取任何外部内容。
• 当你移除元数据时。 该操作会告诉你文件不再携带多少条来源署名，提供署名文字，并提供一份连同署名一起交付的干净文件。已移除的字节绝不会被重新盖章。

始终归你所有的部分

• 你的许可证选择由你决定。 认领一份文件，把过去混在一起的三种状态区分开来：未声明任何公开许可证、明确的版权所有声明，以及一份真正生效的公开授权。Lolly 只会为后两种状态写入一行权利说明，且绝不会从你的个人资料中直接取用。
• 你的作品不会被替你重新授权。 来源的条款和你自己对成果的声明，是两条各自独立的记录。相同方式共享（ShareAlike）条件只适用于它所约束的那份演绎作品，不会自动延伸到你制作的其他一切内容。
• 私下使用的作品始终可用。 只有在涉及分享时，那些以分享为前提的条件才会被提出。这里的任何机制都不会变成导入禁令，也不会有任何许可证问卷阻挡在你和自己的文件之间。
• 一项决定会连同它所依据的事实一起被记住。 你所记录的每一次选择，都会附上一份针对当时的作品、用途、交付路径和受众所生成的指纹。一旦更换素材集、处理方式、格式或受众，系统就会再次提出这个问题。这里没有一个可以“忽略许可证”的总开关，因为点掉一条警告并不能真正交付署名，也不能真正授予许可。
• 你的个人信息与第三方的署名彼此独立。 移除你自己的个人元数据，不会连带移除已获得署名的创作者；一份必须提供的署名，也绝不能成为导出你联系方式的借口。

在命令行中

当评估结果存在必须提供的署名或出现问题时，一次渲染会向标准错误输出打印一个 Rights: 区块。其中包含状态、每个问题各占一行并采用 code - summary 的格式、对交付文件的回读结果，以及可供粘贴的署名文字。

Rights: actions-required
  licence.adaptation-choice - If you share this adaptation, it needs a compatible licence.
  Credential intact. It records 1 source. The exporter recorded it; the source did not sign a credential of its own.
  Credits included in this file's metadata.
  "water wave (OpenMoji Color 17.0.0)" by Vanessa Boutzikoudi (OpenMoji), CC BY-SA 4.0 https://creativecommons.org/licenses/by-sa/4.0/, source https://raw.githubusercontent.com/hfg-gmuend/openmoji/f9fc506a3f913be9897ab0181d611d4c910a4104/color/svg/1F30A.svg, changes: recoloured.

这两个陈述彼此独立，这正是要把它们分开的原因：署名已经写入文件，但在文件被分享之前，仍有一项许可证方面的决定尚未做出。无论如何，文件都会照常写入。

退出码 4 正是这个命令行工具一贯用来表示某项保护性检查给出否定答案的代码。它刻意不用 3，因为 3 的含义是“换一台运行器重试”，而无论换到哪台运行器，都同样会有一项许可证决定在等着你。

--rights=private 表示这次渲染不会交付给任何人。这个区块依然会打印，署名依然可以复制；退让的只是那条以分享为前提的条件，同时也不会记录任何交付声明。这里没有用来忽略某项条件的标志：--rights=ignore 属于用法错误。

这些问题代码是稳定且机器可读的，与界面翻译文字无关：

attribution.source-missing, attribution.delivery-missing, licence.adaptation-choice, licence.use-not-covered, licence.grant-conflict, licence.unknown, source.redistribution-unknown, credential.ingredient-missing.

在 MCP 上，lolly_verify 会返回一个 rights 负载，其中包含摘要、每条已记录来源各占一项，以及所述的检查限制；无需浏览器的 lolly_render 则会返回 status、issues、credits、fingerprint，以及通过回读字节来衡量得出的 creditsInFile 标志。

规则存放的位置

四个引擎模块，全部都是纯函数：不访问网络、不读取时钟、不接触文件系统。规则数据带有版本号，保存在代码仓库中，绝不会临时抓取。

tests/fixtures/rights/ 目录下的预期结果文件，都是直接依据许可证文本编写的，而不是依据评估器的输出结果；其 README 中会为每一条预期结果标注对应的出处章节。

这套机制做不到的事

这里明确说清楚，因为一处未被指明的空白，会被误读成一项承诺。

• NC 与 ND 不会被解读。 它们的条件只会被记录下来，并报告为未知。
• 不会确认最终去向。 Lolly 只会准备好一段说明文字；某个连接器接受了一次请求，并不能证明署名真的送达了读者，这里也不会承诺之后的再次上传、截图或转码会保留隐藏的元数据。
• 原生元数据中的署名字段不会由方案写入。 署名会通过 Content Credentials 以及可读文字来传递。IPTC 和 XMP 中按来源划分的署名字段，目前还不会由署名方案自动填写。
• 更正与撤回功能尚未实现。 为已记录的作品补上缺失的创作者信息、进行本地更正，以及撤回一条记录，目前都没有对应的界面。
• 尚未支持接入外部供应方。 已购买的素材库内容、自定义授权，以及供应方账户，目前都没有导入通道，因此这些授权只能以你自己声明的形式来记录。
• 组织策略尚未与这些结果整合。 目前导出策略和许可证条件仍是两套彼此独立的机制，组织内部的批准并不等同于来自权利人的许可。
• 还有若干交付路径尚未接入这套机制。 下载一份目录原始文件、批量 ZIP、衍生下载，以及“发送”和“复制图像”，目前都还不会评估或携带这些署名。