Lusix Person's Notes

林誠夏、葛冬梅／文

自由開源軟體雖然可以被自由地修改與散布，但其仍然是受到著作權保護的客體，所以若是使用者的利用方式不符合其授權條款所預設的遊戲規則，嚴重時仍然會引發後續的司法訴訟與糾紛。然而、其實許多爭端在開始時仍然具有溝通協商的空間與可能性，本文主要便是就自由開源軟體被不當利用時，所可能收受到的警告信內容來進行披露，並對後續的處理方式，做一個概念的引導及處理流程的建議。

近年的自由開源軟體侵權爭議案件，多數是以違犯 GNU GPL (GNU General Public License) 等 Copyleft（註一）性質授權元件的遊戲規則為大宗，這是因為具有 Copyleft 性質的自由開源軟體授權條款，尤其是 GPL 類型的授權方式，其約束被授權人的義務性要求嚴格，且參與者於自由開源軟體社群中，多屬對於「軟體自由 (Software Freedom)」、「資訊人權 (Freedom of Information)」理念有較高堅持者，對於自由開源軟體分享與合作的觀念，也具有一定程度的使命感，是以此等參與者可能會不計較訴訟勞費的代價，並基於其維護理念的堅持而提出法律爭訟；再者、目前商用影響力極高的自由開源作業系統 Linux Kernel，其亦以 GPL-2.0 為其釋出條款，所以也大幅度拓廣了 GPL 授權元件的實務影響範圍，故近年自由開源軟體侵權爭議方面的火種，極大多數皆是經由這類強烈 Copyleft 性質的授權元件所點燃。

在自由開源軟體侵權訴訟發動之前，通常涉訴的商業公司會先收受到某某元件不當利用的詢問信函，這些詢問信函、多數是來自於不同自由開源軟體專案的熱心參與者。當他們發現某些商業公司在其產品中取用了自由開源軟體元件，卻沒有適當地提供該元件的程式源碼時，便可能先行透過詢問信函來要求說明，或是請商業公司補充該元件程式源碼的取得方式，而若是溝通不果、或是一再詢問而得不到回應時，則這些參與者便可能將此狀況回報到一些專職的自由開源軟體權利維護計畫或是組織（註二），而後經過這些權利維護組織內部論壇討論過後，如果判定不當侵權利用的事證確實明顯且狀態嚴重，便會接著由其出面聯繫該元件的著作權利人取得代理權，再以權利人本人或是代理人的名義（註三）向不當利用的商業公司寄出侵權警告信函，當商業公司收受到這類由權利人或是權利託管組織所寄發出來的侵權警告信函時，此時離正式的侵權訴訟發動便僅有一步之遙。而依近年自由開源軟體的侵權爭議案例來看，可以說、這些警告信件、便是侵權訴訟正式發動前的重要徵兆。

▲ 圖1 自由開源軟體授權爭訟的發動流程示意圖

原則上一封正式的自由開源專案侵權警告信件的內容，會有以下幾個重點訴求：

1. 怠於提供程式源碼的義務性要求：警告信件的首要內容、將指出涉及侵權利用的產品型號，以及其所採用的自由開源軟體元件，並述明該產品哪些部份必須併與此自由開源軟體元件，以提供程式源碼的方式向外散布。
2. 違反授權條款的規定將引發失去合法授權的效果：其後警告信件將依據條款內容指出「不依照自由開源軟體授權條款的散布行為，將導致散布者失去原依條款所能取得的合法授權。」也就是說、此相當於法律行為上的解除事由（註四），基於此一條款、廠商不遵守自由開源軟體授權契約的違犯行為既已發生，則其本來依照自由開源軟體授權條款所能得到的合法授權，便已嗣後自動解除、而無法再以被合法授權者的身份，繼續散布相關產品。
3. 建議廠商調整產品程式源碼的釋出方式
4. 若不配合協同作業則必須停止產品的散布

基本的態度「尊重」：不宜避而不談、第一時間簡短而迅速的回覆→了解社群，不同社群解讀GPL的態度不同：RMS／Linus Torvalds／Harald Welte→可能的解決之道：置換程式源碼／不同利用技術（區隔、獨立性）／金錢賠償

訴訟趨勢→以GPL為主→預防勝於治療→確認開發模式與社群合作開發／確認不公開部份（核心技術、保密協議），不與自由軟體程式碼有關聯／確認利用自由軟體的方式，區隔GPL拘束性。

如收受著作權人寄發的警告信函或訴訟調解聲請等，建議可依下列程序進行處置：

1. 組成審檢小組：公司自行組成審檢小組，進行受控產品的程式碼審檢，以查驗受控事項是否屬實；
2. 釋出善意回應：若受控事項確然屬實，則對舉發單位進行善意回應，表達已就受控事項進行專案處理，嗣內部評估報告出爐，即會依規定處理；
3. 評估修正損失：公司進行內部評估，估算如修正產品釋出狀態及開放程式原始碼，會造成多少實際金錢支出、及失去哪些營業秘密；
4. 尋求協商解決：舉發者如本身即為權利擁有人，則可進行協商解決方式，試著藉由溝通找出對方能夠接受，而公司亦不至遭受不可承受傷害的解決方式，若舉發者本身並非權利擁有人，則逕向原著作/專利權利人查訪進行溝通，如公司無法接受自由軟體授權方式釋出產品，亦可與原權利人溝通採行商業授權的補正，如協商過程對條款解釋有所疑義，則尋求適當的專業機構或法務人員協助分析，最後再依協商結果，踐履雙方皆同意的處置方案。
5. 採取隔離措施：記取經驗、若公司有不得開放的核心智慧財產權利，則在適用上應採隔離措施，即以「先前檢審」的方式，避免其與著佐權類之自由軟體程式相結合，免除其日後被迫開放軟體程式原始碼的風險。
6. 加強觀念教育：公司如欲採用自由軟體程式為其產出的一環，則應事先規劃自由軟體授權條款方面的法律教育訓練，目前許多自由軟體授權爭議案件，發生於員工法律授權概念不足的情形，員工在不完全知悉清楚的前提下，便取用了GPL2一類帶有強烈著佐權性質的自由軟體授權條款，致使公司嗣後亦無法舉證免責，故應加強員工授權意識，免除此類風險再次發生。

註一：Copyleft 此一觀念最早由 GNU Project 的主持人 Richard M. Stallman 所提出，而被廣泛運用在 GNU Project 所適用的公眾授權條款如 GPL、LGPL 與 GFDL，其主張自由開源軟體的著作權人仍可主張著作權法所賦予的權利，再以著作權人的身份規範他人使用其作品的方式，原作者可於授權條款中，明示允許他人對作品進行修改，但同時要求衍生作品的改作人，亦必須採用同樣的授權模式向後散布這個衍生作品，以確保原程式與衍生程式能持續為社會公眾自由使用，此種以著作權人立場要求原作品及其衍生作品，於後續散布過程仍須依循同樣遊戲規則的授權方式，就是 Copyleft 的運作概念，此概念原創者的理念表達可參照，Richard M. Stallman, What is Copyleft?: http://www.gnu.org/copyleft/copyleft.html

註二：例如透過 Mailinglists 的方式聯繫歐洲的 gpl-violations.org project：http://gpl-violations.org/mailinglists.html，或是採用電子郵件將不當利用的狀況提報給美國的 GNU project：http://www.gnu.org/licenses/gpl-violation.html

註三：歐洲的 gpl-violations.org 計畫是由 Harald Welte 於 2004 年初發起，該計畫多以個案式代理的方式，為自由開源軟體專案的權利人代為寄發侵權警告信，與代理進行後續的訴訟事宜；而美國的軟體自由法律中心 (Software Freedom Law Center, SFLC)、與軟體自由託管機構 (Software Freedom Conservancy, SFC)，則多是採專案權利常態託管的方式，為其會員專案進行侵權防治的整體代理行為，SFC 目前託管軟體專案包括 BusyBox、Git、jQuery、Samba，與 Wine 等重要的自由開源軟體專案，其詳細列表可見右列連結：http://sfconservancy.org/members/current/

註四：此類同解除事由的說明文字，以 GNU GPL 與 GNU LGPL 為例，GPL-2.0 規定於第 8 條、LGPL-2.1 規定於第 4 條