不好意思,最近在接觸GPL 3.0
讀到裡面一些規範不是很懂,
下面這裡講到Standard Interface, System Libraries,Corresponding Source for a work in object code form的定義, 不是很懂, 可以為我說明一下嗎?
如果可以舉例講解這些term就更好了,謝謝?

A "Standard Interface" means an interface that either is an official standard defined by a recognized standards body, or, in the case of interfaces specified for a particular programming language, one that is widely used among developers working in that language.

The "System Libraries" of an executable work include anything, other than the work as a whole, that (a) is included in the normal form of packaging a Major Component, but which is not part of that Major Component, and (b) serves only to enable use of the work with that Major Component, or to implement a Standard Interface for which an implementation is available to the public in source code form. A "Major Component", in this context, means a major essential component (kernel, window system, and so on) of the specific operating system (if any) on which the executable work runs, or a compiler used to produce the work, or an object code interpreter used to run it.

The "Corresponding Source" for a work in object code form means all the source code needed to generate, install, and (for an executable work) run the object code and to modify the work, including scripts to control those activities. However, it does not include the work's System Libraries, or general-purpose tools or generally available free programs which are used unmodified in performing those activities but which are not part of the work. For example, Corresponding Source includes interface definition files associated with source files for the work, and the source code for shared libraries and dynamically linked subprograms that the work is specifically designed to require, such as by intimate data communication or control flow between those subprograms and other parts of the work.

The Corresponding Source need not include anything that users can regenerate automatically from other parts of the Corresponding Source.

Hi Kurapika，

下面的翻譯是節錄自我個人簡率的翻過一次的GPL3全文：https://lucien.cc/?p=11

而你所說的範例和進一步的解說，

待我好好想想之後再來分享看看。

敬祝 順心健康

20100730 1120 Lucien C.H. Lin

----------

A 『Standard Interface』 means an interface that either is an official standard defined by a recognized standards body, or, in the case of interfaces specified for a particular programming language, one that is widely used among developers working in that language.

而所謂的「標準界面」，指的是下列二類認定標準中擇一符合的公開界面。第一類為通過國際間標準認證機構官方認可的標準界面，第二類則泛指特定程式語言社群間已廣為參與者認可及使用的一般界面。

The 『System Libraries』 of an executable work include anything, other than the work as a whole, that (a) is included in the normal form of packaging a Major Component, but which is not part of that Major Component, and (b) serves only to enable use of the work with that Major Component, or to implement a Standard Interface for which an implementation is available to the public in source code form. A 『Major Component』, in this context, means a major essential component (kernel, window system, and so on) of the specific operating system (if any) on which the executable work runs, or a compiler used to produce the work, or an object code interpreter used to run it.

關於可執行程式裡「系統函式庫」的範圍，其並不及於程式的整體，但簡單來說只要符合以下二個條件的部份皆涵括之，第一個條件、與可執行程式的「主要元件」包裹在一起進行運用，但其又非這些「主要元件」的本體；第二個條件、僅僅充當「主要元件」與其他元件間聯繫互動以執行程式功能的媒介，或者此媒介的功能乃安置某個「標準界面」、以供此執式程式能夠透過其與公開原始碼的其他軟體進行資訊共享及運作配合。是以為了較精準的界定「系統函式庫」的範圍，首要之務即為釐清「主要元件」的定義，在GPL3授權條款的脈絡裡、「主要元件」意指此一執行程式賴以運作的作業系統(如果有的話)其下不可或缺的重要元件 (系統核心、視窗系統等等不可缺少不可分割的重要元件)，或指的是將此作品進行編譯後產生可執行檔的編譯器，又或許是、執行程式時必備的目的碼直譯器亦包涵在「主要元件」的定義範圍裡。

The 『Corresponding Source』 for a work in object code form means all the source code needed to generate, install, and (for an executable work) run the object code and to modify the work, including scripts to control those activities. However, it does not include the work’s System Libraries, or general-purpose tools or generally available free programs which are used unmodified in performing those activities but which are not part of the work. For example, Corresponding Source includes interface definition files associated with source files for the work, and the source code for shared libraries and dynamically linked subprograms that the work is specifically designed to require, such as by intimate data communication or control flow between those subprograms and other parts of the work.

而所謂「對應原始碼」的定義範圍，則是指程式以目的碼形式存在時，其背後所賴以產生、安裝、執行(如果此程式為一可執行程式的話)此目的碼形式之程式，並可據以修改作品的「原始碼檔案」，這個範圍包括了關於程式運作零零總總的各個腳本和控制變項的說明文件。然而、此謂「對應原始碼」的指涉範圍並不包括前述的「系統函式庫」，或是一般通用的常見附加工具程式，抑或其他未經修改、未為整體作品一部份，而僅是在程式功能的展示上輔助其表現的其他常見的自由軟體程式。如以實際例子來進行說明、所謂「對應原始碼」的範圍包括與程式原始碼檔案習習相關的介面說明檔案，亦涵括其他非程式本體的共享函式庫、動態連結子程式欲與程式連結互通資訊時所需的必要檔案，比如說子程式與子程式間、子程式與程式本體間，具緊密關係的檔案交流或是控制流程等，皆可被視為此種互通資訊時所需的必要檔案(註十二)。

The Corresponding Source need not include anything that users can regenerate automatically from other parts of the Corresponding Source.

然而、「對應原始碼」的範圍亦有其精簡的一面，其並不包括程式的使用者能夠透過「對應原始碼」其中一部份所自動產生的其他程式碼。

可不可以順便請教一下GPL2.0與3.0有什麼不同?
我的認知是GPL3.0主要是為了反Tivoization應運而生的,
所以GPL3.0要使用者(業界的公司)能確保後手除了能編譯GPL的程式碼外,還能夠將編譯出來的程式安裝在裝置上執行,
另外從比較嚴謹的角度去解讀GPL2.0,GPL2不允許GPL的程式碼透過網路散佈,
不知道我的理解有沒有錯誤? 除了我說的這些之外, 請問一下GPL2.0與3.0還有什麼差異呢?
謝謝!

Hi Kurapika，

可不可以順便請教一下GPL2.0與3.0有什麼不同?
我的認知是GPL3.0主要是為了反Tivoization應運而生的,
所以GPL3.0要使用者(業界的公司)能確保後手除了能編譯GPL的程式碼外,還能夠將編譯出來的程式安裝在裝置上執行,

除了反Tivo條款之外，GPL的2版與3版之間還有許多其他不同之處，例如GPL3的定義與用詞都比GPL2來的簡明易懂，除此之外，我下面列出幾項重大的差異之處，供您參考：

(1) 專利授權條款。2版中並沒有明確的專利權授權文字，因此過去2版授權的自由軟體在遇到專利議題時，很容易產生爭議，不過3版第11條明文規定，若程式著作權人或者是其他的共同開發者（貢獻者）本身也是專利權人，或者是有權控制專利權的話，當他將程式以GPL3授權出去的同時，專利權也因此授權出去。

(2) 補充條款。原則上無論是2版或3版，GPL的規定都不能被更動一字一句，不過GPL3第7條明文例外規定，在若干的情況下，使用者再次散布GPL3程式的同時，可以添加原本GPL3所沒有的規定，可以添加的包括了調升擔保條款、顯名聲明條款、版本另名條款、廣告禁止條款、商標保留條款、責任禁添條款。補充條款最主要的用意在於增加與與其他授權條款的相容性，舉例來說，一個軟體開發專案同時利用到GPL2與Apache 2.0授權的程式碼，因為GPL2的感染性，所以Apache2.0程式碼也該因此改為GPL2授權才對，不過Apache 2.0裡面卻有一些GPL2所沒有規定，例如專利授權、廣告禁止、商標保留條款，因此兩條款內容在實際上是有衝突的，因此GPL3增加了第7條的補充條款，這樣透過補充條款的內容，原本是Apache 2.0授權的程式碼，也可以改為採用GPL3+補充條款的形式來授權。

(3) 自動復權規定。依據2版的規定，使用者一旦沒有依據規定利用程式，所有授與的權利將自動終止，除非著作權人另外同意再次授權，否則這位使用者將一直處於無權利用的狀態。不過GPL3第8條規定若是使用者首次違反，並且在一定期間之內就自動採取補正措施的話，這位使用者失去的權利原則上將會自動恢復，他不需要另外連繫著作權人取得再次的授權。這是較為彈性的規定。

(4) 明示允許ASP。ASP是指透過網路提供應用程式服務的商業公司，即使提供服務的應用程式採用GPL2授權，但是因為應用程式是安裝在ASP自己的機房中，並未散布到使用者手上，若是嚴格解釋GPL2文字的話，使用者並沒有權利可以向ASP業者索取原始碼。有社群成員對於ASP利用GPL2程式賺進大把鈔票，卻沒有將修改部份回饋給社群的作法相當不苟同，所以引發討論，這樣的討論延燒到草擬GPL3，有人認為應該要將ASP利用程式的方式納入GPL3，規定ASP也必須對其客戶提供原始碼。不過最後GPL3定稿並沒有將這樣的意見納入，並且在第0條定義到「傳遞（convey）」時，明文規定程式若僅僅是透過網路與使用者互動，並沒有涉及到程式的重製，這就不算是散布。不過FSF也同時訂出另外的孿生條款AGPL3[1]，若是有社群開發者認為ASP也必須提供原始碼的話，就請採用AGPL3來授權自己的程式，而不要用GPL3。這兩份條款內容幾乎一模一樣，除了第13條之外，而第13條的差異就是針對ASP所定，兩份條款負予ASP不同的提供原始碼義務。此外，同一條款還規定GPL3與AGPL3結合成為一個程式的時候，彼此不會互相感染，而是保持各自的授權狀態。

(5) GPL3第2條第1項明文承認使用者的合理使用權，這是GPL2所沒有的規定。

另外從比較嚴謹的角度去解讀GPL2.0,GPL2不允許GPL的程式碼透過網路散佈,
不知道我的理解有沒有錯誤?

針對這個部份，我聽過有人認為，散布GPL2原始碼必須嚴格依據GPL2第3條第1項所描述的三種方式：

GPL2第3條第1項: "3. You may copy and distribute the Program (or a work based on it, under Section 2) in object code or executable form under the terms of Sections 1 and 2 above provided that you also do one of the following:

a) Accompany it with the complete corresponding machine-readable source code, which must be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or,
b) Accompany it with a written offer, valid for at least three years, to give any third party, for a charge no more than your cost of physically performing source distribution, a complete machine-readable copy of the corresponding source code, to be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or,
c) Accompany it with the information you received as to the offer to distribute corresponding source code. (This alternative is allowed only for noncommercial distribution and only if you received the program in object code or executable form with such an offer, in accord with Subsection b above.)"

以上並沒有提到透過網路散布，所以有人認為GPL2原始碼不允許透過網路散布，雖然在GPL2第3條第3項另外有網路散布的相關規定，不過這只是附加規定，也就是只要符合上面三種方式之一，另外再透過網路散布的話，那當然沒有問題，不過若是沒有做到上面三種方式之一來散布，而僅單單透過網路散布的話，那是GPL2所不允許的。

GPL2第3條第3項："If distribution of executable or object code is made by offering　access to copy from a designated place, then offering equivalent access to copy the source code from the same place counts as distribution of the source code, even though third parties are not compelled to copy the source along with the object code."

不過我個人並不贊同這樣的解釋，因為從GPL2第3條第3項的"counts as distribution"可以知道，透過網路散布是被允許的。

這部份的規定由於在架構與文字上均不十分清楚，目前也沒有相關的法院判決，因此在實際糾紛發生時，大多是以著作權人的意思為主：著作權人准許透過網路散布，那就是允許；反之，則是不允許。

以上資訊供參考，歡迎繼續討論！

冬梅　Florence
20100910 1454

再請問一下,如果一開始就只有原始碼要釋出,並沒有binary或執行檔要釋出,而且要釋出的原始碼編譯出來會有問題, 在GPL 2.0與3.0都算違反條款嗎?這部份分別對應到GPL 2.0與3.0哪部分的條款呢?

在GPL3.0,
"Installation Information" for a User Product means any methods, procedures, authorization keys, or other information required to install and execute modified versions of a covered work in that User Product from a modified version of its Corresponding Source. The information must suffice to ensure that the continued functioning of the modified object code is in no case prevented or interfered with solely because modification has been made."
那麼公司產品的安裝資訊需要有哪些項目?一般公司要怎麼確保使用者所修改的程式可以在它所銷售的機器裝置上運行正常呢?

如果某一個程式,用到很多GPL元件(都為2.0),同時也用到一些third party或者其他條約授權(如BSD)的元件,
可以把所有元件的license都放在同一個檔案嗎?另外如果GPL元件有些是2.0,有些是3.0, 在什麼情況放在一起使用會有問題呢?

謝謝!

Hi Kurapika,

再請問一下,如果一開始就只有原始碼要釋出,並沒有binary或執行檔要釋出,而且要釋出的原始碼編譯出來會有問題, 在GPL 2.0與3.0都算違反條款嗎?這部份分別對應到GPL 2.0與3.0哪部分的條款呢?
若是只有釋出原始碼，並沒有散布目的碼的話，這樣並沒有違反GPL的規定，因為只要有了原始碼，其他開發者就可以研究與修改這些原始碼。即使這些原始碼編譯起來有問題，但這並不違反GPL，因為GPL的目的在於實踐研究與修改程式的自由，這些開發已經擁有原始碼，並且可以修改原始碼，所以他們可以研究與修改程式，將這些無法編譯的原始碼修改到可以執行的程度。

不過若是之後使用者散布目的碼的話，一樣負有釋出相對應原始碼的義務，否則就是違反GPL的規定。

在GPL3.0,
"Installation Information" for a User Product means any methods, procedures, authorization keys, or other information required to install and execute modified versions of a covered work in that User Product from a modified version of its Corresponding Source. The information must suffice to ensure that the continued functioning of the modified object code is in no case prevented or interfered with solely because modification has been made."
那麼公司產品的安裝資訊需要有哪些項目?一般公司要怎麼確保使用者所修改的程式可以在它所銷售的機器裝置上運行正常呢?
我引用我的同事林誠夏先生對於這段文字的解釋[1]：

「而『一般性使用商品』的『安裝資訊』，包括了諸如安裝流程、安裝後的授權認證及其他關於程式安裝及使用上所須提供的各式資訊，此等資訊的提供、須使得程式由原始碼格式經過修改後，重新編譯再植入產品內取代原嵌入的舊版軟體，而產品依然能夠運作流暢無誤。質言之、GPL3授權條款對於此等「安裝資訊」的提供要求，在於保證產品內嵌入的自由軟體，不致於經過修改後即無法與產品硬體之間重啟連結運作關係，亦即、不至於任由部份硬體廠商，以硬體設定的方式變相地拑制了GPL3授權之自由軟體的『自由修改性』。亦即、倘若任一硬體機器產品內嵌有GPL3授權程式，其機器生產散布者於產品散布時、亦須提供前述『充足的程式安裝資訊』，而透過此「安裝資訊」提供的配合，此GPL3授權程式在經過修改後仍然能夠於同一硬體產品內運行無誤。」

因此可以知道GPL3這條規定的目的，是為了防止有些公司利用特定技術，阻礙經過修改的原始碼可以載入回原裝置正常運作，例如採取數位加密技術。若所提供的資訊都正確，該公司就已經盡到該盡的責任了，若是使用者自行修改錯誤，而造成無法載入回原裝置正常運作的話，那就自然不是生產產品公司的問題。

[1] 請見：林誠夏，
20071129-GPL3不負責任正體中文化(草稿)，lucien.cc/?p=11，第6條第4項的中文說明。

如果某一個程式,用到很多GPL元件(都為2.0),同時也用到一些third party或者其他條約授權(如BSD)的元件,可以把所有元件的license都放在同一個檔案嗎?
您是要問：將不同授權條款的文字內容，都放在同一檔案之中，是否OK？
另外如果GPL元件有些是2.0,有些是3.0, 在什麼情況放在一起使用會有問題呢?
GPL2規定衍生程式必須採用GPL2規定，GPL3則規定衍生程式必須採用GPL3規定，因此若是這兩者的衍生程式相互重疊，或者彼此為對方的衍生程式的話，這時候自然就產生了授權衝突。 而關於衍生程式究竟應該如何來界定與判斷，則是一個大哉問，會因個案的狀況而定，因此我這邊就您的問題只能做個初步的原則性回覆。

原則上，只要是同一個程式中的所有元件，都必須是要採用同一版本的GPL來授權，因此若一個程式中有的元件採用GPL2授權，有的採用GPL3授權，原則上這樣就有授權衝突的問題。

此外，若GPL2元件與GPL3的元件分別隸屬不同程式，並沒有彼此戶為衍生程式的狀況，可是最後卻編譯成為一個執行檔的話，這時候也會發生衝突的問題，因為GPL2與GPL3都規定所在的執行檔都不可以採用其他的條款授權，這時候自然也產生授權衝突。

不知道您問題所提到的實際狀況如何呢？

冬梅　Florence
20100920 1522

您是要問：將不同授權條款的文字內容，都放在同一檔案之中，是否OK？
是低,我想問說將不同授權條款的文字內容，都放在同一檔案之中，是否OK？同一個程式的所有元件基本上都用GPL2授權,但GPL2,還有BSD, MIT之類的授權條款還有其他商業軟體的授權都放在一個檔案中,這樣可行嗎?

還有您提到GPL 2.0的規定都不能被更動一字一句, 某些授權條款如Apache 2.0可能會跟GPL 2.0衝突,
我想請問一下哪些條約比較不會和GPL 2.0相衝突的? ACME Labs Freeware License www.acme.com/license.html是不是不會和GPL 2.0相衝突呢?

關於GPL2.0和3.0的問題, 您是說同一包GPL的source code, 都要全部被授權成GPL2.0或全部被授權成GPL 3.0囉

另外請問一下,如果將程式碼隨著執行檔一起移交給使用者了,但若該使用者把程式碼弄丟了, 該使用者還可以跟開發者要程式碼嗎?如果可以,那麼開發者該保留程式碼多久呢?

最後再問個問題, 若是A將執行檔給B, B再將執行檔給C, 那麼C可以直接跟A要程式碼嗎? 在B有修改程式碼的情況下, C應該不能夠跟A要吧, 那如果B沒修改程式碼的情況下,C可以跟A取得程式碼嗎?


GPL真是複雜 看了好久都看攏無
感謝您們的回答^^

Hi Kurapika,


您是要問：將不同授權條款的文字內容，都放在同一檔案之中，是否OK？
是低,我想問說將不同授權條款的文字內容，都放在同一檔案之中，是否OK？同一個程式的所有元件基本上都用GPL2授權,但GPL2,還有BSD, MIT之類的授權條款還有其他商業軟體的授權都放在一個檔案中,這樣可行嗎?

這樣是可行的，有些授權條款狀態較為複雜的自由軟體專案也是這樣做，他們將軟體中所利用到的其他元件名稱與授權條款全部都放在一個文字檔中，這樣其他開發者可以一覽所有元件與它們的授權條款。Netbeans就是個很好的例子，他在第1層目錄之下，有三個與授權法律相關的檔案：LICENSE、THIRDPARTYLICENSE、LEGALNOTICE。LICENSE中有這個Netbeans所採用的授權條款說明文字以及授權條款全文；THIRDPARTYLICENSE中羅列了Netbeans中所利用到的他人元件/軟體，以及這些元件/軟體的授權條款全文內容；LEGALNOTICE則是使用者應該注意的其他法律事項，因為這些資訊無法被歸類在前兩個檔案中，所以單獨成立一個說明檔案。

Netbeans網址：netbeans.org/downloads/zip.html。

不過除此之外，我個人還強烈建議，在每一個原始碼檔案的檔頭中插入授權資訊的扼要說明文字，還有如何可以閱讀授權條款的全文，若是之後這些原始碼檔案被個別散布的話，後續拿到這些原始檔案的開發者也一樣可以清楚知道這個檔案的授權內容為何。

進一步資訊您可以參考下列文章：

1) 自由軟體授權的標示通則：授權條款的宣告方式，www.openfoundry.org/tw/for-developers/1884-2010-07-13-09-48-09
2) 利用到GPL元件的商業產品應該如何標示：林誠夏，內含 GPL授權元件產品的標示義務，www.openfoundry.org/tw/legal-article-/2384--gpl-

還有您提到GPL 2.0的規定都不能被更動一字一句, 某些授權條款如Apache 2.0可能會跟GPL 2.0衝突,
我想請問一下哪些條約比較不會和GPL 2.0相衝突的? ACME Labs Freeware License www.acme.com/license.html是不是不會和GPL 2.0相衝突呢?

BSD、MIT是典型可以與GPL2相容、不會產生衝突的授權條款，其他的條款則要視狀況而定，很難有一個抽象、概括的原則說明。

至於您所提到的ACME Labs Freeware License（以下簡稱ACMELFL）是屬於BSD類的授權條款，我看過內容，這是一份可以跟GPL2相容在一個軟體當中的授權條款，並不會產生衝突，也就是說，若是ACMELFL授權部份的程式碼是被GPL感染的話，這些部份可以改為GPL2授權，而不會發生問題。 不過請記得，在整個程式散布的時候，還是註明你們有利用到ACME Labs的哪一個軟體，它的版本號為何，並將ACMELFL全文附上。

關於GPL2.0和3.0的問題, 您是說同一包GPL的source code, 都要全部被授權成GPL2.0或全部被授權成GPL 3.0囉

是的！同一包的原始碼若是GPL2授權，其中就不能存在GPL3授權的部份；若同一包的原始碼是GPL3授權，其中也一樣不能存在GPL2授權的部份。若沒有依照這樣的規則，無論是依據GPL2或GPL3，就都是違反授權規定。

此外，這樣的規則不僅是用於原始碼，也適用於「目的碼」。所以同一包的目的碼也必須全部被授權成GPL2或全部被授權成GPL3。

另外請問一下,如果將程式碼隨著執行檔一起移交給使用者了,但若該使用者把程式碼弄丟了, 該使用者還可以跟開發者要程式碼嗎?如果可以,那麼開發者該保留程式碼多久呢?

這個問題的重點應該是在於：開發者是否還負有提供原始碼給使用者的義務？若答案為「否」的話，即使在現實上，使用者當然可以跟開發者要原始碼，但是開發者因為沒有義務，所以他當然可以不用給。

GPL軟體的使用者之所以擁有可以索取原始碼的權利，是因為有了原始碼才方便修改程式，一旦可以方便修改程式，使用者就是真正地實踐了GPL所授與的「修改權」。既然使用者已經隨著執行檔拿到過原始碼，也就是使用者已經擁有實踐修改權的條件，那麼相對地，開發者就已經盡了他該盡的義務，對於這位使用者就沒有再次提供原始碼的義務。因此這時候使用者自己必須自行承擔沒有原始碼的後果。

不過以上僅是理論的推演，在現實生活中，若使用者真的將原始碼弄丟了，當然還是可以跟開發者再次索取，只是開發者是否一定會再次給予原始碼，就要看這位開發者的態度而定。假如這位所謂的開發者是一家商業公司，並且已經將軟體改為封閉原始碼的方式來授權，這時候使用者跟這家公司再次索取原始碼，我相信應該是無法成功。不過若這是一位持續參與自由軟體開發的開發者，使用者敘明理由跟他再次索取原始碼，我想他應該還是會給的。

最後再問個問題, 若是A將執行檔給B, B再將執行檔給C, 那麼C可以直接跟A要程式碼嗎? 在B有修改程式碼的情況下, C應該不能夠跟A要吧, 那如果B沒修改程式碼的情況下,C可以跟A取得程式碼嗎?

在GPL軟體未被修改的情況下，這個問題會因為A是否為GPL軟體的著作權人，而有不同的答案。

若A是GPL軟體的著作權人，也就是說A是這個GPL軟體的原始授權人，依據GPL的規定，B與C都是A的被授權人，因此C不但可以跟B索取原始碼，還可以直接跟A這個原始授權人索取，假如C將軟體執行檔原封不動地轉給D，D除了有權利跟C索取原始碼之外，也一樣可以跟A索取。

假如A只是GPL軟體的後手使用者，並非是著作權人或原始授權人，此時A就只對B有提供原始碼的義務，對於C並沒有義務，若是C來向A索取的話，A是可以拒絕不給原始碼，A並且可以主張自己已經將原始碼給了B，請C去跟B索取原始碼。

若GPL軟體被B修改過，然後B將這個衍生軟體給C，C這個時候當然只能跟B要，而不能跟A要，因為A並沒有這個B修改的衍生軟體，A只有未經修改過的。這在A是軟體著作權人的情況，也是一樣。

GPL真是複雜 看了好久都看攏無
感謝您們的回答^^

不會。若是還有什麼問題或者想法，歡迎繼續回文！

冬梅　Florence
20100928 1506

又來請問幾個問題:
1.我聽說在嵌入式系統裡面，所有程式都是包在一起,成為一份韌體檔案運作(比如成為.bin, .img檔)、一同出貨的，所相結合的程式多被當成GPL授權的程式, 假使包在一起運作的程式含有GPL授權的程式(如busybox), 同時也包含OpenSSL的程式, 這樣會有GPL violation嗎?OpenSSL好像跟GPL不相容是吧? 有什麼規避方法嗎?

2.toolchain若為一個壓縮檔, 其中某些程式為GPL授權,某些為個人自己寫的,解壓縮之後各個程式可以各自安裝在OS上運行,這樣需要將toolchain整個壓縮檔都用GPL授權嗎?

3.若GPL程式釋出沒附上toolchain的程式, 附上的為toolchain的程式碼(GPL授權),讓GPL程式的後手自行編譯該toolchain, 再利用編譯好的toolchain來編譯GPL程式, 那麼對於toolchain的程式碼在隨GPL程式釋出時需要注意哪些事項?

4.若一嵌入式裝置連同安裝資訊都販售轉交給使用者,其依照GPL3釋出的程式碼還需要附上安裝資訊嗎?

先多謝解答了^^

Hi Kurapika,

以下簡單回覆你的問題。

1、OpenSSL是否與GPL授權的程式不相容？

是、OpenSSL只能與內設link exception類型的GPL2授權軟體結合運作，但是、它可以和GPL3授權軟體相容。

OpenSSL專案目前採取雙重授權：https://www.openssl.org/source/license.html，它有二種授權方式，一是「OpenSSL License」、另一為「Original SSLeay License」，此二種授權條款皆屬於BSD類型的自由軟體授權條款，原則上二者的授權義務性都非常低，但是、就像原來四款BSD與GPL不相容的議題一樣，「OpenSSL License」與「Original SSLeay License」皆有內設的「廣告條款」，這樣的「廣告條款」造成OpenSSL與GPL2.0不相容；但是、GPL3因為在第7條設有Additional Terms，所以OpenSSL與GPL3授權的程式，應該可以結合在一起變成GPL3授權的程式，前提是加上Additional Term裡面關於「額外顯名聲明」的條款。

2、Toolchain裡面部份程式是以GPL授權，那就代表全體Toolchain都得以GPL來授權釋出嗎？

非必然、但建議是，否則就將個別程式分別打包以避免爭議。

GPL授權條款有述明，如果二個軟體專案只是因為「軟體儲放」的關係燒錄在同一片光碟片上，那麼彼此之間是不會產生授權拘束性的，但就、Toolchain的儲放方式顯然與將不同程式專案燒錄在同一片光碟片的情況有差異。也就是說、當然，Toolchain裡面並不是所有元件都有彼此互動的關係，但一般來說為了避免爭議，如果真的二隻程式互動之間具有獨立性，建議就不要把包在同一個Toolchain裡面運作。

具體的說明可以參考GPL-violation.org資深工程師Armijn Hemel經葛冬梅小姐中譯的這篇文章：https://www.openfoundry.org/tw/for-developers/8127-2010-08-30-15-14-41(英文原文請參照：https://www.openfoundry.org/en/for-developers/8127-2010-08-30-15-14-41)。

3、第3部份的問題我不是很能掌握，姑且論以「以SOURCE CODE的格式散布GPL授權的Toolchain，有哪些需要注意的特別事項」。

沒有、就如同一般GPL原始碼程式散布時所需要掌握的那些要點，如果真要說的話，就是GPL對SOURCE CODE的定義非狹義，其認為SOURCE CODE亦包含有讓人足資遵循的INSTALL INFORMATION與COMPILING SCRIPT等相關資訊。

其他對於GPL程式散布的要點，可以參照歐洲自由軟體基金會「Useful Compliance Tips For Vendors」這篇文章：https://fsfe.org/projects/ftf/useful-tips-for-vendors.en.html，或是參考我這篇非官方認證的中文釋義版本：https://lucien.cc/?p=5。

4、第4部份的問題我也不是很能掌握，姑且論以「嵌入式自由軟體產品的程式原始碼與安裝資訊都已經移交與下游品牌商，而由下游品牌商販售予一般消費者時，這樣原來的上游軟體商還需要個別向一般使用者提供這些安裝資訊嗎。」

原則上不用，依照GPL授權條款的規定，孰為終端散布者孰負這個「提供程式原始碼與安裝資訊檔案的義務」。所以、在上面這個案例裡，一般消費者需要程式原始碼時，原則上向品牌商要求，而品牌商則向上游的軟體供應商要求。

希望上述的資訊有解答到您的問題，有後續想法的話歡迎接續討論。

20101014 1415 LUCIEN C.H. LIN