登入  |  English
法律源地

法律源地

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

 

法律源地

有經驗的開發者在利用自由開源軟體時,會主動了解軟體專案所適用的授權條款,以遵守授權義務規定的方式來應用自由開源軟體。但是,不少開發者可能容易忽略的是,有些自由開源軟體專案裡,還可能包含或附帶與主專案框架不同授權條款的元件,若是應用專案的方式涉及到這些元件的話,便可能會在實際應用上產生完全不同的效果。

【個案實例】

1、關鍵引擎採用 LGPL-2.1 授權的 GPL-2.0 專案:VLC

這幾年很受到歡迎的多媒體播放器與其框架專案VLC,就是一個很顯著的例子。VLC專案整體採用 GPL-2.0 授權,但是為了讓 VLC 可以持續地被應用在 Linux、Windows、Mac OS X、Android 等不同平台上,該專案的開發者在 2011 年決定,要將 VLC 的關鍵引擎改用 LGPL-2.1 來重新授權(註一),這是因為 LGPL-2.1 對於函式庫的利用方式有著較為彈性的規定,使用者只要在合於授權規定的方式內,透過函式庫既定的介面來與其互動存取資料,則新開發出來的軟體,就可以適用非 LGPL-2.1 條款的方式來授權散布,甚至必要時也有機會採取封閉源碼的方式來授權新軟體。因此當開發者僅利用到 LGPL-2.1 函式庫或程式碼的話,就有著根據 LGPL-2.1 授權規定來開發私有軟體 (proprietary software) 的彈性空間(註二),但若是開發者確實是利用到整個 VLC 專案的程式碼,包括 LGPL-2.1 授權的函式庫,以及 GPL-2.0 的播放框架時,便可能必須一體遵守 GPL-2.0 的規定,因此時 GPL-2.0 授權的程式碼,也一併經引用而成為後續衍生專案不可分割的一部份了。
「開放硬體 (Open Hardware)」的概念與推動,奠基於自由開源軟體 (Free and Open Source Software, FOSS) 過去三十年間的成功發展,可以說,分享創意、群體共工的開發模式,已經由軟體程式創作的領域,進展到硬體裝置的設計與實作上!這樣的進展趨勢,主要是民智已開,讓過往多是閉鎖在大型企業的硬體設計,也能轉化以群聚創意的共工模式來進行。從歷史面來分析,過往的硬體設計與產銷販售,必須由企業家先群集大量的金融資本,以建立市場供應鏈並贏得競爭,然而當前全球通曉硬體設計的通才漸多,而有時業餘的愛好者,在既定硬體開發板釋出電路圖的基礎上,反而能夠在熱情的投注與巧思的浥注下,激盪出更令人驚豔的應用方式;而再從現實面來觀察,開放硬體領域近年來確實在開放風潮的推波助瀾下,產出了不少頗具影響力的成績,例如 Facebook 在本年度初,便將其資料中心主機板設計的共同插槽架構,貢獻給開放電腦平台 (Open Compute Platform, OCP) 這個與開放硬體推動有關的團隊(註一)。而其他的顯著成果,例如 OpenCores 專案,其建置目標在提供開源且可重覆利用的開放晶片設計,並比附援引近似的自由開源軟體授權條款來釋出相關成果,以吸納開發社群與中小型硬體設計廠商加入,目前已發展出近千餘個設計專案;此外,Arduino 更是一個集自由開源軟體專案與開放硬體設計為一身的出色專案,其以一塊 Simple i/o 介面板為基礎,建立起一個由使用者、開發者、廠商三者構成的擴充生態系,該專案主體的程式碼以 GPL-2.0 釋出,相關函式庫則以較寬鬆的 LGPL-2.1 釋出,多數的硬體設計圖,則普遍採用創用CC 姓名標示-相同方式分享,或創作者認可的其他創用CC 授權條款來提供;此外,國內重要的科技公司威盛電子 (VIA),近年來亦推出一個名為 APC 的客製化電腦方案(註二),亦是以開放硬體的授權框架為其基礎的運作模式。
接觸過自由開源軟體 (Free and Open Source Software)、創用CC 授權條款 (Creative Commons licenses) 與相關領域的人對於「公眾授權條款」這個詞應該都不陌生,因為在許多場合或者文獻資料中常常都會看到它。但是,「公眾授權條款」這樣一個被廣泛利用的中文辭彙,其實並沒有被清楚定義,甚至也沒有人嘗試加以描述或說明,因此筆者透過這篇文章,嘗試對其內涵進行整理、歸納,並且給予「公眾授權條款」一個基礎的解釋概念,讓未來有需要利用到這個詞的人,有一個參考的依據。

由於本篇文章將會綜合討論不同領域的授權條款,以及比較著作權與專利權的不同之處,這些條款的內容與權利的態樣均不完全相同,但囿於篇幅,筆者無法詳細介紹其中所有的相關內容,因此在相關段落中,還請讀者自行參閱引註當中的延伸資訊,在此先行說明。
雖著網際網路的進一步發展,近年來雲端運算成為一鼓新興的潮流,無論是大型的商業公司或小型的資訊服務業者,乃至於個人工作室,都乘著這鼓潮流,嘗試開發網路應用程式或提供相關的商業服務。與一般的軟體開發專案一樣,在開發網路應用程式或線上服務平台(以下統稱這些應用程式與服務平台的開發專案為「雲端應用專案」)的時候,也可能面對部份專案內容無法對外提供程式源碼 (Source Code) 的情況,例如雲端應用專案中某一部份的程式碼,因為受到第三方保密協議的拘束,所以不能對外提供源碼與相關資訊。這樣的專案若仍想要利用自由開源軟體元件來開發的話,那麼選擇哪些條款授權的元件,才不會造成未來應用時產生必須提供程式源碼的衝突,將是開發過程的一項重點。因此,本文將針對常見的自由開源授權條款(註一),說明相關的義務規定,據此建議雲端應用專案可以選擇哪些條款授權的元件,以避免無法提供源碼的專案產生授權義務上的衝突。
1. 前言

第三方利用人將自由開源軟體專案(以下簡稱「專案」)運用於其商品或服務的開發及相關商業行為時,首要重視者即其利用方式是否合乎該專案之授權條款。所有 OSI 認證的授權條款對於著作權授權皆有規範,較新近的條款對於專利權授權亦多有規範(註一)。然而,不同於著作權及專利權,商標權在授權條款中若有明文者,皆明示其專案之智慧財產權之授權範圍不包含商標及相關標章和名稱;未於授權條款中規範者,亦等同未就商標進行授權。其原因是,商標權乃利用該商標於商品或服務的法定專用權,目的在於保護商標權人之品牌,使他人不能隨意攀附商譽,亦避免其品牌價值被其他劣質商品或服務所影響,或是品牌印象被淡化,而失卻其商標權之保護(註二);同時,商標權亦旨在保障消費者對於該商品或服務之質量水平的信賴。因此,若利用人欲於其商品或服務中利用自由開源軟體,並會利用到該專案的名稱、商標或標識等,亦需注意利用方式必須符合該專案的商標政策或者合於商標法制規範,始得為之。

更多文章...

第 4 頁, 共 26 頁

4