# 在商業產品中使用 GitHub 程式碼：授權條款與檢查事項
> 寬鬆型授權條款 MIT、Apache 和 BSD，著作傳（copyleft）GPL/AGPL，缺少 LICENSE 檔案，以及檢查 AI 加入的程式碼來源。
Source: https://ailoot.ai/blog/zh-hant-tw/github-code-commercial-licenses/
Canonical: https://ailoot.ai/blog/zh-hant-tw/github-code-commercial-licenses/
Language: zh-Hant-TW
Publisher: Ailoot (https://ailoot.ai/)
Translation: guide-177
Revision: sha256-7bf7655548f9e009f3a465338c85681e526fa015b445171d72c4dcd34182ccb0
你正在打造產品，並在 GitHub 上找到一段現成程式碼：一個程式庫、一個範本，或是完整符合你需求的專案。Claude 建議你把它加入專案。接著你停了下來：這些程式碼看起來是公開的，但你真的可以使用嗎？更不用說販售包含這些程式碼的產品了。作者會不會之後找上你？
我會依序說明：為什麼 GitHub 上的開放程式碼本身不代表你已取得許可、哪些授權條款允許你使用程式碼並販售產品、哪些 copyleft 條件可能要求提供受涵蓋作品的對應原始碼，以及如何在使用程式碼前花一分鐘檢查授權。不會用「要看情況」帶過。
[在 Ailoot 說明文件中查看實用的操作資訊](https://ailoot.ai/docs/)。
注意
本文僅供參考；我不是律師。以下會說明常見授權條款和規則的內容，並附上主要來源連結，但請依照授權條款內容確認你的具體情況；如果產品規模大且涉及商業用途，也請諮詢律師。由你自行做決定。
## GitHub 上的程式碼可以免費使用，是真的嗎？
重點
不行。程式碼可以被檢視，不代表你獲准在自己的工作中使用。原則上，所有程式碼都受著作權保護，除非作者另行授權，否則你不得使用。單是發布在 GitHub 上，只代表其他人可以檢視儲存庫，並在 GitHub 內建立副本。你把程式碼放進自己產品的權利，來自作者附加到儲存庫的授權條款；GitHub 本身不會授予這項權利。
這裡最大的陷阱是「開放」這個詞。你看得到原始碼，就以為既然它沒有被藏起來，自己就可以使用。這種想法是錯的。「開放檢視」和「取得使用授權」是兩回事。
原則上，任何創作作品（包括程式碼）從創作完成的那一刻起，都受著作權保護。在作者明確授權以前，你不得使用。GitHub 在自己的授權參考頁面上也是這麼說的。
當你創作一項作品時（程式碼也是創作作品），它原則上會受到專屬著作權保護。除非你附上另有規定的授權條款，否則其他人若複製、散布或修改你的作品，就可能面臨權利主張或訴訟。
— choosealicense.com（GitHub 參考專案），https://choosealicense.com/no-permission/
另一層是 GitHub 本身。有人認為，既然發布程式碼時已同意 GitHub 的規則，就也能使用那裡其他人的程式碼。規則說的恰好相反。作者將儲存庫設為公開時，只允許其他人檢視和 fork，也就是在 GitHub 內建立副本。這不代表你獲准在自己的工作中使用程式碼。
將儲存庫設為公開，即表示你授予其他使用者非專屬、全球性的授權，讓他們透過本服務，在 GitHub 功能範圍內使用、展示及重製（透過 fork）你的素材。你可以透過附加授權條款授予其他權利。
— GitHub 服務條款，第 D 節，https://docs.github.com/en/site-policy/github-terms/github-terms-of-service
關鍵詞就在最後一句：「在 GitHub 功能範圍內」以及「額外權利來自授權條款」。Fork 仍留在 GitHub 內。一旦你想在自己的產品中使用程式碼，更不用說販售產品，就需要作者另行授予授權。沒有授權，就沒有權利——即使程式碼就在眼前、清楚可見也是如此。
## 使用別人的程式碼，由什麼決定？
重點
由儲存庫中的授權檔案決定，檔名通常是 LICENSE 或 LICENSE.md。這是作者授予的許可，說明你可以或不可以如何使用程式碼。授權條款會回答三個問題：你能否在商業產品中使用程式碼、能否修改程式碼，以及能否讓自己的原始碼維持封閉。不同授權的答案各不相同，因此首先要檢查這個檔案，然後才打開程式碼本身。
關鍵就在一個檔案。妥善維護的儲存庫會附有授權檔案，通常叫做 LICENSE，有時叫 LICENSE.md，也可能直接在 README 中提及。這是作者授予的許可，會列出你可以使用程式碼的條件。通常在 GitHub 儲存庫頁面的側邊欄，就能看到授權名稱，不必先打開檔案。
為了不被法律用語搞得一頭霧水，讀授權條款時可以針對自己的情況問三個問題：
1. **能否在有人付費使用的商業產品中使用這些程式碼？**
2. **能否依照自己的需求修改程式碼？**
3. **之後是否必須公開產品的原始碼，還是可以維持封閉？**
授權條款之間的差異，幾乎都在於第三個問題的答案不同。前兩個問題，一般的開放授權通常都回答「可以」：使用、修改、販售。最容易踩雷的是，授權條款是否會要求你公開自己的程式碼。接下來會用這三個問題來介紹主要類型。
## 哪些授權條款允許你使用程式碼並販售產品？
重點
對商業產品最方便的是寬鬆型授權條款：MIT、Apache 2.0 和 BSD。它們幾乎允許所有事情：使用和修改程式碼、販售產品，以及讓你自己的原始碼維持封閉。只有一項義務：保留授權條款文字和著作權聲明。Apache 2.0 也能防範專利權主張，並要求標示修改過的檔案。如果別人的程式碼採用這些授權之一，你就可以放心用在商業產品中。
先說好消息。對想打造產品並販售的人來說，最好的選擇是一類稱為寬鬆型授權的條款。這類授權有好幾種，但最常見的是 MIT、Apache 2.0 和 BSD。三者對前兩個問題都回答「可以」，也允許你讓自己的原始碼維持封閉。
最常見、最簡單的是 MIT。它的條文只有一個段落。
特此免費授予任何取得本軟體副本的人不限用途的權利，包括使用、複製、修改、合併、發布、散布、再授權和販售本軟體副本的權利，前提是所有副本均須附上上述著作權聲明及本許可聲明。
— MIT 授權條款，opensource.org，https://opensource.org/license/mit
簡單來說，MIT 允許你幾乎任意使用程式碼，包括販售產品和讓自己的原始碼維持封閉。唯一的義務是附上授權條款文字和著作權聲明。例如 Babel、.NET 和 Rails 都採用 MIT 發布，所以你很可能早已使用過採用這項授權的程式碼。
Apache 2.0 的做法類似，但多了兩項重要內容。第一，它明確防範專利權主張：程式碼作者承諾不會因為這段程式碼所涉專利而控告你。第二，使用時還有一些較正式的要求。
你可以在任何媒介中重製及散布本作品或衍生作品的副本，無論是否經過修改，但須提供本授權條款的副本、標示修改過的檔案、保留著作權及專利聲明，並在 NOTICE 檔案存在時附上其可讀取的副本。
— Apache License 2.0，第 4 節，https://www.apache.org/licenses/LICENSE-2.0
BSD（2 條款版和 3 條款版）基本上與 MIT 類似：可以使用、修改和販售，但要保留著作權聲明。我把三種授權整理成表格，讓你一眼看出差異。
| 授權條款 | 販售產品 | 原始碼維持封閉 | 必須做的事 | 專利保護 |
|----|----|----|----|----|
| MIT | 可以 | 可以 | 保留著作權聲明和授權條款文字 | 沒有相關條款 |
| Apache 2.0 | 可以 | 可以 | 保留著作權聲明和 NOTICE 檔案，標示修改內容 | 有 |
| BSD（2 條款版和 3 條款版） | 可以 | 可以 | 保留著作權聲明 | 無 |
用在自己的專案時，可以這樣理解：如果別人的程式碼採用 MIT、Apache 2.0 或 BSD，你可以放心。你可以將它用於商業產品、修改它，也可以讓自己的原始碼維持封閉。只要不要移除你所採用部分的授權檔案和著作權聲明即可。
## GPL 與 AGPL 的原始碼義務如何適用？
GPL 與 AGPL 允許商用。GPL 來源義務在傳遞受涵蓋作品時產生，單純伺服器執行、未傳送副本，不是該觸發。AGPLv3 對遠端互動的修改版本增加提供原始碼要求；應判斷哪個結合作品受涵蓋，分開獨立元件不會自動全部納入。
Copyleft 在條件符合時，讓受涵蓋作品與衍生物保持相同授權。GPLv3 散布受涵蓋或結合衍生作品的來源／物件碼副本，須符合授權與 corresponding-source 義務，不自動套用同一產品或伺服器上的所有獨立程式。
以網路服務為例，在自己伺服器託管 GPL 程式庫、不把副本給使用者，本身不要求公開整項服務。向顧客散布受涵蓋結合 app 才可能觸發，應先查整合與授權，判斷需附哪些來源；送到瀏覽器的用戶端另有散布問題。
AGPLv3 增加網路條件：修改程式後，若使用者遠端互動，應顯著向他們提供該版本對應原始碼。這不同於「只要託管任何 AGPL 元件，所有獨立服務都必須公開」。
專有產品應檢查受涵蓋作品、元件如何結合、是否散布副本，以及 AGPL 網路條件是否適用。無法履行時，選相容寬鬆替代或取得另外許可。商用本身允許，重點是實際授權及整合是否合規。
## 如果儲存庫完全沒有授權檔案，該怎麼辦？
重點
沒有授權檔案，就不能使用程式碼。這不代表「免費」；恰恰相反，沒有授權條款時，程式碼仍完全受作者的著作權保護，你無權使用、複製或修改。能在 GitHub 內檢視和 fork 並不能改變這一點，也不會讓你有權把程式碼放進產品。如果你真的需要這段程式碼，唯一妥當的做法是寫信給作者徵求許可，或等作者新增授權條款。
常見的錯誤想法是：沒有授權條款，就代表沒有任何限制，可以自由使用程式碼。事實正好相反。沒有授權不等於許可；原則上，它代表未獲許可。沒有授權條款的程式碼仍完全受作者的著作權保護，你不能擅自使用。
我們一開始提到的規則再次適用：程式碼原則上受著作權保護，沒有明確許可就不能複製、修改或散布。在 GitHub 內檢視和 fork 的權限，無法突破這項限制，也不會授予你在自己產品中使用程式碼的權利。
如果程式碼沒有授權，但你真的需要，實際上可以這樣做：
1. **聯絡作者。** 直接在儲存庫的討論區或透過電子郵件，詢問是否可以使用程式碼，以及適用哪些條件。有時作者只是忘了新增授權條款，收到詢問後就會補上。
2. **尋找替代品。** 幾乎任何用途都有第二個、第三個，甚至第十個相似儲存庫；你總能找到其中一個採用適當 MIT 或 Apache 授權的專案。
3. **不要使用。** 如果你沒有取得許可，也找不到替代品，那段程式碼就不屬於你，不能放進準備販售的產品中。「誰會發現？」這種想法，往往會在產品開始賺錢並受到關注時造成麻煩。
## 如果是 Claude 自己把別人的程式碼加進專案呢？
重點
這是另一種情況，不要與直接複製儲存庫混為一談。你自行從特定儲存庫取用程式碼時，必須遵守其授權條款。Claude 或其他 AI 依照你的要求產生程式碼時，通常會針對任務組合出自己的文字，而不是複製別人的檔案；此時問題會轉為生成程式碼的權利。不過，如果 AI 明確重現了別人受授權保護的可辨識程式碼片段，授權條款仍然適用。這兩種情況都值得檢查程式碼來源。
這裡還有另一層，很容易和前一種情況混淆。你前往儲存庫並複製檔案時，前面提到的授權義務就直接適用。另一種情況則是你提出要求，讓 Claude 替你寫程式碼。
一般情況下，AI 會針對你的任務組合出自己的文字，而不是複製別人的檔案。此時問題就轉到另一個領域：生成的程式碼由誰擁有？你能不能販售？這是另一個很大的主題，我在一篇談AI 寫出的程式碼歸誰所有的文章中介紹過。
但有一種例外要記住。有時 AI 幾乎逐字產生別人的可辨識程式碼，例如知名程式庫中的完整函式。遇到這種情況，不論實際敲下按鍵的是誰，該程式庫的授權仍然適用。因此，Claude 整段搬進來的大型現成程式碼區塊，也應該像你親自複製的一樣檢查。
## 使用程式碼前如何檢查授權：操作步驟
重點
流程如下：開啟儲存庫頁面，查看側邊欄中的授權名稱；打開 LICENSE 檔案本身；確認它屬於寬鬆型（MIT、Apache、BSD）還是著作傳型（GPL、AGPL）；依照自己的情況評估，決定使用程式碼或尋找替代品。如果完全沒有授權，就不要使用。整個檢查只要幾分鐘，應該在程式碼進入專案之前進行，而不是事後才查。
把這些內容整理成一份簡短清單，方便你在將任何第三方程式碼加入專案前檢查。由上而下依序進行。
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 打造了產品；接下來呢](https://ailoot.ai/blog/zh-hant-tw/ai-product-maintenance-after-launch/)。
### 常見問題
可以販售包含 GitHub 上別人程式碼的產品嗎？
可以，前提是程式碼採用寬鬆型授權，例如 MIT、Apache 2.0 或 BSD。這些授權允許你在商業產品中使用程式碼、販售產品，並讓自己的原始碼維持封閉，只要求你保留授權條款文字和著作權聲明。GPL 與 AGPL 也允許商用，但來源義務取決於受涵蓋作品，以及散布或適用 AGPL 網路觸發。若沒有授權檔案，就完全不能使用程式碼。
GitHub 儲存庫沒有授權代表什麼？
代表你不能使用程式碼。原則上，沒有授權就是沒有許可；這不代表「免費」。程式碼仍完全受作者的著作權保護。在 GitHub 內檢視和 fork 儲存庫，不會讓你有權在產品中使用程式碼。如果你需要這段程式碼，請聯絡作者徵求許可，或尋找採用開放授權的同類作品。
對我的產品來說，MIT 和 GPL 有什麼不同？
MIT 允許你使用和修改程式碼、販售產品，並讓自己的原始碼維持封閉；唯一義務是保留授權條款文字。GPL 也允許商用，傳遞受涵蓋結合或衍生作品時，需履行對應來源與相同授權義務；單純託管未傳副本不同，獨立元件不自動涵蓋。
使用 MIT 授權的程式碼，需要做什麼嗎？
需要，只要做一件小事：在專案中保留所用程式碼的 MIT 授權條款文字和著作權聲明。通常就是原始程式碼附帶的 LICENSE 檔案。MIT 不要求其他事項；你可以修改程式碼、販售產品，並讓原始碼維持封閉。
如果是 Claude 自己加入別人的程式碼，而不是我加入的呢？
你仍然應該檢查來源。AI 通常會針對你的任務產生自己的文字，這時問題就轉為生成程式碼的權利，是另一個主題。但如果 AI 幾乎逐字重現了知名程式庫中別人的可辨識程式碼片段，該程式庫的授權仍然適用。對於整段搬進來的大型現成程式碼區塊，要像檢查自己複製貼上的程式碼一樣檢查。
### 來源
- [choosealicense.com - GitHub 選擇授權條款的參考專案](https://choosealicense.com/)
- [choosealicense.com - 沒有授權代表什麼](https://choosealicense.com/no-permission/)
- [GitHub 服務條款，第 D 節（授予其他使用者的授權）](https://docs.github.com/en/site-policy/github-terms/github-terms-of-service)
- [MIT 授權條款（opensource.org）](https://opensource.org/license/mit)
- [Apache License 2.0（apache.org）](https://www.apache.org/licenses/LICENSE-2.0)
- [GNU General Public License v3.0（gnu.org）](https://www.gnu.org/licenses/gpl-3.0.en.html)
- [GNU Affero General Public License v3.0（gnu.org）](https://www.gnu.org/licenses/agpl-3.0.en.html)
[開啟 Ailoot](https://ailoot.ai/)。
## 常見問題：在商業產品中使用 GitHub 程式碼：授權條款與檢查事項
### 伺服器用了 GPL 程式庫，就必須公開整個網路服務嗎？
單純託管且未傳副本，不是 GPL 散布觸發；若散布受涵蓋的結合／衍生 app，可能有來源義務，獨立元件不自動全部受涵蓋。
### AGPLv3 對網路服務多什麼條件？
經修改的 AGPL 程式支援遠端互動時，必須向這些使用者提供對應原始碼。應查程式與整合，不假定完全無須公開，也不假定所有獨立服務都得開源。
## Ailoot · 公司及其專案組合
Ailoot以累積的營運經驗、廣大的客戶群、穩定的服務及持續的KPI管理為基礎。
公司及其專案組合：數百萬客戶，每月銷售額達數十億。
Ailoot將這些營運經驗用於API存取，讓客戶的產品、代理、應用程式及自動化流程使用AI功能。