January 25, 2007

LGPL 與 C++ Template Library

在我小時候用 Zortech C++ 與 Turbo C++ 的那個年代,那些商業 C++ compiler 就有 Template 的支援,GNU g++ 也在 Cygnus Solution 的大力支持下納入許多 C++ 規格的實做。而,GNU [LGPL] (Lesser General Public License) 則是 GNU GPL 的「變形」,允許動態連結函式庫的行為,謝東翰前輩曾做了一份繁體中文翻譯 [GNU 較寬鬆公共許可證 (中譯版)],在 [FSF/UNESCO Free Software Directory] 有部份採用 BSD License / GPL / LGPL / QPL 授權發行的 C++ Library 列表,當然這些專案多少也用了 C++ Template,至於以 GNU LGPL 發行的套件,我們也很清楚,在其上發展動態連結的應用程式,可不受 LGPL 約束,也就是可成為 closed-source software,不過,倘若修改到 library 本身,就必須依循 GPL/LGPL 發佈。

在 Realtime 與自動控制領域頗有名氣的 [Orocos Real-Time Toolkit] (RTT) 最近在 1.0.2 版發佈時,更改了授權方式,詳情見 [Orocos Real-Time Toolkit 1.0.2 released],以下節錄與授權方式相關的部份:
    A license change from LGPL to the GPL + linking exception was done. The LGPL did not cover C++ templates correctly, while the new license does and is legally more sound for use in commercial applications.
引發我的注意是因為 "LGPL did not cover C++ templates correctly" 的陳述,看來這與程式語言特性有關。之前在 blog [熱血之餘談軟體授權] 與 [檢視 GPL 3.0 草案] 提到 GPL/LGPL 在程式語言的角度來說,有語意模糊的弊端,不僅動態語言如 Java 者會有爭議,現在我們也看到 C++ 這樣的 "meta-language" 若以 LGPL 發行,將會衍生一些「非預期」的模稜兩可行為。FSF Europe 的 mailing-list 有一篇由 Benoît Jacob 張貼的討論 [Writing an exception to LGPL for a C++ template library],關鍵處就是以下陳述:
    As a special exception, you may consider instantiation of templates or use of macros or inline functions from this file en pair with using a normal linked library. Thus you can use it this way without causing the using part to be converted into the LGPL. This file itself is however always covered by the LGPL.
C++ 的 template 有著類似 C 語言 macro 或 inline function 的特性,都會依據特定規則「展開」為原始表示型態,再經由編譯系統進一步合成對應的目的碼,只是說實做的層面有差異,C 語言的 macro 專注於 pre-processor 層面,而 inline function 與 C++ template 則是 semantic analysis 層面,其相似處就在於「程式碼展開的行為」,並且我們也見這是「衍生性」的操作,於是,這下子就有趣了,GPL/LGPL 的「病毒」是否就「感染」使用該 C++ Template Library 的應用程式呢?

Federico Montesino Pouzols 隨後 [回應],指出 [GCC C++ Standard library](libstdc++) 與 [Common C++] 在此議題的澄清表述,前者 (libstdc++):
    As a special exception, you may use this file as part of a free software library without restriction. Specifically, if other files instantiate templates or use macros or inline functions from this file, or you compile this file and link it with other files to produce an executable, this file does not by itself cause the resulting executable to be covered by the GNU General Public License. This exception does not however invalidate any other reasons why the executable file might be covered by the GNU General Public License.
後者 (Common C++) 則是:
    As a special exception, you may use this file as part of a free software library without restriction. Specifically, if other files instantiate templates or use macros or inline functions from this file, or you compile this file and link it with other files to produce an executable, this file does not by itself cause the resulting executable to be covered by the GNU General Public License. This exception does not however invalidate any other reasons why the executable file might be covered by the GNU General Public License.

    This exception applies only to the code released under the name GNU Common C++. If you copy code from other releases into a copy of GNU Common C++, as the General Public License permits, the exception does not apply to the code that you add in this way. To avoid misleading anyone as to the status of such modified files, you must delete this exception notice from them.

    If you write modifications of your own for GNU Common C++, it is your choice whether to permit this exception to apply to your modifications. If you do not wish that, delete this exception notice.
隨後 Federico Montesino Pouzols 又 [補充] 說:
    Both issues can be sorted out with a GPL + exception license. In general, using LGPL for C++ libraries is a bad idea -I would say. Besides the "lesser" aspect of the LGPL, it is obsolete in its language (when you have templates and methods implemented in headers, the division between the library and the application using it is not a matter of just linking anymore). In the obsolete language of the LGPL, when you use a template, you would be basically copying code.
Java Core Library 的自由實做計畫 [GNU Classpath] 就是採用 GPL + exception license,其著眼點就是避開語言層次的限制與模糊不清,正如前述提到:
    "when you have templates and methods implemented in headers, the division between the library and the application using it is not a matter of just linking anymore."
若在 GPL/LGPL 的語意來說,當 C++ compiler 編譯 C++ 應用程式時,會從 C++ Template Library 的標頭檔「複製」特定的程式碼片段到應用程式去,這也使得應用程式被「內嵌」原本以 GNU LGPL 發行的程式碼,進而被「感染」,也就失去 LGPL 的立意。所以,具體的克服方式就如 Federico Montesino Pouzols 指出:
    Some FAQs about the libstdc++ "runtime exception" are answered here: http://gcc.gnu.org/onlinedocs/libstdc++/17_intro/license.html.

    To the best of my knowledge, GPL + linking exception is the best way of extending the LGPL conditions for C++ libraries. Using an exception similar to that of libstdc++ you will of course allow using your library in proprietary applications. If you prefer to avoid that abuse, you could reformulate the exception so that it only allows the library to be used in GPL and LGPL (or a list of free licenses acceptable from your point of view) apps and libs.

    It seems the eCos license 2.0 (http://www.gnu.org/licenses/ecos-license.html) is also a case of GPL + exception. This license however adds the restriction that source code of the app. using the library must be available as specified in section (3) of the GPL.
看了以上陳述後,可以得知 [Orocos Real-Time Toolkit] 從 GNU LGPL 授權移轉到 GPL + linking exception,就是基於以上考量,這種「行為導向」的描述也更符合現況。
由 jserv 發表於 January 25, 2007 04:39 PM
迴響
發表迴響









記住我的資訊?