開放原始碼授權
最後更新:
Breezo 是靠別人的作品運作的。這一頁列出你使用本站時，瀏覽器實際下載並執行的第三方元件、它們各自依據什麼授權散布，以及原始碼可以在哪裡取得。這裡陳述的是事實而不是法律結論：我們用了什麼、我們查過什麼、以及我們沒查什麼。
這一頁涵蓋什麼
底下每一項，都是你的瀏覽器會下載並執行的東西。這個區分是有作用的：建置這個網站會用到大量軟體 —— 編譯器、打包器、影像最佳化工具、測試工具 —— 而它們沒有任何一個會被送到你手上。把建置工具跟真正在你機器上跑的程式混在一起列，只會讓這一頁變長、讓重要的部分被埋掉，所以它們被移到後面自己的段落。
這一頁的純文字版本 —— 含完整的著作權標示，以及我們自行保管的那兩個檔案的雜湊值 —— 與授權全文放在一起發布。這裡提到的每一份授權都放在本站上：你不需要連到別人的伺服器，才能讀到我們告訴你的那些條款。
HEIC 影像：heic-to 與 libheif
HEIC 與 HEIF 檔 —— iPhone 相機預設拍出來的格式 —— 由 heic-to 1.5.2 解碼，它內嵌了 libheif 1.22.2。heic-to 依據 GNU 寬鬆通用公共授權第 3 版或更新版本散布。這個義務的源頭是 libheif 而不是 heic-to 本身：libheif 自己的條款把「函式庫本體」放在 LGPL 之下，而範例程式與各語言的包裝層才是 MIT。我們用的是函式庫本體。
它以單一、自足的 JavaScript 模組形式放在 /_astro/ 底下，檔名以 heic-to. 開頭、後面接一段內容雜湊。只有在你真的處理 HEIC 檔時才會被下載，而且那是這份程式碼在本站唯一存在的地方。它裡面沒有任何一行 Breezo 自己的程式碼，結尾是一個普通的模組匯出 —— 也就是說它是可以被換掉的：只要做出一個匯出 heicTo 的模組（改過的也行），把那個檔案換掉即可。
有一件事與其讓你自己發現，不如直接講明：我們發布的那個檔案，跟 heic-to 專案發布的並非位元組完全相同。我們沒有改動它任何一行原始碼，但我們的建置流程把它又壓縮了一次。一個被再次壓縮過的模組，是否滿足 LGPL 對「以適合重新連結的形式提供函式庫」這項要求的每一種解讀 —— 這個問題我們沒有資格下定論，而我們寧可寫下這段話，也不要假裝這個問題不存在。
另外有一件「沒有出錯」的事，值得記下來，因為你從外面看不出來。heic-to 的建置說明提到一個選用的 HEVC 編碼器 x265，它帶的是 GPL 而不是 LGPL —— 那是一套更嚴格、影響面更廣的授權。我們檢查了實際發布出去的那個檔案，裡面沒有任何 x265 或 libaom 的痕跡：本站只解碼 HEIC，編碼器從一開始就沒有被包進來。這件事現在每次建置都會自動斷言，所以它不可能悄悄改變。
影片：mediabunny
影片工具使用 mediabunny 1.53.0（Mozilla 公共授權 2.0），把已經編碼好的影片封包從一種容器格式搬進另一種。這正是那些工具又快、又不會讓你損失畫質的原因：沒有任何東西被重新編碼，串流是原封不動帶過去的。
MPL 是檔案層級的弱 copyleft 授權 —— 它的要求附著在它所涵蓋的那些檔案上，而不是整個使用它的程式。我們沒有修改那些檔案。mediabunny 以獨立模組形式送出，裡面沒有 Breezo 的程式碼，原始碼發布在下方位址。
兩個由我們自己保管副本的檔案
大部分元件都是透過一般的套件管理器取得。有兩個不是：我們把位元組本身放進自己的儲存庫，因為這兩個案例裡，我們需要的版本都不是套件管理器提供的那一版。對這兩個檔案，我們同時記錄了檔案大小與 SHA-256 雜湊，任何人都可以據此檢查「我們送出去的」是不是「上游發布的」。
SheetJS Community Edition 0.20.3（Apache 授權 2.0，© 2013 年至今 SheetJS LLC）負責在 XLSX 轉 PDF 工具裡讀取試算表。它是 951,904 位元組，完全依照 SheetJS 發布的原樣送出，沒有被重新壓縮。
harfbuzz-subset.wasm 是 HarfBuzz 的 WebAssembly 建置版本，由 harfbuzzjs 專案發布，依據 HarfBuzz 自稱的「Old MIT」寬鬆授權散布。它是 612,552 位元組，取自 harfbuzzjs 的 v1.6.0 釋出版本，同樣是位元組原封不動送出。它的工作是把每一套內嵌字體裁到文件實際用得到的那些字 —— 沒有它，Office 轉 PDF 的每個檔案都會扛著一整套中日韓字型。
你的瀏覽器還會下載哪些
PDF 頁面由 PDF.js（pdfjs-dist 6.2.108，Apache 授權 2.0，Mozilla 基金會）算繪成圖片。PDF 檔案由 pdf-lib 1.17.1（MIT，© 2019 Andrew Dillon）建立與編輯，它內含 pako 1.0.11（© 2014–2017 Vitaly Puzrin 與 Andrei Tuputcyn）負責壓縮，並透過 @pdf-lib/fontkit 1.1.1（MIT）嵌入字體。有密碼保護的 PDF 由 @cantoo/pdf-lib 2.8.1（MIT）解密，新加上保護的也由它加密 —— 那是 pdf-lib 的分支，實作了標準安全處理器，並使用 crypto-js 4.2.0（MIT，© 2009–2013 Jeff Mott 與貢獻者）。這個分支會在「加上保護」與「移除密碼」那兩頁載入，在其他每一頁則只有在檔案真的是加密的時候才會被載入，所以大多數的造訪從來不會下載到它。
ZIP 壓縮檔由 fflate 0.8.3（MIT，© 2026 Arjun Barrett）讀寫。QR code 來自 qrcode 1.5.4（MIT，© 2012 Ryan Day）。影像的編碼、解碼、無損最佳化與縮放由 jSquash 系列套件（Apache 授權 2.0）負責，它們是衍生自 Google Squoosh 的 WebAssembly 建置 —— MozJPEG、libwebp 與 oxipng 就是從這裡進來的。你的瀏覽器會拿到哪一種建置，由 wasm-feature-detect 1.8.0（Apache 授權 2.0，Google）在執行時決定。
網站本身用 Astro 7.2.0（MIT，© 2021 Fred K. Schott）建置。Astro 主要是建置期工具，但它會在每一頁貢獻少量執行期程式碼，所以它屬於這一段，而不是下一段。
哪些不在這份清單上，以及為什麼
有好幾個帶 copyleft 授權的元件會被用來建置本站，但從來不會到你手上 —— 影像最佳化工具 sharp 與它的 libvips 核心、CSS 轉換工具 lightningcss，以及另外二十多個。它們產出的是普通的圖片與普通的 CSS；它們自己的程式碼留在建置用的機器上。我們在發布出去的檔案裡搜尋過它們的任何痕跡，一個都沒有。
這件事值得講出來，因為它是這一頁上影響面最廣的單一判斷：那二十幾個元件之所以「不在清單上」而不是「被列出來」，靠的就是它。如果這個判斷錯了，這一頁就是不完整的。我們寧可把它攤在這裡講明，也不要讓它默默成立、然後指望沒有人問。
我們不確定的地方
這一頁上有三件事是未定的，不是已經解決的。把它們抹平會讓這一頁讀起來更漂亮，也更沒有價值。
第一是 HEIC 那一段提到的重新壓縮問題。對於「一個被打包工具壓縮過的 JavaScript 模組，如何適用 LGPL 的重新連結要求」，我們沒有找到具權威性的指引，而我們不打算自己發明一個答案。
第二是影像編解碼器。發布那些 WebAssembly 二進位檔的 jSquash 套件宣告的是 Apache 授權 2.0，上面記錄的就是這個。我們沒有逐一打開被編譯進去的每一個上游編解碼器的授權檔 —— MozJPEG、libwebp、oxipng 等等 —— 所以請把那一項當成「發布者的宣告」，而不是「我們自己的查證」。
第三是 libde265，heic-to 建置設定裡點名的那個 HEVC 解碼器。我們知道它在裡面；我們沒有直接讀過它的授權。
以上沒有任何一句是在主張我們「有」或「沒有」遵循什麼。它描述的是：我們用了什麼、我們查到哪裡、以及我們在哪裡停下來。
更正
如果這一頁上有任何錯誤、遺漏或過時之處 —— 某個版本已經往前走了、某行著作權標示我們寫錯了、某個元件我們沒注意到 —— 請寄信到 hello@breezofile.com。更正會直接改在這一頁上，而不是只私下回覆你一個人。