這篇文章原本刊登於自由軟體鑄造場的法律專欄，感謝Lucien對本篇文章所提供的意見。
~~~~~~~~~~ 本文開始 ~~~~~~~~~~
所謂的受雇人，簡單來說，就是在一間公司或組織聘用來在負責一定職務工作的員工，因此受雇於一間公司來專職開發軟體、韌體的工程師，就是受雇人，而該公司就是雇用人（註一）。若是這間公司利用 GPL 元件來開發產品，軟體工程師可以自由散布產品程式碼嗎？工程師在產品中所撰寫開發的程式碼，其權利是屬於工程師本身、還是該公司？這些疑問是受雇軟體工程師在利用自由開源軟體來開發產品時，可能會產生的，因此本文將先從著作權法相關的規定談起，並且說明實際雇傭關係的運用狀況，進而釐清這些可能的疑問。 閱讀全文 受雇人利用 GPL 元件開發公司產品的著作權歸屬與運用疑義解析
這篇關於專利授權條款介紹的文章，持續寫了約一個禮拜，其中 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 等，摘要式說明這些條款中與專利相關的規定，希望可以幫助有需要的朋友，能得到進一步掌握自由開源專利議題的參考資訊。
此篇文章原載於自由軟體鑄造場網站上的「法律專欄」。
~~~~~~~~~~ 本文開始 ~~~~~~~~~~
經過這二、三十年的發展，自由開源軟體 (Free and Open Source Software, FOSS) 在品質與數量上面均有大幅度的成長，近年來更是大舉被產業界取來進行商業利用，也因此被應用的層面愈來愈廣，但對於傳統上僅熟悉私有軟體 (proprietary software) 授權模式的商業公司而言，初接觸自由開源軟體不免會引發各式各樣的問題與困擾，例如：「是否可以在終端產品中嵌入自由開源軟體進行商業販售？」、「是否作為內部開發工具就沒有延申要提供程式原始碼 (Source Code) 的問題？」、「如何讓工程師快速了解授權內容，從第一線開始避免侵權利用？」。在國內，有些公司已設有專職人員來研究與處理上述的相關問題，不過就筆者所知，這樣的公司目前仍是少數，大部份的狀況是，面臨到自由開源軟體授權問題與困擾的產品工程師，必須肩負起閱讀授權條款、釐清授權義務規定、回覆客戶相關問題，以及研究如何實踐授權義務、讓客戶安心等等的責任，這使得工程師在原本的產品開發與既定的管理工作之外，又增加了研讀艱澀授權條文的工作，而可能導致心力分散、處於不堪負荷的狀態。這樣的現象挑戰著商業公司的管理階層：如何在內部深化應用自由開源軟體的同時，又能夠同步降低可能產生的風險與困擾？因應這樣的轉變與問題，國外許多公司均制定有自由開源軟體產品應用的管理流程，讓員工在利用自由開源軟體元件加速產品開發的同時，有一套制式的流程可以遵循，不過這樣的觀念在國內仍屬少見，因此本文將介紹一個簡化版的自由開源軟體核准流程，作為商業管理流程的範例，藉此向讀者說明善用管理流程所可能發揮的功效。
授權說明：本文章採用CC-BY-NC-SA 3.0 unported條款授權。
======
今年的 COSCUP2011 跟 Lucien 進行了一場演講，講題是「自由軟體授權資訊的標示與SPDX」，談的是基本卻非常重要的軟體授權資訊的標示問題，以及介紹 SPDX (Software Package Data Exchange) 這個計畫所制定的規格書。
由於自由軟體容許使用者修改與散布，因此許多開發者都會利用既有的自由軟體元件，來加速專案的開發時程。不過在取得快速開發優勢的同時，卻產生了不少元件 授權狀態衝突與違反授權規定的問題。這些問題的根源之一在於，許多自由軟體的授權標示方式與內容並不友善：資訊可能藏在網站或檔案的某個角落，難以搜尋取 得，即使找到，其中的文字也可能過於簡略，無法讓開發者全面理解到元件中所有的授權內容。因此從去年開始以 Linux Foundation 為首的自由軟體推動組織發起了 SPDX (Software Package Data Exchange) 計畫，希望透過建立自由軟體授權標準資訊的方式，減輕目前標示不清所產生的問題，進而讓自由軟體的利 用更為便捷。目前 SPDX 計畫的產出已經略具規模，開放源碼促進會 (Open Source Initiative, OSI) 也根據這個計畫的內容，修改了網站上面授權條款的標示。因此本場次將會介紹目前常見的自由軟體標示方式、說明過往產生的相關問題，並針對 SPDX 計畫的內容做概要介紹，作為國內社群與廠商開發與利用自由軟體時參考之用。
就是這款 “Inspiron Mini 10v“！
前一陣子參加 Ubuntu Hardware Summit 時，才跟同事談起，沒有看到預載 Ubuntu 出貨的電腦，對於這個終端使用者十分友善的 Linux 作業系統來說，有點可惜，結果今日就看到這則新聞！
這是 Dell 的小筆電，上面預載 Ubuntu Moblin Remix Developer Edition，當然也有預載 XP 作業系統的版本供選擇，價格貴約 5,000 元，但是硬碟空間 160 GB，比預載 Ubuntu 的 8 GB 硬碟多了許多 。之所以會有這樣的差異，我想因為目前選擇預載 Ubuntu 的買家，即使不是專業資訊人員，至少也是玩家或半玩家，這些人並非單純的使用者，會有大於一般使用者的硬碟需求，配以 160 GB 也不見得足夠，因此節省成本，僅配以基本的 8 GB 硬碟，讓這些使用者自行購買符合其容量需求的硬碟。
… 接續《 Ubuntu Hardware Summit 2009（上）》。
之所以會參加這場研討會，因為近來跟工作上友人談到，可以在台灣舉辦一場針對公司管理階層的自由軟體研討會。正在討論的期間就看到同事傳來這場研討會的訊息，看上去，Canonical也有相近的意圖，因此來看看，實際舉辦這樣活動，現場狀況會是如何。
在報到處看到的報名名單還蠻長的，沒有仔細算，但是超過二百人是絕對有的，現場實到的人數大約140人左右。這比我預估的多，因為記憶中的議程大多是行銷、社群運作等非技術的內容，對這類內容感興趣的台灣廠商很少，所以原本估計來參加者大約 70 人上下。不過開幕演講的現場調查顯示，大部份與會者都是軟體工程師，仔細看看議程，原來這些人是來聽技術內容的，再加上一整天非技術議程零落的聽眾，所以，果真，在台灣，大部分的廠商還是只關心技術，並不關心自由軟體在管理、運作與行銷等等非技術層面的內容。
今日參加 Canonical 所舉辦的”Ubuntu Hardware Summit 2009“。這是招商大會，因此一些 Canonical 重要的技術或業務人員均飛來台灣參與這場的高峰會。活動對象很明顯地以硬體廠商與相關工程師為主，不過 Canonical 的 Engineering Manager Hugh Blemings 在開幕演講的調查顯示，現場沒有硬體工程師，倒是軟體工程師一堆。有意思的開始！
整天的議程除去開場演講外，共六個時段，十三場議程，分別在兩個主要會議廳進行，其中六場偏技術議程，另外七場為行銷、品質管制、社群運作相關等議程。因此可以看到，Canonical 想要讓與會者對於 Canonical 與 Ubuntu 來個一次大了解：從技術到行銷、品質管制、社群運作面等等。除去技術部份，其餘的議程較適合業務或管理階層人員來聽，而因為現場與會者大多是軟體工程師，因此參與這些議程的人數自然不多，只能用零零落落來形容。