登入  |  English
法律源地

法律源地

本網站法律源地提供相當多自由軟體授權與法律的資訊,歡迎您閱讀這些資訊。

 

法律源地

經過這二、三十年的發展,自由開源軟體 (Free and Open Source Software, FOSS) 在品質與數量上面均有大幅度的成長,近年來更是大舉被產業界取來進行商業利用,也因此被應用的層面愈來愈廣,但對於傳統上僅熟悉私有軟體 (proprietary software) 授權模式的商業公司而言,初接觸自由開源軟體不免會引發各式各樣的問題與困擾,例如:「是否可以在終端產品中嵌入自由開源軟體進行商業販售?」、「是否作為內部開發工具就沒有延申要提供程式原始碼 (Source Code) 的問題?」、「如何讓工程師快速了解授權內容,從第一線開始避免侵權利用?」。在國內,有些公司已設有專職人員來研究與處理上述的相關問題,不過就筆者所知,這樣的公司目前仍是少數,大部份的狀況是,面臨到自由開源軟體授權問題與困擾的產品工程師,必須肩負起閱讀授權條款、釐清授權義務規定、回覆客戶相關問題,以及研究如何實踐授權義務、讓客戶安心等等的責任,這使得工程師在原本的產品開發與既定的管理工作之外,又增加了研讀艱澀授權條文的工作,而可能導致心力分散、處於不堪負荷的狀態。這樣的現象挑戰著商業公司的管理階層:如何在內部深化應用自由開源軟體的同時,又能夠同步降低可能產生的風險與困擾?因應這樣的轉變與問題,國外許多公司均制定有自由開源軟體產品應用的管理流程,讓員工在利用自由開源軟體元件加速產品開發的同時,有一套制式的流程可以遵循,不過這樣的觀念在國內仍屬少見,因此本文將介紹一個簡化版的自由開源軟體核准流程,作為商業管理流程的範例,藉此向讀者說明善用管理流程所可能發揮的功效。 

若是把常見的自由軟體分成三類:對使用者限制甚少的 BSD 類、以 Copyleft 的授權拘束性著稱的 GPL 類、及不屬於前述兩類的其他類,則 Apache Software Foundation(簡稱 ASF)推出的 Apache 授權條款會落入 BSD 類中。而 Google 的 Android 作業系統雖以 Linux 為基礎,但卻選擇與 Linux Kernel 不同的授權條款-Apache License 2.0(簡稱 Apache-2.0),Android 作業系統之所以選擇 Apache-2.0,是因為相較於拘束性強的 Copyleft 類授權條款,如 GPL 或是 AGPL 系列條款,Apache-2.0 相對是對商業公司較有彈性的授權條款,其並沒有 GPL 類別的諸多規定,更不被要求義務性地將自行開發的程式碼再回饋給自由開放源碼社群,而可以將這部分程式碼封閉私有化後加以利用(註一);當然,這樣的論點也受到不少批評,認為這是只享受不付出、佔程式開發者便宜的行為。然而,若是採對使用者規定愈少,愈有利於商業公司軟體開發及利用的論點,只有幾百字規定的 BSD 授權條款豈非最佳選擇?(註二)Apache-2.0 佔有什麼優勢,獲得諸如 Google 等商業公司的青睞,本文以下將與 BSD 授權條款相對照,試著對 Apache-2.0 解析之。

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

部份的自由開源軟體專案開發者,慣常表達出其嫌惡軟體專利 (software patent) 的立場,因為若是任由軟體專利制度發揮到極致,很可能會直接扼殺自由開源軟體未來的接續發展,然而、近年許多跨足自由開源軟體商業加值應用的產業公司,也慣常的會透過專利申請的手段來保障其商業優勢,此種專利申請模式、已經是在業界行之有年並且體系性的被固定維持,若說是為了因應自由開源專案的應用而要其突然式的改弦易轍,亦有現實上的困難。有鑑於此、本文要討論的議題是,從軟體社群與產業公司這二個不同的立場出發,觀察其對於軟體專利反對與認同、弱化與強化不同態度之間的理由與作法,並透過這些資訊的分析,協助國內自由開源軟體專案的社群開發者與商業應用公司,能更深入了解自由開源軟體所涉及的專利問題與可能的解決方式。
本文上篇的文章連接頁面如右:https://www.openfoundry.org/tw/legal-column-list/8446-the-license-inheritance-bounds-of-gnu-gpl-01

【實務上對 GPL 衍生程式可資操作的基本判別流程】

綜上所述、關於 GPL 衍生程式的判定標準,以及其授權拘束性的擴散範圍,可以歸納出三個可資操作的基本判別流程:

  1. 該軟體專案中是否內含 GPL 授權元件的程式碼?若是如此,該專案是否已明確適用該 GPL 元件授權人認同的獨立與可區分機制,來利用這個元件?
  2. 軟體專案裡的其他元件是透過靜態連結,抑或是動態連結的方式與該 GPL 授權元件進行互動?
  3. 若是採用動態連結的互動方式,則此 GPL 授權元件所提供的功能是否居於整個軟體專案的核心地位?是否失去此一 GPL 授權元件的連結,則整個軟體專案的多數功能便不復完整?

更多文章...

第 8 頁, 共 26 頁

8