隨手行文 | 閒語集 | 過客留言 | 飛鴿傳書

《Linux紅帽旋風》摘要

出版商與系列名：天下文化 - 資訊時代 13
原名：Under The Radar
作者：Robert Young (Chairman of Red Hat, Inc.) and Wendy Goldman Rohm
譯者：鄭鴻坦
ISBN：957-621-665-6
First edition: 2001.12.5
Second edition: 2002.10.30

原始碼授權

所有這些已經公開發布，供開放原始碼軟體所使用的標準授權協議，都有一些共通的特點。最明顯的就是，所謂開放軟體「自由使用」，除了表明軟體不收費之外，更意謂著將有關使用與再散播的限制減至最低程度。

亥克認為，最好是選一種現有的開放原始碼授權合約來使用，或是根據我們特定的業務需求，選擇一種來加以修改。

選擇中還包括了根本不必授權，也就是將軟體宣布為公共版權。雖然「公共版權軟體」這個名詞，經常被隨意用來泛指開放原始碼軟體或自由軟體，但是如果嚴格定義，公共版權軟體指的是沒有版權的軟體。就是說版權已經過了時效，或是版權持有人明確宣告放棄版權。沒有版權，就沒有所謂軟體「所有人」能加以授權；因而在任何情況下，任何人都可以使用該軟體，沒有任何限制。

「把軟體放進公共領域，能給使用者及開發人員最大限度的自由。然而，它同時會開啟另一個可能性，讓有些開發者利用這個軟體做基礎，創作出所有權專屬的程式。」亥克說道。如果這些程式在市場上取得優勢，從實際角度來看，縱使它仍有某些部分屬於公共版權，這軟體已經不再算是開放原始碼了。事實上，使用者甚至可能不知道，這個所有權專屬的產品，利用了公共版權的程式碼。

由於這個潛在的問題，大部分開放原始碼的支持者提倡，不要將軟體放進公共領 域；即使是不相信「智慧財產」這個觀念的開發人員，也鼓勵大家使用著作權的機制， 只要透過正式的開放原始碼授權，就能確保軟體的原始程式碼可供眾人運用。 GNU GPL 就是最好的例證（這一點稍後會說明）。

BSD授權

另外一方面，諸如 BSD 這類授權方式，相對較少對開發人員的行為加以限制，包括限制其發展開放原始碼產品的所有權專屬版本。

如亥克所說明的， BSD 授權原先被用在加州大學柏克萊分校發表的各個 Unix 版 本上。從此以後， BSD 授權或是其改版授權（像是原始的麻省理工學院及X協會授 權），就被其他幾個開放原始碼專案所沿用。

BSD 授權正式授與人們對原始程式碼或二進位碼無限制的使用權，並要求保留開發者的版權說明，以及相關資料。亥克指出，它還要求開發者得在廣告資料上列名，並 在法律文字上明訂開發者的有限責任。

有些源自 BSD 授權的授權書，像是原始 X 協會授權，由於省略了廣告要求，因此 遭受到批評。其他則是添加條款，要求軟體必須「收費」供應。

由於最初研擬 BSD 授權，是為了發表大學因研究而開發出的非商業性軟體副產品，所以它的法律條文反映了這種傳承。它們恪守給予研究者（也就是開發者）適當肯 定的學術傳統，保障大學或者開發者受雇的機構擁有基本的法律權益。除此之外，它的條款對軟體的使用，沒有實質上的限制。

從商業軟體公司的觀點來看，在必須讓開放原始碼的授權發揮效用的情況下， BSD 型態的授權是條款與條件最少的一種。從開放原始碼開發者的觀點來看， BSD 型態 的授權賦予使用者運用原始程式碼創作衍生作品的最高自由。這些自由涵蓋了依據 BSD 型態授權取得開放原始碼軟體，以及用它創作原始程式碼不開放的所有權專屬產品。

結果，許多開放原始碼的支持者，因為希望開放原始碼軟體所衍生的作品，也應該 延續開放原始碼授權，因此建議後來者不要使用 BSD 型態授權。

「反版權(Copyleft)」條款

在另一方面，亥克就曾經詳細解釋過，GNU GPL 及其修正版本，企圖規範開發者的行為，禁止他們「私藏」程式碼，或者在更改開放原始碼的產品後，不將所做的 變動回饋給開發者社群。

根據亥克形容，就許多方面來說， GPL 位在光譜的一端，BSD型態的授權在中 間，而二進位碼的限制性授權則是在另一極端。基本上， BSD 型態的授權允許開放原 始碼軟體無限制的商業用途，對衍生所有權專屬作品的創作毫無限制； GPL 則明確設 計用來防止開放原始碼軟體被用以創作所有權專屬的衍生作品。

GPL 之所以能如此，是透過其中的「反版權」（copyleft）條款，要求經 GPL 而 散播的程式，不得收取權利金，並須提供原始程式碼。它還要求以這類程式為基礎的衍 生作品，也必須實施 GPL。

GPL 對所謂 GPL 程式的衍生作品，有著相當廣泛的定義。它這麼說：「傳播或 發表的任何作品，其全部或一部分，包含或是衍生自 GPL 程式，或是這類程式的任何 部分」，就是衍生作品。除了 GPL 程式的修正版本之外，還明確包括使用到 GPL 程 式的片段程式碼，或是執行碼固定連結 GPL 程式庫的程式。無論新程式的原始程式碼 原先經由何種授權， GPL 明確註明，當傳播根據 GPL 程式所製作的產品時，即使內含部分不是 GPL 的程式碼片段，這個整體作品的傳播，仍然必須遵循 GPL 規定—— 「不論作者是誰，其他授權人的許可及於整體，亦及於其任何部分。」

因此，如果在包含自有程式碼的所有權專屬程式中，使用到 GPL 程式碼，就必須 依原先 GPL 程式碼的相同條件，將你的原始程式碼納入 GPL 。根據亥克所說， GPL 程式碼的這種性質，使得許多人比喻它是「病毒」，能夠顛覆所有權專屬的「主」程 式，進而製造出更多的GPL程式。

換言之， GPL 程式碼能夠「感染」原本非GPL的程式，這個事實會導致一個現 象：如果你採用 GPL 程式碼，就只能創作出 GPL 程式。任何團體，像是自由軟體基金會，如果想要鼓勵 GNU 哲學的散布，這個特性是必要的。亥克解釋說：「如果你想從頭創作開放原始碼產品，或想在產品內引用其他的 GPL 程式，這種特色也是必要 的，或至少是可以容忍的，因為 GPL 廣為自由軟體開發族群使用與接受，而且現有的 GPL 程式碼數量很多。」不過，這個特性對那些想以其他方式，授權自有技術的商業 軟體商來說，會構成問題。

各公司也可以稍微修改 GPL 較具爭議性的部分，而採取「創作者授權」（artistic license）的方式。網景後來就研擬出魔斯拉公共授權（MozPL）及後續版本「網景公共 授權」（或稱為NPL），做法比 BSD 更進一步，同樣透過壓制「軟體藏私」的方式授 權，但允許開發人員隨意創作所有權專屬的附加程式。

「既然開放原始碼軟體不能沿用傳統軟體的授權及收費方式，就必須根據提供給客 戶的價值，找出產生營收與利潤的其他途徑。」亥克建議：「而這麼做如果想要成功， 就必須選擇適當的企業模式，並且好好執行。」

可行的企業模式

為了替公司開創新的開放原始碼業務，亥克已經找出幾種企業模式，有一些也經過 OpenSource.org 確認。

「販售支援」模式是經由配銷媒體、商標、訓練、諮詢、訂製開發以及售後服務賺 取收益，而不是透過傳統軟體權利金。

「介面糖霜」模式則是以銷售硬體為主，但在驅動程式及介面程式碼這類以往必須 取得授權的搭配軟體，則是採行開放原始碼模式。

「相關配件」模式則是專門經銷圖書、電腦硬體，以及其他支援開放原始碼軟體的 相關物件。

「促成服務」模式下，創作及配銷開放原始碼軟體的目標，主要是支援營利性質的 線上服務公司。

「品牌授權」模式則是利用自身品牌及商標的使用權，向其他依此製造衍生產品的 公司收取費用。

「先賣後送」模式則是讓一家公司的軟體產品，以傳統商業產品的方式開始產品生 命週期，再於適當時機轉型為開放原始碼產品。

「軟體連鎖經營」結合了上述幾種模式（特別是「品牌授權」及「販售支援」），指 的是一家公司授權其他公司，利用其品脾及商標，於特定地理區域或縱向市場中，成立 相關機構進行訂製軟體的開發。公司向連鎖機構提供訓練及相關服務，以換取某種連鎖 經營權利金。

亥克認為混合模式也行得通，如此可以各種不同的方式，緩和有關開放原始碼的限 制。舉例來說，針對相同產品，一家公司或許會「兼容並用」傳統授權方式以及開放原 始碼授權方式，依不同使用者予以區隔，譬如營利機構相對於非營利機構，或是機構相 對於個人，以及／或是按不同的使用型態加以區分，像是內部網路相對於外部網路，某 種平台相對於另一種平台，等等。

除此之外，一家公司可以將原始碼廣泛授權給所有使用者，甚至允許免費的「測試 用」授權，但是仍然收取「修改權」的權利金，以某種方式限制修正版本的傳播。

雖然這些企業模式，就嚴格定義而言，並不是真正的開放原始碼模式，但亥克相信它們在某些狀況下，對某些公司來說，或許是可行的模式。 第三方技術

亥克更進一步，為任何想實施開放原始碼策略的公司，提供一份入門指南。從所有 權專屬轉換到開放原始碼，公司會面臨一些議題。

程式碼共用是其中之一。就是公司的開放原始碼產品，可能會與另外以所有權專屬 程式碼為基礎的產品，共用一段通用程式碼。（這在網景案例中確有其事。）

在這種情況下，公司必須確定開放原始碼的開發能夠進行，而不至於使其他內部開 發的工作複雜化。這點可能需要在授權方面做特殊考量，還有以模組化方式落實開放原 始碼與所有權專屬程式碼之間的明確區隔。

亥克說道，在切換到開放原始碼模式之際，第三方技術可能也會成為一項議題。任 何公司的產品，在現有原始程式碼的基礎中，可能包含經第三方授權的技術。這部分程 式碼必須特別處理，才能製作可以發表的開放原始碼產品。典型的選擇是將程式碼徹底 移除，或是透過特殊安排尋求把第三方程式碼包括在內的許可，或是使用相同或類似功 能的開放原始碼來取代這種程式碼。第三方技術的存在，也可能影響公司對開放原始授 權的選擇。

為確保原始程式碼可以公開傳播，程式碼也必須加以消毒。也就是刪除或更正任何 深藏於程式碼中的不妥文字，以及程式人員在工作時所添加的，只為內部閱讀之用的精 采評論。

雷蒙的建議

就在網景宣布後不久，雷蒙收到朋友寄來的電子郵件，提到網景之所以決定要開放 瀏覽器技術的原始程式碼，是受到了他文章的影響。

雷蒙感到驚訝，因為他不曾與網景談過。一九九八年元月二十七日，他寫了一封內 容如下的電子郵件給巴克斯代爾，作為回應。

上星期聽說我的論文＜教堂觀與市集觀＞，促使了網景決定散布領航員的 原始程式碼，並嘗試採用市集開發模式，我覺得非常欣慰。我認為我可以有信 心地代表整個自由軟體界發言說，我們全都為這項大膽的行動感到高興，願意 支持網景，並祝你們落實新策略一切順利。

然而，行百里者半九十。立意良好、具前贍性的理論，必須有適切的執行 予以落實。網景的宣告無可避免地，會引發後續能否有效執行的質疑。讓我得 以寫出那篇論文的相同體驗，又促使我提出一些建議，希望你能慎重考慮。 針對網景的執行面，我覺得有三點迫切的主要議題：

首先，網景原始碼授權的確切條款，將會是策略成功與否的關鍵。其次， 自由軟體界的健全與善意，從現在起對網景已經有了正面的利害關係，必須考 慮如何加以保護。第三，有心採用市集模式進行開發專案，並不等於知道如何 實行。

原始碼授權的條文是第一項主要議題。它們是潛在雷區，因為在海外已經 有傳聞，懷疑網景有意重演昇陽在爪哇授權上使過的欺騙手法——在極小字 體印得密麻麻、乍看之下似乎相當寬鬆的條款中，暗藏了許多方便公司控管的 文字。

我向你保證，即使只是若有其事，網景也會自食惡果。自由軟體及Unix 社群對昇陽授權案有種「上一次當，是你不要臉；上兩次當，是我自己蠢」的 強烈感受。對於任何看似再度暗使控管把戲的圖謀，不會心軟。

我建議你們研究在http://www.debian.org/social_contract.html上的「德比安 自由軟體準則」。它們是根據多年來對GNU授權及相對競爭的內容，以非常 嚴謹的態度研擬而成。它們代表著人們對所謂「自由軟體」授權，最低限度的 文化共識。網景的領航員原始碼授權必須與它們相符，才能夠取信於人—— 你們不應該只是順應，還必須把這種作法公開。 在各種常用自由軟體授權的條款及意涵方面，正好我是個專家（在最大的 Linux 檔案網站上，用了我的詳細探討作為參考：你們可以連上 http://sunsite.unc.edu/pub/Linux/LICENSES/theory.html參閱）。我很樂意協助網 景研擬授權。

你們選擇的策略，實際上使網景的未來，仰賴於自由軟體界的健全與善 意。這兩者的維繫現在將是網景的重要考量。除非一般的自由軟體文化茁壯， 你們將無法爭取到成千上萬具有開創性的共同開發者，如果他們對網景沒有好 感，自然不會有興趣花時間在網景上。

幸好網景有極佳的形象做基礎。只要能妥善處理領航員原始碼授權，要做 到這兩點既不至於太昂貴，也並不困難。你們必須和自由軟體界的領導機構， 發展策略聯盟關係。這至少代表著，成為Linux 國際以及自由軟體基金會的贊 助公司。

再說一次，這是你們該做、而且要公開做的事。你們要這麼做是因為，加 強自由軟體文化的制度與團結，會增加你們得自市集策略的優勢。而你們要公 開做是因為，它是給自由軟體社群的清晰訊息——你們會認真珍惜他們的貢 獻。

最後，網景是否能夠順利落實市集開發模式，還有一項重大議題。姑且先 不論你們要這麼做的動機，或是你們人員的才智與動力，過程中仍然有著實質 上的障礙。我見到的就有兩大障礙。

首先，實踐（或是作為主要接觸）市集模式，較諸執行傳統大教堂式的開 發，需要不同而且更寬廣的才能組合。你們必須謹慎選擇人員。理想人選應具 備精湛的技術才能、極佳的溝通能力，以及在自由軟體界的良好風評。這個人 還需要有足夠的政治判斷力，以便在主導專案的執行時，能讓網景與自由軟體 社群的合作，是創造雙贏的局面。最後，這個人需要得到網景高層主管的信 任，他才能做出那些雙贏決策，並接受監督是否落實。

對信任需求，我不能置喙，但是依其他條件篩選，我想我認得一位極佳人 選，以及一位目前任職於網景的優秀人選。 其次，你們可能會有文化上的惰性問題。比起任何我所知的、自外於自由 軟體文化的其他商業單位，網景與該文化有著較好的聯繫。雖然如此，我能輕 易地想見，實踐市集模式的誠實嘗試，可以如何被內部傾軋，以及對封閉式大 教堂模式不自覺的依戀所蒙蔽。

我非常不希望這些不良後果發生，因為如果網景的嘗試受到挫敗，對於我 所由衷信仰的自由軟體文化，會有極端負面的影響。自由軟體模式會落得極其 不受信賴，使得未來類似的嘗試將難如登天。試想蓋茲會如何開懷大笑! 其他 你可以自己想像……

所以我非常願意與你及網景合作，以確保你們的策略成功。最低限度，我 能夠協助某些意識的激發。我認為網景同仁應該要有機會見識教堂觀與市集觀 實地搬演，感受到公司內部明確訊息說，這就是你們選擇的方向。

在無損於我的超然立場的情況下，我還有其他方式，能致力於加強網景與 自由軟體文化間的聯繫，使雙方互蒙其利。我願意和你探討這個可能性。

有鑑於此，一旦有適合雙方的時機，我願意與你及網景其他相關人員會面 討論。

簡潔為上

紅帽開始接到來自分析師以及業界其他人的探詢，質疑扎文斯基的辭職，以及魔斯拉初期的種種困難，是否會對整體開放原始碼運動造成傷害。

一時之間，這種情形難免被解讀為對這個運動的一記重擊。但是我有不同的看法。 相對於一開始就使用開放原始碼模式來建構程式碼，或許這個要「解放」龐大所有權專 屬程式碼的挑戰，對扎文斯基而言太困難了。

封閉式軟體開發團隊在編寫程式碼的過程中猛抄捷徑，可能造成非常複雜難懂的所 謂「義大利麵程式碼」（spaghetti code）。旁人不易瞭解箇中的奧妙，也就使不上什麼力 氣來加以改進。

一個公開而且由一群同志以合作為基礎所建構的專案，可以確保程式碼即使不可能 完美，至少夠清楚，能讓他人瞭解其邏輯，並且為之做出貢獻。

魔斯拉專案的問題在於，先是擷取大量閉門造車寫成的複雜C++ 程式碼，然後直 接就「解放」了這些程式碼。

在另一方面，大多數成功的開放原始碼專案，從一開始就是開放原始碼專案。這種 做法的好處在於，開放原始碼的工程師，由於無法為程式注解分神，會特意寫出極其簡 潔的程式碼。實際上，他們會設法讓其他開發者只需「閱讀程式碼」，而不必閱讀程式 碼的說明文件。

再者，基於必要，開放原始碼專案必須像是大型拼圖的個別片段一般，非常模組 化。開發人員要能夠花上一、兩個星期，切割拼湊大段程式碼，而無需擔心會「毀掉」 別人進行中的工作。網景通訊家不是以這種方式寫成的，所以魔斯拉必須重寫，以求與 開放原始碼開發模式相容。

所有權專屬專案原本就缺乏撰寫簡潔程式碼的誘因，當然不會有理由為求簡潔而重寫程式碼；但簡潔卻是開放原始碼專案常有的現象。

網景此刻的問題，強化了我從電腦租賃業學到的教訓：對自己所負責的企業要小心 管理財務。有些分析師，甚至我們部分董事會成員，偶爾會表示關切，認為紅帽做為一 家網際網路軟體公司，就財務方面而言，經營過分保守。

大多數與我們處境相同的公司，會馬上籌集資金，然後大舉「燃燒」資金，試圖儘 快建立市場占有率。我們卻正好相反，大多是在現金流量成長能力的範圍內，來推動紅 帽的成長。過去我們所籌得的資金，最早是來自貝騰，其次是一九九八年九月那一回 合，第三次是在一九九九年三月結案的回合。然而，這些資金僅止於營運週轉用途。事實上，大部分資金都還存在銀行裡。

正如網景的巴克斯代爾常常說的「如果公司做長沒有利潤，搶短就在所難免了。」

駭客傳人

「駭客」（hacker）一詞被賦予輕蔑的意義，是因為像某十四歲少年企圖入侵大企業 及政府機構電腦的這類事情被過度渲染了。在Linux社群之間，「駭客」一詞可是一種 尊稱。

這個族群最早的一批人，是麻省理工學院一九五○年代後期的學生。他們熱愛修護 大學裡的大型電腦，並且自稱為駭客。一九七一年，十八歲的史托曼還在哈佛大學就讀 時，就從麻省理工學院人工智慧實驗室（Artificial Intelligence Laboratory）發難，自命 為早期駭客的嫡系傳人。那時候的環境都還是以合作與共享為基礎。

史托曼 (R.H. Stallman) 的美學品味是嬉皮式的。事實上有段時間，他就住在辦公室裡，睡在心愛的電腦旁邊。

到了一九八一年，情況開始起了變化。當時史托曼還在麻省理工學院裡面工作，城 裡的另外一頭，蓋玆與亞倫正在使用哈佛大學的電腦，為現在已經是古董級的Altair 8800撰寫一套作業系統。（那時托瓦玆還只有十歲，剛開始學習如何在這種老式電腦 上撰寫程式。）

程式設計師取得微軟的第一支程式——用在Altair上的培基（BASIC）電腦語言， 並依當時程式設計環境的慣例，隨意複製流通。早期免費流通軟體的做法，啟發蓋玆寫出他那篇著名的（給電腦玩家的公開信）。這封信曾刊載在許多電腦期刊上，並於一九七六年正式發表。蓋茲寫道：「你們大多數人的軟體都是偷來的。你們的作法，適足以 扼殺別人撰寫好的軟體。有誰受得了從事專業的工作卻一無所獲？」

rock註：微軟的第一支程式，即 BASIC 語言，是由蓋茲本人親手撰寫出來的。

接下來都成了歷史。蓋茲後來賣了一套所有權專屬作業系統給IBM，那就是M S-DOS。MS-DOS託IBM的福，成為個人電腦的業界標準，而微軟迅速以合 約箝制電腦製造商，最終造就其壟斷地位。正值業界日益倚賴所有權專屬程式碼之際， 史托曼繼續滿懷熱情，為自由軟體而奮鬥。舉例來說，他創作了一套免費的文字編輯器 emacs，透過網際網路廣泛流傳使用。

rock註：上述歷史在 The Making of Microsoft (中譯：彈指乾坤) 一書中有詳細說明， 該書是微軟到1993為止的傳記。 由該書可知， Bill Gates 可稱得上軟體專利權之父。

史托曼於一九八四年開始著手創作 GNU ——他的 Unix 免費版本。這個系統的許多部分，對後來的 Linux 影響很大。他的成果，包括 GPL 授權的研擬，催化了軟體工 具的創作，在相當程度上引爆了網際網路。而稍早自由軟體的努力也造成了影響。

奧爾曼（Eric Allman）在一九八一年創作了 Sendmail ，網際網路上有百分之八十的往來郵件，都是透過這支開放原始碼程式來進行傳遞的工作。目前這支程式仍由數千位線上程式人員，透過 sendmail.org 在維護。除此之外，奧爾曼還在一九九八年十一月創 辦了 Sendmail 公司。為了營利，他向客戶銷售此一開放原始碼軟體的易用版本，同時 提供技術支援與相關服務。

開放原始碼界的另外一股重要力量是 perl 。作者沃爾（Larry Wall) 原先是位語言學家，後來在寶羅斯電腦公司（Burroughs Corp.）服務時，得到政府資助專案而寫成這套有用的語言工具，時年四十三歲。軟體完全免費，不過沃爾賣出了五十萬本的 Perl 使 用手冊。

另外一支開放原始碼程式 BIND ，原先是由加州大學柏克萊分校以自由軟體的方式進行開發。有了 Bind 之後，就可以直接輸入網域名稱，像 Linux.com 之類的文字位 址，而不再需要輸入機器碼（一般稱為 IP 位址，例如 43.72.66.209 ），使一般大眾在優 游網際網路時更為簡便。

rock註：BIND 目前由 Internet Software Consurtium 接手維護； http://www.isc.org/

阿帕契集團是由貝倫多夫（Brian Behlendorf）在二十五歲時所創立，當時他受聘為 《連線》（Wired）雜誌架構網站，為了改良網路伺服器軟體，他自行增修程式，並將成 果連同原始程式碼，放到網際網路上流通。隨後其他貢獻者再加入他們的程式碼，「阿帕契」（Apache）由此誕生。這名字的由來，是因為該軟體係蒐集許多貢獻者的程式碼 「修補」（A patchy）而成。目前網際網路有一半以上的網站使用阿帕契。IBM也選擇 它做為IBM網路商務軟體的基礎，而沒有採用網景或微軟的封閉原始碼網路伺服器軟體。

法律的類比

開放原始碼在學術領域裡非常普遍。學院與研究機構始終有開放原始碼的傳統。有 了網際網路，或者說有了像紅帽、天鵝座這類的公司之後，從事研究與學術工作的程式 設計人員有更好的方法來發展科技，甚至還可以把它應用在商業市場上。

基本上，開放原始碼也與西方民主制度的運作方式相容。試想，如果法律體制是以封閉原始資料的結構來運作，那麼律師豈不是每次都要重新研擬答辯，因為他必須付權 利金，才能引用先前存在的判例。

今天如果一個律師想出新的辯詞，在最高法院打嬴了官司，他不能用這番辯詞申請 版權或專利。其他律師可以自由引用他的辯證，而無須請求批准。

開放原始碼重視效率，多過重視道德。就像在法律界，與其不斷重新創造，不如大 家分享共同的法律傳承，這樣我們的社會將變得更有效率。然而無論理由為何，以所有權專屬模式演化而成的軟體，一直都不准分享，誠如史托曼所說的，我們每寫一段程 式，都必須從頭開始。

電腦語言之所以被稱為語言，是因為它們確實就是語言。即使我們允許作者擁有著 作權，使他們不至於因作品被任意重印，而導致著作收入遭到剝奪，但作者可不能就書 中的概念要求專利。其他人可以任意改寫或引用作者的想法，並且可以自由在引進的新 概念上進行建構。

然而在過去的軟體世界裡不可能如此。不只是因為專利和版權，原始程式碼也一直是秘而不宣。

專利權的危險性

未來的幾年間，以Linux為平台來連結網際網路的新型電子設備，將會有爆炸性的 進展。這個作業系統將會刺激許多新市場區間的成長。

隨著開放原始碼市場的成長，觀察法律如何因應演變饒富趣味。軟體界有些人相 信，軟體專利弊多於利。另有一些人則擁護專利，或是愛恨參半。

我們比較傾向於認為軟體專利是一種禍害，或者至少是具有破壞力的，會損害軟體 產業的機能。有必要讓更多人也意識到，軟體上的專利權並不是件好事。

史托曼的 GPL 授權雖然偉大，卻還有進步的空間。由於愈來愈多商業公司發表的程式碼，使用的就是 GPL 及 NPL 相容的授權方式，顯見這個產業的法規普遍需要大 幅改進。

托瓦茲還相信，如果沒有軟體專利，這個世界會變得更好。然而他也尊重其他人的觀點，但是當某些參與 Linux 的程式人員起了貪念，他會感到不悅。

「我認為無論從事任何藝術性質工作，或是撰寫任何程式碼，人們都有權利選擇適合他們的授權方式，」托瓦茲說道：「所以當有人告訴我，說我早該為Linux另外弄個版權時，我真的不太高興。」當然， Linux 是屬於 GPL 的反版權。

托瓦茲補充說道：「我會這麼想：「你算老幾，竟敢這樣要求我？」我的看法是， 如果你不喜歡這種授權方式，那就請便，你不一定要使用Linux，對不對？你不需要來 修改。既然要改，那你對當初把系統做得這麼好的其他人，多少也應該有點虧欠。」

托瓦茲說，專利權主張之於軟體環境，相較於程序之於製造業環境，更具有危險 性。「專利是行之有年用來保護工程製造方法的手段，所以你是針對某種特定程序或構 件、或是程序的最終結果而主張專利。專利權主張具有危險性。你們的做法對軟體沒有 好處。」托瓦茲說道。

「目前鬧上法庭的案例似乎還很少，那是因為沒有人知道未來會怎麼發展。大型公 司甚至不願意冒險，讓司法界來判定軟體專利的效力低於一般專利。所以狀況演變成， 在商業世界中，你把這些專利當作是『別冒犯我，否則讓你好看』的工具，一種心理上 的防衛機制，」托瓦茲說道：「在精神層面上這是一種挑釁。我不太喜歡。我的做法是 盡可能遠離這一團混亂，避開顯著的個案，譬如加密方面明顯的專利議題。那是個我們 覺得少碰為妙的領域。」

然而針對其他狀況，他說道：「如果我們獨立完成的是隨機的程式小修正，不太可 能每個人都會遍尋所有的專利應用程式，試圖找出它們。好，如果是我們自己獨立完成 的，而且相當明顯，不會侵犯專利，那麼我們就可以用它來保護自己。」

到目前為止，他說 Linux 程式設計人員並不擔心。「至於企業，那又是另一回事。 確實有跡象顯示企業憂心仲仲，他們一方面討厭專利制度，但在另一方面卻又非要與專 利為伍不可。」

托瓦茲說，如果對於軟體的專利控制觀念能夠漸漸轉變，公司的經營哲學也必然會 有重大的革新。他相信長遠來看，如果軟體程式碼能像字母一樣隨人使用，那麼所有公 司與個人都將獲益良多。