你好，

請問一下，我們是 embedded linux device 的硬體廠商。
我們在準備 release GPL source codes 時，
下游的客戶亦要求要我們釋出 compilation 與 building firmware 的 scripts。
因為這些 scripts 基本上也是我們開發出來的，與 GPL 的 source codes 無關。
所以不 release 這些 scripts 是不是合法？

謝謝！

您好、依照GPL授權條款的文意解釋，其實下游客戶這樣的要求是符合條款預設的，Source Code的範疇在GPL授權條款裡的定義，其實比一般字面上的理解大得多，GPL授權條款第二版第三條是這樣說的：

“The source code for a work means the preferred form of the work for making modifications to it. For an executable work, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable.”

我個人不精準但是比較容易理解的翻譯如下：

“程式原始碼(Source Code)的妥善定義，對於程式的散布者而言，就是他本身要修改這個程式時所會選用的最優修改格式。對於一個可執行軟體來說，它的完整程式原始碼包括此一軟體的各個模組、使用介面定義檔、還有相關用來編譯程式的編譯腳本及安裝流程說明文件。“

所以就這款條文來看，GPL程式的收受者其實有地位要求散布者提供比字面定義更多的程式原始碼。

有後續問題歡迎接續討論。

敬祝 順心愉快

20090402 1427 自由軟體鑄造場 林誠夏

林先生，您好：

我們有個疑慮是，因為 building scripts 在我們的開發環境中，
是比較上層的，統合 GPL codes 與 private codes 的。

這樣的 scripts 基本上，有下列三樣功能：
1. 進到 GPL codes 與 private codes 執行 make (透過他們自己的 makefile)
2. copy GPL binaries 與 private binaries 到同一個目錄下。
3. 將這個目錄，做成 firmware 的 update image。

我們可以提供，伴隨 GPL codes 中的 makefile，
所以，任意開發者，都可以產生這些 binaries。

除此之外，我們的 building scripts 是不是，不在你說的範圍內？
因為，
1. 他是我們獨立開發的。
2. 他不依靠 GPL codes，事實上他只是操作 GPL codes。
所以，任意開發者，
沒有這樣的 scripts 就沒辦法做出我們的 firmware。
這也是我們想要保護自己的地方。

謝謝！

Hi，

這個問題要詳細解釋的話，就得細說從頭了，得從GPL授權條款的生成意義說起。

GPL授權條款是Richard Stallman實現他軟體自由的重要工具，因為GPL授權的程式的最大特色就在於，即使收受程式的後手只拿到程式目的碼，這個後手也有權利是可以向前手要求完整的程式原始碼，能看到程式原始碼的話，後手才有「使用、研究、修改、重製散布」程式的自由，這是Richard Stallman認為每個軟體程式都該賦予後手使用者的四大自由。

而為了更為推廣他這個「軟體自由」的理念，Richard Stallman也為GPL授權程式設計了一定的「授權承繼性/授權感染性」，就是「用到」GPL程式碼的其它程式，也要follow GPL這樣的rule來散布，讓世界上愈來愈多的程式可以用符點這四大自由理念的狀態進行散布，所以、大家最常問到也最想知道的就是，什麼標準之下叫作「用到」GPL的程式碼，也就是說什麼程度的使用方式是要被GPL授權條款所拘束。

這個「用到」的方式基本上來說就是三種，一是「修改拘束」、二是「取用拘束」，三是「結合拘束」。不過、這個問題並不是這個討論問題的核心，所以先略過不談。上面之所引這麼多GPL授權條款的生成意義，是要表達一個概念，那就是「GPL授權程式本來就是要引導別人釋出你自身撰寫程式的原始碼的」。這是Richard Stallman設計GPL授權條款的初衷。

所以在這個概念下，Richard Stallman對於「程式原始碼(Source Code)」定義的範疇，也較其他授權條款表達的更為擴張，GPL授權條款認為原始碼不僅僅是raw material，而應該是讓其他得到GPL程式的人能夠看得懂程式架構與運作邏輯的說明文件，這是一個較為擴張的概念。當然、GPL授權程式這樣的擴張概念不一定會為商業使用者所欣賞，商業上運用GPL程式的朋友會覺得雖然確實是利用了開放程式碼，但是在程式修改上也盡了很多的工時和努力，很怕程式原始碼的編譯腳本及安裝說明文件一旦完整流行，那會陷自己的商業競爭力於不利的境界，這都是可以理解的。

那麼來談比較實際一點的問題，提供很low很差勁的程式原始碼給別人，會有什麼不利益，或者說、會失去哪些利益。因為若是從軟體社群發展的觀點來說，一個開放程式原始碼專案的原始碼檔案若是給的更詳盡，是有助於其他人參與後續程式的開發，把這個軟體專案的規模做的更大更好；但若是從商業利用者的角度來說，採用GPL的開放程式碼的用意主要在於「縮短工時」，但一旦散布上需要開放全部詳盡的寫作文件，則又覺得反而不利公司的商業發展了。

所以我們把問題再轉回來，「提供很low的GPL程式原始碼給後手，對於商業公司會有什麼不利益的可能性」。其實簡單來說就是提供程式給這個商業公司的前手或是後手，會出面和這個商業公司argue，對於前手的argue，就是將原GPL程式以GPL授權條款散布給商業公司的這個原程式的著作權人的argue，這是比較嚴重的，因為就法律狀態來說這是一個「有權利人的argue」，像是Harald Welte去告D-link、或是FSF代理某些自由軟體的著作權人去告沒有提供程式原始碼的商業公司，這是比較嚴重的狀況，因為就法律狀態上這是一個「侵權行為」，權利人可以依著作權法上權利人的權源提起訴訟，這種訴訟原權利人也比較有機會發動「假處分」、「假扣押」等快捷的司法處分；但若是後手對於這個商業公司的argue，急迫性不會那麼強，因為後手要求商業公司要提供詳盡程式原始碼的要求是基於GPL授權條款這個「契約」，而契約的爭執原則上是要訴訟程序到最後確定時，才會有公論和定案，也才會有正式的判決和法律效果出來。

所以如果比較客觀回答您的原始問題，下游的廠商依據GPL授權條款向您要求程式附帶的編譯腳本及安裝說明，他是可以要求的，但這是一個依據GPL授權條款「契約效力」的要求，對方不能直接透過法院要求強制執行，他可能還是得透過司法訴訟來確立這件事可否執行，比較具體的處理方式，建議可以從二個方面進行思考：

第一、貴公司後續散布的程式原始碼，不應比原程式所提供的程式原始碼更為簡陋。

如果說貴公司取用了他人依GPL程式散布的程式原始碼，修改程式嗣後再散布時，卻用更隱晦不明的寫作方式來散布修改版本的程式原始碼，那這種狀況就比較容易引發原程式的原始著作權利人的非難，因為原權利人提供他人的是一個較為清晰的版本，但被修改過後反而較為難懂、較不易理解，這是不建議的修改態度。

第二、商業性的散布行為應可透過商業協商來處理。

假若貴公司擔心的是完整的程式原始碼散布予下游廠商，會造成下游廠商往後取此原始碼自行洽談其他供應商供貨而斫損到公司利益，建議可以透過商業契約的訂立來彌補GPL授權條款的不足，誠然GPL授權條款要求程式的散布相關規定僅能依照GPL授權條款的預設，任何使用者並不具資格去增刪GPL授權條款任何字句，但是商業公司與商業公司之間的貿易行為，仍然可以透過其他的買賣契約來補足GPL授權條款未述及的不足處，也就是說、程式的散布方式還是依照GPL授權條款的規定，但是商業貿易上關係的存續、買受量的多寡、後續支援服務的金額，這些都是可以透過另外的商務協議契約來達成的，只要形式上、實質上不產生對GPL授權條款預設權利義務關係的修改，另外的商務協議是可行的，也就是說、依據GPL授權條款的規定，貴公司不能阻止下游廠商把所得到的程式原始碼再依照GPL授權的方式再散布出去，但可以另外與其洽談彼此商務合作的期間，例如合作期間三年、年供貨量最低500單位一類的商務契約，若這樣的協商方式不獲對方肯認，則再考慮改用非GPL授權的程式進行產品的改寫，另行提供其close source的相類產品，而不用提供下游廠商相關的程式原始碼。

希望這些回應對您有所幫助，有後續問題歡迎接續討論。

祝 好

20090403 1420 自由軟體鑄造場 林誠夏

另外、單位上的技術同仁亦建議可多加詳述該 firmware 的結構，

如果 GPL授權程式 與unopen專屬授權的部分，在運作層次上是獨立的，

即使是燒在同一個晶片或ROM裡，那麼這是可以不用開放專屬授權部份的程式原始碼的。

例如，處理音效的晶片，一顆即有包含麥克風與輸出音源(接喇叭或耳機)，

如果兩個處理的部分是分開的(可能執行時寫在不同的address space)，則算 aggregation、不算combination，這種狀況專屬授權的部份是可以不用開放程式原始碼的。

如果是沒辦法分開的，那麼看專屬程式這部分貴公司是否有修改的權利，

若是貴公司本身對於專屬unopen的部份亦沒有修改的權利，

那麼在專屬程式上外包一層 Open的API(Application Program Interface)，供這個GPL程式及其它程式能夠使用，

這個作法亦有不少人採用，那麼也有機會可以不用開放程式原始碼。

希望對您有所幫助。

20090403 1432 自由軟體鑄造場 林誠夏

大致上，還是有點不大懂。
（還請見諒）

我們很樂意，也覺得必要，來提供，
我們任何使用過以及修改過 GPL 的完整版本。
當然也不會，故意讓他隱晦難懂。

就我們下游廠商可能會招到 GPL 原始作者的告訴。
所以我們也會採取與我們下游廠商相同的立場，來面對 GPL。

Building firmware 的 scripts ，
我們的想法是，他是我們開發的。
就他的產生，純粹是我們開發的成果，沒有其他人或 GPL 的參與，我們就是原始的作者。
但就對後手而言，沒有這些 scripts，卻又無法 building firmware。
不給 scripts，等於是剝奪了他們在我們硬體上執行這些 GPL 程式的能力。
（當然，他們絕對有能力，可以在其他任何的硬體上，執行我們修改過 GPL 程式。）

參照，gpl-violations.org Source Code Release FAQ。
按 Harald 的說法，應該要 release building firmware scripts。
但，總覺得他好像擴大了 GPL 原始涵蓋的範圍。
因為這樣的 scripts 並沒有『修改』，沒有『取用』，也沒『結合』任何 GPL 的 codes。

確實是我雜七雜八引論太多，反而變得有點失焦。



那下面用比較直觀的概念來討論吧!



原則上，GPL授權條款目前還處於「一個中國、各自表述」的階段，就是一個GPL授權條款，可是解釋者的立場及角度不同，最後解釋出來的範圍也會不同。



原始碼的範圍，照Harald Welte的說法，應該要release building firmware scripts，那是因為Welte是開放程式原始碼理念的信奉者，他認為透過開放程式碼這個手段，人類的智慧可以不受限的公開共享，最後對整個人類群體都是有益的，所以像Richard Stallman以及Harald Welte等人，對於GPL授權條款的解釋向來是採比較「擴張」的態度。



而對於商業公司來說，編譯產品的scripts並沒有「修改」、沒有「取用」，甚至也沒有「結合」到GPL授權的程式碼，一旦把這些詳盡的資訊全部釋出，可能會產生斫害自己商業利益的結果，所以對於「全盤開放」這回事也是疑惑不前的。



那麼法律上的判準應該是怎麼樣?司法判決應該是要尋求二邊立場的公正的中間值，但是很遺憾的，目前各國的自由軟體授權訴訟案例，都不算是進入條款內文的實質審查階段，德國的案子是在形式上肯定了GPL授權條款的有效性，美國的案子是在司法救濟上肯定了自由軟體授權條款的可救濟性(假處分)，但是仍然沒有就GPL授權條款內容字斟字酌的司法判決產生，也就是說、現階段，這個原始碼的範圍要給到什麼程度，還沒有一個篤立的司法機構跳出來進行解釋。



我個人在推廣演講時常常用大學生抄筆記的例子來比喻GPL程式原始碼的概念，原則上筆記人人會抄，但是精細或是粗糙有所不同，有的人幾乎是逐字記下，有的人只記微言大義，可能只有本人才能看得懂。很多自由軟體運動的推行者，鼓吹的就是大家多多提供記載詳盡的筆記，那樣後來拿到程式原始碼的人才能夠按圖索驥，把程式間的架構重新建立起來，甚至比原本的原型更好，所以、如果這個GPL程式是完全自創，那麼程式原始碼提供的詳細與否基本上就是良心事業，借過筆記的人都知道，如果借來的筆記像無字天書怎麼看都參透不了，那就是莫可奈何的事，畢竟這是對方無償免費出借的筆記，所以一般程式的原著作權人願意將其寫作的程式以GPL授權方式和大家共享就很不錯了，怎麼還可能要求程式的原始著作權人提供如何如何詳盡的程式原始碼?但是!如果這個程式原始碼也是抄來的，也就是說取用別人的GPL授權程式碼來再改寫，就完全不是這麼一回事了。



第二種狀況好比有人抄寫了很詳盡的課程筆記，也願意用自由軟體授權的方式無償釋出，但是他要求改寫的每一個人都應該要照著預設的遊戲規則走，也就是說，抄他的筆記可以，再改寫後散布也很歡迎，但是後續衍生作品的詳細度不能寫的比他原來的更low，這就是為什麼現在會有一些自由軟體授權訴訟是由社群參與者起訴大型商業公司的理由，因為這些GPL程式的原創作者當初開放釋出的程式碼嗣後被商業利用者封閉起來利用，有違他本來要與大家分享的初衷。但若是抄了原創者的code，後續也願意將主程式以開放程式原始碼的方式釋出，但是關於script及install information不想要太快的全盤公開，這就真的是比較難以遽下判斷的hard case了。



只能說、目前的自由軟體訴訟，很多是由於態度問題，各國直接被告訴的對象，泰半不是開放不完全的廠商，而是幾乎完全不開放也不願意和原著作權利人交談協商的對象，才會對簿公堂走上司法途徑，我的個人看法是凡事都有商量的餘地，「提供GPL程式原始碼」一事求的是什麼?其實從理念觀點就是把「使用、研究、修改、重製散布」移交給收受程式的後手，讓有心學習有心改進這程式的人有機會可以這樣做，所以若不是完全封閉機會連基本的程式原始碼都不給的話，我個人認為就還有和程式原授權人彈性磋商的空間，所以關於「GPL授權程式原始碼該給到什麼地步」這個問題，坦白說真的是要看個案而定的，筆記抄的很好也願意讓他人改寫再散布的人很多，後手把它改寫爛了或是改寫了不再散布出來，有的人會在意有的人不會在意，所以重點就是「誰會在意誰不會在意」，又、「在意的人他在意到什麼程度」，「有沒有可以協商取得共識的可能性」?事實上泰半的案子，如果和自由軟體授權的原權利人進行溝通取得諒解，多是可以順利釐清這些誤解的。



希望這些回答對您有所幫助，有後續問題歡迎接續討論。



20090406 1520 自由軟體鑄造場 林誠夏

林先生，謝謝您，清楚的論述。

我們目前大概有個底，知道該怎麼做。
基本上，儘量保持 GPL 的精神。
就如同您所說的，就範圍部分，有點模擬兩可。
但就，自由、分享的精神是很確定的。
只是考量到商業競爭上的問題，
有時就只能儘量在合法，合理的範圍內做釋出，
以期可以不違背 GPL 的精神，又能保護自己。

謝謝您耐心的回答。