軟體開源軟體演變：為什麼開源定義
開源定義的十項準則
目前 OSI 所維護的開源定義，主要由十項準則構成，這些準則彼此環環相扣，共同構築出開源授權的門檻。以下逐一說明：
第一，自由再散布（Free Redistribution）。授權條款不得限制任何一方將軟體作為某個整合性軟體的一部分來販售或贈與，也不得要求對這樣的販售收取權利金或其他費用。這項準則確保了軟體可以透過各種通路流通，也保障了商業再散布的空間。
第二，原始碼（Source Code）。軟體必須包含原始碼，且必須允許以原始碼形式散布。若某些產品未隨附原始碼，則必須提供公開且易於取得的原始碼取得管道，例如免費透過網路下載。刻意混淆原始碼或以壓縮、包裝形式阻撓取得，都不符合此項要求。
第三，衍生作品（Derived Works）。授權條款必須允許修改與衍生作品，並允許這些作品以與原軟體相同的授權條款散布。這項準則是開源協作的核心，確保他人可以在既有基礎上持續創新，而不必擔心法律風險。
第四，原作者的原始碼完整性（Integrity of The Author's Source Code）。授權條款可以限制原始碼以修改後的形式散布，但僅限於當授權條款允許散布「修補檔」以利區別時。授權條款必須明確允許基於修改後原始碼所建立的衍生作品散布，且可以要求衍生作品使用不同的名稱或版本號。
第五，不得歧視個人或團體（No Discrimination Against Persons or Groups）。授權條款不得對任何個人或團體有所歧視，例如不得限制特定國家、特定組織或特定用途的使用者。
第六，不得歧視使用領域（No Discrimination Against Fields of Endeavor）。授權條款不得禁止任何人將軟體用於特定領域，例如不得禁止商業用途或基因研究用途。這項準則確保開源軟體能被廣泛應用於各種場景。
第七，授權條款的散布（Distribution of License）。與軟體相關的權利，必須適用於所有重新散布軟體的人，無須另行簽署額外授權。
第八，授權條款不得專屬於特定產品（License Must Not Be Specific to a Product）。附隨於某個軟體的權利，不得取決於該軟體是否為某特定軟體散布的一部分。也就是說，不能將授權與特定產品綁死，否則將限制了軟體的自由流動。
第九，授權條款不得限制其他軟體（License Must Not Restrict Other Software）。授權條款不得對隨同散布的其他軟體施加限制，例如不得要求所有隨同散布的軟體都必須是開源。
第十，授權條款必須技術中立（License Must Be Technology-Neutral）。授權條款不得以特定技術或介面風格為前提，例如不得要求使用者必須透過特定點擊介面來同意授權。
這十項準則看似繁複，實則圍繞著一個核心精神：讓軟體的自由流通與協作成為可能，同時避免授權條款成為阻礙創新的枷鎖。任何一套授權條款，只要符合這十項條件，便有機會被 OSI 認證為開源授權。
開源定義與自由軟體定義的異同
許多人會將「開源」與「自由軟體」混為一談，實際上兩者高度重疊，但側重點不同。自由軟體定義由 FSF 提出，強調使用者的四大自由，帶有較強的倫理與哲學色彩，認為軟體不應剝奪使用者的自由，封閉軟體是一種社會問題。開源定義則由 OSI 維護，雖同樣保障使用、研究、修改與散布的自由，但論述上更側重工程實務與商業可行性，較少觸及「軟體是否應該自由」的道德判斷。
在實務上，絕大多數被 OSI 認證的開源授權，也都符合自由軟體定義；反之，符合自由軟體定義的授權，通常也會被視為開源授權。兩者的差異更多體現在「為什麼要開源」的論述上，而非「什麼是開源」的具體條件。對企業而言，理解這層細微差異，有助於在選擇授權條款與對外溝通時，精準表達自身的立場與價值觀。
三、開源授權條款的演變與分類
開源定義提供了判斷授權是否「合格」的框架，但在此框架之下，各家授權條款仍有相當大的設計空間。三十年來，開源授權條款經歷了從少數幾種到百花齊放的演變，並逐漸形成幾種常見的分類方式。理解這些分類，是掌握開源軟體實務運作的必經之路。
寬鬆式授權與傳染式授權
最常見的分類方式，是依照授權條款對衍生作品的「約束力」強弱，區分為寬鬆式授權（permissive license）與傳染式授權（copyleft license）。寬鬆式授權，如 MIT、BSD 與 Apache License 2.0，允許使用者自由使用、修改與再散布軟體，甚至可將修改後的版本以閉源形式散布，僅要求保留原始著作權聲明與授權條款。這類授權對商業應用極為友善，因此廣受企業與新創團隊歡迎。
傳染式授權，則以 GPL 系列為代表，要求基於該軟體所衍生的作品，也必須以相同或相容的開源授權釋出。換言之，若你將 GPL 軟體整合進自家產品並對外散布，你的產品也可能被要求開源。這種「以自由保障自由」的設計，確保了軟體不會被中途私有化，但也讓部分企業在採用時格外謹慎。除 GPL 外，LGPL 採取較寬鬆的折衷策略，允許以動態連結方式使用而不必然傳染；AGPL 則進一步將「網路服務使用」納入散布範圍，以應對雲端時代的挑戰。
從 GPL 到 MIT、Apache 的實務選擇
回顧開源授權的演變，可以觀察到一條清晰的軌跡：早期由 GPL 主導，強調軟體自由的不可剝奪；進入 2000 年代後，隨著網路服務與商業開源模式興起，MIT、Apache 2.0 等寬鬆授權逐漸成為主流，尤其在 JavaScript、Python、Go 等語言的生態系中更為明顯。這樣的轉變，並非單純的「寬鬆取代嚴格」，而是反映了不同社群對「如何讓軟體被更多人使用」的策略思考。
以 Apache License 2.0 為例，它在寬鬆授權的基礎上，額外處理了專利授權的問題，要求貢獻者對其貢獻內容授予專利許可，並在專利訴訟發生時終止授權。這種設計在企業環境中特別受到青睞，因為它降低了專利風險，也讓大型企業更願意投入開源專案。相對地，MIT 授權則以簡潔著稱，幾乎不設任何額外條件，適合希望極大化採用率的專案。至於 GPL，則持續在作業系統、嵌入式裝置與社群導向專案中扮演要角，特別是在強調「軟體應保持自由」的領域。
值得注意的是，授權條款的選擇往往與專案的治理模式、商業策略與社群文化密切相關。一個專案若希望建立開放且中立的生態系，通常會選擇寬鬆授權；若希望確保所有衍生作品都回饋社群，則可能偏好 copyleft 授權。沒有絕對優劣，只有是否契合專案目標。
四、開源定義面臨的現代挑戰
開源定義誕生於 1998 年，當時的軟體世界與今日已有天壤之別。雲端運算、軟體即服務（SaaS）、容器化部署與人工智慧模型的興起，對「散布」與「衍生作品」等傳統概念帶來前所未有的挑戰。開源定義是否仍足以應對這些變化，成為近年來社群與產業界爭論的焦點。
雲端服務與開源的界線
在傳統軟體散布模式下，使用者取得軟體複本並在其裝置上執行，因此授權條款可以透過「散布」行為來觸發義務。然而，在雲端服務模式下，使用者往往透過網路遠端使用軟體，並未取得軟體複本，這使得 GPL 等 copyleft 授權的「傳染」效果出現灰色地帶。部分企業因此將開源軟體包裝為雲端服務，卻未依授權精神回饋社群，引發「開源被雲端巨頭搭便車」的爭議。
為應對這樣的挑戰，AGPL 授權被設計出來，將「透過網路提供服務」視為一種散布行為，要求服務提供者也必須釋出原始碼。然而，AGPL 並未被所有企業接受，部分公司甚至明令禁止使用 AGPL 軟體。與此同時，一些基礎設施軟體廠商開始採用「源碼可得」（source-available）授權，例如 Business Source License（BSL）或 Server Side Public License（SSPL），試圖在開源精神與商業利益之間取得平衡。這些授權往往限制雲端服務商將軟體作為服務轉售，因而被 OSI 認定不符合開源定義，卻又在實務上大量被採用，形成「開源」與「源碼可得」兩套語彙並行的局面。
這場爭議的核心，其實正是「開源定義」的價值所在：當廠商試圖以模糊語言包裝限制性授權時，開源定義提供了一把明確的尺，讓社群得以區分「真開源」與「類開源」。這也解釋了為何 OSI 近年來持續強調授權審查的重要性，並對新興授權條款保持嚴格把關。
人工智慧時代的開源爭議
如果說雲端服務挑戰的是「散布」的概念，那麼人工智慧則進一步挑戰了「原始碼」與「衍生作品」的定義。近年來，所謂「開源模型」大量湧現，這些模型公開了權重與部分訓練細節，但其訓練資料、程式碼與授權條件往往未完全透明。學界與社群因此展開激烈辯論：一個僅公開模型權重、卻未公開訓練資料與完整訓練程式碼的模型，能否被稱為「開源」？
OSI 於 2024 年發布「開源 AI 定義」（Open Source AI Definition, OSAID），試圖為這個新領域建立判準。該定義要求開源 AI 系統必須提供足夠的資訊，讓他人得以研究、修改與再散布，包括模型參數、訓練程式碼、資料資訊等。然而，由於訓練資料往往涉及著作權、隱私與商業機密，實務上要完全符合定義並不容易，這也使得「開源 AI」一詞持續處於爭議之中。
這場辯論的意義，不僅在於技術層面，更在於話語權的爭奪。當廠商以「開源」為名行行銷之實，卻未真正賦予使用者自由時，受損的不只是消費者信任，更是整個開源生態的公信力。開源定義在此時此刻的角色，正是扮演那道防線，確保「開源」不會淪為空洞的行銷詞彙。
五、開源定義為何依然重要
走過三十餘年的演變，開源定義早已不只是法律文件上的條文，而是整個軟體生態系的共同基礎。無論是企業採購、開發者選型、社群治理，乃至於公共政策制定，開源定義都提供了一個可依循的判準。以下從實務與治理兩個層面，說明開源定義在今日為何依然關鍵。
對企業與開發者的實務意義
對企業而言，開源定義是風險管理的第一道關卡。當企業引入第三方開源元件時，必須確認其授權條款是否符合開源定義，才能據此評估法律義務、專利風險與商業模式相容性。若誤將「源碼可得」授權當作開源授權使用，可能在產品散布時觸發額外義務，甚至面臨訴訟風險。反之，若能正確辨識授權類型，企業便能在合規的前提下，善用開源軟體加速產品開發。
對開發者而言，開源定義則關乎專案的長期發展。一個明確標示開源授權的專案，更容易吸引外部貢獻者，因為貢獻者可以確信自己的貢獻不會被單方面私有化。此外，開源定義也保障了開發者將專案用於商業目的的權利，這對於希望建立商業生態的專案團隊至關重要。換言之，開源定義不僅保護使用者，也保護貢獻者與維護者，讓多方能在可預測的規則下協作。
對社群治理與永續發展的影響
開源專案的可持續性，近年來成為社群關注的焦點。許多關鍵基礎設施專案由少數志工維護，卻支撐著全球無數商業服務，一旦維護者倦怠或資金斷鏈，便可能引發資安危機。開源定義在此扮演的角色，是確保專案的治理與授權透明，讓企業與基金會能夠在明確的規則下提供資源支持，而不至於因授權混亂而卻步。
此外，開源定義也有助於防止「開源洗白」（open washing）現象。所謂開源洗白，是指廠商將實際上限縮使用者自由的產品，包裝成開源以獲取社群信任與政策優惠。若缺乏明確的定義與認證機制，這類行為將侵蝕公眾對開源的信任，進而影響政府採購、學術採用與企業投資的意願。OSI 的授權審查與認證標章，正是為了維護這份信任而存在。
從更宏觀的角度來看，開源定義也影響著公共政策的走向。近年各國政府在推動數位主權與公共數位基礎設施時，經常將「開源」列為採購或補助條件。若缺乏統一的定義，政策執行便可能出現漏洞，讓不符合開源精神的產品取得不當優勢。因此，開源定義不僅是技術社群的內部規範，更是公共治理的重要參考。
六、結論：定義是開源生態的基石
回顧開源軟體的演變，我們可以看到一條清晰的脈絡：從自由軟體運動對使用者自由的堅持，到開源一詞的策略性誕生，再到開源定義成為全球通用的判準，這一路走來，每一步都伴隨著對「什麼是開源」的重新思考。開源定義之所以重要，並非因為它是一成不變的教條，而是因為它提供了一個可被檢驗、可被討論、也可被修訂的框架，讓社群在面對新技術、新商業模式時，仍能保有共同的語言與底線。
在雲端服務與人工智慧快速發展的今日，開源定義正面臨前所未有的挑戰。源碼可得授權的興起、開源 AI 模型的爭議、以及開源洗白現象的蔓延，都讓人們不得不重新審視「開源」的邊界。然而，正因為這些挑戰存在，開源定義的價值才更加凸顯。它提醒我們，開源不只是一種開發方法，更是一種關於自由、協作與透明的承諾；而定義，正是讓這份承諾得以被檢驗、被守護的基石。
對於身處軟體產業的每一個人而言，理解開源定義，不僅是法律合規的必要功課，更是參與開源生態的基本素養。當我們在專案中選擇授權、在企業中評估開源元件、在社群中討論治理模式時，開源定義都會是那個最可靠的起點。唯有持續關注定義的演變，並在實務中落實其精神，我們才能確保開源生態在快速變動的時代中，依然保持開放、健康且永續。