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

自由軟體鑄造場將於 9/22 下午舉辦一場小型的討論會，討論會中邀請到著名的自由開源軟體侵權查緝專家 Armijn Hemel，分享其近來在歐洲處理侵權糾紛的經驗。Hemel 先生會將焦點放在最近德國所發生的幾件 GPL 侵權糾紛上，這些侵權糾紛皆由同一位 Linux 核心著作權人所發動，由於這位著作權人向侵權公司要求高額的賠償金，因此在檯面下引發了是否濫用 GPL 的爭議。透過 Hemel 先生的介紹，預計將會討論侵權救濟措施的合理邊際何在？以及當公司在遭遇到類似侵權主張時，有哪些應對措施可以採取。歡迎有興趣的朋友報名參加。 ...

GPL 是被廣泛採用的自由開源授權條款，不過由於 GPL 具有授權拘束性，衍生程式必須仍然適用相同條款授權（註一），所以在利用上會需要注意與之結合的程式碼授權內容是否相容，因為與之結合的程式碼一旦成為 GPL 衍生程式，就代表著在散布時必須要透過 GPL 條款來授權散布，若是其原本的授權內容與 GPL 不相容，會讓使用者無法同時符合兩份條款的義務規定，進而可能發生侵權利用的狀況。 因此本文將以 GPL-2.0 ...

...  針對這樣的運用方式，GPL-2.0、GPL-3.0、Apache-2.0、MPL-2.0 與 EPL-1.0 等授權條款，均有明確的文字，表示使用者可以透過收取費用的方式來提供額外的保證或擔保（註三）。而這種保證或擔保費用的收取，更是自由開源軟體的客製化承包商，得以生財牟利的彈性化商業應用模式。 值得注意的是，此類保證或擔保的承諾，是由特定使用者所自行提供，因此未來若是保證或擔保事由真的發生的話，也必須由這位特定的使用者自己來承擔保證或擔保責任，原自由開源軟體的授權人或其他的使用者，並不會連帶被課予這樣的保證或擔保責任。在一些授權條款中，有著明確的文字來闡明這樣的原則。所以若是因為某特定使用者額外提供的保證或擔保承諾，而使得授權人或其他使用者遭致損失或必須負擔額外責任的話，這位特定的使用者就必須協助授權人或其他使用者，來免於負擔這些額外的責任，而在授權人或其他使用者因此受有損失的情況下，這位特定使用者還必須要加以賠償這些無辜受殃者所遭遇的損失。 ...

...  其次，GPL-2.0、GPL-3.0、LGPL-2.1、LGPL-3.0、MPL-1.1、MPL-2.0、EPL-1.0 與 CDDL-1.0 這八份條款授權的元件，也是可以選擇的另外一種類別。這類授權條款都具有「授權拘束性（註二）」，原則上會拘束元件修改版本的授權方式，也就是修改後的衍生程式必須採用相同條款來授權，無法採用其他條款授權，例如元件原本採用 GPL-2.0 授權，修改後的版本也因此必須採用 ...

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

... sublicense 的條款之列；而使用率與知名度皆非常高，被 Linux Kernel 採納為其授權條款的 GPL-2.0，也不在這份清單裡面，所以這兩個狀況，都必須被進一步解釋與披露，才能讓讀者對於自由開源軟體領域裡 sublicense 機制的應用，有一個基礎但全面的認識。首先說明 BSD-3-Clause 的狀況，多數的論者認為解釋上從條款目的性的觀點來看，BSD-3-Clause 應該是能容許 ...

... 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 義務規定是否被啟動的重要地位。 在單純的例子裡，大家都可以輕易理解什麼是散布，例如甲從網路下載了 ...

GNU Affero General Public License 3.0 (AGPL-3.0) 是自由軟體基金會於 2007 年 11 月 19 日所發佈的一份自由開源軟體授權條款（註一）。這份授權條款與 GPL-3.0 為孿生條款，因為這兩份條款僅在第 13 條有所不同，其餘的規定則一模一樣。但這第 13 條的不同差異處，就讓 AGPL-3.0 與 GPL-3.0 的拘束特性有著很大的分別，這也讓許多提供網路服務的公司對於這份條款避之唯恐不及。但 ...

GPL 授權條款制定的目的，是希望人人都可以研究、修改與散佈程式，為了要達到這個目的，取得程式源碼 (Source Code) 是不可或缺的前提要件。因為雖然一位有能力的開發者在拿到目的碼的狀況下，也有可能透過逆向工程來將程式還原到源碼的形式，但這畢竟非常不便，也不是常態，很多情形下也有違法侵權之虞。因此在 GPL 授權條款的規定中，提供程式源碼是一項非常重要的義務，針對程式的研究與修改，透過源碼形式來進行是最為便捷的。而為了讓任何一位拿到程式的後手使用者，都可以順利取得相對應的程式源碼，GPL ...

從 2007 年中 GPL-3.0 編撰完成之後，新版 GPL-3.0 與舊版 GPL-2.0 的差異就是一個常被拿出來討論的議題。理論上，我們可以用「更新與升級 (update & upgrade)」的角度來理解 GPL-3.0，也就是說，GPL-3.0 與 GPL-2.0 兩份新舊條款，在推動軟體自由（Software Freedom，註一）的本質方面是相同的，但因為成文時空背景的差異，新版條款就軟體自由的保障加入了補充手段，並試圖處理舊版條款在 ...

... Inheritance，註二）而附加的「例外許可條款」（以下簡稱「例外條款」），讓使用者在應用 GPL 類元件產生衍生程式之後，有著為衍生程式選擇非 GPL 類授權方式的可能性，同時也維持商用自由開源軟體的多重目的。　 【以增加條款相容性為主要目的】 就筆者目前所觀察到的現象，典型的例外條款是附隨於 GPL 這份主授權條款而存在。由於 GPL 規定衍生專案的整體仍然必須採用 GPL 繼續授權，若是衍生專案中包含了 ...

... MPL-2.0 不但能夠與 Apache license 在同一個軟體專案下合諧運作而不產生衝突，透過「備位條款」的新機制，也能夠在需要的時候與 GPL、LGPL、AGPL 相容，使程式碼更易於再次被利用及散布（註二）。本文以下將針對此次改版的 MPL-2.0 與之前 1.1 版的主要差異點作要點分析。   差異要點分析 一、定義條款 將「適用程式」(Covered Code) ...

... Stallman 自由軟體鬥士精神，且身為世界上第一款以 GPL 授權條款釋出的 GNU Emacs，可以說是完全遵照最純正 GPL 精神來發展的自由軟體。 不幸的是，這次違反 GPL 授權條款的事件正好發生在 GNU Emacs 本身。也因為其特殊身份，使得整個事件的始末變成一個非常值得探討的議題。 GNU Emacs 違反 GPL 授權條款一事 2011 年 7 月 27 日，在專門討論 ...

Mozilla 日前釋出了 Mozilla Public License (MPL) 的第二版。此授權協議距離上一次更新已超過 10 年時間，修改重點針對其他自由軟體與開放源碼授權提供更佳的相容性，可望為 Mozilla 專案擴展更廣泛的程式碼重復利用的選擇。 新版 MPL 歷經 21 個月的公開諮詢。其基礎是 1998 年制定的 MPL 1.0 版，該版本僅於 1999 年翻修過一次。MPL ...

...  近年的自由開源軟體侵權爭議案件，多數是以違犯 GNU GPL (GNU General Public License) 等 Copyleft（註一）性質授權元件的遊戲規則為大宗，這是因為具有 Copyleft 性質的自由開源軟體授權條款，尤其是 GPL 類型的授權方式，其約束被授權人的義務性要求嚴格，且參與者於自由開源軟體社群中，不乏對於「軟體自由 (Software Freedom)」、「資訊人權 ...

... 的案子，柏林地區法院日前駁回 AVM 所提出，Cybits 的 Surf-Sitter 軟體侵害其著作權與商標法的主張。法院裁決 AVM 必須允許其他公司提供的軟體，修改該公司 Fritz!Box 路由器中以 GPL 授權、基於 Linux 上的韌體。 AVM 之前嘗試要禁止 Cybits 修改該公司路由器中所使用的韌體，其中包含了基於 Linux 自由軟體的關鍵元件。這兩家公司都使用到以 GPL ...

本文上篇的文章連接頁面如右：https://www.openfoundry.org/tw/legal-column-list/8446-the-license-inheritance-bounds-of-gnu-gpl-01 【實務上對 GPL 衍生程式可資操作的基本判別流程】 綜上所述、關於 GPL 衍生程式的判定標準，以及其授權拘束性的擴散範圍，可以歸納出三個可資操作的基本判別流程： 該軟體專案中是否內含 ...

GPL 類別的授權程式，最為人著稱的特性便是其「牽一髮而動全身」的授權拘束性（License Inheritance，註一）。所謂的「授權拘束性」白話來說，指的是當使用者將 GPL 授權的程式碼抄寫到自己的軟體專案時，如果抄寫程度佔專案程式碼的比例很大，或是此一 GPL 授權元件提供了專案的核心功能，並且專案的其他元件在互動上亦無法與其分割，則整個軟體專案便會一體被視為該 GPL 授權元件的衍生著作，嗣後使用者如果再行散布這個軟體專案，便僅能適用 ...

前言 Ruby 是屬於開放原始碼的物件導向程式語言，近年因 Ruby on Rails (RoR) 開放網頁應用框架的興起而廣為人知，並於 2006 年由 TIOBE 獲選為年度程式語言。 過去，Ruby 採用 GPL-2.0 或 Ruby 授權 的雙重開放原始碼授權，但從 2011 年 7 月 31 日所釋出的 Ruby 1.9.3 preview1 版本裡，筆者發現除了功能性的改進外，對於開放原始碼授權也進行了大幅度的變更。 ...

近來眾家廠商相繼推出 Android 平板裝置，對於 Linux 來說似乎是件好事。然而這些平板電腦遵循 GPL 與否的問題，卻使 Android 平板市場籠罩上一層陰影。受雇於紅帽 (Red Hat) 的 Linux 核心工程師 Matthew Garrett，針對市面上 Android 平板裝置的 GPL 遵循程度，做了依次總體檢。結果顯示，許多推出 Android 平板的廠商並未切實遵守 GPL。 ...

... 的基本資料： 軟體名稱：PDFCreator 檔案大小：17.8 MB 官方網站：https://www.pdfforge.org/ 下載網址：SourceForge.net PDFCreator 適用軟體平台：Windows（XP、Vista 和 Windows 7） 授權：GNU General Public License (GPL) ◎ 選擇繁體中文的問題和解決之道 雖然說這個版本已經解決了一些問題，不過在繁體中文介面方面卻出現了問題，首先就是在某些安裝步驟會出現亂碼： ...

大多數自由軟體的使用者，只知道使用時要注意軟體是採用何種條款授權釋出，並沒有進一步考慮到軟體的商標授權，也是使用時需要一併關注的重要課題。所以，筆者特別利用本文淺談自由軟體相關的商標授權問題，希望能讓讀者站在與著作權不同的商標權利用觀點，來觀察自由軟體商業應用方面的不同面相。 商標就是一般俗稱的「品牌」，是由文字、圖形、記號、顏色、聲音、立體圖形所組成的識別標誌，它需要向國家權責機構申請登記註冊後才受到保護，功用是拿來區分產品製造商或是商業服務的來源，舉例來說，消費者一看到紅底黃字的英文大寫 ...

這是一篇與同事天馬行空討論之後的心得分享，因為覺得內容蠻有意思，所以寫出來與大家分享。既然是天馬行空討論的心得分享，因此沒有完整的架構與結論，內容涉及的層面也有點廣泛，但是囿於篇幅，所以許多基礎內容將略而不提，在此先與說明。 很多人將 Copyleft 機制與 GPL 的授權感染性劃上等號，但其實這並不是正確的觀念。 Copyleft 只是 Richard Stallman（Stallman）所設計出來的一種機制，目的在於讓一個程式可以符合四大自由，也就是希望透過這一套機制，程式可以自由地為人所研究、修改與再次散布出去，並且希望程式可以一直抱持在這樣的狀態，不會改變。Stallman ...

...  軟體授權  GNU General Public License (GPL)  官方網站  https://camstudio.org/ 軟體下載  https://camstudio.org/dev/  開啟下載頁面，使用者必須分別下載兩個檔案，CamStudio.2.5.b1.bin.zip 與 mfc71.dll。 下載完成後，將 CamStudio.2.5.b1.bin.zip ...

最常見的 GPL-2.0 授權承繼性／拘束性 (License Inheritance) 討論，就是利用 GPL-2.0 程式碼所產生的新程式是否必須採用 GPL-2.0 授權，此外就是 Linux 系統上的應用程式是否也必須採用 GPL-2.0 進行後續的散布與授權，後者的討論因為 Linux Kernel 主要開發者兼精神領袖 Linus Torvalds 已清楚表態，寬鬆地認為單純的應用程式可以不採用 ...

GPL 這個授權條款一般來說是適用於「軟體授權」的狀況，但是近年來也看到不少採用 GPL 來授權圖示的例子（註一）。但令人疑惑的是：因為 GPL 授權條款的內容主要是規範軟體授權的運用方式，尤其是要求釋出程式目的碼 (binary code) 的散布者，也必須肩負後續提供程式源碼 (Source Code) 的義務，那麼以 GPL 散布圖示的時候，是不是只要將圖示的圖檔提供出來，便就符合了 GPL ...

荷蘭籍軟體工程師 Armijn Hemel 近日發佈一份「GPL 檢驗工程指南 (The GPL Compliance Engineering Guide)[1]」，提供了一套檢測嵌入式產品是否侵害 GPL 程式的基礎指南。 這份基礎指南就像是一套標準作業流程，說明如何檢驗一個沒有提供原始碼的嵌入式裝置是否有利用到 GPL 程式碼。指南一開始分析 GPL 程式如何應用在嵌入式裝置中，以及如何檢查開機管理程式、開機順序、檔案系統、壓縮方式與執行檔，也羅列用來進行檢查的各項工具，例如：binutils、hexdump、file、strings、tar與 ...

兩個月前談過「分開散佈．責任轉嫁」這種用來避開 GPL 感染的一種方法，今天要談的是另外一種方法：區隔機制。 所謂的區隔機制就是在 GPL 程式與 nonGPL 程式中間插入一個中介的介面，這個介面寫得夠好，讓 nonGPL 程式透過介面與 GPL 程式互動，nonGPL 程式因此不會包含任何的 GPL 程式碼，所以 nonGPL 程式不受到 GPL 感染。而這個介面可以是 LGPL、BSD 或 ...

一個常被提出的問題：要如何在利用 GPL 程式碼的同時，避免其他部份的程式碼也被 GPL 感染？之前曾經提過一些抽象的判斷標準，例如採用動態連結 (dynamic link) 利用 GPL 程式碼，因此開發出來的新程式，許多開發者認為可以不用受到 GPL 的拘束，但是採用靜態連結 (static link) 利用 GPL 程式碼，許多開發者認為新程式仍應該採用 GPL 授權。這樣的標準仍是相當抽象，這期的法律園地就來談一個比較具體的方式，筆者稱這樣的方式為「分開散布．責任轉嫁」。 ...

歐洲在過去 4 年，陸續產生 5 件 GPL 的法院案例，其中 4 件在德國，一件在法國，美國則是在 2007 年年底一口氣有 4 件 GPL 的訴訟案出來。在美國這 4 件案子出來前，就有不少人問我，美國既然是自由／開放源碼軟體的發源地，卻遲遲未見 GPL 法院訴訟，反而在德國產生了第 1 件 GPL 的訴訟，原因為何？現在美國有了案例，就讓我們先來大略瞭解一下這 4 個案例的始末，然後再來看美歐面對法律爭端時，處理態度的差異在那裡。 ...

... Wow! USB Protector 隨身碟病毒偵測軟體。採用開放原始碼 GPL3 授權，供個人或企業自由使用與研究。 Wow! USB Protector 是一款自動偵測隨身碟是否含有惡意程式的自由軟體。可以偵測出常見的隨身碟病毒，提供即時捕捉隨身碟病毒或可疑程式的功能，是一款輔助防毒軟體的安全工具。目前有繁體中文與英文介面，支援 Windows 2000/XP/2003/Vista 32bit/64bit ...

...  Apache-2.0 (Apache License 2.0)  MPL-1.0  (Mozilla Public License 1.0) SPL-1.0 (Sun Public Licnese 1.0) LGPL-2.1 (GNU Library/Lesser Public License 2.1) 首先要找出 BSD 類的條款，因為這一類條款的規定寬鬆，對於修改出來的衍生程式並沒有任何的限制，也因此對於選擇自己程式碼授權條款幾乎沒有任何影響。在這四份條款中，Apache-2.0 ...

此文的適用客體是以 GPL-2.0 釋出的商用產品，建議欲將 GPL-2.0 軟體應用於商業販售的廠商，可依此於產品販售前進行簡單的自我評量。原始參考文字取自歐洲自由軟體基金會（Free Software Foundation Europe, 以下簡稱為 FSFE）編著之 Useful Compliance Tips for Vendors 一文。本譯文摻雜了許多原文所無的贅字以幫助讀者得其真意，所為者乃提供簡單的中文說明及引論，有意參訪原文者可參照註解所附連結（註一）。而承繼 ...

從 2004 年開始，德國軟體工程師 Harald Welte（簡稱 Welte）以一年一個法院案例，向各界展現 GNU General Public License v.2 (GPL-2.0) 在德國的法律效力。今年七月底則向慕尼黑法院控訴著名的 Skypy，一審獲判勝訴。 爭端產品是透過 Skype 網頁販售的 VoIP-Telephon（註一），該產品韌體採用了 GPL-2.0 授權的程式，包括 ...

經歷了約一年半開放式網路論壇的意見討論，LGPL-3.0（註一）亦隨著 GPL-3.0 於 2007 年 6 月 29 日同天定稿，其基本的修正趨勢可大分為兩點，第一就是在函式庫程式 (library) 的應用方面更添彈性，LGPL-3.0 授權條款一方面試圖微調外擴性質的授權拘束性（註二），卻也同時拓深了所轄函式庫可能的散布管道；第二是將函式庫的實際運行法則案例化，舉凡 LGPL-3.0 條款第 ...

歷時一年半的意見蒐集與修改，GPL-3.0（註一）終於定稿，除了整體結構較為嚴謹外，也透過用詞上的去區域化，加強了 GPL-3.0 在不同國家司法管轄區域裡，被合理解讀的彈性（註二）。此外，GPL-3.0 相對於 GPL-2.0 的重大修改如下： TiVo 相關條款：目前 TiVo 產品的使用者，雖然可以取得程式原始碼 (Source Code) 修改 TiVo 的控制程式，但在修改之後卻會因為該產品的數位權利管理機制 ...

前幾天一位社群朋友轉寄一篇 Allison Randal 的文章（註三）連結給我，其中就以 Linux 為例，說明未來可能碰到的 GPL2（GNU General Public License, v.2）、GPL3 相容性問題。通篇看下來，發覺，其中所隱藏的問題還真不小！ 在 GPL2 規定中，與本文所要探討問題有關的是第 9 條，該條是說 FSF 可以隨時修改或發佈新版 GPL，此時使用者再次散布程式的時候，有著可以選擇修改版、新版或任何一版 ...

許多人在談到 GPL-2.0 時，只將重點放在它的感染性、它強制要求使用者提供原始碼等等特性上，其實其他的條款也相當重要，卻常被忽略，GPL-2.0第 7 條（註一）就是其中之一。 GPL-2.0 第 7 條首要的意義在於專利權，因為只要是程式，就會有專利侵權的風險，這樣的風險在自由／開放源碼與專屬軟體幾乎一樣的，而 GPL-2.0 所關心的是被授權人必須繼續以不收取授權金方式來散佈程式，因此在第 ...

2005 年初，美國一位軟體工程師 Daniel Wallace 控訴 FSF (Free Software Foundation) 違反美國的 Sherman Act（註一），請求法院發出禁制令，禁止GPL (GNU General Public License) 在美國境內的推廣與使用。 Wallace 表示 FSF 透過 GPL 與 Red Hat、Novell 以及 IBM 等幾家大公司，進行大量的著作權交互授權 ...

... AFL-3.0、OSL-3.0 與 MPL-1.1（註一）均有類似的規定。 最著名的 GPL-2.0 與 LGPL-2.1 則是在條款一開始之處，透過條款的著作權聲明，明示禁止他人修改條款內容，此外，這兩份條款還規定，任何一位使用者都不可以對程式後續收受者的權利增加任何限制，因此一般人僅可以單純地使用 GPL-2.0/LGPL-2.1 來授權自己的程式，並無法修改條款內容後再來使用（註二）。 不過這並不代表完全沒有轉寰之道，GNU ...

...  不過到目前為止，在這個領域還沒有一個所謂「可以快速辨識授權條款差異的方法」，所以自由軟體鑄造場 (Open Source Software Foundry, OSSF) 在這樣的狀況下，為使用者開發出了「授權指引」與「授權精靈」（註一）這樣的授權指引工具，如果使用者開發的為原生軟體專案，則可以透過此一網頁程式的操作，在回答幾個問題之後，簡便地挑選到適合使用的自由開源軟體授權條款。不過，如果對於使用者來說，授權精靈所詢問的相關問題若仍還是過於複雜、難以理解，這時候筆者就會用更簡潔的自由開源軟體授權三分法，來解釋不同類型授權條款之間的差異，那就是：「GPL ...

...  這樣的判斷方式適用於大部分的自由／開放源碼授權條款，當然，GPL 也不例外。不過也有授權條款針對此點有特別規定，AGPL (Affero General Public License v.1)（註一）與HPL (Honest Public License v.1)（註二）即為二例。 AGPL 與 GPL-2.0 基本上是完全相同的內容，只是 AGPL 在第 2 條第 1 項後面多了第 (d) ...

全球第一個經過完整法院訴訟程序（Hauptsacheverfahren，本案程序）的 GPL (GNU General Public License) 案例判決書，於今年九月在德國法蘭克福地方法院正式出爐，原告 Harald Welte（以下稱 Welte）第一審勝訴，被告則透過媒體表示不會上訴。GPL 在德國法管轄區域內的法律有效性與可執行性正式確立。 原告為馳名社群的德國軟體工程師 Welte，被告為台灣友訊 ...

2006 年一月 FSF (Free Software Foundation，自由軟體基金會) 發佈 GPL 第三版 (GPL3) 的草案，經過半年多的討論，七月底發佈了草案的第二版。修改重點包括文字描述簡單化、內容國際化、強化 GPL3 對於未來技術的適應性以及協調與其他授權條款的相容性等等。草案第二版看上去雖然有不少的修改，不過基本上仍然遵循相同的原則，大部份的修改只是針對前一版的內容再加以清晰化與具體化。 ...

對於 GPL（註一）有所了解的人都知道，一旦一個程式包含 GPL 程 式碼，所開發出來的程式也必須要採用 GPL。GPL 第 0 條第 1 段中 相關的原文是這樣寫的：“... that is to say, a work containing ... or a portion of it, ...”。這樣的規範內容相當模糊，究竟包 含多少 GPL 程式碼行數才可以算是這裡的“portion of ...

LGPL 的英文全文是「GNU Lesser General Public License（註一）」，那麼顧名思義，LGPL 在內容上是較為寬鬆的「GPL (GNU General Public License)」，所以說、LGPL 的基本架構與義務性要求都與 GPL 如出一轍，例如 Copyleft 的授權循環拘束機制，不得向收受程式者收取軟體授權金等特色皆幾近相同，不過、既然名為「寬鬆」，那必然也會有若干獨立於 ...

...  已經運作將近十五年的 GPL（GNU General Public License）第二版終於要改版，這應該可以列為 2005 年度首要大事！針對這個可以說是運用最為廣泛的自由/開放源碼授權條款，自由軟體基金會計畫發動一個為期一年的意見收集程序，聆聽各界看法，做為草擬第三版參考之用，不過修改內容並非毫無規則可循，自由軟體基金會發表了四項原則，作為草擬 GPL 第三版過程之最高依據。這樣的一個修改草擬程序，會對於整體自由/開放源碼授權條款的未來發展有何影響，十分令人期待。自由軟體基金會預計 ...

一九八九年自由軟體之父史托曼（Richard M. Stallman）草擬 GPL（ GNU Genral Public License）（註一）第一版，在經過兩年的運作 後，旋即於一九九一年修改釋出第二版，沿用至今，GPL 第二版已經 堂堂邁入第十五個年頭了，其間社會環境變遷與第二版草擬時有所不 同，為了因應這些變化，並且同時解決第二版在運作時所產生之問題， GPL 目前的著作權人自由軟體基金會正著手草擬 ...