登入  |  English
感謝您對「自由軟體鑄造場」的支持與愛護,十多年來「自由軟體鑄造場」受中央研究院支持,並在資訊科學研究所以及資訊科技創新研究中心執行,現已完成階段性的任務。 原網站預計持續維運至 2021年底,網站內容基本上不會再更動。本網站由 Denny Huang 備份封存。
也紀念我們永遠的朋友 李士傑先生(Shih-Chieh Ilya Li)。
法律源地

法律源地

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

 

法律源地

常接觸自由開源軟體的讀者應該都聽過雙重授權 (dual-licensing) 或多重授權 (multiple-licensing) 模式,也就是一個自由開源軟體透過多份不同的條款來授權散布,而軟體的使用者因此可以選擇最貼近自己需求的條款來後續散布這個軟體。這樣的多重授權模式常被應用在商業化利用的自由開源軟體上,最常看到的條款組合模式是以一份 GPL 類條款搭配商業授權條款來釋出,由於 GPL 類條款具有較為嚴格的授權拘束性,衍生程式的源碼必須在散布時也同時提供出來,對於不能履行這項義務的使用者來說,這時候就必須選擇洽談商業授權內容,在給付一定的授權金之後,使用者就可以獲得散布衍生程式無需提供源碼的授權條款。因此在這種「GPL 類+商業條款」的多重授權模式下,使用者通常只需要確認衍生程式源碼是否可以在散布時提供出來,就能決定要採用哪一種授權條款,而在相關產品的授權資訊標示上也因此相對地單純(註一)。不過在多重授權模式中,還有一種的態樣是透過多份自由開源授權條款來散布,在面對這種多重自由開源條款授權的軟體時,使用者條款在選擇條款的考量標準與授權標示上,均與上述「GPL 類+商業條款」的典型略有不同,因此本文將從多重自由開源條款授權的緣由談起,來說明在面對這種軟體時,可以採用什麼樣的基本態度來選擇條款,以及如何適當地標示後續散布的授權聲明內容。

在自由開源軟體的商業應用過程中,軟體專利侵權的潛在風險一直是個受到矚目的議題,因為依各國著作權法及電腦程式保護專法的規定,著作權性質的保謢標的多是限定在著作的表現形式上,故而重新撰寫且完全不抄襲他人的程式碼,將有機會主張新創作的程式,是一個全新的創作,而不受到他人既定程式的著作權利拘束,這也是 GNU 計畫 (GNU Project: GNU is Not Unix) 當初設立起步的主要思維:透過群策群力的方式,不加抄襲但重新創作具 Unix 系統所有功能的全新電腦作業系統,來讓後續的應用不受到既定 Unix 作業系統的拘束;然而在專利權的領域裡,因為其保護的標的多為抽象,且可實施在不同載體的技術方法和步驟,故第三人專利的議題在自由開源商用領域可能引發的效應,往往讓商業使用者憂心,畢竟,自由開源軟體專案允許多人共工的模式,一方面確實是加速了軟體專案的開發效率與期程,然而,開發流程裡是不是有開發者誤用或因疏忽寫入第三人既存,且受軟體專利保護的演算法,而讓整體專案後續曝露在專利侵權的風險下,這方面的推論,理論上亦有可能成真。
 
不過,自由開源軟體專案,在經過了這二十多年的商業化發展之後,全球利用它來進行商業營利的公司,亦已經發展出了不同的措施,可以一定程度面對這些可能產生的第三人專利侵權問題,這些不同措施所能產生的影響各有不同,其有效性也待實務驗證,不過其中有的措施,甚至可能對於全球專利制度產生重大而長遠的影響,這是此篇文章想要進行基礎討論和說明的要點。

所謂的受雇人,簡單來說,就是在一間公司或組織聘用來在負責一定職務工作的員工,因此受雇於一間公司來專職開發軟體、韌體的工程師,就是受雇人,而該公司就是雇用人(註一)。若是這間公司利用 GPL 元件來開發產品,軟體工程師可以自由散布產品程式碼嗎?工程師在產品中所撰寫開發的程式碼,其權利是屬於工程師本身、還是該公司?這些疑問是受雇軟體工程師在利用自由開源軟體來開發產品時,可能會產生的,因此本文將先從著作權法相關的規定談起,並且說明實際雇傭關係的運用狀況,進而釐清這些可能的疑問。

自由開源軟體近年被廣泛地運用在各類的資通訊產品與服務中,不過由於其為眾人協作的作品,故有時也會聽到資服業者,轉述終端使用者的疑慮,認為若產品中的自由開源軟體在共工撰寫的過程裡,可能隱有侵權重製、改作的糾紛,那麼產品使用者,是不是也會因此連帶被法律風險所波及?但其實從實務運作與法學論理上來看,身為單純的使用者,若對所購置產品侵權的風險不具合理的認知期待性,則其購買使用的行為,並不必然附隨有高度的侵權責難,這一點不論產品是否有嵌入自由開源軟體來使用,皆然。本文以下即從善意保護制度、侵權實務現況,以及自由開源軟體授權條款中的特殊規定等角度著手,來為讀者分析解釋這樣的概念。

近十年來,自由開源授權軟體元件 (Free and Open Source Software, FOSS) 被大舉運用到商業應用的環境裡,然而,FOSS 的授權規則,亦相當程度賦含了自由分享的理念,故其中不少義務性要求與條件,並不能全然依照傳統商業授權的定式與慣習來進行,而若取之為應用的商業公司過於疏忽了義務性要求方面的條件,在貢獻者與商用者立場產生嚴重期待落差時,難免會引發原始權利人出來主張其開源授權的成果遭到濫用,進而提升到法庭上授權爭訟的衝突狀態。因為如此,許多 FOSS 商業應用者無不自問:究竟應該完成哪些義務性條件的遵守,才能有效降低開源授權爭訟的相關風險?這樣的問題,多數 FOSS 的研發社群朋友,並不會給過予一個界限分明的答案,一來並非所有 FOSS 專案撰寫的程式開發者,都能清楚依據著作權法主張其權利範圍與義務要求,二來許多程式開發者,更重視的是開源取予協調 (give and take) 的尊重與感受,故其並不想要在相關議題上過於闡釋,以免對 FOSS 專案的互惠分享範圍自我設限(註一)。然而,自由開源軟體授權條款的型態甚多(註二),其相關的義務性要求亦有些許分殊,若是能有更簡便的要項能夠遵守,則亦將有助於降低開源授權爭訟的相關風險,故本文依據司法實務以及所能接觸到的和解資訊,整理以下三大要點,提綱挈領地進行資訊分享。

更多文章...

第 1 頁, 共 26 頁

最先
前一個
1