本文原刊登於自由軟體鑄造場的法律專欄。
~~~~~~~~~~ 本文開始 ~~~~~~~~~~
接觸過自由開源軟體 (Free and Open Source Software)、創用CC 授權條款 (Creative Commons licenses) 與相關領域的人對於「公眾授權條款」這個詞應該都不陌生，因為在許多場合或者文獻資料中常常都會看到它。但是，「公眾授權條款」這樣一個被廣泛利用的中文辭彙，其實並沒有被清楚定義，甚至也沒有人嘗試加以描述或說明，因此筆者透過這篇文章，嘗試對其內涵進行整理、歸納，並且給予「公眾授權條款」一個基礎的解釋概念，讓未來有需要利用到這個詞的人，有一個參考的依據。
由於本篇文章將會綜合討論不同領域的授權條款，以及比較著作權與專利權的不同之處，這些條款的內容與權利的態樣均不完全相同，但囿於篇幅，筆者無法詳細介紹其中所有的相關內容，因此在相關段落中，還請讀者自行參閱引註當中的延伸資訊，在此先行說明。
本文原刊登於自由軟體鑄造場的法律專欄。
~~~~~~~~~~ 本文開始 ~~~~~~~~~~
雖著網際網路的進一步發展，近年來雲端運算成為一鼓新興的潮流，無論是大型的商業公司或小型的資訊服務業者，乃至於個人工作室，都乘著這鼓潮流，嘗試開發網路應用程式或提供相關的商業服務。與一般的軟體開發專案一樣，在開發網路應用程式或線上服務平台（以下統稱這些應用程式與服務平台的開發專案為「雲端應用專案」）的時候，也可能面對部份專案內容無法對外提供程式源碼 (Source Code) 的情況，例如雲端應用專案中某一部份的程式碼，因為受到第三方保密協議的拘束，所以不能對外提供源碼與相關資訊。這樣的專案若仍想要利用自由開源軟體元件來開發的話，那麼選擇哪些條款授權的元件，才不會造成未來應用時產生必須提供程式源碼的衝突，將是開發過程的一項重點。因此，本文將針對常見的自由開源授權條款（註一），說明相關的義務規定，據此建議雲端應用專案可以選擇哪些條款授權的元件，以避免無法提供源碼的專案產生授權義務上的衝突。
這篇原本是發表在鑄造場法律專欄的文章，閱讀資料與撰寫的過程很有趣，因為在研讀判決書的時候，遇到一些對我來說很陌生的法律概念（唉唉唉，我本來就不是一個好的法律學生），感謝Lucien的參與討論與指正，讓我可以將本案中德國法的觀念跟台灣這邊的規定串接起來。
~~~~~~~~~~ 本文開始 ~~~~~~~~~~
今年 (2013) 3 月 adhoc dataservice GmbH 與 Buhl Data Service GmbH 兩間德國公司在 Bochum 地方法院達成和解協議（註一），這是針對違反 LGPL-3.0（GNU Lesser General Public License version 3.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 的義務規定（註二）。
這個版本的中文內容是我任職於資策會科技法律中心[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/。
這篇關於專利授權條款介紹的文章，持續寫了約一個禮拜，其中 GPL-3.0 第 11 條第 4-7 項的內容花了我大部分的時間，這四個條項的文字非常抽象難懂，就算是搭配了自由軟體基金會的說明理由書來看，還是耗了我許多時間去思考，然後加上與同事的討論、對照條文後，才比較可以領略其中的深意。
GPL-3.0 草擬過程有許多大型公司參與討論，說明理由書在這部份的解說中也不止一次提到，商業公司對於 GPL-3.0 第 11 條第 4-7 項內容有著不同的意見與考量點，所以可以想見，當初在制定這部份規定時所上演過的激烈角力賽，也因此可以推估，這四個條項應該是激烈討論、平衡各方利益後的折衝結果，因此所產生的文字抽象、其中蘊含的邏輯不易理解。
總之，自己對於文章中說明 GPL-3.0 第 11 條第 4-7 項的文字不甚滿意，未來若是有機會改寫的話，會再改寫的白話、易懂些，目前只能希望讀的人的可以看懂 >_<！
此篇文章原載於自由軟體鑄造場網站上的「法律專欄」。感謝林誠夏對於本文所給予的建議。
~~~~~~~~~~ 本文開始 ~~~~~~~~~~
軟體專利與自由開源軟體的本質有所不同（註一），因此如何將軟體專利對於自由開源軟體開發模式的衝擊降到最低，一直是自由開源領域中一個重要的議題。目前實務上所採取的應對措施有許多種，包括鼓勵重要技術的先前揭露、成立交戶授權如 Open Invention Network 這樣的組織等等，而新近修訂的自由開源軟體授權條款，也大多加入了專利授權與規劃的相關規定，因此本文選擇了數份常見且具重要影響力的自由開源軟體授權條款（註二），包括 BSD-2-Clause、BSD-3-Clause（以下統稱這兩份授權條款為 BSD）、MIT、Apache-2.0、EPL-1.0、MPL-2.0、CDDL-1.0、GPL-2.0、GPL-3.0、LGPL-2.1、LGPL-3.0 與 AGPL-3.0 等，摘要式說明這些條款中與專利相關的規定，希望可以幫助有需要的朋友，能得到進一步掌握自由開源專利議題的參考資訊。
此篇文章原載於自由軟體鑄造場網站上的「法律專欄」，與林誠夏共同撰寫完成。
~~~~~~~~~~ 本文開始 ~~~~~~~~~~
GPL 授權條款有著許多不同於傳統軟體授權方式的相關規定，其中散布程式的時候必須提供源碼的規定，則是影響最大、也最常被違反的一項。這項義務與其他 GPL 條款中所規定的義務一樣，都是透過散布行為而被開啟，也就是說，程式被利用或移轉的方式若不是 GPL 條款所定義的散布行為，散布者就可以自由選擇是否要去遵守其他後續的相關義務規定。因此散布的內涵有著左右 GPL 義務規定是否被啟動的重要地位。
在單純的例子裡，大家都可以輕易理解什麼是散布，例如甲從網路下載了 GPL 程式 A 之後，再將程式 A 拷貝到朋友乙的電腦中，這時候程式 A 就是從甲的手中被散布到了乙的手中，因此依照 GPL 規定，甲負有將程式 A 源碼提供給乙的義務。但是隨著資訊科技的發展與商業交易行為的多樣化，使用者可能在利用銀行自動化設備與租借嵌入式裝置的同時，而間接利用到、或者甚至間接占有了 GPL 程式一段期間，例如前一陣子才停止網路電視服務的壹多傳媒，該服務出租網樂通機上盒給予客戶，客戶只要自行將顯示螢幕與網路線接到機上盒，就可以收看所提供的網路電視節目，這個機上盒為嵌入式的 Linux 作業系統，有利用到很多 GPL 程式，但是壹多媒體在最初時並沒有釋出機上盒的程式源碼，因而引發後續爭議，就是一個典型的例子。這種透過出租產品與提供服務，所造成程式碼移轉的行為，是否也屬於 GPL 所規定的散布程式碼的行為？針對這個問題，本文將會針對目前被廣泛採用的 GPL-2.0 與 GPL-3.0 說明相關規定，並嘗試釐清問題的癥結點，期望可以拋磚引玉的讓大家對這個議題，有一些基本的認識。
此篇文章原載於自由軟體鑄造場網站上的「法律專欄」。本文感謝林誠夏與林懿萱的校閱與建議。
~~~~~~~~~~ 本文開始 ~~~~~~~~~~
近年來隨著手持裝置的熱賣，依附這類裝置運作的線上軟體市集（以下簡稱「軟體市集」）已經成為散布與販賣軟體的重要管道之一，因而吸引了許多開發者在手持裝置上開發各類的軟體（以下簡稱這類軟體為 “App”），並透過軟體市集來散布，不過由於軟體市集自有一套運作的規則與機制，其呈現介面也與傳統的桌機、筆電不同，因此若開發者利用自由開源軟體開發 App、並透過軟體市集來散布時，是有可能會產生授權衝突或違反散布義務等問題。本文從了解軟體市集特有的運作規則與機制開始，說明筆者目前所觀察到的一些問題，同時提出預防這些問題發生的建議措施，供 App 開發者參考之用，希望用以降低未來授權糾紛產生的機率。
此篇文章原載於自由軟體鑄造場網站上的「法律專欄」。感謝林誠夏對於本文結尾所給予的建議。
~~~~~~~~~~ 本文開始 ~~~~~~~~~~
GNU Affero General Public License 3.0 (AGPL-3.0) 是自由軟體基金會於 2007 年 11 月 19 日所發布的一份自由開源軟體授權條款（註一）。這份授權條款與 GPL-3.0 為孿生條款，因為這兩份條款僅在第 13 條有所不同，其餘的規定則一模一樣。但這第 13 條的不同差異處，就讓 AGPL-3.0 與 GPL-3.0 的拘束特性有著很大的分別，這也讓許多提供網路服務的公司對於這份條款避之唯恐不及。但 AGPL-3.0 在使用上真的如此令人恐懼？其中的條款內容究竟如何？在利用自由開源軟體元件的同時，又應該以什麼樣的態度與立場來面對 AGPL-3.0？本文將會針對這些問題一一說明 。
GPL 授權條款制定的目的，是希望人人都可以研究、修改與散布程式，為了要達到這個目的，取得程式源碼 (Source Code) 是不可或缺的前提要件。因為雖然一位有能力的開發者在拿到目的碼的狀況下，也有可能透過逆向工程來將程式還原到源碼的形式，但這畢竟非常不便，也不是常態，很多情形下也有違法侵權之虞。因此在 GPL 授權條款的規定中，提供程式源碼是一項非常重要的義務，針對程式的研究與修改，透過源碼形式來進行是最為便捷的。而為了讓任何一位拿到程式的後手使用者，都可以順利取得相對應的程式源碼，GPL 設有一套規定散布者如何提供程式源碼的規定，來保障這些源碼可以持續地被後手取得。
此篇文章原載於自由軟體鑄造場網站上的「法律專欄」。感謝林誠夏對於本文所給予的修正。
~~~~~~~~~~ 本文開始 ~~~~~~~~~~
GPL 授權條款制定的目的，是希望人人都可以研究、修改與散布程式，為了要達到這個目的，取得程式源碼 (Source Code) 是不可或缺的前提要件。因為雖然一位有能力的開發者在拿到目的碼的狀況下，也有可能透過逆向工程來將程式還原到源碼的形式，但這畢竟非常不便，也不是常態，很多情形下也有違法侵權之虞。因此在 GPL 授權條款的規定中，提供程式源碼是一項非常重要的義務，針對程式的研究與修改，透過源碼形式來進行是最為便捷的。而為了讓任何一位拿到程式的後手使用者，都可以順利取得相對應的程式源碼，GPL 設有一套規定散布者如何提供程式源碼的規定，來保障這些源碼可以持續地被後手取得。