1、此文譯自David A. Wheeler所寫「Make Your Open Source Software GPL-Compatible. Or Else.」一文，翻譯並未經過原作者授權及認證，且摻雜許多原文所無之贅字以幫助讀者得其真意。
2、關於「Make Your Open Source Software GPL-Compatible. Or Else.」可參照此 ，此一英文版本方為原作者傳達其意涵的唯一正確版本。
初稿完成於2002年6月5日；修訂時間2007年8月9日；翻譯時間2008年2月14日。
This essay argues that developers of open source software / Free Software (OSS/FS) should use an existing widely-used license compatible with the General Public License (GPL), such as the GPL, LGPL, MIT/X, or BSD-new licenses. This article was previously printed, with a number of changes, as an article at OsOpinion.
此 篇文章欲表彰的核心議題是，欲將所開發軟體以自由軟體授權方式釋出者，應盡量使用散布程度高且為眾人所熟知的授權條款來為程式進行授權，並且讓此程式與 GPL授權的程式具有相容性以利程式的後續散布，像是以GPL授權條款本身或是LGPL、MIT、三款式的BSD等符合前述要件的自由軟體授權條款來為程 式進行授權。
Introduction-簡介
This essay is a call to all those developers who are developing open source software / Free Software (OSS/FS, also called FLOSS or FOSS). OSS/FS developers: Please, where possible, use an existing widely-used license for your software that is known to be compatible with the GNU General Public License (GPL), such as the GPL, LGPL, original MIT/X, or BSD-new licenses. And, if you create your own license – and please try not to – make sure that your new license is compatible with the GPL. You don’t need to use the GPL – not even the Free Software Foundation (FSF), the developer of the GPL and its most avid proponent, claims that absolutely all software must be GPL-licensed. (For example, see the endorsement by FSF’s Richard Stallman of Ogg Vorbis license changes, and note that the FSF developed and maintains the Lesser GPL as a compromise license.) But make sure that your OSS/FS software’s license is GPL-compatible, i.e., that you can combine your code with code released under the GPL into one larger program. The rest of this essay explains why and how to do so.
這篇文章乃是要向自由軟體的程式開發者呼籲：如果客觀條件許可，請盡量選用散布程度高且為眾人所熟知的自由軟體授權條款，並且亦請考慮其與GPL授權條款之間的相容性，方有利於程式的後續散布效率，如GPL授權條款本身或是LGPL、MIT、三款式的New BSD等，就是符合前述條件的自由軟體授權條款。再者、如果您新編了個人式的授權條款(最好是不要、 因為現時自由軟體授權條款的數目已然繁多，並且這也會大大阻礙了他人取用您程式的機會，畢竟不是每個程式設計師都兼有法律專業，其並不必然會願意花費時間 對這些自行創建的授權條款進行詳加研讀，反而很可能因為對授權條款的內容不甚理解而直接放棄使用您的程式)，也請讓這些新撰的授權條款能夠在本質上與 GPL授權條款相容。說實在的、這篇文章並不是洗腦式的要您將自己編寫的程式都以GPL授權條款來釋出，這樣的訴求連編撰GPL授權條款的自由軟體基金會都不敢這般赤裸裸的要求(進一步了解可參照Richard Stallman所撰the endorsement by FSF’s Richard Stallman of Ogg Vorbis license changes一文，並且請注意、自由軟體基金會本身亦已認知到GPL授權條款的嚴苛義務性要求未必能讓所有人皆心悅臣服願意取用，故進而撰寫了軟體自由理念實踐上及義務性要求上皆較為寬鬆的LGPL供人選用)，但是為了您程式日後散布上的便利性考量，讓其能與GPL授權程式相容一事至為重要，如此一來、您所撰寫的程式方可與現時世上大部份的自由軟體之間產生融合應用的可能性，本文以下的內容即對您解釋這些自由軟體授權關係的相容性策略，以及如何以最簡便的方法為您的程式預留與GPL程式相容的可能性。
GPL-incompatible licenses risk lack of support (GPL most popular)-自由軟體與GPL授權條款不相容的風險所在(從GPL程式的廣大佔有率觀點談起)
Why a GPL-compatible license? Because if your OSS/FS project isn’t GPL-compatible, there’s a significant risk that you’ll fail to receive enough support from other developers to sustain your project.
為何您 所編寫的自由軟體應盡量使其採用與GPL程式具有相容性的授權條款?一言以蔽之、即是自由軟體程式裡，GPL佔有廣大市佔率所造成的影響，也就是說、若您 自行編撰的軟體程式與GPL授權條款之間不相容，則會造成市佔率極高的GPL軟體程式並不能夠與您程式相結合的後果，亦即此一程式很可能因此得不到多數自 由軟體程式編寫者的支援，而成為孤鳥程式，而若以自由軟體開發方式首重「多人共工」此一特點來審視，「失去網路同好的奧援」對於程式的後續發展及研發實在 是個不小的風險。
Many OSS/FS developers prefer the GPL, because they believe the GPL (1) provides a better quid-pro-quo for developers, (2) establishes collaboration between people and companies better than consortia, (3) protects their work in today’s less-than-kind environment, and/or (4) encourages increasing the amount of Free Software. Examples of such thinking include Jeremy Allison’s “Freedom Fighters" (which points out that NetApp’s improvements to BSD-licensed code are not contributed back but its improvements to GPL-licensed code have been), as well as Eben Moglen’s claims that BSD-style licenses are “a really good license for your competitor to use". Moglen’s point is that he believes a business should use a license which requires others to give back their changes (like the GPL) if it does not want to provide a free lunch to its competitors. Many people argue for the GPL, though the view that the GPL is a good or necessary license is not a universally-held position by OSS/FS developers (e.g., see Montague).
許 許多多投身自由軟體程式編撰的開發者樂於使用GPL授權條款，因為他們相信GPL授權條款帶來以下的各種好處：(1)建立一個「程式原始碼開放與取得供需 平衡」、「施與及收穫善意循環」的良好環境；(2)於程式使用者及研發公司之間構築一種合諧的共工機制，而不需要透過特定聯盟機構來費心操作；(3)GPL律定已開放的程式原始碼不可嗣後為任何人所封閉，此可保護初始創作者的心血不至於日後為特定人士所私有式獨占利用；(4)利用GPL授權條款的「授權攫取特性」來進一步擴展GPL程式的數量及市佔比率。進一步要了解這些開放者選用GPL授權條款的理由，您可參閱Jeremy Allison所著 「自由鬥士」一書(此書舉NetApp程式為例，其以BSD授權條款釋出散布的程式碼，經過改良後的成果並不會迴流到原作者手上，但是其以GPL授權條款釋出的程式碼，就一定程度會反饋原作者成為一種施與得的循環)、或是Eben Moglen所著「BSD授權條款如何利人不利己」一文，Eben Moglen的觀點在於、若是任何人有意就其所釋出的自由軟體進行商業營運，那麼程式碼經修改後可否反饋回到著作權人手上(像GPL授權條款就具有這項特 性)，就是一項著作權人需嚴肅思考忖度的重要特性，因為若是缺漏此項特性而又想利用程式進行商業營運，便如同做了好球給同類型的競爭同業打，讓別人利用此 一程式搭順風船、吃免費的午餐，可說是非常的利人不利己。是以在這些想法的主導下，許多自由軟體界的程式設計者偏好使用GPL來釋出其軟體程式，雖然此種傾向並非人人都有，亦非放諸四海而皆準(可參照Bruce Montague的不同意見)，但其確乎代表了某程度自由軟體編寫上取用GPL授權條款為適用條款的主流思想。
But even if you don’t like the GPL yourself, many potential co-developers do… and your project is more likely to be successful if you accommodate them. Usually even avid GPL proponents will support OSS/FS programs with other GPL-compatible licenses, if you choose to not use the GPL. For example, the FSF has long supported the X Window System (X11), even though it’s released under the MIT/X license. However, if your license isn’t GPL-compatible, developers may create a competitor instead so they can take advantage of GPL’ed code.
在這種主流思想的影響下，若然 您的地位為程式軟體的原始設計者，且並不欣賞GPL授權條款的諸般義務性規定而拒絕選用GPL，但當您將程式以自由軟體授權的方式釋出時，許多潛在的程式 後續修改者卻會有相當比例是愛用GPL授權條款的人，如果能預留這些修改者將程式衍生作品以GPL授權釋出的「相容性」，那也可以一定程度加速這個原生軟 體的推廣效率，因為此時您的軟體程式與GPL授權條款之間具有相容性，那麼連最虔守的GPL理念推廣者都不致於去反對它或是拑制其散布。舉例來說、自由軟 體基金會長期來一直支持「X視窗(X11)」這個軟體計劃，即使其並非是以GPL授權條款來進行釋出，而是採用MIT授權條款。並且反過來說、如果您所釋 出的自由軟體與GPL授權條款並不相容，那麼通常的狀況下依此軟體的性質，其會於網路社群中催生出另一獨立編寫的GPL相容版本來與您的程式競爭，因 GPL相容的程式能取用到最多的軟體共享素材，如果您的程式本質上不能與這些GPL的可用素材相容，那麼就可能引發網路社群另行編寫相類程式來取代它的動 機。
And there’s a lot of GPL’ed code to take advantage of:
看以下這幾條表列，您可以清楚了解到，GPL相容性可以帶來這麼多的軟體編寫共享素材：
1. Freshmeat.net reported on November 10, 2003 that 69.66% of the 32,592 software branches (packages) it tracked are GPL-licensed (the next two most popular licenses were the LGPL, 5.29%, and the BSD licenses which combined to 4.82%). Some Freshmeat branches are proprietary, but clearly the GPL is the leading OSS/FS license in this set. You can also see the latest Freshmeat.net statistics.
1、依照Freshmeat.net這個網站2003年11月10日的統計分析， 其觀察了32,592個軟體專案的釋出條款，比例第一的就是佔有69.66%的GPL(第二多的是5.29%的LGPL，第三多的是BSD授權條款的 4.82%)。當然不可諱言的、Freshmeat.net所觀察的部份專案其實算是私有專屬軟體的範疇並非自由軟體，但從這份統計分析亦可讓讀者一目了 然，目前在自由軟體授權條款的領域裡、選用性比例最高的就是GPL授權條款，其佔有全然傾斜的半壁江山，想要進一步確認這個事實的讀者請按此檢閱Freshmeat.net上最新的統計分析數據。
2. SourceForge.net reported on November 10, 2003 that the GPL accounted for 71% of the 45,736 projects it hosted with OSI-approved open source licenses (next most popular were the LGPL, 10%, and the BSD licenses, 7%). Not all SourceForge projects are active or have produced much code, but nevertheless this gives reasonable evidence that the GPL is widely used. You can also see the latest SourceForge.net statistics. Another way to get SourceForge statistics – and many others – is through FLOSSmole. FLOSSmole is a tool for querying data about FLOSS repositories, and they make it easy to analyze data from many sources.
2、而依照SourceForge.net這個自由軟體界最大的專案管理平台2003年11月10日的數據分析， 其上選用開放源碼促進會認可的自由軟體授權條款的專案有45,736個，這些專案有71%的第一高比例是選用GPL授權條款為其專案釋出的條款(第二高為 LGPL的10%，第三高為BSD授權條款的7%)。當然、並非所有於SourceForge.net上的軟體專案都是活躍且高成果產出的成功專案，但無 論如何、這樣的數據已足以表彰，GPL授權條款確實是以超出其他授權條款甚多的比例在被推行運用著，欲進一步確認此項事實的讀者請按此檢閱SourceForge.net上最新的數據分析。此外、您亦可透過FLOSSmole這個網站來查找SourceForge.net、或是其他更多的自由軟體相關資源網站的數據分析，FLOSSmole這個網站的特點之一就是可以交叉詢查各大著名自由軟體資源網站上提供的資料，是一個方便使用者簡易分析此等數據資料的入口網站。
3. In my paper More than a Gigabuck: Estimating GNU/Linux’s Size, I found that Red Hat Linux, one of the most popular GNU/Linux distributions, had over 30 million physical source lines of code in version 7.1, and that 50.36% of the lines of code were licensed solely under the GPL (the next most common were the MIT license, 8.28%, and the LGPL, 7.64%). If you consider the lines that are dual licensed (licensed under both the GPL and another license, allowing users and developers to pick the license to use), the total lines of code under the GPL accounts for 55.3% of the total.
3、在拙著More than a Gigabuck: Estimating GNU/Linux’s Size一文中，曾經就GNU/Linux裡著名的Red Hat版本做過統計分析，其7.1版於數目超過三千萬筆的程式碼編寫來源裡，就有超過一半的50.36%高比例是單獨僅以GPL授權條款來釋出其所編寫的程式(第 二高的比例是MIT授權條款的8.28%，以及LGPL的7.64%)。如果考慮到某些程式元件其實也以雙重授權的方式來釋出的話(亦即一手以GPL授權 條款釋出，但另一手也以其他授權條款同時同步釋出程式，這樣的方式能讓程式的使用者視其需要選用較為有利的授權條款)，那麼Red Hat7.1版程式元件以GPL授權釋出的比例就更為驚人，整體觀之能夠達到55.3%之譜。
4. Savannah hosts 1,986 mostly-GPL projects (as of November 11, 2003) and strongly encourages GPL-compatible licenses.
4、Savannah網站其上營運1,986件大部份為GPL授權的專案主機代管服務(依2003年11月11日統計)，其網站營運政策聲明項裡並強烈建議使用者為其軟體專案選用與GPL具有相容性的授權條款。
5. The FSF’s free software directory lists OSS/FS software. On September 24, 2002, I downloaded their entire directory, and found that it had 1550 entries, of which 1363 (87.9%) used the GPL license, 103 (6.6%) used the LGPL license, 32 (2.0%) used a BSD or BSD-like license, 29 (1.9%) used the Artistic license, 5 (0.3%) used the MIT license, with other licenses being even rarer. The FSF prefers the GPL license, so the FSF directory statistic may be biased in the percentage of GPLed software it registers, but the directory still provides strong additional evidence that the GPL is a widely used license for OSS/FS.
5、在自由軟體基金會網頁裡的自由軟體分類目錄中， 列示了各式各樣可資下載使用的自由軟體。於2002年9月24日時，筆者下載了它整個目錄內容來進行分析，發現全部1550筆程式資料裡，有1363筆 (約佔全部的87.9%)是以GPL授權條款來進行散布的，103筆(約6.6%)是依LGPL授權條款，32筆(約2.0%)使用BSD或近似BSD類 型的授權條款，29筆(約1.9%)使用Artistic授權條款，5筆(約0.3%)使用MIT授權條款，除此之外的其他授權條款不是沒人使用，但其比 例顯得更為稀少而渺小。當然我們可以合理推論，自由軟體基金會對於GPL授權條款當然會有偏好的傾向，是以此一軟體分類目錄裡群集了較高比率的GPL授權 程式亦是事理之必然，但無論如何、此一目錄仍是觀察上一個有力事證，足以表彰GPL授權條款確實於自由軟體的世界裡被廣為運用、流傳。
6. Eric S. Raymond’s “Homesteading the Noosphere” (section 2) reported that in July 1997 about half the software packages with explicit license terms at North Carolina’s Metalab (formerly Sunsite) used the GPL. At the time Metalab was the largest OSS/FS software archive.
6、 Eric S. Raymond於其所著“Homesteading the Noosphere”一書中(第二章)，指出於1997年7月時、美國北卡羅來納州的「超越研究室(前身稱為太陽站台sunsite)」所收納的程式專 案，其一半以上都明示採用GPL授權條款，於其時「超越研究室」是全美最大的自由軟體收納儲存資料庫。
7. The Who is Doing It (WIDI) study examined the BerliOS SourceWell list of applications. Of the 1136 applications tracked at that time, the top three were the GPL at 85.9% (976/1136), LGPL at 4.6% (52/1136), and BSD-style at 2.8% (32/1136).
7、在一份名為「是誰在研發」 的自由軟體專案開發者的調查統計報告中，其報告內容披露出於其時進行的1136件自由軟體專案中，使用比率最高的授權條款第一名是GPL的85.9% (1136件專案中佔了976個)，第二名是LGPL的4.6% (1136件專案中佔了52個)，第三名是BSD類授權條款佔了2.8% (1136件專案中有32個)。
8. What about what’s used, rather than what’s developed? A 2003 MITRE survey of U.S. Department of Defense (DoD) use of FLOSS found that 52% of the reported FLOSS applications were released under the GPL; the next-largest licenses were BSD (6%), Apache (5%), various “Community" (4%), and LGPL (3%). Even if you claimed that all non-GPL licenses were simply BSD variants (which is not true), the GPL had a simple majority of the licenses of FLOSS in use.
8、除了以開發者選用比例的角度外，我們還可以用使用比例的角度來觀察GPL授權條款的廣大市佔率。以美國國防部2003年委託MITRE公司做的自由軟體使用調查報告為 例，報告內容指出52%的自由軟體應用程式是以GPL為其釋出時指定的授權條款，其次是BSD的6%、Apache的5%、各式各樣的社區式分享條款有 4%，還有LGPL有3%。即使有人謬誤的宣稱除了GPL以外的其他授權條款都算是BSD類的變體(事實上並不是這樣)，仍然無礙GPL授權條款在自由軟 體使用比率上居於宰制性多數地位的這個事實。
9. A survey of FLOSS developers in Asia by Shimizu et al. in 2003-2004 found that across Asia, 64.7% preferred “GPL-compatible" licenses (presumably they meant GPL or LGPL licenses) while 15% preferred BSD-style, and in Japan, 42% preferred “GPL-compatible" licenses while 30.2% preferred BSD style licenses.
9、在Shimizu等人2003年至2004年於亞洲地區做的自由軟體開發者調查分析一文裡， 其發現64.7%的開發者偏好選用「GPL相容條款(就本文的定義特指GPL或是LGPL等自由軟體基金會編寫的公眾授權條款」來釋出其軟體程式，而有 15%的開發者偏好BSD類型的自由軟體授權條款；而在日本、約有42%的軟體開發者偏好選用「GPL相容條款」，而有30.2%比例的開發者偏好BSD 類型的自由軟體授權條款。
Karl Fogel’s “Producing Open Source Software: How to Run a Successful Free Software Project says that “If you want your code to be able to be mixed freely with GPLed code — and there’s a lot of GPLed code out there – you should pick a GPL-compatible license."
Karl Fogel所撰「開發自由軟體：如何營運一個成功的自由軟體專案」一文中，更是開宗明義的破題說到：「如果您想讓所寫的軟體程式能夠自由不受限制的，與其他以GPL釋出的軟體程式碼相融-這樣的好處是目前能取用的GPL釋出程式碼非常豐富-那麼您就該果斷的選用與GPL授權條款具有相容性的授權條款。」
You ignore this amount of code and support at your project’s peril.
如果捨棄了取用這些眾多GPL釋出程式碼的可能性，那無疑的就是置您自行編寫的自由軟體程式為孤鶵，而有可能得不到網路社群共工的奧援而有中斷開發的風險。
Other projects show GPL compatibility important-比對著名自由軟體專案的開發歷程以揭露GPL相容程度的重要性
Want more evidence that GPL compatibility is important? Several large, high-profile OSS/FS projects have undergone painful changes to make themselves GPL-compatible:
如果以上GPL授權程式獨大的市佔率還不足以勸服您，請再參閱以下幾個自由軟體界裡具指標意義的重要軟體專案其授權方式轉換歷程，亦可相當程度為您揭露GPL授權相容的重要性為何：
1. The widely-used Python language underwent major license changes in 2001 so that version 2.1 and on would be GPL-compatible.
1、極之著名且廣為使用的Python程式語言於2001年間在授權方面做了重大變革，最大的改變動機就是讓Python授權條款自2.1以後與GPL授權條款間具有相容性。
2. The popular text editor vim became GPL-compatible, after a long legal discussion. Linux Journal magazine has awarded vim as the most popular editor multiple times, so this isn’t an obscure program.
2、歷經了漫長的法律授權爭議討論後，受到許多使用者喜愛的文字編輯器vim終於也變的能與GPL相容了。Linux Journal這本雜誌曾經多次稱許vim為最受歡迎的文字編輯器之一，所以這可不是什麼默默無名的雞肋程式喔。
3. Mozilla also underwent a complex relicensing scheme, again, to resolve perceived incompatibilities between their older licenses and the GPL.
3、Mozilla這個著名的自由軟體專案群(其下轄有使用率非常驚人的網路瀏覽器Mozilla Firefox)，在長時間的討論後也微調了它的授權策略，原因主要就是為了解決舊版MPL授權條款無法與GPL相容的問題。
4. Zope also transitioned from their “Zope Public License version 1” (which was GPL-incompatible) to a GPL-compatible license.
4、Zope也是成功的自由軟體專案，其亦揚棄舊版的「Zope公眾授權條款1.x版」，轉而改用與GPL授權條款相容的2.x版，此亦為一向GPL相容性靠攏的著例。
5. The University of California at Berkeley released a large quantity of code (the Berkeley Software Distribution, BSD) that became the basis of the various *BSD systems. The original BSD license included an awkward advertizing requirement that was GPL-incompatible. After many requests (including notes that the license was GPL-incompatible), Berkeley decided to change the license in 1999 making this code GPL-compatible (the FSF has a page discussing the original BSD advertizing clause from their perspective).
5、加州大學柏克萊分校釋出了許多以BSD條款授權的軟體程式碼，可說是BSD類作業系統的骨幹而居功厥偉。但一直以來自由軟體界對於這些軟體程 式碼，亦有其適用上的困擾，因為早期的BSD授權條款具有一項「廣告條款」的聲明，而這項聲明恰是與GPL授權條款所無法相容的，以致於BSD授權的軟體 程式雖給予後手極大的修改及應用自由，但前述這些軟體程式碼卻無法與自由軟體界裡最大分支的GPL授權體系交相融合。此一不便在歷經許多自由軟體社群的呼 籲和陳情後，加州柏克萊分校終於1999年做出正式回應，其發表正式聲明刪除原BSD授權條款的第三條「廣告條款」，此後的BSD版本即可與GPL授權條 款相合(有興趣深入了解此段爭議歷史的讀者、可參閱此一連結內容，內容為自由軟體基金會從追求「軟體自由理念」的立場評論舊版BSD的廣告條款。)
6. Apache changed their license to “version 2.0”, and one of their goals was to be “compatible with other open source licenses, such as the GPL”. Unfortunately, the Apache Software Foundation believes Apache License version 2.0 is compatible with the GPL version 2, while the Free Software Foundation’s legal team asserts that Apache License version 2.0 is not GPL-compatible. Since that time, the FSF and Apache Software Foundation have been working together, and GPL version 3 is known to be compatible with the Apache License version 2.0 (Apache co-founder Brian Behlendorf is delighted by the Apache 2.0 / GPLv3 license compatibility). This long history makes it clear that both sides believe that GPL compatibility is an important advantage in an OSS/FS license.
6、Apache可說是自由軟體世界裡於網路伺服器方面表現傑出的要角，其授權條款由Apache1.0升級至Apache2.0的重要原因之 一，就是增加Apache軟體與其他的自由軟體程式之間的相容性，當然、與GPL授權程式之間的相容性就是左右其改版考量的重點項目。但是不幸的這個爭議 在Apache授權條款改版為2.0後並沒有馬上被弭平，就Apache軟體基金會的認知、Apache授權條款2.0的版本已然與GPL授權條款2.0相容，但顯然自由軟體基金會就此事持不同意見，自由軟體基金會的法律諮商團隊公開宣稱Apache授權條款2.0仍然是有若干規定不符合GPL的預設造成二不相容。從那時候開始、自由軟體基金會與Apache軟體基金會開始攜手協商解決此一爭議，是以其後編撰的GPL3.0的版本即被認為與Apache2.0相容無疑(進一步的資訊、可參閱Apache軟體基金會的共同創始人Brian Behlendorf所發表關於此事的析論)。 從這段冗長的授權條款改版歷史來看，可以清楚知道不管是自由軟體基金會或是Apache軟體基金會，都認知到他種自由軟體授權條款能與GPL授權條款保有 相容空間的重要性，不論是其他自由軟體授權條款的支持者或是理念派的GPL偏好社群，都可以透過這樣的彈性互容機制而互蒙其利。
7. The toolkit Qt (the basis of KDE) originally had a GPL-incompatible license. Its owners now dual-license Qt with the GPL so that Qt is GPL-compatible.
7、挪威Trolltech公司的Qt工具組(KDE 窗面系統裡的重要元件)本來是以QPL為其授權條款，這是一款與GPL絕不相容的自由軟體授權條款。但Trolltech嗣後改弦易轍以雙重授權模式來釋 出Qt，除了商業授權模式之外、另一手是選擇以GPL為其自由軟體授權模式的授權條款，而不再延用其自行編寫的QPL，從這一點來看、GPL授權條款的相 容性造成的影響不容忽視。
8. As noted in Wine history, the Wine project‘s “history of licensing has sparked many debates." The WINE project originally had the BSD-old license, a GPL-incompatible license; this incompatibility with the GPL drove the developers to switch to the GPL-compatible X11 license in January 2000. Many developers expressed concern about appropriation of the code by commercial entities, so in March 2002 the developers agreed to switch Wine to the LGPL license. The “ReWind" project was created for those who wanted an X11-licensed codebase, but most developers decided to focus their efforts on synchronizing with the LGPL’ed Wine, and the vast majority of development and new features appear there first. The Wine project reports that shortly after changing the license to the LGPL, development began to pick up at a greater pace (more patches began to appear, the leader Alexandre made more CVS commits, and more applications were reported to work).
8、Wine也是一個著名的自由軟體專案、其讓使用者得以在Linux下模擬微軟Windows的作業環境，並進而得以使用某些只能在微軟Windows下運作的程式。其專案網頁上可查找到Wine這個專案的開發歷程， 其中一段文字明述「Wine曾在研發的過程中歷經多次授權方式選擇的爭辯及火花」。怎麼說呢?初始之時、Wine專案是以舊版的四款BSD為其授權條款， 此時因為舊版BSD的「廣告條款」而與GPL授權條款無法相容；這個與GPL無法相容的困境迫使Wine的研發者，於2000年1月份改用與GPL相容的 X11授權條款，但授權方面的爭議並未因此而塵埃底定；許多Wine的程式開發者表達了他們的疑慮，那就是Wine的部份軟體程式碼來源是由商業團體所提 供，那麼將其一概繩以X11授權條款的拘束是否合宜?是以到了2002年3月這些程式開發者便決議將Wine轉而使用LGPL授權條款來進行散布 (LGPL與GPL相容，並且其亦容許一定範圍下商業軟體與LGPL程式連結運作卻不互相雜揉干涉的應用模式)。「ReWind」這個子計劃、就是一個意 欲將Wine同步以X11及LGPL授權條款研發釋出的專案，因為部份的研發者希望保有以X11授權條款釋出的程式型態，但此時大部份程式研發者的能量已 轉而專注到LGPL釋出的Wine專案上，此時雖然Wine兼有以X11及LGPL授權條款釋出的版本，但其後程式碼的改良及產出無論是在時效上或數量 上，LGPL釋出的版本都佔領先趨勢，也可說是終於與GPL授權條款具強質相容性所帶來的好處(LGPL釋出版本可資運用的修補檔較多，且網友回報程式臭 蟲的效率或是上傳相關應用程式的數量較之X11單軌釋出時期有顯著的提升)。
9. Alfresco relicensed their enterprise content management program from the MPL to the GPL (both FLOSS licenses, but the MPL is GPL-incompatible). Stephen Shankland’s article on Alfresco reports Matt Asay (Alfresco’s vice president of marketing) saying that moving to the GPL removes some barriers, and allows Alfresco able to easily integrate with other GPL projects. It also quotes 451 Group analyst Raven Zachary saying that, “Alfresco’s use of the GPL license for its Community Edition allows for potentially greater community contributions due to license familiarity and established standards."
9、Alfresco是有相當名聲的自由軟體研發公司，其轉換了旗下的企業資訊管理系統的授權方式，從MPL授權條款改成了GPL授權條款(皆為自由軟體類的公眾授權條款，但MPL向被認為與GPL授權條款不相容)。根據Stephen Shankland對Alfresco撰寫的評論新聞， 其中報導了Matt Asay(Alfresco銷售部副理)針對授權轉換一事對外的官方聲明，其認為將專案授權條款轉換為GPL後可消弭許多程式編寫上的障礙，譬如轉換後的 Alfresco專案便可輕易的與其他眾多GPL軟體程式碼相結合，這可說是Alfresco著眼永續發展的一大利基。文中亦引述了分析家Raven Zachary的評論：「Alfresco對其社群版本的軟體改採GPL授權釋出，此可一定程度吸引軟體社群的開發者對Alfresco的軟體提供貢獻， 因為多數的自由軟體程式編寫者對於GPL的授權模式最為熟悉，並且此一作為有助於編寫上格式的統一劃齊。」
Multiple major projects don’t undergo painful license changes unless they have a reason to do so. The GPL is so popular that GPL compatibility is now an important requirement in a license. Eirik Eng, president of Trolltech (owner of Qt), explained Trolltech’s actions by saying, “lately the GPL has been used more and more for newly opened source [software].” The article “Replacing init with Upstart" notes that when the authors were starting their “Upstart" project, they looked at existing systems as a starting point, and Sun’s SMF and Apple’s program ‘launchd’ “were immediately ruled out due to licence issues. It was important for us that the solution be uncontroversially free so that other distributions might adopt it; many had already rejected these for GPL incompatibility reasons."
事實上、轉換釋出程式的授權條款對於自由軟體專案營運者本身而言絕對是件大事，需要費時推廣、事前也需要進行許多權利盤點、釐清及解釋方面的工 作，可說是非常麻煩，然後、為何還會有這麼多的軟體專案在其營運有年之後，才終於決定要向GPL授權條款相容的方向靠攏呢?其最大的著眼點，不可諱言的就 是考量到GPL軟體程式的廣大市佔比率。挪威Trolltech公司(Qt專案的著作權人)的總裁Eirik Eng，曾在解釋其Qt專案的授權方式為何由QPL轉為GPL與商業授權模式併行的場合裡公開表述：「重要的影響因素之一、在於新的自由軟體專案採用 GPL授權條款的比例愈來愈高。」而以下這篇文章「不要輸在起跑點」 則指出，愈來愈多的自由軟體程式開發者在營運專案之初，其著眼的是如何在既有資源的基礎上更行擴張，善用現存的自由軟體程式碼方能「百尺竿頭更進一步」， 而不是「萬丈高樓總是從頭蓋起」那般苦力耗損的事倍功半，以例子來佐證的話、譬如昇陽的SMF及蘋果的launchd軟體專案，可說就是因為授權條款方面 的爭議，致使推行之初即被軟體社群拒絕接納而終被掃地出門。對於自由軟體社群而言、新的軟體專案的性質可否被驗証為具有「高度軟體自由性」一事非常重要， 若是限制過多或是條款內容過於繁複新穎，則軟體社群取用的機率就大為降低(另一方面來看、對這個新專案進行除錯增補的機率也是大為降低)，是以很多情形 下、某些新的自由軟體專案不為自由軟體社群所接納採用，最大的原因並非其程式編寫技術粗略，而很可能是因為其與GPL授權條款無法相容而根本上就被大多數 的自由軟體開發者拒絕取用。
Sun’s Solaris operating system was released under the CDDL, a GPL-incompatible FLOSS license. Sun has every right to release their software under whatever license they choose (within the law), of course. However, Groklaw’s article “Sun Responds to Criticism of CDDL” states that because the CDDL is not GPL-compatible, Sun will not gain the community support it hopes to garner from using the CDDL. The article predicts that “The result will be, though, that Linux will continue to develop more quickly and it will bury Sun’s license and its code… Sun is free to cut itself off from that, if it so chooses, but it will reap what it sows. If they imagined that the world would drop the GPL and adopt the CDDL instead, I trust by now they realize that isn’t going to happen… I seriously doubt that any license that is GPL/LGPL incompatible will be widely adopted.”
值得探討的是、昇陽將其下Solaris作業系統以CDDL進行授權釋出，CDDL是一個改寫自MPL的自由軟體授權條款，但其與MPL具有同樣 的問題懸而未解，那就是並不能夠與GPL授權條款相容。當然、依據著作權法的預設，昇陽公司有權將其所研發的任何一款軟體以其偏好的授權方式釋出，然而、 參閱著名的自由軟體爭議評論網站Groklaw這篇「昇陽對CDDL授權條款的評論回應」一文， 評論者直接了當的指出、因昇陽執意採用與GPL授權條款不相容的方式釋出其Solaris，其將無法得到多數自由軟體程式開發者社群的奧援，並且評論者預 估Linux仍會持續成長，並且最後終將蓋過Solaris現階段贏得的舞台及目光，於其時、昇陽當然可以壯士斷腕的停止開發Solaris相關計畫，但 這麼一來就失卻了其原本要以自由軟體授權模式營運軟體專案的預期目的。如果昇陽一開始的想像是部份的自由軟體程式開發者會揚棄GPL而改採CDDL的中庸 策略，我相信到目前為止昇陽公司應該了解到這個算盤是已然打不響了，就筆者的個人看法來說、我強烈懷疑在自由軟體界，能有什麼無法與GPL相容的新式授權 條款，卻還能夠為人廣為散佈取用的可能性存在。
More recently, in November 2006 Sun announced that they would be releasing their implementation of Java. The license? The GPL, along with a few LGPL-like-exceptions for their library – and not the CDDL.
就在最近、2006年11月時，昇陽公告其將旗下Java語言的相關重要程式對公眾聲明釋出。那是用哪一份授權條款呢?最後謎題揭曉還是取用了GPL授權條款，部份的函式庫是採用LGPL授權條款的方式來迴避GPL太強烈的授權攫取性，以上的重點是、昇陽並無法堅持選用其自行編撰的CDDL，最後還是和現實環境妥協而採用了GPL授權為主的策略。
There’s also recent evidence that GPL compatibility is important from one project that’s tried to go from GPL-compatible to GPL-incompatible: XFree86. The XFree86 project historically led development of a popular X server, and traditionally the vast majority of its code used the simple “MIT/X” open source license that is GPL-compatible. The XFree86 president, David Dawes, decided to change the XFree86 license to one that wasn’t GPL-compatible, primarily to give developers more credit. In the end, this change led to a mass exodus, as nearly all developers and users immediately abandoned XFree86, because of this attempt to switch to a GPL-incompatible license. See my appendix on XFree86 for more detailed information about this.
我們還可以舉另一個從GPL相容走向GPL不相容的反向例子，XFree86、以彰明GPL相容性對一個自由軟體專案未來發展的重要影響性。 XFree86這個軟體專案一直以來都在X伺服器的研究發展上居於領導地位，而傳統上其大部份的軟體程式碼是以MIT授權條款來進行散布，於GPL相容性 方面並沒有任何問題。但後來XFree86的專案領導人、David Dawes，其決定將XFree86的授權方式從MIT移轉為另一個與GPL不相容的授權條款，這樣的更動主要著眼在新的授權條款，設計上給予程式的研發 者更為詳盡的顯名聲明。但是最後、這樣的授權轉換對專案造成了極之不利的傷害，幾乎所有的XFree86研發者及使用者都摒棄不再繼續使用 XFree86，就因為此時XFree86的授權模式，造成其再也無法與其他GPL授權的程式相容。有興趣進一步了解XFree86授權轉移相關資訊的讀 者，請參閱本文關於XFree86的附錄。
Samba’s Volker Lendecke stated that any European Commission remedies involving Microsoft’s release of data would require the use of a GPL-compatible license. So even data releases – not just software code – are being examined to see if they are GPL-compatible.
此外、轉述Samba的核心工程師，Volker Lendecke對於歐洲議會修正微軟不公平競爭現況的建言， 其認為非僅止於程式原始碼的範疇，就連微軟所釋出的檔案資料格式亦應與GPL授權條款相合，方能真正解決微軟挾其市佔率行事實上之寡占的問題。由此可知、 與GPL授權接軌乃是一種不停被向上提升的訴求，程式的著作權利人如欲將程式以自由軟體授權的方式釋出，就其程式的未來發展必然得考慮到，GPL授權條款 的影響力長遠且巨大，並且在自由軟體的世界裡，GPL授權相容性的訴求乃程式著作權利人須於程式散布前再三忖度、無可規避的重要思考問題。
Some GPL-incompatible licenses to avoid-以下的授權條款與GPL並不相容、是您取用前須審慎評估並且最好避免採用的
There are many GPL-incompatible licenses that you should avoid releasing software under if at all possible. We’ve already mentioned the CDDL; here are some others:
以下會提到幾款略有名氣的自由軟體授權條款，但其實它們是與GPL不相容的，如果您取用其為程式釋出時的授權條款，一定程度下會為您的程式帶來後 續開發上的困擾，就一般自由軟體程式開發者的角度而言(如果您是專門的自由軟體商業營運公司，則自然另有堅持考量吧?)，您應該盡量避免使用它們。之前已 提到了昇陽的CDDL，以下就為您介紹須特別注意的其他條款：
1. Avoid the original (“4-clause") BSD license. The original BSD license included a clause now called the “obnoxious BSD advertising clause”. This stated that:
All advertising materials mentioning features or use of this software must display the following acknowledgement: “This product includes software developed by the University of California, Berkeley and its contributors. "
1、 請盡量避免使用舊版(四款)的BSD授權條款來釋出您的程式。此一版本的BSD授權條款含有一款「讓人嫌惡困擾的廣告條款」如下：「任何使用此一軟體者，其於散布促銷時須公告明示以下的顯名聲明：『此一產品使用了加州大學柏克萊分校及其貢獻者的軟體程式。』」
This made it incompatible with the GPL, as well as introducing practical problems noted by the FSF. The problem is that when code is merged together (and it is), and everyone adds their own name (they did), people couldn’t advertize without listing potentially hundreds of people – making this completely clause impractical as software scaled. In June 1999, after two years of discussions, the University of California removed this clause from the license of BSD. Thus, this is an obsolete license that should no longer be used; use licenses such as the “new BSD" aka “modified BSD" or “3-clause BSD" license instead.
就是這幾行字使得舊版的BSD授權條款無法與GPL授權條款相容，因為GPL授權條款在2.0版本時，並不能夠讓散布者增添任何一項其條款本無的 限制至條款內容裡，而這項廣告條款、即被視為對於收受程式者增添了GPL授權條款本無的「額外限制」，進一步來說即為逾越了GPL授權條款的授權態樣，更 詳盡的說理請參閱自由軟體基金會針對此一問題所做的分析。 而就務實面來說、舊版BSD授權條款要求在程式碼融合時，任一對於程式碼有貢獻者都應提供其自身的名字，並且逐一列上前有貢獻的先行者名字，但一個成功的 自由軟體專案往往彙集眾人的成果，是以後續此種顯名的義務動輒羅列上百人，造成程式編寫散布上尾大不掉的負累及包袱。是以在1999年6月，經過了眾多網 路社群二年期間的爭論及陳情後，加州大學柏克萊分校終於正式聲明撤除了舊版BSD授權條款此一極富爭議性的「廣告條款」。是以、舊版的BSD授權條款可說 是已然被廢止的歷史遺物，如果程式編寫者沒有特別的堅持立場請不要選用它，您可選用去除「廣告條款」後的「新版BSD授權條款(三款BSD授權條款)」， 其方可與GPL授權的程式相容無礙。
2. Avoid the “Academic Free License" (AFL). It has been claimed that the AFL was a “compatible upgrade” from “licenses such as BSD and MIT”, but this is a misleading claim; as the FSF notes, “the modified BSD license and the X11 license (aka MIT) are GPL-compatible, but the AFL is not." (at least version 1.1 and 2.1 are incompatible, and I believe that AFL version 3 is incompatible as well). The AFL has some nice properties from a legal point of view, but its GPL-incompatibility is a serious failing that completely dwarfs those advantages. Projects such as SHPTRANS have noted the AFL incompatibility as a serious problem, and have chosen to not use the AFL for this reason. At one time some people in the OSI recommended the AFL, but as of July 30, 2007 the OSI lists the AFL license as being “redundant with more popular licenses", and pointedly does not include it with “Licenses that are popular and widely used or with strong communities".
2、請盡量避免使用AFL授權條款(Academic Free License)來釋出您的程式。雖然很多人宣稱AFL授權條款是BSD及MIT條款的「相容性升級版本」，但這其實是個誤解；參照自由軟體基金會的官方 意見，其認為「新版的BSD授權條款及MIT授權條款是和GPL授權條款相容的，但是AFL授權條款卻是不相容的。」(就AFL條款內容來解析，其1.1 及2.1版本皆與GPL授權條款不相容，筆者認為之後的AFL第3版應該也是不相容。)誠然、AFL授權條款就法律觀點而言、是有許多對自由軟體創作饒富 趣味及幫助的創見設計，但其與GPL授權不相容這點，就大為弱化了其實際上被廣為選用的可能性。像是SHPTRANS這個自由軟體專案， 就是注意到AFL授權條款有著與GPL相容爭議的問題，而最終決定放棄選用AFL為其程式釋出時的授權條款。曾經有一段期間、開放源碼促進會甚為推崇 AFL授權條款，但是截至2007年7月30日筆者登錄開放源碼促進會網站查找的結果，AFL授權條款的地位已然被其他更具普遍性的授權條款所取代，開放 源碼促進會在分類上已不再將其歸於「具普遍使用性或為重要的軟體社群所選用」一類即為明証。
3. For now, avoid the “Common Public License" 1.0 (CPL), though this may change. The CPL is not nearly as popular as the GPL, LGPL, BSD-new, or MIT/X11 licenses, but it has more uses than most other licenses. The CPL is even in the OSI’s list of “Licenses that are popular and widely used or with strong communities". Some other licenses, such as the Eclipse license, are based on the CPL. It is known that the CPL is incompatible with GPLv2, so for the moment it is probably best avoided. However, it is possible that the CPL is compatible with GPL version 3, which would make it much more palatible and similar to the Apache 2.0 license (which is incompatible with GPLv2 but compatible with GPLv3). At the moment, I’d wait until there’s been lengthy legal analysis to settle the matter.
3、從現在開始、請盡量避免使用CPL授權條款(Common Public License 1.0)來釋出您的程式，當然CPL嗣後還有可能改版，但截至目前為止請自行斟酌後再行採用。CPL授權條款的使用率雖然比不上GPL、LGPL、三款的 BSD，及MIT授權條款，但與其他授權條款相比其仍算得上非常具有影響力。在開放源碼促進會的標準裡，CPL授權條款被劃歸為「具普遍使用性或為重要的 軟體社群所選用」一類，此外還有部份的自由軟體授權條款是參照CPL的內容來編寫，如Eclipse授權條款，就是基於CPL所衍生的父子條款。但截至目 前為止、CPL1.0版本與GPL2.0版本的授權內容並不相容，是以如您有意得到與GPL授權程式相容所帶來的好處，當前對於CPL的授權選用上還是保 守些、少用為妙。當然、或許日後CPL的授權內容可以與新版本的GPL相容，例如Apache2.0就是一個最好的例子(Apache2.0與 GPL2.0不相容，但卻可與新版的GPL3.0相容)，不過目前為止筆者對CPL的建議是、與其等待冗長的法律授權爭辯塵埃底定，不如先行觀望避用以減 少麻煩。
4. Avoid the “Open Software License" (OSL). This is supposed to be a strongly protective license like the GPL. But it’s incompatible with the GPL, and almost no one uses this license, so any such code cannot use or be used by the vast majority of FLOSS projects. The FSF also believes that the distribution terms make normal development processes illegal, creating a severe practical problem. Again, at one time some people in the OSI recommended the OSL, but as of July 30, 2007 the OSI lists the OSL license as being in the category “Other/Miscellaneous licenses", and pointedly does not include it with “Licenses that are popular and widely used or with strong communities".
4、請盡量避免使用OSL授權條款(Open Software License)來釋出您的程式。雖然這是一個對於軟體自由理念相當有防護意識的自由軟體授權條款，然後、它並不能夠與GPL授權條款相容，並且從實而 言、目前並沒有多少專案採用OSL授權條款，那麼擺在眼前對OSL條款使用者的最嚴峻考驗就是，選用OSL授權條款的專案並無法摘採現行自由軟體世界已然 成熟的果實，亦即、您將無法取用其他多數人以GPL釋出的軟體程式碼，慣用GPL授權的其他程式設計師亦無法取用您依OSL所釋出的軟體程式碼。自由軟體基金會並認為OSL授權條款在散布條款方面頗有爭議，可能在實際應用上會帶來一些非預期的嚴重問題。同樣的、OSL授權條款散布之初，開放源碼促進會亦曾給予其頗高的評價，然而筆者截止於2007年7月30日所做的調查，顯示開放源碼已將其改列在不具重要性的「其他/混合類型」，已不再歸於「具普遍使用性或為重要的軟體社群所選用」這個類別。
5. Avoid using the “Creative Commons" licenses for software. The Creative Commons FAQ says, “Creative Commons licenses are not intended to apply to software. They should not be used for software… [they don’t distinguish, as needed,] between object and source code… We strongly encourage you to use one of the very good software licenses available today [instead]." Jay Tuley’s “5 reasons to not choose a CC license for code" explains more. The debian-legal Summary of Creative Commons 2.0 Licenses recommends that authors who wish to create works compatible with Debian’s “Debian Free Software Guidelines" should not use any of the licenses in the Creative Commons license suite; licenses with the “NonCommercial" or “NoDerivs" license elements are fundamentally incompatible with FLOSS, authors who use or are planning to use the Attribution 2.0 license should consider a similar Free Software license such as a BSD- or MIT-style license…, and Authors who use or are planning to use the Attribution-ShareAlike 2.0 license should consider a similar Free Software license such as the GNU General Public License [GPL]. The Creative Commons has “wrapped" the GPL and LGPL if you want to use the Creative Commons search engine.
5、請盡量避免使用「創用CC授權條款(Creative Commons)」來釋出您的程式。Creative Commons的常見問題列表裡明示：「創用CC授權條款並非供程式碼釋出時使用的公眾授權條款，您無法透過創用CC授權條款來釐清程式原始碼與目的碼的 分別與範疇，所以請不要輕率的將其套用在軟體程式上，較諸於創用CC授權條款、現存許多軟體類的公眾授權條款更適合套用在程式碼釋出的事務上， Creative Commons組織強烈建議您能直接就這些授權文件裡選用一項符合程式碼釋出需求的條款。 Jay Tuley所著「五個勸服您不要利用創用CC授權條款釋出程式碼的理由」一文將此事解釋的更為清楚。Debian vs. 創用CC授權條款2.0版本的相容報告書中， 彰明了某些創用CC授權條款的預設標章是與Debian的自由軟體運行架構有所悖逆的，舉例來說、創用CC授權條款裡「非商業性使用」及「禁止改作」兩項 標章，便徹底衝擊到自由軟體界的基礎運行法則，如強將這些創用CC授權條款的授權規定加諸以軟體程式碼上，則必然造成釋出專案於自由軟體界畸形難存。是以 有心以創用CC授權條款的諸般組合來釋出其軟體程式者，應改用理念相近的自由軟體授權條款，如創用CC授權條款裡的「姓名標示」此一授權態樣，可選用運作 方式近似的BSD或是MIT授權條款；而如果程式著作人想利用創用CC授權條款裡的「姓名標示-相同方式分享」此一授權組合，則可改用著佐權意涵相近的 GPL授權條款。此外、創用CC的搜尋引擎亦早已為GPL及LGPL授權條款創作獨立的授權標章，這表示：1、創用CC授權條款與GPL的授權態樣目前並 不相容，2、透過創用CC搜尋引擎亦可查找部份以GPL、LGPL授權釋出的軟體；3、Creative Commons組織並不建議他人利用創用CC授權條款來釋出其程式作品。
6. Avoid the “Mozilla Public License" (MPL). This was originally created by Mozilla, but its GPL-incompatibility caused so many problems that they re-licensed their work under a GPL/LGPL/MPL triple license. Don’t duplicate their mistake.
6、請盡量避免使用「MPL(Mozilla Public License)」來釋出您的程式。MPL授權條款乃是為了Mozilla專案「自由軟體化」所量身訂做、費心編撰，但其授權態樣與GPL授權條款並不完 全相容。因著與GPL授權程式難以相容的困境，Mozilla基金會嗣後只好改絃易轍將Mozilla軟體專案以GPL/LGPL/MPL的多重授權方式 「併行釋出」，那麼、您還要追隨他們的舊路重蹈覆轍嗎?
7. Avoid the “NASA Open Source Agreement" version 1.3. This is one of those rare cases where the OSI has accepted a license as being an open source software license (per the open source definition), but the FSF has determined that the license is not a Free Software license (per the Free Software definition). The problem is that it requires that changes be your “original creation”. FLOSS software development depends on combining code from third parties, so if that is interpreted literally, this agreement would prohibit practically all real work and would certainly be GPL-incompatible. It’s best to avoid this license.
7、請盡量避免使用「NASA開放源碼授權協定」1.3版的規定來釋出您的程式。「NASA開放源碼授權協定」可說是非常另類的公眾授權條款，因 開放源碼促進會將其列為開放原始碼授權條款的一員(依其十項開放原始碼軟體的定義檢驗)，但自由軟體基金會卻依另一角度拒絕承認其足以列入自由軟體授權條 款的範疇(依其自由軟體的四大自由定義檢驗)。引發爭議的最大徵結點在於，「NASA開放源碼授權協定」要求釋出程式的後續修改，須為修改者親力親為的 「原始創作添附行為」，是以在自由軟體界裡常見的程式碼相互抄寫自由，就在這層定義下被封鎖了，那麼如將此一修改標準進行嚴格的文義解釋，自然「NASA 開放源碼授權協定」會與GPL授權條款產生互斥，是以在現階段、最好是避免使用此類較富爭議性的授權條款。
Consider GPL incompatibility carefully-如您執意選用與GPL不具相容性的其他授權條款，還請在做出最後決定前三思再三思
There are reasons for an OSS/FS project to be GPL-incompatible, but weigh any such notions with an extremely critical eye. Sometimes a program or library was originally proprietary, and can only be released as OSS/FS under GPL-incompatible conditions. If so, the code had better be good and essentially complete when it’s released, because many developers won’t get involved with it. Many OSS/FS projects are already saddled with a GPL-incompatible license, and it’s just too hard to change. Some include other requirements they believe are critical, such as adding more patent clauses for licenses, defense, or mutual termination (such as the IBM public license).
當然、某些自由軟體專案執意採取與GPL兩不相容的授權條款，背後必然有其目的性的合理考量，但鑑於GPL授權程式的市佔率實在太高，多數自由軟 體程式編寫者對於GPL授權條款的偏好性實在太強，當您正處於為釋出程式選用合適授權條款的選擇階段，請務必將GPL的影響力加入考慮因素。有時候、程式 或函式庫本身本來就是以私有軟體的授權型態存在，那麼可能將其改為自由軟體授權態樣時，並無法一蹴可及的選用與GPL相容的授權條款，如果真是如此、那麼 此一以GPL不相容條款釋出的軟體程式碼，其於釋出時就必然得在素質及完整性上趨於完善，因為若非如此、就自由軟體世界的生態來看，其就無法吸引大多網路 社群共工編寫此一軟體的參與動機。另外、某些歷年已久的自由軟體專案，已以與GPL不相容的授權條款釋出已久，若冒冒然更動其授權態樣可能困阻重重。再 者、有時候程式釋出者選用與GPL不相容的授權條款，是看重此類條款設計上可能有的獨到之妙，例如專利授權條款、對釋出者的特別保護條款，或是契約嗣後終 止的雙方條款等設計(例如IBM公眾授權條款即為明例)。
But remember that these supposed benefits may not outweigh their many disadvantages. Note all the projects listed above that switched from a GPL-incompatible license to a GPL-compatible one. An example of the problems – in fact, one of the more important ones – is that the OpenSSL license is widely viewed as being GPL-incompatible (including by FSF lawyers, GNOME, and Debian, based on detailed independent analysis). While the OpenSSL developers claim it’s GPL-compatible and “support” the use of OpenSSL by GPL’ed software, the legal minefields are such that OpenSSL often has to worked around, or abandoned by switching to a different program (as CUPS did). The usual alternatives for OpenSSL are Mozilla Network Security Services (NSS) and GNU Transport Layer Security (GNU TLS).
但是請注意一件事、上述這些授權條款的獨到之妙與GPL相容性所帶來的 好處相比，很可能結果是不利大於有利的。您可以回到此篇文章的前頭，將部份軟體專案的授權態樣轉移案例重新閱讀一次，若非這些著名專案的GPL不相容性已 為其永續發展帶來困擾，那又何必大費周章轉移其授權態樣來向GPL相容的世界靠攏?而若是要針對GPL不相容性所帶來的不利之處討論，OpenSSL這個 專案即為顯著明例，OpenSSL所使用的OpenSSL授權條款向來被視為與GPL條款不相容(持此觀點者包括自由軟體基金會的律師群們、GNOME計 畫，及Debian等網路社群)，然而OpenSSL專案的開發者卻聲稱其與GPL程式得以相容，並且認為OpenSSL程式能與其他GPL授權釋出的軟 體程式碼結合運用，是以這樣的聲明造成某程度的法律授權地雷，當程式開發者終於了解到OpenSSL程式與GPL程式的不相容性時，其只好想辦法將整個程 式中有關OpenSSL的部份代換掉(CUPS這個專案就這樣做了)。一般來說、程式開發者可以選擇用Mozilla 的網路安全服務程式(NSS)，或是GNU計畫下的傳輸層安全性程式(GNU TLS) 來取代OpenSSL涉及的部份。由此例可知、若一個自由軟體專案堅守其與GPL授權程式不相容的立場，但其又未能掌握宰制市場多數佔有率的力量時，其永 續營運上的最大的風險就是為GPL授權的支持者所避用，或甚至、被其後編寫的後起之秀給取代掉，畢竟在自由軟體的世界裡，發生授權相容困境而重起爐灶重新 編寫的案子可說是多如牛毛、不乏其例。
License proliferation considered harmful-不要再自行創造獨門的自由軟體授權條款，過多的授權條款提高了選擇的門檻並造成自由軟體程式碼互相取用困難
Indeed, the proliferation of OSS/FS licenses in general has been identified by many as a problem to be resolved. It was an issue noted in Fink’s LinuxWorld 2005 address, and others supported this view such as Groklaw. This is not a new observation; Bruce Perens noted back in 1999, “Do not write a new license if it is possible to use one of the ones listed here. The propagation of many different and incompatible licenses works to the detriment of Open Source software because fragments of one program cannot be used in another program with an incompatible license.” Eric S. Raymond’s Software Release Practice HOWTO strongly states (as a heading!) “don’t write your own license if you can possibly avoid it,” and he suggests that developers use “one of the standard licenses carried on the OSI site if at all possible.” The Open Source Initiative’s License Proliferation Committee Report recommended addressing this by categorizing licenses; unsurprisingly the category “Licenses that are popular and widely used or with strong communities" included the MIT/X, BSD-new, LGPL, and GPL licenses. If you doubt that license proliferation can be a problem, just look at Fedora’s Licensing Guidelines and Fedora’s Licensing page – they are setting up complex licensing documentation that can be electronically recorded and analyzed, just to assure license compliance.
說真的、「自由軟體授權 條款過多且讓使用者難以簡便選擇」一直以來就是個極需被解決的大問題，HP的副總裁Martin Fink於2005年即將此視為「問題」來加以描述，並且許多引領自由軟體發展的先行者也持這樣的觀點，如著名的Groklaw網站上的評論觀點亦同。其 實這樣的問題並非近年才被觀察到的新聞，Bruce Perens早在1999年就清楚的發表其個人觀點：「請盡量選用現存的自由軟體授權條款，不要隨意創生更多新式授權條款造成程式碼之間分享的困難，過多 的授權條款其實對於自由軟體的未來發展是一種阻礙，擺在面前最大的問題就是、如果這些授權條款互不相容，那麼程式碼與程式碼之間是難以被互相取用的。」 Eric S. Raymond這位鼓吹以開放原始碼做為新式程式編寫手段的先行者，其於「如何開發及散布開放原始碼軟體簡易守則」一文中強烈建議(直接明示於標題裡)開 發者：「若非沒有別的選擇，請不要撰寫自己的自由軟體授權條款」，並於文中勸誘程式開發者：「優先選用開放源碼促進會認可並由某一團體常態營運維持的授權 條款」。而開放源碼促進會對此事的回應，便是透過深化授權條款分類項目的描述來處理；意料之中的、「具普遍使用性或為重要的軟體社群所選用」這個類別裡便 涵括有MIT、三款BSD、LGPL與GPL這些具有GPL相容性的授權條款，由此亦可見GPL相容重要性之一般。如果到了這時候您對於創建新式授權條款 對於程式衍生的麻煩性還存有懷疑，煩請參閱Fedora Linux的授權指引書及Fedora Linux的授權聲明網頁即可窺其一二-簡單來說、這兩份授權聲明列示了Fedora Linux裡複雜的各式授權內容，以便這些資料能夠被電子化的記錄及分析，如此方可確認整個大專案維持其授權相容上的妥適性，可見自由軟體授權相容的處理 非為小道，其可能耗費掉專案營運者諾大的時間成本與心力，而就自由軟體專案的長遠發展而言，這是一個必須朝簡化方向努力處理的議題。
Other things to consider-其它您需要細加思量了解的兩三事
While it’s possible to relicense OSS/FS software to make it GPL-compatible, it can be quite difficult — you’re much better off avoiding a mistake, and starting off GPL-compatible in the first place. Changing licenses usually requires approval of the relicensing from every copyright holder and a rewrite of the code where the approval wasn’t granted. When OSS/FS projects get large this is incredibly difficult, because after many years it’s often impossible to contact all of the contributors. Thankfully, many projects don’t have to endure this transformation, because they’ve avoided it to start with. The W3C, for example, explicitly states that all its software releases are OSS/FS and are compatible with the GPL. This statement shows that they believe GPL compatibility is very important, and this policy eliminates the problems that would come from GPL incompatibility.
雖然就法理上來說、程式釋出後方才發現 授權條款不合用，嗣後還是有以其他條款重行授權的可能性，但這是就理論面思考，在現實世界裡，自由軟體釋出後欲更換授權條款可說是困難重重，其具體實踐的 困難度非常之高。所以最聰明的方法是程式初始釋出時就不可選擇失誤，至少一開始就該把GPL授權相容性這一點詳加考慮好。之所以說自由軟體重行授權困難重 重，那是因為重行授權時需要得到所有相關著作權人的明示同意，這包括了程式散布後對程式碼有所添附的貢獻者。那麼一個自由軟體專案如已散布許久，自然其貢 獻者繁多且部份識別資料已殊不可考，是以在意思連繫上費時費力而造成重行授權非常困難。但幸運的是、許多自由軟體專案的營運者已知悉了此類問題，而在專案 釋出初始即已洞燭機先，預留了專案未來發展上與GPL授權相容的可能性。舉W3C(World Wide Web Consortium)為例、其即以網頁聲明表示所有W3C散布的軟體皆為自由軟體，其並可與GPL授權的程式完整相容。此段聲明足資表彰W3C認可軟體 程式具有GPL授權相容的特性是非常重要的一件事，透過此類聲明其更足以消弭掉許多GPL授權不相容的懷疑所可能拖累專案營運的諸如弊病。
It’s worth noting that the GPL has a very strong legal basis, which is attractive to many people. The GPL is easy to comply with (it doesn’t even require money to do so), but people do take its requirements seriously. Eben Moglen is a lawyer who’s been enforcing the GPL for years, and has excellent evidence that the GPL really is enforceable. He also explain’s the GPL’s legal basis, which turns out to be very strong. Paralegal Pamela Jones has written another explanation of the GPL’s legal basis for laymen; as both note, the GPL is a license, not a contract, which makes it unusually easy to enforce. “Taking the Case: Is the GPL Enforceable?" by Jason B. Wacha (General Counsel, MontaVista Software) is a detailed legal analysis by a lawyer showing that “the GPL is an enforceable agreement." A German court has found that the GPL is legally enforceable, for the very reasons Moglen and Jones stated. This was in response to some enforcement actions by netfilter. In 2006, a U.S. court found that the GPL was quite legitimate; Daniel Wallace tried to invalidate the GPL in Daniel Wallace vs. Free Software Foundation, and not only was Wallace’s suit dismissed, but Wallace was ordered to pay costs as well. In this case, the judge (John Daniel Tinder, United States District Court) also declared that “[T]he GPL encourages, rather than discourages, free competition and the distribution of computer operating systems, the benefits of which directly pass to consumers. These benefits include lower prices, better access and more innovation." This was appealed, and the U.S. Court of Appeals (7th circuit) formally ruled in 2006 that the GPL does not violate U.S. antitrust rules, and that “the GPL and open-source software have nothing to fear from the antitrust laws" – creating an even stronger defense against future cases. The proven legal strength of the GPL is attractive to many people who must choose a license for their open source software. But this strength comes from taking its requirements seriously – which means that people must take incompatibility seriously too.
此外值得額外一提的是，GPL授權條款亦具有相當強的法律論理基礎，這項特性對於 許多選用GPL的程式著作權人至為重要。將自己的程式採用GPL授權釋出至為簡易(基本上聲明採用GPL及附上授權條款全文隨程式釋出即可，您甚至可能不 需花費任何金錢就可以做好這件事)，但當別人依GPL授權條款收受這個程式檔案時，其必須嚴格遵守GPL授權條款預先劃下的遊戲規則，亦即得精準的實踐 GPL授權條款要求的諸般義務性要求。Eben Moglen是一個經年累月鼓吹闡釋GPL授權條款可執行性的律師(軟體自由法律中心的首屆執行長)，透過其撰文舉証、讓我們了解到GPL授權條款確為具 有強制執行效力的合法軟體授權條款，其亦透過法律論理的述事方式，讓一般人了解到GPL此類公眾授權條款，對於程式收受者的具體拘束力權源何在。從事法務 工作的Pamela Jones亦以通俗用語撰文，向一般人簡易淺顯的解釋GPL授權條款的法律論理基礎，但其上二位法律專門人員、其見解皆認GPL為「授權條款」，而非一開 始即為要約承諾雙方議定合致具有強質拘束效力的「授權契約」，那麼就此觀點來看、GPL授權條款的執行力會不會有所削弱呢? Jason B. Wacha(MontaVista軟體公司的一般諮詢員)曾就這個議題撰寫「GPL授權條款之執行拘束力-從案例事實的觀點分析之」一文討論之，其結論就 是依法律論理的觀點，GPL授權條款本質上仍是具有強制執行效力的合法協定。此外、德國慕尼黑地方法院的司法處分亦足資表彰GPL授權條款確有法律上的可 執行性，其據以發給假執行處份的論理理由同於上述Eben Moglen及Pamela Jones所曾發表的法律觀點，這個案子主要是由Netfilter的著作權人透過司法手段維護其GPL授權完整性所發起的舉措。而在美國、2006年亦 有司法判決一定程度表彰了GPL授權條款的合法性地位；Daniel Wallace試圖透過司法訴訟來舉証GPL授權條款違反美國的反托拉斯法案而「無效」，其間的法庭辯論歷程可查找Daniel Wallace vs. Free Software Foundation這個司法判決的內容，而判決的的最後結果、Daniel Wallace敗訴，其訴求不為承審的美國地方法院所肯認，法官並且裁定Daniel Wallace須負擔訴訟過程所產生的所有訴訟費用。在此一司法判決裡，承審法官(John Daniel Tinder)甚至於判決理由中揭示：「GPL授權條款並未限制自由市場的開放競爭，相反的、其甚至推動電腦程式作業系統進行更公開化、更有效率的公開競 爭，而其所帶來的益處可說直接歸於廣土眾民的一般消費者，這些益處包括降低軟體程式取得成本、降低公眾對於軟體程式的取得門檻，甚至於軟體開發上激發更多 的創意產出。」而後Daniel Wallace不服上訴、美國聯邦第7巡迴上訴法院(座落於伊利諾州、芝加哥市)於2006年做出正式判決，上訴法院認為GPL及其相類的自由軟體授權條 款並非美國托拉斯相關法案所涵攝的排拒對象，是以GPL授權條款並未因違反美國反托拉斯法案而無效-此一判決較之前例更具判決先例性，自此在美國GPL授 權條款的形式有效性已然毋庸置疑。透過這些司法判決為GPL授權條款有效性的背書，自然對於部份的自由軟體程式編寫者而言，GPL授權條款變得很有吸引 力。但須要事前述明的是、雖然選用GPL授權條款的方式非常簡便，但GPL授權條款為使用者帶來權利時，其同時要求使用者亦須服膺於授權條款預設的義務性 要求之下，舉例來說前已提及的「授權攫取性」即為最具特色的義務性要求之一，是以取用GPL授權程式碼者、必然要體認到取用者權利義務關係之間的對稱性， 意即、解決本身程式的授權態樣與GPL授權態樣的不相容之處，否則便可能造成GPL授權條款的違犯而被控侵權。
Making your OSS/FS software GPL-compatible-三種簡便確認軟體專案具有GPL相容性的方法
So, how do you make sure that your software is GPL-compatible? Fortunately, there are three easy ways to do this:
所以、簡單來說，您應該如何確認您所欲釋出的自由軟體是與GPL授權相容的呢?以下介紹三種簡易的檢測方法供您利用：
1. One way, of course, is to use the GPL.
1、第一種最直接的方法，很簡單、直接採用GPL授權條款來釋出您的軟體程式。
2. Another is to use a different license that is known to be GPL-compatible, in particular the LGPL, MIT/X, or BSD-new (modified BSD) licenses. Obviously there are several licenses you can choose while remaining GPL-compatible. The FSF maintains a list of licenses it has determined to be GPL-compatible. Don’t use the old/original BSD license, which is generally accepted as being GPL-incompatible and has many practical problems; even Berkeley has switched to the new BSD license for their software. You might also consider using the Apache 2.0, but note that while it is compatible with GPL version 3, the developers of the GPL are confident that it is not compatible with GPL version 2.
2、第二種方法、就是選用著名且已被廣為認証具有GPL相容性的授權條款，像是LGPL、MIT/X、或是BSD-new (三款的BSD)等即符合上述條件。顯而易見的、在自由軟體的世界裡這類的授權條款並不乏其例，您能夠選擇使用這些授權條款，同時為釋出的軟體預先保有嗣 後與GPL授權程式相容的可能性。自由軟體基金會本身也提供了一個清楚的列表，其上明示哪些授權條款是能夠與GPL相容的，但是請記得不要採用舊版的 BSD授權條款，因它已然被評議為與GPL殆不相容，並且程式散布後亦會產生許多難以處理的衍生問題；畢竟連BSD授權條款的創始者加州大學柏克萊分校， 都已經將其下眾多軟體轉而改用新版的BSD授權條款(三款BSD)，此即為一具有指標意義的重要案例。另一個需特別注意的是Apache2.0授權條款， 請記得此一授權條款雖與最新版本的GPL3.0相容，但其與現佔自由軟體授權比例第一高的GPL2.0仍不相容。
If you’re considering the BSD-new license, Bruce Perens, the FSF, and I recommend using the MIT/X license instead (the FSF calls this the X11 license). There are several reasons to prefer the MIT/X license over BSD-new. First, MIT/X is much simpler, a good thing in a license. Second, a few non-lawyers have claimed that BSD-new isn’t GPL-compatible; I don’t think this is a real issue, but is instead a misunderstanding of the law, since expert lawyers on the topic from both Red Hat and the Free Software Foundation have refuted this claim. Finally, there isn’t the confusion of having two different common licenses with the same name.
倘 若您有意選用新版的BSD授權條款(三款的BSD)，那麼Bruce Perens、自由軟體基金會、以及敝人我，都傾向建議您直接選用MIT授權條款就行了(自由軟體基金會稱其為X11授權條款)。當然、這關涉到幾個簡單 的理由，第一點、MIT授權條款比起新版BSD的條款內容更為簡潔，符合當代「極簡即優」的撰文哲學；第二點、若干的網路社群朋友曾經公開發表過新版 BSD授權條款與GPL並不相容的看法，雖說這類的言論可能是基於誤解而產生的機率較大，Red Hat公司及自由軟體基金會旗下的專業法律從事人員亦都曾公開駁斥過這類的說法，但無論如何這是一個爭議點所在，畢竟、新版的BSD及舊版本BSD的條款 稱謂一概都還是BSD，某個程度上這就是一個在揀選授權條款時，容易讓人混淆出錯的紛爭問題，但如果自始即挑選MIT授權條款來取代新版的BSD條款(二 個授權條款的實質內容解釋起來幾無二致)，就不至於會有上述混淆或是誤解的問題產生。
You can use another pre-existing license known to be GPL-compatible, though using an unusual license risks causing developers to not support your project (some developers won’t want the risk and trouble of working under an unfamiliar and unusual license). My FLOSS License Slide shows how several common licenses are compatible (or not).
當然、您亦可以選用任何一款現存並經過評鑑 為具有GPL相容性的自由軟體授權條款，但須注意的是、選用過於冷門的授權條款可能導致他人參與此一專案的興趣降低(部份的自由軟體程式開發者並不想耗費 時間去了解他所不熟悉的授權條款、便會有避免參加此類專案的傾向)。更多資訊請參閱拙著自由軟體授權相容類表一文，其中表列有幾種使用率較高授權條款的相 容狀態(或是不相容的狀態)。
3. A third alternative is to dual license (or even triple license) the program. That is, release it under more than one license simultaneously, one of which is GPL-compatible (such as the GPL or LGPL), and let the user pick which license they’ll use. Widely-used projects such as Perl, Mozilla, and Qt do this. (the Mozilla project even uses a triple license (MPL/GPL/LGPL)). The Debian Free Software Guidelines (DFSG) FAQ notes that “The GPL is particularly common in dual licenses because it allows the code to link with the large body of GPLed code available including many important libraries, and to be incorporated into other GPLed works… This is almost always due to a project starting with a home-brewed GPL-incompatible license, then realizing they’d made a mistake and finding relicensing in this fashion to be the most convenient resolution." One problem with dual licensing is that you can only incorporate code from elsewhere that is compatible with all of the licenses. Thus, dual licensing can make it impossible to legally use some potentially useful code for as long as you maintain the multiple licenses. It’s one of the more reasonable ways to fix a mistake, but it’s better to avoid mistakes in the first place… especially when there’s clear evidence that using a GPL-incompatible license is a mistake for OSS/FS projects.
3、第三種方法可說較為迂迴，那就是運用「雙重授權模式 (或甚至三重授權模式)」來處理程式與GPL授權相容的問題。所謂的「雙重授權模式」、就是將軟體程式以多於一種的授權態樣向外同時散布，而由程式的被散 布人任擇一款其欲使用的授權條款，而若此時授權條款的選項之一包涵與GPL授權相容的授權條款(比如說GPL授權條款本身或是LGPL等條款)，就能夠一 定程度的解決軟體專案的GPL相容性問題。許多極之著名的自由軟體專案都採用此種雙重授權模式，如Perl、Mozilla、以及Trolltech公司 的Qt都是(Mozilla此一軟體專案甚至採用三重授權模式，將程式以MPL、GPL，以及LGPL同時併行釋出)。在Debian自由軟體指導方針常 問詢答裡提到「GPL授權條款、最常被取用為運行雙重授權模式的基礎，因為如此一來軟體專案便可透過此一GPL授權的選項，來與自由軟體世界裡眾多的 GPL授權程式進行相融結合，並亦可藉此取用這些GPL授權程式碼的成果…而現階段採用雙重授權模式的著名專案，可說多肇因於程式初始釋出所選用的授權條 款與GPL並不相容，故幾經思量後方才選用此種雙重授權的模式，來與自由軟體界裡的其他眾多GPL授權程式碼『謀合』。」然而、利用雙重授權模式來處理 GPL授權相容性的問題，仍然會有其不盡完善之處，舉例來說、自由軟體界以GPL授權挹注至軟體專案的成果，未必皆能夠被雙重授權裡另一授權模式的程式所 用(因為貢獻者是以GPL授權釋出其添附成果，並非必然將此成果授權予營運專案的公司)，從這個觀點來看、雙重授權模式確實可以修正一些專案程式與GPL 授權不相容的格格不入之處，但若專案程式欲完全擁抱與GPL相容的優勢，避免專案程式在自由軟體界成為封閉孤島，那就須在程式釋出之初即做好良好規劃，也 就是程式一開始釋出時就要將GPL相容的設計考量進去。
If you can’t use any of these easier approaches, then it’s still possible to use a GPL-compatible license, but at that point you need a lawyer’s help – and in general I do not recommend it. That’s because license analysis can quickly become very complicated. For example, the FSF developed the GPL and maintains a list of licenses that it believes to be compatible and not compatible with the GPL. Note the number of subtle points brought out in their analysis! My point isn’t to debate their legal analysis (which not everyone agrees with); I just want to show that determining GPL compatibility can be complicated, so there are excellent reasons to keep things simple. Some advice is available from the FSF, but since they may not be the owners of the software, there may be more room for disagreement than you might think. And in addition, when revisions of the GPL are released, new problems are likely to arise. It is likely to be much more difficult to upgrade licenses if you have an odd one-off license. In short, the best way to make a program GPL-compatible is to keep things simple.
如果以上敘述的三種簡易方法您都不能採用，倒也不是說您的軟體專案就必然無望與GPL授權取得相容性了， 但此時法律授權態樣的調配會相形變得複雜許多，您甚至需要諮詢專業的法律服務才能夠釐清相容性爭議的各個細項，是以筆者的建議是盡量不要把事情弄得那麼複 雜化，如果有簡便的方法和策略能夠選取，那麼最好就是用簡便的方法來處理事情。授權條款的最大爭議來源在於眾人對於授權條款的解讀或有落差，舉例來說、自 由軟體基金會的網頁上提供了一份與GPL授權相容的授權條款列表，如您細加詳讀可以看到其上許多立場及主張皆是有所爭議，未必能驟下定論的!筆者此言並非 質疑自由軟體基金會此份列表論理的精準性(但其實許多人對其論理持不同見解)，舉此例是為了說明自由軟體授權條款相容性的調配是非常複雜且難以處理的，所 以在GPL授權相容性的追求上，筆者還是呼籲秉持「極簡即優」的處世原則來處理這類的問題。對於提升軟體專案的GPL相容性、撰寫GPL授權條款的自由軟 體基金會提供了相當多的建議，但是自由軟體基金會畢竟只是授權條款的撰文者，其並非所有以GPL授權釋出程式的著作權人，如果著作權人對於條款本身或是相 容性的見解有所不同，那麼現實世界裡自由軟體程式的相容爭議就會更形複雜；再者、日後GPL若是更行改版時，必然又會衍生新的GPL授權相容爭議，是以在 這種狀況下、如您將自己的軟體專案以冷門、或是獨自編寫的授權條款予以釋出，就算此一條款在法律論理的解讀下是與GPL授權型態具有相容性的，在軟體專案 的營運上您可能仍然得不到來自GPL軟體社群的奧援，並且己身的授權條款亦得一再改版來適應GPL授權條款的未來改版，不是非常的複雜與滯礙難行嗎?所以 筆者才會一直呼籲「極簡即優」的處世邏輯，若要讓您所釋出的專案程式能夠妥善的與GPL授權程式間具有相容性，最好還是採取上述三種簡易方案來處理。
If you’re submitting changes to an existing OSS/FS project that uses a GPL-incompatible license, include a note in your submission that you’re dual-licensing your changes with a GPL-compatible license (such as the GPL, LGPL, or MIT/X license); that will make it much easier for the project to dual-license the entire program later.
附帶一提、可能您已然釋出的軟體專案是選 用與GPL授權型態不相容的授權條款，若是冒冒然地將其改用其他GPL相容的授權條款重行釋出困阻重重的話，建議可以將此專案其後的個別更新成果，漸次性 的改用與GPL相容的「雙重授權策略」釋出，雖然這些更新成果屬於個別性的釋出，但因其個別的GPL相容性，或可勸誘感興趣的GPL社群參與更新檔案的修 改、增補及共工，如此將來整個軟體專案進行授權轉換時(轉為使用GPL相容的授權條款)，則在專案背後已然形成一定人數的GPL社群予其支持，可大幅降低 軟體專案未來授權轉換向GPL授權相容靠攏的困難程度。
If you release software under the GPL (solely or as a dual-license), you should include the “version X or later" clause as recommended in the GPL itself and used by nearly all GPL users. Using the “version X or later" phrase makes transition to updated GPL text really easy, and guarantees future compatibility as the GPL gets updated and clarified as new situations arise. Other text in the GPL limits what those later versions will say, and new versions of the GPL cannot decrease what you can do with the original work. Most proprietary licenses of today have clauses anticipating changes in terms as years go by – adding “or later" is just a different way to do it. A few companies just cannot bring themselves to say ‘version 2 or later’ though; in such cases, they should designate a proxy who will be authorized to release the code under a later version of the license as those new versions become available, and establish a process to examine the later versions and give permission once review determines it’s okay. But I believe the “version X or later" approach is really the better approach if you choose to use the GPL; the whole point of the GPL is to ensure that you can gain access to later improvements to a program, and GPL revisions are created specifically to protect against attacks on that access.
再者、就筆者個人的角度建言，若是您採用GPL授權條款釋出您的軟體專案時(純以GPL授權釋 出、或是以GPL及其他授權條款搭配成雙重授權模式釋出)，煩請明列允許「被授權人得逕依更新版本的GPL授權條款將程式更行釋出」的選項，亦即若日後 GPL授權條款經過自由軟體基金會的更新改版後，此一軟體程式的收受者不須特別知會原始著作權人，便得將程式適用更新版本的GPL授權條款後予以釋出。此 一「更新版本釋出選擇權向後授權」的選項，能夠讓軟體專案於釋出後還能夠簡易的完成其授權狀態的更新，以便確保此一軟體專案能夠自行更新，以便與更新版本 的GPL授權程式碼完美相容(部份新的軟體程式可能在散布時逕以最新版本的GPL釋出，如舊版GPL時期的軟體專案能透過散布者之手更新到最新版的GPL 授權態樣，則可與這些較新編寫的GPL程式碼完整相容)。須要這樣處理的原因在於，舊版的GPL條款與新版的GPL條款在授權上並不相容，此指其在法律授 權關係的態樣上不能併存的狀態(此乃因GPL授權條款不論舊版或更新版，必然內含強烈的「授權攫取性(License Capture)」，意即當使用者截取一段受GPL拘束的軟體程式碼，並將其用於其他軟體程式的專案進行結合後，這整個大型的軟體專案日後即受GPL授權 條款所拘束，此後僅能以GPL授權條款為釋出散布時的唯一授權條款。此類「著佐權(Copyleft)」式的向後拘束性，不論在GPL授權條款的舊版或更 新版，都必然是其非常堅持的重要特性之一)，是以若GPL授權條款舊版及更新版本軟體的程式碼進行實際結合時， 舊版軟體的立場它會去拘束更新版軟體改用舊版的規定，而更新版軟體的立場也會拘束舊版軟體改用更新版的規定，此時就產生一個授權選擇妥適性的衝突，而此處 提及的「更新版本釋出選擇權向後授權」的選項，就能夠輕易的調解程式日後面對GPL條款改版後，可能遭遇的新舊版本相容性衝突問題。此種「向後指定」的條 款撰寫技巧，其實在一些私有專屬軟體的授權條款裡亦是不乏其例，但如您是透過營運自由軟體專案以牟求利益的商業化公司，則建議在程式最初釋出時採用「更新 版本釋出選擇權指定代理」的選項，此一選項代表當有新版的GPL授權條款產生時，此時以舊版GPL釋出的軟體專案是否跟進改版，取決於程式原始著作權人預 先指定之代理人，此一代理人(此例中多是原始釋出軟體專案的商業公司)可在審慎評估過新舊版GPL授權條款的異同及可以產生的影響後，再行決定是否將軟體 專案跟進改用最新版本的GPL授權條款更行釋出。以筆者的個人意見來說、「更新版本釋出選擇權向後授權」的選項具有最為簡便易用的優點，畢竟當您選用了 GPL授權條款時，某個程度上您即認同了其欲追求解放當代「軟體自由」的理念，簡單來說、就是任何程式依GPL授權條款為人釋出後，此一程式嗣後經過修 改、改良的成果總是會依其授權循環裨益到所有收受程式之人，亦即將研究、改良、重製、再散布程式等四大自由不斷的傳散下去，而GPL授權條款的版本更新即 是為了維護這個基本理念，其欲對照未來發生的科技及法律爭議，來對授權條款的內文進行微調以讓其與時俱進、因應時勢，永遠的保障依GPL授權條款散布程式 者能將此四大自由傳遞於收受程式的後手，若是您完全認同這樣的理念、則不妨在釋出軟體專案之始即將此「更新版本釋出選擇權的權力向後授權」，讓您釋出的程 式在未來能夠在最短時間內即可因應GPL授權條款的更新改版。
Which version of the GPL should be your base? For many years, GPL version 2 was the only real choice, but in 2007 GPL version 3 was released. GPL version 3 has a number of improvements if your goal is to ensure that recipients can modify their software; for example, it eases international enforcement (by changing U.S.-centric terms to broader terms), adds better patent defenses, is compatible with more licenses (in particular the Apache Public License and the Affero GPL), and counters “Tivoization" (users must be able to modify GPL’ed software they receive). More detailed commentary on GPLv3 is available, including those by Glyn Moody, Mark Radcliffe, and Luis Villa. Palamida is tracking which projects are updating to GPL version 3, a process which seems to be going well. “GPL version 2 or later" gives maximum compatibility, but since nearly all projects have the “or later" clause, it isn’t really much more compatible than “GPL version 3 or later" for most people. I expect that there will be a gradual migration of many projects from “GPL version 2 or later" to “GPL version 3 or later". So for most projects, “GPL version 3 or later" is probably the best choice, since it lets you take advantage of the GPL version 3 improvements.
那麼到底哪一個GPL授權條款的版本應該被視為您釋出專案程式時評鑑考量的基準呢?過去數年間、 GPL2.0版是唯一的選擇，但在2007年末GPL3.0釋出後已改變了這個陳習舊事。GPL3.0的版本相對於2.0，其針對現階段的自由軟體授權爭 議提出了更多合理性的調配及解釋，而其表現出來的理念同於2.0的版本，基本上就是要維護程式收受者能夠對程式進行「研究、改良、重製、再散布」等等深化 利用的四大自由；GPL3.0與2.0版本的實際不同處，舉例來說、其用語更多的通俗淺顯以利於國際化運用，新增了若干保護自由軟體運作不受軟體專利制度 干擾影響的防衛機制，並且也大大的增進了其與其它著名自由軟體授權條款之間的相容性(例如與Apache授權條款及Affero GPL授權條款之間的相容配置即為著例)，此外、特別設有反制軟體程式「TIVO化」的規定(TIVO是一種將電視節目預錄至儲存媒體，嗣後方便使用者隨 時觀看這些節目的數位化裝置。此種機器常內嵌有以GPL授權的軟體程式，其雖然並不明文禁止此內嵌的GPL程式被使用者修改，但這些程式一經修改後，便再 也無法重新植回機器正常運作，意即機器內嵌的軟體一經修改，則硬體自動拒絕修改後的軟體程式運作造成死機，這就是所謂的「TIVO化」流程)，部份的 GNU計畫推行者認為此是對於GPL程式極不合理的運用方式，這類TIVO裝置的產品製造商從自由軟體的使用上得到了自由修改內嵌程式的好處，但卻不願意 將這樣的自由及好處提供給花錢購置產品的消費者，是以透過GPL3版的更新明文禁止它。現行對於GPL3.0的各式評論及解釋風潮正方興未艾，包括 Glyn Moody、Mark Radcliffe，以及Luis Villa這此研究自由軟體授權議題的名家都曾經撰寫專文針對條款更新的內容加以釐清及評論。而關於哪些軟體程式正由GPL2.0的版本轉向3.0靠攏， Palamida這個網站正持續進行追蹤及統計分析，簡單的就結論來看、其轉換的數量及速度呈現向上發展的趨勢，是以就這點來看、當前採用GPL授權的軟 體雖多仍以「GPL2.0及其後版本」的條件散布釋出，但因其容許散布者依「GPL其後版本」來將軟體程式更行釋出，是以現階段散布GPL程式者將其更改 指定「GPL3.0及其後版本」的條件釋出程式似亦無甚不妥。就筆者個人的立場而言、吾喜見更多的GPL程式改以「GPL3.0及其後版本」為程式釋出時 的參照基礎，因從實而言、GPL3.0釐清了許多GPL2.0時期懸而難解的爭議問題，其在適用性及相容性上適合現今多數的GPL軟體專案，若新釋出的 GPL軟體能夠直接指定適用GPL3.0，則便可馬上享有其針對現況更新調配後的好處。
In short, make sure that your OSS/FS software is GPL-compatible, or your OSS/FS project may never have the support you wanted.
簡 單來說、務必讓您所欲釋出的軟體專案具有GPL授權相容性，否則您的軟體專案可能永遠得不到其他自由軟體程式編寫者的奧援，無法享用自由軟體界裡已然累聚 眾多的GPL授權程式碼成果，他人亦無法取用您的軟體專案來與其他重要的GPL授權程式相結合，這樣的營運發展可以說是與自由軟體開放共享、多人共工的理 想有違，最後軟體專案還可以淪為孤島軟體而無法被永續營運開發。
________________________________________
Appendix A: The Cautionary Tale of XFree86
If you’re looking for a cautionary tale of how things can go badly because of a GPL-incompatible license, you need look no further than the tragic story of XFree86’s demise. The XFree86 project historically led development of a popular X server, and traditionally the vast majority of its code used the simple “MIT/X” open source license that is GPL-compatible. At one time, if you used a Unix-like system and a graphical user interface, you were very likely to be using XFree86… that’s how widespread it was.
The XFree86 president, David Dawes, decided to change the XFree86 license to one that wasn’t GPL-compatible, primarily to give developers more credit. This proposed license change caused a serious uproar. Jim Gettys, a well-respected developer and co-founder of X, strongly opposed this change to the XFree86 license, even though he’s not a strong advocate of the GPL. Richard Stallman asked that something be worked out. An article at Linux Today and a discussion at Freedesktop.org showed that Red Hat, Debian, SuSE, Gentoo, Mandrake, and OpenBSD planned to drop XFree86 if they switched to this new license.
Not all parties objected because of GPL incompatibility; OpenBSD’s Theo de Raadt’s objection was that the new license made the code “less free”, rather than specifically about GPL compatibility. But many others specifically protested this proposed change on the grounds that a GPL-incompatible license is unacceptable. Branden Robinson performed a detailed XFree86 license analysis (available from the mailing lists of XFree86 and The Open Group; a shorter version was posted by Debian). In this detailed analysis, he pleaded that XFree86 repair the few licensing problems currently in the code base and keep the program GPL-compatible, saying, “The path to clearing away GPL-incompatibilities due to the BSD advertising clause for the entire XFree86 source tree (as of XFree86 4.3.0, anyway) seems fairly short. Given that, it seems a shame to entrench a similar incompatibility both broadly and deeply.” The XFree86 mailing list from February 2004 includes many statements from individuals stating that GPL compatibility is important to them.
Since the XFree86 folks wouldn’t switch to a GPL-compatible license, the X.Org Foundation (formed January 2004) announced its own version of X on April 6, 2004. One of its key enhancements was that “only files without the new XFree86 1.1 license are included in the X11R6.7.0 release.” The X.org foundation home made it even clearer that GPL compatibility was the key problem; it says that “The X.Org repository is based on XFree86 4.4 RC2. Just before its 4.4 release, XFree86 adopted a new license possibly incompatible with the GPL. For this reason, we have recreated its tree as closely as possible without importing files affected by the new license.”
Unlike most forks, which get no or lukewarm support, the X.Org foundation fork was immediately endorsed by many key organizations, including Novell’s SUSE, Red Hat, HP, TrollTech, and FSF Europe among others. FreeBSD later left XFree86, and as noted above, the leader of OpenBSD had already stated that he did not support XFree86’s approach. By July 2004, Linux Weekly News (LWN) could honestly report that nearly all XFree86 developers had switched over to the new GPL-compatible fork, leaving XFree86 mostly dead. The primary discussion topic in the new fork’s mailing list was what new features and design improvements should be made first, with the presumption that whatever XFree86 did was irrelevant. The transition was swift, and can be shown by examining the “XFree86 forum” mailing list; the June 2003 archive of this list had 20 messages about XFree86 (plus 13 irrelevant spam), and all 20 were technical discussions related to improving the program. By June 2004 there were only 13 relevant postings in the whole month (plus 62 spam messages), and instead of being all technical discussions, many of those messages were acknowledgements between list members that XFree86 had been abandoned by most of its developers and users or were a discussion about how FreeBSD might possibly stay with XFree86 (FreeBSD later left XFree86, quashing this hope). For example, William M. Quarles re-posted an instant messaging conversation stating that “Most of the major distributions have either left XFree86 behind and switched to X.org, or are [still] using XFree86 4.3 [the old unmaintained version].”
Now it’s true that there were more issues than GPL incompatibility. There had been various calls for restructuring the organization of developers, and for opening up (and speeding up) development. But none of those issues caused a sudden exodus of developers and users. All projects (proprietary and OSS/FS) have discussions about their structure and progress, and rarely do they lead to an immediate abandonment by all users and developers at once. The issue (or at least the final straw) that caused the mass exodus by users from XFree86 was the effort to switch to a GPL-incompatible license. It’s clear that trying to switch a popular OSS/FS program from a GPL-compatible license to a GPL-incompatible license can be met with stiff and swift resistance.
Appendix B: Information about the GPL and other Licenses
There are many information resources about the GNU General Public Licence (aka GPL). The GPL itself is available on-line. The GPL Frequently Asked Questions (FAQ) has more information from its author. Groklaw maintains a page of resources about the GPL. Mitchell L. Stoltz’s “The Penguin Paradox: How the Scope of Derivative Works in Copyright Affects the Effectiveness of the GNU GPL, 85 B.U. L. Rev. 1439 (2005) discusses the GPL and the law’s definitions of derivative works.
There are a large number of OSS/FS licenses that exist, though the vast majority of software is covered by the five most common ones. Some are “protective", like the GPL or Affero GPL – they work to protect the software from being turned into a proprietary product, including as part of a larger work. Some are “permissive", such as the BSD-new and MIT/X license; they permit turning the program into a proprietary work. and some licenses like the LGPL are compromises between “protective" and “permissive" – the LGPL, for example, protects the component (usually a library) but permits its insertion into a larger proprietary work. The FSF maintains a list of licenses and some analyses of them. The Open Source Initiative’s license list lists licenses that it has determined are open source software licenses.
Appendix C: GNU projects not under a copyleft license
The Free Software Foundation (FSF) advocates use of the GNU General Public License (GPL), but even they gladly accept the use of software not under the GPL as part of their GNU project.
The following are “GNU packages" not under a copyleft license:
• Kawa [fsf.org]: licensed under the Kawa License [gnu.org], which is an X-11/MIT style license. Kawa is a Scheme/Emacs Lisp environment that runs on Java.
• GNU less [fsf.org]: the latest tarball from ftp.gnu.org is GPL, but older versoins are non-copyleft.
• Ncurses [gnu.org], which is distributed under an X11-style license.
• Proto [fsf.org], which is a software development tool for finding C and C++ function prototypes, and is in the public domain.
• Quexo [fsf.org], xquery implementation using Kawa to compile to java bytecode. Under the Kawa license, which means an X11-style license.
• Speex [fsf.org], an audio compression codec for voice, under the Xiph.org license (a modified BSD)
(My thanks to Javier Candeira who identified many of these.)
