創作權益、署名與歸屬於你的部分

你應該能夠使用他人創作的優秀作品，而不必成為授權方面的專家，也不必悄悄抹去創作者的名字。因此，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、衍生下載，以及「傳送」和「複製影像」，目前都還不會評估或攜帶這些署名。