2003 年 3 月美國一家電腦公司 SCO 控告電腦界的藍色巨人 IBM（SCO Group v. International Business Machines, Inc.，註一），其指稱 IBM 在未經 SCO 的合法授權下，將 Unix 部份的程式源碼 (Source Code) 使用在 Linux 作業系統的撰寫中。這項指控的基礎在於，SCO 擁有 Unix 的著作權，SCO 並未事先授權 IBM 可以將 Unix 的程式源碼用在 Linux 當中，因此 SCO 向 IBM 提出控訴，並要求 IBM 須賠償其所受到的損害。IBM 也於同年八月初向 SCO 提出反訴。此案於 2007 年 8 月 10 日，因 SCO 與 Novell（SCO Group v. Novell, Inc.，註二）之間的訴訟案而有突破性的進展，美國聯邦法官 Dale Kimball 於 SCO 與 Novell 一案中，判定 Unix 的著作權屬於 Novell，此一判定之後 SCO 就 Unix 著作權相關的訴訟已難有勝算，故其後 SCO 旋即向法院提出破產保護及公司重整的申請。

SCO v. IBM 這個案子剛開始時，許多人均抱以相當高的期望，寄望透過這一個案子的審理，法院可以對 GPL (GNU General Public License) 在美國法上的定位做一個清楚的闡釋。不過若是我們撇開主觀意識，單純地從宏觀的角度來重新審視這個案子，可以發現案件爭端的最初源頭在於自由開源軟體的社群開發模式，因為任何一個人均有地位可以對程式源碼加以修改，所以任何一個人均有機會將任何一段截取其他程式的源碼寫入自由開源軟體軟體專案中，而若是所寫入的源碼是未經他人授權的，且修改人亦沒有清楚意識到，再加上現代軟體的程式碼編寫量均相當的大，使用未經授權源碼的情形並不容易被察覺，這時候就會為被修改的自由開源軟體專案埋下法律爭端的隱憂。SCO 控告 IBM 一案就是基於這樣一個假設前提而產生的。

也就是說、在理論上，由於自由開源軟體專案採多人共工的開發方式，故個別開發者將未經授權的程式碼寫入自由開源軟體專案的情況較不易為人所察覺，同樣地，將自由開源軟體專案裡的源碼寫入另外一個軟體專案裡，也一樣不易為人所知，如果兩個專案的授權狀態相容，則這樣彼此抄寫的行為原則上便不會引發授權衝突的問題，因為自由開源軟體專案的開發特性，就是在於任何人均能自由地對以自由開源方式授權的程式碼，進行增補、修改、散布，以及進階應用。然而、若是兩個專案的授權方式不相容，那麼寫入程式碼與被寫入專案間的授權狀態便會產生衝突，而這些衝突，會使被融入專案的授權狀態陷於不穩定的疑慮，這樣的狀況對於學院的研究專案可能不是太大的問題，因為單純研究並不涉及營利的話，實務面上不易產生嚴重的司法爭訟，然而、若是此一專案日後有商業應用的可能性，則此種授權不穩定的疑慮，勢必得在產品舖貨販售之前先行解決。

上述這類問題在專案開發管理者有意識的情況下，可以透過事先對授權條款的分析與瞭解來加以預防，較易產生問題的是，部份的專案開發者在無意識的情況下將程式碼寫入授權條款不相容的程式中，而產生授權衝突的情況，此一衝突的事實若是事後方才得知，除了商業產品可能引發侵權賠償的爭端外，還可能導致必須將之前寫入的程式碼全部置換的結果，這些後續的補救措施皆是費時耗力的。此外、源碼的混入除了要在衝突性上進行檢驗之外，專案管理者有時亦需進一步對於混入後元件的授權狀態進行分析，不然商業使用上、仍然會有肇生授權爭議方面的風險。以最常見的兩類自由開源軟體授權條款為例，若是 GPL 授權的程式碼被寫入 BSD 授權的軟體元件中，且此 GPL 授權的程式碼在元件運作上且有重要地位，且無法與其他 BSD 授權的程式碼進行區隔，則該軟體元件在解釋上會成為 GPL 授權程式碼之衍生著作 (derivative work)、或是集合著作 (collective work)，而可能進一步被要求必須同樣依照 GPL 授權條款的方式來向後釋出。此時、若是使用者仍然以為該元件是以 BSD 類的授權條款來釋出，而誤認其使用上幾乎沒有任何限制，甚至將元件改用收取授權金或封閉源碼的方式來再散布，其後肇生 GPL 侵權訴訟的法律風險性便會大為提高！

然而、自由開源軟體專案的源碼混入模式，也並非全然不利於商業產品的加值運用。端視應用者從哪一個角度來觀察這個開發特性。一般來說、目前大型商業公司在採用自由開源軟體進行產品開發時，首先在選擇階段上、多會傾向取用有穩固社群支援的軟體專案，此種作法的原因、一來具有穩固社群支援的自由開源軟體專案，多已建立了較為嚴縝的程式碼貢獻 (commit) 與管理流程，所以程式碼本身產生授權衝突的可能性得以大為降低；再者、具有穩固社群支援的專案，其軟體的更新與除錯速度亦會較為穩定。接下來、在選擇階段之後，則會建立內部流程進行程式碼的編寫管控，以將源碼混入產生衝突的可能性降至最低。最後、如該項產品的銷售模式與策略許可，這些商業公司亦會透過內部的軟體開發人員，將程式源碼上傳 (upstream) 至該軟體專案的共同開發套件庫裡，以讓該公司編寫過的程式碼，能夠得到軟體社群合力除錯方面的助力，以及隨著專案主程式改版一併得到更新的好處。

所以、本文的撰寫目的並非在於引起程式開發者使用自由開源軟體專案的恐懼，而是希望透過 SCO 控訴 IBM 這件自由開源軟體界眾所周知的案件作為引子，從不同的角度，幫助讀者審視並發掘自由開源軟體多人共工模式與傳統模式的不同之處！對於自由開源軟體專案，大家必須要了解到的一個重要前提，社群開發的多人運作模式、仍是自由開源專案發展上的重要基礎，透過這樣的模式、可以大幅度增進傳統單線開發模式所無法達致的專案開發效率，然而、若是該專案的開發進程裡，沒有妥善的管理與審核流程，有時源碼混入不清的狀況也實在是無可全然避免，所以有意取用自由開源軟體專案進行產品開發的商業公司，應將自由開源軟體特殊的開發模式一併列入產品向性的規劃，正視因此特性可能引發的授權問題，並進而積極地採取瞭解與預防措施才會是最佳的態度。

---

註一：有關 SCO Group v. International Business Machines, Inc. 的事實調查與相關文件請見 Groklaw 右列專頁：https://www.groklaw.net/staticpages/index.php?page=20031016162215566。

註二：有關 SCO Group v. Novell, Inc. 的事實調查與相關文件請見 Groklaw 右列專頁：https://www.groklaw.net/staticpages/index.php?page=20040319041857760。