譯自“David Turner: The LGPL and Java“。翻譯並未經過原作者的授權及認證，且摻雜許多原文所無之贅字以幫助讀者得其真意，原作者所撰寫之英文版本方為具解釋性的唯一可參照版本，故<font color="red">本頁面之相關資訊僅供線上參考</font>，<font color="red">而不採用公眾授權的方式提供重製與散布</font>。
如果您對於這個分頁內容有任何的資訊分享或是改進建議，歡迎寄信到lucien.cc@gmail.com留言指教。
The LGPL and Java by David Turner
LGPL授權條款在Java環境下的運作方式 作者：David Turner
This article was written in November 2004, when LGPLv2.1 was the most current version of the license. Since then, LGPLv3 has been published. The main points of this article remain true about LGPLv3, but some of the details, such as section numbers, have changed.
此篇文章是在2004年11月份完成，當時使用比率最高的LGPL授權條款是2.1的版本。其後在2007年有了新的3版LGPL，這篇文章裡關於LGPL的原則說明還是能適用在3版上，但部份細節的內容需讀者自行意會後調整，例如所指條文的序號就略有變動。
It has always been the FSF's position that dynamically linking applications to libraries creates a single work derived from both the library code and the application code. The GPL requires that all derivative works be licensed under the GPL, an effect which can be described as “hereditary.” So, if an application links to a library licensed under the GPL, the application too must be licensed under the GPL. By contrast, libraries licensed under the GNU Lesser General Public License (LGPL) may be linked to proprietary applications.
自由軟體基金會在連結方面向來解讀的立場是，若是將應用程式動態連結至函式庫後，結合為一個新的軟體專案，那這個軟體專案便是該應用程式與函式庫共同的衍生作品。也就是說、此例中如果該函式庫是以GPL為授權條款，那就會開啟一般俗稱的「GPL授權條款的授權承繼性1)」，也就是說、整個衍生的軟體專案都要受到GPL授權條款的拘束，在再散布時只能以GPL授權條款為唯一能選擇的授權方式，此拘束力及於軟體專案中本非以GPL授權的應用程式部份。比較上來說、LGPL授權條款在拘束範圍上就沒有GPL這麼嚴謹的授權承繼性，所以LGPL授權的函式庫能與不開放程式源碼的私有應用程式 (Proprietary applications)以連結的方式結合在一起運用，而不會影響彼此的授權狀態。
In July of 2003, Slashdot published a story claiming that I had claimed that the LGPL did not function as intended in the case of Java. This story was based on a misunderstanding of a response to a question sent to licensing@gnu.org, and many attempts to clarify the issue in the Slashdot story did not get across. I have recieved numerous questions about the story since, via both licensing@gnu.org and personal email.
在2003年7月份的時候， Slashdot網站上發表了一篇報導，這篇報導提到我(David Turner)認為LGPL授權的函式庫在Java的環境下進行編譯，彼此的授權機制將不能妥善的運作。這樣的報導內容，其實是誤解了我於 licensing@gnu.org信箱的回覆內容，其後我於Slashdot網站上也做了若干更清楚的修正說明，但此議題的澄清效果並不如預期，後來還是有很多朋友透過 licensing@gnu.org或是我個人的信箱來詢問這個問題。
FSF's position has remained constant throughout: the LGPL works as intended with all known programming languages, including Java. Applications which link to LGPL libraries need not be released under the LGPL. Applications need only follow the requirements in section 6 of the LGPL: allow new versions of the library to be linked with the application; and allow reverse engineering to debug this.
自由軟體基金會在此議題方面的立場其實非常確定：LGPL的授權規則可以適用在任何已知的程式語言編寫環境，當然也包括Java這個程式語言的編譯環境。就LGPL的授權規則而言，應用程式透過連結的方式利用LGPL函式庫，並不會造成應用程式在散布時僅能使用LGPL來進行授權。這個應用程式的授權狀態只要不與LGPL第6條的規定相違背：那就是允許應用程式的使用者可以新版的LGPL函式庫取代舊版，來與這個程式進行連結運用；並且、容許應用程式的使用者可以對該程式進行還原工程，以解決使用上可能遭遇的軟體瑕庛(Bug)。
The typical arrangement for Java is that each library an application uses is distributed as a separate JAR (Java Archive) file. Applications use Java's “import” functionality to access classes from these libraries. When the application is compiled, function signatures are checked against the library, creating a link. The application is then generally a derivative work of the library. So, the copyright holder for the library must authorize distribution of the work. The LGPL permits this distribution.
而在Java這個程式語言的運作環境下，原則上會將應用程式所會連結利用的函式庫改以JAR(Java Archive)的檔案格式儲放。應用程式一般也要透過Java內設的”輸入機制”來利用這些儲存為JAR檔名的函式庫。而當應用程式透過Java進行編譯時，函式庫與應用程式之間的呼叫關係亦會被Java環境重新編撰以建立連結。所以、一般來說這個應用程式會被視為函式庫的衍生作品。以至於、這個衍生作品需經原函式庫的著作權利人同意後方能繼續向外散布。而這樣的利用方式，與LGPL授權條款預設的規則並沒有任何的衝突(LGPL授權的程式、原本就允許衍生作品能夠繼續向外散布)。
If you distribute a Java application that imports LGPL libraries, it's easy to comply with the LGPL. Your application's license needs to allow users to modify the library, and reverse engineer your code to debug these modifications. This doesn't mean you need to provide source code or any details about the internals of your application. Of course, some changes the users may make to the library may break the interface, rendering the library unable to work with your application. You don't need to worry about that—people who modify the library are responsible for making it work.
如果您散布了一個Java的應用程式，並利用Java的輸入機制來利用LGPL授權的函式庫，這個程式的授權狀態其實稍加調整就可以符合 LGPL所要求的散布義務。這個應用程式的授權狀態需要容許使用者能修改應用程式背後的函式庫(以LGPL授權的函式庫)，並且應用程式本身也要容許使用者可以進行還原工程以修正程式後續可能遭遇的軟體瑕庛。但這並不表示您需要提供這個應用程式的完整程式源碼或是內部的呼叫資訊。當然、若程式後續使用者誤改了函式庫的部份程式碼，會造成應用程式與函式庫之間的溝通介面失效而讓整個軟體無法運作。然而、這樣的問題您毋需特別緊張，在自由軟體的改作規則裡，本來就是修改者要為軟體專案的合用性自負其責。
When you distribute the library with your application (or on its own), you need to include source code for the library. But if your application instead requires users to obtain the library on their own, you don't need to provide source code for the library.
如果您將上述專案的應用程式與LGPL授權的函式庫一併釋出，那麼您需擔負向後手提供這些函式庫程式源碼的義務。但是如果這個軟體專案的運作機制，是讓使用者自行下載或是打包函式庫進來使用，則您就不用擔負這些LGPL函式庫程式源碼的提供義務。
The only difference between Java and C from the LGPL's perspective is that Java is an object-oriented language, supporting inheritance. The LGPL contains no special provisions for inheritance, because none are needed. Inheritance creates derivative works in the same way as traditional linking, and the LGPL permits this type of derivative work in the same way as it permits ordinary function calls.
若從LGPL授權的適用立場來分析，Java與C這二種程式語言的最大差異點，就在於Java屬於物件導向的程式語言，而物件導向的程式編譯環境，很容易啟動LGPL內設授權承繼性(Inheritance)的議題。但即使這樣的編譯環境啟動了LGPL內設的授權承繼性，實際應用上並不會造成太大的影響。因為依照LGPL授權條款的規定，應用程式透過傳統的連結結合關係來利用函式庫，或是透過一般功能呼叫的方式來利用這個函式庫的評價並沒有不同，結論都是該應用程式並不需要受到LGPL內設授權承繼性的嚴格拘束，在散布時僅需提供LGPL函式庫部份的程式源碼即可2)。
