自由開源軟體侵權爭端案例文章彙整

近來在整理法律專欄中,跟自由開源軟體侵權相關的文章,也同時將鑄造場網站上相關的新聞報導也做了整理。在鑄造場工作了這麼多年,雖然沒有一案不漏地介紹過所有侵權爭端案例,不過重要的案件都沒有漏掉。只是其中有些文章沒有做後續更新,因此資料仍是舊的,是比較可惜的地方。

【新聞報導】

一、BusyBox 侵權案件(違反GPL)

「Monsoon Multimedia 與 BusyBox 的 GPL 侵害訴訟達成和解」
http://www.openfoundry.org/tw/foss-news/1287

「SFLC 控告 Verizon 違反 GPL 散佈開放源碼軟體」
http://www.openfoundry.org/tw/foss-news/1334

「BusyBox 開發者與 Xterasys 取得 GPL 侵權訴訟和解」
http://www.openfoundry.org/tw/foss-news/1353 繼續閱讀 自由開源軟體侵權爭端案例文章彙整

[簡報] COSCUP 2013

我在今年COSCUP簡報的主題是貢獻者契約,早在2009年7月份的法律專欄,我就撰寫過這個主題的文章,不過今年度4月份我的同事兼前輩林懿萱又寫了一篇相關的文章,因此才讓我想要在COSCUP上面談這個主題。

《他人貢獻部份的智慧財產權管理》
http://www.openfoundry.org/tw/legal-column-list/2117-2010-07-15-10-16-56

《淺談貢獻者契約在自由開源軟體之應用》

http://www.openfoundry.org/tw/legal-column-list/8961-a-brief-introduciotn-of-the-application-of-contributor-agreement-in-the-field-of-foss

~~~~~~~~~~~~~~~~~~~~~~~~ 簡 報 資 訊 ~~~~~~~~~~~~~~~~~~~~~~~~~~
pdf檔:檔案下載請至20120803 from Florence T,M. Ko
odp檔:檔案下載請點這裡下載
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 繼續閱讀 [簡報] COSCUP 2013

雲圖 (Cloud Atlas)

“I seen too much o’ the world. I ain’t good slave."
~~ Autua

每個人對於電影的喜好不盡相同,而雲圖正是一部打中我多項偏好的電影:細緻的服裝、豐富的色調、美麗的音樂、交錯跳躍的故事劇情、變化多端的人物臉龐以及對於人性正面進化的樂觀態度,這些元素讓我在看這部片子時,在在感覺到無比的享受。

而這部電影最讓我印象深刻的是黑人奴隸Autua所的一句話:

“I seen too much o’ the world. I ain’t good slave." (我看過這世界太多的人事物,我不是個好奴隸!) 繼續閱讀 雲圖 (Cloud Atlas)

從開放源碼的理想到提供源碼的義務

本文原刊登於自由軟體鑄造場的法律專欄

過去在為商業公司的員工進行教育訓練課程時,都會介紹自由開源軟體具有「開放程式源碼」的授權特性,講久了,卻發現關於這一個特性卻沒有寫過介紹文章,所以才興起了我要撰寫這篇文章的念頭。不過寫完之後才發現,這篇文章不僅是在釐清「開放源碼」與「提供源碼」這兩個概念,也順便將自由軟體到開放源碼的歷史做了一個簡要的介紹,所以若是有人想要快速了解從四大自由到開放源碼間的歷史由來,本文可以當作一個入門的文章來閱讀。

~~~~~~~~~~ 本文開始 ~~~~~~~~~~

開放源碼(Open Source,註一)是現在許多人在接觸自由開源軟體時,第一個會接觸到的詞,它代表此類程式在散布時,皆能夠從散布者手上取得程式源碼。不過常見到的是,部份使用者會將這個詞,誤解為使用自由開源軟體所必須遵守的義務,認為一旦取得、持有自由開源軟體就必須主動公開手上所持有的程式源碼。其實開放源碼理想與提供源碼義務是兩個不同、但有所關聯的概念:開發者因為認同自由開源軟體理念,而主動公開其所撰寫的程式源碼,並授權給予他人來利用,所以他人才有機會以更深層的方式,利用到其所散布的自由開源軟體,這是屬於實踐開放源碼理想的過程;而當使用者取得自由開源軟體的程式源碼,部份條款要求其得在散布軟體的同時提供源碼給予後手,則是屬於履行授權義務的過程。本文以下將從自由軟體與四大自由談起,介紹相關的歷史背景與授權條款中提供源碼義務的內容,來說明開放源碼與提供源碼所代表的意義,以釐清兩個概念之間的關係。 繼續閱讀 從開放源碼的理想到提供源碼的義務

淺析自由開源軟體專案與其個別元件授權條款之差異

本文原刊登於自由軟體鑄造場的法律專欄

這是一篇有趣的文章,文章靈感來自於近日跟一位業界工程師所聊到的一段話,當時他表示有些自由開源軟體專案的授權還蠻複雜的,因為專案整體標示的是一種授權,但是裡面卻可能包含許多其他不同授權的程式碼,一不注意的話,可能就會誤解授權義務規定,而有侵權利用的狀況產生。這讓我想到,前一陣子處理的諮詢問題中,剛好也有開發者誤認元件授權條款跟專案整體授權條款一樣,最後必須置換元件的實例,因此而有了撰寫這篇文章的想法。

~~~~~~~~~~ 本文開始 ~~~~~~~~~~

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

【個案實例】

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 授權的程式碼,也一併經引用而成為後續衍生專案不可分割的一部份了。

繼續閱讀 淺析自由開源軟體專案與其個別元件授權條款之差異

試論「公眾授權條款」之名詞辨析與基礎概念

本文原刊登於自由軟體鑄造場的法律專欄

~~~~~~~~~~ 本文開始 ~~~~~~~~~~

接觸過自由開源軟體 (Free and Open Source Software)、創用CC 授權條款 (Creative Commons licenses) 與相關領域的人對於「公眾授權條款」這個詞應該都不陌生,因為在許多場合或者文獻資料中常常都會看到它。但是,「公眾授權條款」這樣一個被廣泛利用的中文辭彙,其實並沒有被清楚定義,甚至也沒有人嘗試加以描述或說明,因此筆者透過這篇文章,嘗試對其內涵進行整理、歸納,並且給予「公眾授權條款」一個基礎的解釋概念,讓未來有需要利用到這個詞的人,有一個參考的依據。

由於本篇文章將會綜合討論不同領域的授權條款,以及比較著作權與專利權的不同之處,這些條款的內容與權利的態樣均不完全相同,但囿於篇幅,筆者無法詳細介紹其中所有的相關內容,因此在相關段落中,還請讀者自行參閱引註當中的延伸資訊,在此先行說明。

繼續閱讀 試論「公眾授權條款」之名詞辨析與基礎概念

利用自由開源軟體元件開發雲端應用專案

本文原刊登於自由軟體鑄造場的法律專欄

~~~~~~~~~~ 本文開始 ~~~~~~~~~~

雖著網際網路的進一步發展,近年來雲端運算成為一鼓新興的潮流,無論是大型的商業公司或小型的資訊服務業者,乃至於個人工作室,都乘著這鼓潮流,嘗試開發網路應用程式或提供相關的商業服務。與一般的軟體開發專案一樣,在開發網路應用程式或線上服務平台(以下統稱這些應用程式與服務平台的開發專案為「雲端應用專案」)的時候,也可能面對部份專案內容無法對外提供程式源碼 (Source Code) 的情況,例如雲端應用專案中某一部份的程式碼,因為受到第三方保密協議的拘束,所以不能對外提供源碼與相關資訊。這樣的專案若仍想要利用自由開源軟體元件來開發的話,那麼選擇哪些條款授權的元件,才不會造成未來應用時產生必須提供程式源碼的衝突,將是開發過程的一項重點。因此,本文將針對常見的自由開源授權條款(註一),說明相關的義務規定,據此建議雲端應用專案可以選擇哪些條款授權的元件,以避免無法提供源碼的專案產生授權義務上的衝突。

繼續閱讀 利用自由開源軟體元件開發雲端應用專案

LGPL-3.0 訴訟案例解析:FreeAdhocUDF 侵權和解案

這篇原本是發表在鑄造場法律專欄的文章,閱讀資料與撰寫的過程很有趣,因為在研讀判決書的時候,遇到一些對我來說很陌生的法律概念(唉唉唉,我本來就不是一個好的法律學生),感謝Lucien的參與討論與指正,讓我可以將本案中德國法的觀念跟台灣這邊的規定串接起來。

~~~~~~~~~~ 本文開始 ~~~~~~~~~~

今年 (2013) 3 月 adhoc dataservice GmbH 與 Buhl Data Service GmbH 兩間德國公司在 Bochum 地方法院達成和解協議(註一),這是針對違反 LGPL-3.0(GNU Lesser General Public License version 3.0,註二)授權條款所達成的法庭和解,具有司法審判上既判力的效果,此一和解結果當事人不得再依司法手段爭執,從實務上來看,這樣的法庭和解也很有機會在未來相類的爭訟案件上,具有參考的地位。在當前自由開源軟體的侵權案例中,多是當事人自行談妥條件後進行庭外和解,經過法院訴訟程序而具有既判力的案例較少,因此本文將會介紹此案的內容,以供有興趣進一步了解自由開源軟體侵權案例的讀者參照之用。

繼續閱讀 LGPL-3.0 訴訟案例解析:FreeAdhocUDF 侵權和解案

利用 Apache-2.0 程式所應遵守的義務規定

這篇文章是與Lucien一起完成的,透過鑄造場的法律專欄發布。Apache-2.0是一款很寬鬆的授權條款,所以我原本很天真地以為這樣的主題不會太困難,等到真正著手撰寫之後,才發現正是由於寬鬆的授權特性,讓Apache-2.0在實際應用上呈現出非常多樣化的型態,因此反而在處理實際範例的部份花了很多的時間,果真是大意不得啊!謝謝Lucien花了許多時間來處理實際範例的內容。

~~~~~~~~~~ 本文開始 ~~~~~~~~~~

Apache License 2.0(簡稱 Apache-2.0)是 Apache Software Foundation(簡稱 ASF)在 2004 年所發布的授權條款(註一),雖然從數據上來看,Apache-2.0 被社群專案應用的程度遠不如 BSD、GPL 等授權條款,不過由於 Apache HTTP、Android 平台核心部份與 ASF 旗下所有專案均採用 Apache-2.0 來授權,因此近兩年來,筆者在工作上發現,有較以往為多的人詢問 Apache-2.0 條款的內容,這些問題中,又以詢問應該要如何遵守 Apache-2.0 義務規定佔了大部分。為此,本文特別針對 Apache-2.0 的義務規定加以說明,並且模擬常見應用狀況,提供實際應用的著作權聲明範本,希望可以便利開發者了解 Apache-2.0 的義務規定(註二)。

繼續閱讀 利用 Apache-2.0 程式所應遵守的義務規定

IBM Public License Version 1.0 非官方中譯

請注意:這篇中譯文僅供有需要之人參考之用,但不適用本部落格的創用CC授權方式

這份中譯本的草稿是我任職於資策會科技法律中心[1]時所翻,當時的草稿內容粗糙,所以一直放在自己的電腦裡。近來經過Lucien的修改與潤飾後,成為現在這個版本,中譯內容相當完備,因此釋出!

IBM Public License Version 1.0 (IPL-1.0)是IBM早期開始參與自由開源軟體時,所制定出來的授權條款,基本架構與後來改版而生的Common Public License Version 1.0 (CPL-1.0)以及Eclipse Public License, Version 1.0 (EPL-1.0)類似,但在實質內容上略有不同。

IPL-1.0: http://opensource.org/licenses/IPL-1.0
CPL-1.0: http://opensource.org/licenses/cpl1.0.php
EPL-1.0: http://opensource.org/licenses/eclipse-1.0

[1] 現在已經改組升級為科技法律研究所:http://stli.iii.org.tw/

繼續閱讀 IBM Public License Version 1.0 非官方中譯

A stupid human living somewhere on Earth.