在商業產品中使用 GitHub 程式碼：授權條款與檢查事項

你正在打造產品，並在 GitHub 上找到一段現成程式碼：一個程式庫、一個範本，或是完整符合你需求的專案。Claude 建議你把它加入專案。接著你停了下來：這些程式碼看起來是公開的，但你真的可以使用嗎？更不用說販售包含這些程式碼的產品了。作者會不會之後找上你？

我會依序說明：為什麼 GitHub 上的開放程式碼本身不代表你已取得許可、哪些授權條款允許你使用程式碼並販售產品、哪些 copyleft 條件可能要求提供受涵蓋作品的對應原始碼，以及如何在使用程式碼前花一分鐘檢查授權。不會用「要看情況」帶過。

在 Ailoot 說明文件中查看實用的操作資訊。

GitHub 上的程式碼可以免費使用，是真的嗎？#

這裡最大的陷阱是「開放」這個詞。你看得到原始碼，就以為既然它沒有被藏起來，自己就可以使用。這種想法是錯的。「開放檢視」和「取得使用授權」是兩回事。

原則上，任何創作作品（包括程式碼）從創作完成的那一刻起，都受著作權保護。在作者明確授權以前，你不得使用。GitHub 在自己的授權參考頁面上也是這麼說的。

另一層是 GitHub 本身。有人認為，既然發布程式碼時已同意 GitHub 的規則，就也能使用那裡其他人的程式碼。規則說的恰好相反。作者將儲存庫設為公開時，只允許其他人檢視和 fork，也就是在 GitHub 內建立副本。這不代表你獲准在自己的工作中使用程式碼。

關鍵詞就在最後一句：「在 GitHub 功能範圍內」以及「額外權利來自授權條款」。Fork 仍留在 GitHub 內。一旦你想在自己的產品中使用程式碼，更不用說販售產品，就需要作者另行授予授權。沒有授權，就沒有權利——即使程式碼就在眼前、清楚可見也是如此。

使用別人的程式碼，由什麼決定？#

關鍵就在一個檔案。妥善維護的儲存庫會附有授權檔案，通常叫做 LICENSE，有時叫 LICENSE.md，也可能直接在 README 中提及。這是作者授予的許可，會列出你可以使用程式碼的條件。通常在 GitHub 儲存庫頁面的側邊欄，就能看到授權名稱，不必先打開檔案。

為了不被法律用語搞得一頭霧水，讀授權條款時可以針對自己的情況問三個問題：

1. 能否在有人付費使用的商業產品中使用這些程式碼？
2. 能否依照自己的需求修改程式碼？
3. 之後是否必須公開產品的原始碼，還是可以維持封閉？

授權條款之間的差異，幾乎都在於第三個問題的答案不同。前兩個問題，一般的開放授權通常都回答「可以」：使用、修改、販售。最容易踩雷的是，授權條款是否會要求你公開自己的程式碼。接下來會用這三個問題來介紹主要類型。

哪些授權條款允許你使用程式碼並販售產品？#

先說好消息。對想打造產品並販售的人來說，最好的選擇是一類稱為寬鬆型授權的條款。這類授權有好幾種，但最常見的是 MIT、Apache 2.0 和 BSD。三者對前兩個問題都回答「可以」，也允許你讓自己的原始碼維持封閉。

最常見、最簡單的是 MIT。它的條文只有一個段落。

簡單來說，MIT 允許你幾乎任意使用程式碼，包括販售產品和讓自己的原始碼維持封閉。唯一的義務是附上授權條款文字和著作權聲明。例如 Babel、.NET 和 Rails 都採用 MIT 發布，所以你很可能早已使用過採用這項授權的程式碼。

Apache 2.0 的做法類似，但多了兩項重要內容。第一，它明確防範專利權主張：程式碼作者承諾不會因為這段程式碼所涉專利而控告你。第二，使用時還有一些較正式的要求。

BSD（2 條款版和 3 條款版）基本上與 MIT 類似：可以使用、修改和販售，但要保留著作權聲明。我把三種授權整理成表格，讓你一眼看出差異。

用在自己的專案時，可以這樣理解：如果別人的程式碼採用 MIT、Apache 2.0 或 BSD，你可以放心。你可以將它用於商業產品、修改它，也可以讓自己的原始碼維持封閉。只要不要移除你所採用部分的授權檔案和著作權聲明即可。

GPL 與 AGPL 的原始碼義務如何適用？#

Copyleft 在條件符合時，讓受涵蓋作品與衍生物保持相同授權。GPLv3 散布受涵蓋或結合衍生作品的來源／物件碼副本，須符合授權與 corresponding-source 義務，不自動套用同一產品或伺服器上的所有獨立程式。

以網路服務為例，在自己伺服器託管 GPL 程式庫、不把副本給使用者，本身不要求公開整項服務。向顧客散布受涵蓋結合 app 才可能觸發，應先查整合與授權，判斷需附哪些來源；送到瀏覽器的用戶端另有散布問題。

AGPLv3 增加網路條件：修改程式後，若使用者遠端互動，應顯著向他們提供該版本對應原始碼。這不同於「只要託管任何 AGPL 元件，所有獨立服務都必須公開」。

專有產品應檢查受涵蓋作品、元件如何結合、是否散布副本，以及 AGPL 網路條件是否適用。無法履行時，選相容寬鬆替代或取得另外許可。商用本身允許，重點是實際授權及整合是否合規。

如果儲存庫完全沒有授權檔案，該怎麼辦？#

常見的錯誤想法是：沒有授權條款，就代表沒有任何限制，可以自由使用程式碼。事實正好相反。沒有授權不等於許可；原則上，它代表未獲許可。沒有授權條款的程式碼仍完全受作者的著作權保護，你不能擅自使用。

我們一開始提到的規則再次適用：程式碼原則上受著作權保護，沒有明確許可就不能複製、修改或散布。在 GitHub 內檢視和 fork 的權限，無法突破這項限制，也不會授予你在自己產品中使用程式碼的權利。

如果程式碼沒有授權，但你真的需要，實際上可以這樣做：

1. 聯絡作者。 直接在儲存庫的討論區或透過電子郵件，詢問是否可以使用程式碼，以及適用哪些條件。有時作者只是忘了新增授權條款，收到詢問後就會補上。
2. 尋找替代品。 幾乎任何用途都有第二個、第三個，甚至第十個相似儲存庫；你總能找到其中一個採用適當 MIT 或 Apache 授權的專案。
3. 不要使用。 如果你沒有取得許可，也找不到替代品，那段程式碼就不屬於你，不能放進準備販售的產品中。「誰會發現？」這種想法，往往會在產品開始賺錢並受到關注時造成麻煩。

如果是 Claude 自己把別人的程式碼加進專案呢？#

這裡還有另一層，很容易和前一種情況混淆。你前往儲存庫並複製檔案時，前面提到的授權義務就直接適用。另一種情況則是你提出要求，讓 Claude 替你寫程式碼。

一般情況下，AI 會針對你的任務組合出自己的文字，而不是複製別人的檔案。此時問題就轉到另一個領域：生成的程式碼由誰擁有？你能不能販售？這是另一個很大的主題，我在一篇談AI 寫出的程式碼歸誰所有的文章中介紹過。

但有一種例外要記住。有時 AI 幾乎逐字產生別人的可辨識程式碼，例如知名程式庫中的完整函式。遇到這種情況，不論實際敲下按鍵的是誰，該程式庫的授權仍然適用。因此，Claude 整段搬進來的大型現成程式碼區塊，也應該像你親自複製的一樣檢查。

使用程式碼前如何檢查授權：操作步驟#

把這些內容整理成一份簡短清單，方便你在將任何第三方程式碼加入專案前檢查。由上而下依序進行。

1. 在儲存庫頁面找到授權名稱

   在 GitHub 上開啟儲存庫。授權名稱通常會顯示在右側欄，或檔案清單下方，例如「MIT License」、「Apache-2.0」或「GPL-3.0」。如果欄位空白，而且沒有授權檔案，就已經是警訊；最後一步再回頭確認。

2. 打開授權檔案本身

   在檔案清單中找到 LICENSE、LICENSE.md 或 COPYING，然後打開。確認檔案中的名稱和側邊欄顯示的名稱一致，也確認授權適用於你要使用的程式碼，而不是只適用於儲存庫中的其他部分。

3. 判斷類型：寬鬆型或著作傳型

   MIT、Apache 2.0 和 BSD 屬於寬鬆型；你可以在封閉式商業產品中使用程式碼。GPL 和 AGPL 屬於 copyleft，需查受涵蓋作品、散布及 AGPL 網路條件才確定來源義務；名稱本身不能說明哪些獨立元件受涵蓋。

4. 對照自己的情況

   回答三個問題：你要販售產品嗎？你會修改程式碼嗎？你想讓原始碼維持封閉嗎？MIT、Apache 和 BSD 適用於販售的封閉式產品。GPL／AGPL 應判斷哪些受涵蓋或結合作品需對應來源、何時觸發，再評估能否履行。

5. 沒有授權就不要使用

   如果沒有授權檔案，而且 README 也沒有說明使用許可，你就不能使用程式碼。聯絡作者徵求許可，或尋找採用適當授權的同類作品。「公開可取得」不等於取得許可。

這項檢查看起來很繁瑣，直到你的產品成長、開始賺錢，有人問起產品內使用的第三方程式碼時才會明白。開始前花 2 分鐘，比日後處理爭議省事得多。我另外談過產品上線後該怎麼做，才能避免停滯：我用 AI 打造了產品；接下來呢。

開啟 Ailoot。