Bible Network Crypto DeFi Onchain RWA AI Agent Stablecoin Chain SAFU CryptoTax DeFAI AGI Claude Me Claude Skill Claude Design Claude Cowork
獨立知識媒體
與任何項目無關聯
學會用 Claude,每件事都做得更好
claudeskill-me.com
最新
為什麼裝了 Skill 卻不會觸發?15,000 字元預算爆了,Claude Code 會悄悄丟棄描述且不警告  ·  Effort 跟 Temperature 都是「調整輸出」的參數,差在哪裡?新模型上其中一個已經失效  ·  官方 anthropics/skills 倉庫評測:168k 星星的內容品質沒問題,問題出在你根本找不到它  ·  Subagent 不是更聰明的小 Claude——它解決的是隔離問題,不是能力問題  ·  SKILL.md 到底該寫多長?官方 500 行門檻背後的三層漸進式披露邏輯  ·  XML 標籤怎麼用才對?3 個真實案例對比純文字 Prompt 的差異
名詞解析 · tools-integration

Source-Available

原始碼可見授權
tools-integration intermediate

30 秒版 · 給沒耐心的人
一種能看到原始碼、但不保證開源授權所隱含的自由再利用與散布權利的授權類型,常被誤認為等同於開源。
完整解說 +
01 · 這是什麼?

原始碼可見授權是什麼,跟開源有什麼不同?

Source-Available(原始碼可見)指的是一類授權方式:原始碼公開放在可以看到的地方,任何人都能閱讀、參考裡面的實作邏輯,但這不等於開源授權(Open Source License)所隱含的完整權利。開源軟體倡議組織(OSI)對「開源」的定義,要求授權必須允許自由再散布、且不能限制商業使用;Source-Available 授權通常會附加「使用範圍限制」(field-of-use limitation),例如只能用於學習參考、不能整合進自己要對外發布的產品,或是禁止特定商業用途。

兩者最容易混淆的地方,是散布管道其實一模一樣——Source-Available 的程式碼常常放在 GitHub 這類跟開源專案相同的平台上,看起來、用起來都很像開源專案,這也是為什麼這個授權類型最需要特別留意條款細節,不能單憑「原始碼看得到」就假設自己擁有開源授權才有的權利。

02 · 為什麼存在?

Source-Available 授權為什麼存在,解決了什麼問題?

這種授權類型的出現,某種程度上是為了填補「完全開源」與「完全封閉」之間的一個中間地帶。有些公司想公開原始碼,讓開發者能學習、審視、甚至在自己的環境裡測試,藉此建立信任、吸引開發者社群參與;但又不希望競爭對手直接把這份程式碼包裝成競品,或是被雲端服務商未經授權就拿去架設收費服務轉售——這種「開源被拿去營利、原作者卻拿不到對應回報」的疑慮,正是 Source-Available 這類授權模式興起的部分背景。

對於像 Claude Skill 這樣的技術資源,官方選擇把複雜的、實際用於正式產品的技能公開成 Source-Available,等於是在「完全不公開、開發者只能憑空猜測底層邏輯」跟「完全開源、任何人都能直接拿去做競品」這兩個極端之間,選擇了一個折衷:讓開發者看得到、學得到,但不代表可以無限制地重新包裝散布。

03 · 如何影響你的決策?

Source-Available 授權實際運作起來是什麼樣子?

Anthropic 官方的 anthropics/skills 倉庫為例,docx、pdf、pptx、xlsx 這四個文件處理技能被明確標示為 Source-Available,跟倉庫裡其他採用 Apache 2.0(一種標準開源授權)的範例類技能區隔開來。官方在說明裡表明,公開這幾個技能是為了讓開發者「參考更複雜的技能該怎麼寫」,但同時附上明確的免責聲明:這些技能僅供示範與教育用途,Claude 產品裡實際的行為可能跟這裡展示的實作不完全一致,使用前務必在自己的環境裡充分測試。

實務上,判斷一份 Source-Available 的程式碼能不能用在你的場景,關鍵不是看它放在哪裡(GitHub 上跟開源專案長得一樣),而是要仔細讀授權條款裡的使用範圍限制——單純研究學習通常沒有問題,但如果打算把程式碼原封不動或稍加修改後,包進自己要對外發布或商業化的產品,就必須先確認條款是否允許到這個程度。

04 · 你該怎麼辦?

看到一份技術資源標示 Source-Available,我在使用前該做什麼確認?

第一步是找到明確的授權說明文字,不要只看「原始碼公開」這個表面事實就下結論——通常這類說明會出現在倉庫的 README、LICENSE 檔案,或是官方文件裡。第二步是具體確認你的用途落在哪一類:純粹閱讀學習、在自己內部環境測試、還是打算整合進要對外發布的產品,這三種用途在 Source-Available 授權下經常被區別對待,前兩者通常沒問題,第三種最容易踩到限制條款。

第三步,如果同一個倉庫裡混雜了不同授權(例如一部分技能是 Apache 2.0 開源、一部分是 Source-Available),務必逐一確認你要用的那個項目具體適用哪一種,不要因為倉庫整體看起來很開放,就假設所有內容都適用同一套規則——這正是本文開頭提到的、Anthropic 官方倉庫裡實際存在的情況。

資料來源:anthropics/skills - GitHubA Comprehensive Guide to Source-Available Software Licenses, Featuring Heather Meeker - FOSSA Blog
實際例子 +

Anthropic 官方的 anthropics/skills 倉庫是一個具體案例:倉庫裡的 algorithmic-art、canvas-design 這類創意示範技能採用 Apache 2.0 開源授權,可以自由再利用;但實際支撐 Claude 內建文件生成能力的 docx、pdf、pptx、xlsx 這四個技能,則被明確標示為 Source-Available——同一個倉庫、同樣公開在 GitHub 上,卻適用兩套不同的授權規則,這正是為什麼不能單憑「這個倉庫是公開的」就假設裡面每一份程式碼都能自由使用。

常見誤解 +
✕ 誤解1
× 誤解:能在 GitHub 上看到原始碼,就代表可以自由拿來使用或整合進自己的產品,實際是:能看到原始碼只代表這是「原始碼可見」,不等於「開源」——Source-Available 授權常附加使用範圍限制,例如禁止整合進對外發布的產品,必須逐一確認實際條款,不能單憑放在公開倉庫這件事就假設擁有開源授權的全部權利
✕ 誤解2
× 誤解:同一個倉庫裡的所有內容一定適用同一套授權規則,實際是:像 Anthropic 官方的 skills 倉庫這樣,同一個公開倉庫裡可以同時存在 Apache 2.0 開源技能與 Source-Available 技能,必須針對你要用的具體項目個別確認,不能用倉庫整體的觀感去推斷單一檔案的授權
這件事跟你有什麼關係 +
直接影響

優點是能讓公司在保護商業利益的前提下,依然把複雜、實際用於正式產品的程式碼公開出來,讓開發者社群受益於學習與參考;缺點是這種介於開源與封閉之間的中間地帶,天生容易讓使用者誤判自己擁有的權利範圍,一不小心把「可以看」誤認為「可以用」,需要額外花時間確認授權條款細節,不能用看待一般開源專案的直覺去操作。

提問
請至少輸入 10 個字