GPL Inheritance-QA 中央研究院資訊科技創新研究中心自由軟體鑄造場林誠夏法政研究

GPL Inheritance-QA 中央研究院資訊科技創新研究中心自由軟體鑄造場林誠夏法政研究
中央研究院　資訊科技創新研究中心　自由軟體鑄造場林誠夏　法政研究　　TEL: #1474 本著作採用創用CC 「姓名標示－非商業性」授權條款台灣3.0版

Tuxera NTFS/HFS+ linux file system kernel driver
問題詳述: 目前專案中有使用到 3rd party 廠商 Tuxera 所研發的 Linux file system (NTFS/HFS+) kernel driver, 這個 file system driver 是運行在 Linux kernel 的 software module, 根據 GPLV2 的定義, 廠商應有義務要提供 file system driver source code, 但是目前廠商並沒有公開原始碼給我們, 請問這樣是合法的嗎, 我們可以要求廠商提供嗎? 2014/02/11

依據GPL-2.0授權條款的義務性要求，a work based on the GPL-ed Program，應被視為GPL授權元件的衍生著作(derivative work)，從而後續散布程式碼時，也必須依GPL-2.0第2條的規定，以GPL-2.0授權條款的方式為之。所以關於NTFS/HFS+的Linux Kernel Driver，最重要的討論點就是，該驅動程式是否基於Linux Kernel而作的衍生，還是該驅動程式是先有專利格式、Windows下的規格與版本，才被porting到Linux Kernel上成為一個專屬的驅動元件。這個問題正是涉入了GPL-2.0對衍生關係介定的灰色地帶(Grey Area)。 2014/02/11

依照Linus Torvalds的看法，任何依附在Linux Kernel上運作的Kernel Module，都應該是Linux kernel的衍生著作，從而必須要以GPL-2.0授權條款的方式來提供： Torvalds與其他Linux Kernel的重要開發者，也有認知到，不一定全部與Linux Kernel運作的驅動程式，都可以在法律狀態上完整無誤的被解讀為Linux Kernel的衍生著作，例如有些驅動程式，是 Unix時代就已經存在，之後只是被更改呼叫設定的轉到Linux Kernel上來進行使用，這樣的驅動元件，Linus Torvalds本人並不堅持必須依GPL-2.0來授權運用，然而，從技術層面與個人態度，他仍然表達不欣賞、不讚賞這樣的處置模式，只是沒有讓它升格為一個法律爭訟的議題。 2014/02/11

2014/02/11

The reason the kernel is exposed in such a LGPLd way when using modules is simply that there are a lot of kernel device drivers for Unix available, and they were not all written under Linux. If somebody wants to port his SVR4 driver to Linux but doesn't want to GPL it, I feel that he should have the right to do that, using modules. After all, the driver wasn't actually derived from Linux itself: it's a real driver in its own right, so I don't feel that I have the moral right to force him to switch copyrights. Linux Torvalds對Nvidia不提供其Linux Kernel下的開源驅動程式所作的批評： (48分10秒之處) 所以說，Tuxera就NTFS格式，是有另行和Microsoft取得其授權：用於Linux Kernel之上，而是類同上述Unix、Nvidia的狀況，而落入了GPL-2.0授權拘束性的模糊地帶上。 2014/02/11

2014/02/11

Linux kernel drivers 的 iSCSI module
問題描述: 2a. 請問Linux kernel中的drivers中的module是要GPLv2 Release嗎? 我們修改的內容是Linux target driver, 包含iSCSI function(iSCSI module) 2b. 前述a的問題如果成立, 要如何partial release? 2014/02/11

Linux kernel drivers 的 iSCSI module
就2a. 的部份：依Linux Kernel多數developers的意見，Linux Kernel下的driver module必須都是依GPL-2.0來對外進行提供，而此看法，對於Linux target driver並沒有特別的例外。就2b. 的部份：是否有其他方式，可以GPL-2.0部份釋出Linux Target Driver，而不及於驅動程式所有部份的程式碼。業界實務上有一種作法，是將Linux Driver寫到應用程式的層級，因為許多的Kernel developers也認同 Linux Kernel上有所謂Kernel Space與User Space，如果這些Driver可以提升到應用程式的User Space層級，且其運作與crash都不會直接影響到Linux Kernel的運作，其故障排除也不需要從Kernel方面來進行程式補贅與修改，則部份Kernel devlopers認為這樣的狀況便「存而不論」，其並不表示讚賞，但現階段也不會進行直接的法律爭訟動作，進一步的相關資訊，可參照Jonathan Corbet於LWN.net上發表的專文： 2014/02/11

2014/02/11

Open Source / Closed Source
Apache-2.0 Apache-2.0 Apache-2.0 Public Domain Apache-2.0 MIT BSD-like LGPL-2.0 Apache-2.0 BSD-like BSD-like GPL-2.0 2014/02/11 2009 © Alvaro Fuentes Vasquez (Kronox), released under GFDL-1.2+, with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts.

rsync 問題描述: 3a. 如果自己寫了一套獨立軟體中間command string 執行GPL授權規範下的program(non library)，這樣的情況下，GPL的感染力是否涵蓋上述獨立軟體，若是不公開上述獨立軟體的source code是否符合GPL 授權規範? 3b. 請問上述問題中軟體授權GPLv3與GPLv2 or GPLv1的情況是否相同? 2014/02/11

rsync 就3a. 的部份：以GPL授權程式既定的溝通介面(interface)來呼叫其功能，如果此種呼叫關係只是單純利用 GPL元件功能(the program that uses the GPL-ed program)，而並非衍生自GPL元件的衍生關係 (not work based on the GPL-ed Program)，則GPL授權元件的授權拘束性，並不必然涵蓋自這樣的獨立軟體。直接可參註的資訊，例如GNU計畫下GPL條款FAQ裡的「What is the difference between an “aggregate” and other kinds of “modified versions”?」(GPL授權條款中「聚合著作」與「修改著作」間的差異在哪裡，又彼此的區隔分界在哪？)： faq.html#MereAggregation 2014/02/11

2014/02/11

rsync An “aggregate” consists of a number of separate programs, distributed together on the same CD-ROM or other media. The GPL permits you to create and distribute an aggregate, even when the licenses of the other software are non-free or GPL-incompatible. The only condition is that you cannot release the aggregate under a license that prohibits users from exercising rights that each program's individual license would grant them. 所謂的「聚合著作」指的是許多獨立運作的程式，在散布時被儲放在同一個散布媒介，如CD光碟片上一同散布。GPL授權條款容許GPL程式能夠與其他程式，集結為聚合著作後合併散布，即使聚合著作裡其他的程式並非自由軟體，或者在授權狀態上是與GPL不相容亦可。此種作法唯一要注意的地方，就是整個聚合著作的授權方式，並不能去干涉聚合著作裡個別程式所本有的授權規則。 2014/02/11

rsync Where's the line between two separate programs, and one program with two parts? This is a legal question, which ultimately judges will decide. We believe that a proper criterion depends both on the mechanism of communication (exec, pipes, rpc, function calls within a shared address space, etc.) and the semantics of the communication (what kinds of information are interchanged). 關於程式與程式間的聚合關係，究竟是二個獨立程式被合併儲放，或者是一個程式被切割為二個部份後儲放，這是一個法律問題，也就是說、有權做最後判定的是訴訟發生時的承審法官。不過、原則上，這樣的問題可以從二個層面來進行判定，一是程式與程式間的溝通機制的方式(例如：究竟是以 exec、 pipes、rpc，或是呼叫function calls後在同一段共享記憶體區段執行的種種不同方式)，第二則是程式與程式間溝通語彙的內容(究竟這二個程式運作時交換的是哪類別的資料)。 2014/02/11

rsync If the modules are included in the same executable file, they are definitely combined in one program. If modules are designed to run linked together in a shared address space, that almost surely means combining them into one program. 所以、如果不同的程式模組已經被結合在同一個可執行檔中去運作，那此種結合狀態很明確的就是兩個程式被結合為一個單一程式。而如果是不同的程式模組，但在設計上預設會透過連結的方式，呼叫彼此到同一段共享記憶體去運作，那也幾乎可以表示這兩個模組其實就是一個單一程式的二個部份。 2014/02/11

rsync By contrast, pipes, sockets and command-line arguments are communication mechanisms normally used between two separate programs. So when they are used for communication, the modules normally are separate programs. But if the semantics of the communication are intimate enough, exchanging complex internal data structures, that too could be a basis to consider the two parts as combined into a larger program. 以比較的方式來解說，兩個獨立的程式常會透過pipes、sockets，或是下command-line的方式來結合運作。所以如果二個程式模組之間的構通機制是透過pipes、sockets，或是command line的方式，那這二個模組之間的結合關係，通常會被判定就是聚合著作而非程式彼此間的修改著作。然而、如果這二個程式模組在資訊交換上有著相同結構的語彙邏輯，則就算彼此是透過pipes、sockets，或是command line的方式來溝通，但因為彼此交換的資訊具有層級上的相同性，足證這樣的結合運作關係密不可分，故也有可能例外的被認定是同一個軟體程式的二部份。 2014/02/11

rsync 就3b. 的部份：就衍生程式的判定，GPL-2.0和GPL-3.0並無明確的不同，而GPL-1.0 僅為1989年至1991年推出的短期條款，目前極少被運用到，現階段對於GPL授權拘束性的解釋，原則上以2版和3版為主要討論標的即可。 2014/02/11

區隔GPL程式碼的措施中央研究院資訊科技創新研究中心自由軟體鑄造場林誠夏法政研究
中央研究院　資訊科技創新研究中心　自由軟體鑄造場林誠夏　法政研究　　TEL: #1474 2014/02/11

2014/02/11

To be derivative work or not to be derivative work,
that's the question. 2014/02/11

1. 剔除拘束性質程式碼 2. 核心技術分開散布 3. 中介隔離預作區隔 2014/02/11

剔除 / 分開 / 中介 2014/02/11

剔除 / 分開 / 中介風險↑ 風險↑ 風險↑ 2014/02/11

一個GPL各自解讀 2014/02/11

1. 剔除拘束性質程式碼 2014/02/11

不要用 2014/02/11

(1)分析授權狀態 2014/02/11

B. BLACKDUCK/掃描完自行剔除 C. PALAMIDA/掃描完買風險保單 D. FOSSOLOGY/掃描授權資訊
E. BAT/以拆解字串方式驗證目的碼查驗程式碼授權狀態的方式 2014/02/11

自由開源軟體授權分析輔助工具－自動化程式碼掃描系統
葛冬梅為了要解決工作上所需處理的授權分析問題，筆者常會需要了解一個專案究竟利用了哪些自由軟體元件，以及這些元件是採用哪一份自由軟體授權條款？這些工作通常得透過人工進行，也就是請實際開發專案的工程師提供他們的軟體架構圖，並且查詢這些軟體元件適用哪些授權條款，等到取得這些資料後，才有辦法進行後續的授權分析，以研擬授權衝突的解決方案。若涉及的自由軟體元件僅三、四個，那這樣的人工作業尚不困難，但若是牽涉到幾十個自由軟體授權元件，那就得花上好一番的功夫來進行人工作業。因此為了簡便這些授權分析的流程，近年不少團隊就此需求建置了自由軟體程式碼掃描的自動化系統，以掃描軟體專案程式碼的授權方式，並進一步列出報表以顯示該專案裡自由軟體元件的利用情形，以及所使用到自由軟體元件的授權細節。 2014/02/11

(2)實施剔除工作 2014/02/11

A. 尋求原程式著作權人的另行授權 B. 學習後重新創作不相容的程式碼
C. 以非COPYLEFT性質的軟體代換 2014/02/11

A.另行授權 2014/02/11

2014/02/11

B.重新創作 2014/02/11

重新創作≠抄襲改作 2014/02/11

著作權法保護標的僅及於著作的表達、不及於著作的概念。重點是不可機械式自動編譯、或是用全自動轉譯的手法。
2014/02/11

月落烏啼霜滿天，江楓漁火對愁眠；姑蘇城外寒山寺，夜半鐘聲到客船。楓橋夜泊唐張繼 2014/02/11

月落烏啼霜滿天，江楓漁火對愁眠；兩岸猿聲啼不住，請用猴標六神丹。改寫楓橋夜泊唐張繼 2014/02/11

秋夜江邊，殘月西沉，烏鴉啼叫，清霜滿天。滿懷鄉愁孤臥客船，只有火紅的江楓，明滅的漁火相伴。夜深難眠，又聽到從蘇州城西寒山寺傳來的悠揚的鐘聲，幽靜得更令人難耐。
改寫楓橋夜泊唐張繼 2014/02/11

自小背誦張繼的楓橋夜泊，所以旅遊時興沖沖的來到寒山寺看看，秋天晚上的天氣確實非常寒冷，感覺頭頂以上滿罩一層薄霜，月亮下沉時烏鴉的啼叫聲顯得特別淒厲，岸邊楓樹的葉子早已呈現火紅的顏色，在明明暗暗燈火的照耀下，讓人不禁想起台北故鄉的霓紅燈，隨著鐘聲擺盪起伏，終於感受到一人旅行的孤獨感。重新創作楓橋夜泊唐張繼 2014/02/11

This image is a work of a U. S
This image is a work of a U.S. military or Department of Defense employee, taken or made during the course of an employee's official duties. As a work of the U.S. federal government, the image is in the public domain. Author Raúl Silva Permission “for any use you want" Fair use at: 2014/02/11

MPL-1.1 2014/02/11

MPL-2.0 2014/02/11

C. 軟體代換 2014/02/11

2014/02/11

2. 核心技術分開散布 2014/02/11

2014/02/11

GPL v.2-2-2 These requirements apply to the modified work as a whole. If identifiable sections of that work are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works. But when you distribute the same sections as part of a whole which is a work based on the Program, the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it. 2014/02/11

2014/02/11

GNU is Not Unix 2014/02/11

Linux Kernel 2014/02/11

Independent and separate works
2014/02/11

分開散布→獨立性 2014/02/11

2014/02/11

靜態連結動態連結 2014/02/11

Static Link: 必然的連結關係代表其他程式與GPL程式間不可分割的依賴關係衍生著作-非獨立著作 2014/02/11

此圖下載於：作者polarpila採用創用CC-姓名標示-非商業性-禁止改作對外釋出；此處特別聲明為在自由軟體推廣演講中進行「合理使用」，請讀者不要更行移置他用。 2014/02/11

Dynamic Link: 浮動的連結關係代表其他程式與GPL程式間可被取代的獨立關係獨立著作-不受授權拘束限制 2014/02/11

2014/02/11

Windows, Linux, Mac OS X, MeeGO....
2014/02/11

此圖下載於：作者The 2th RoOm採用創用CC-姓名標示-非商業性-相同方式分享對外釋出；此處特別聲明為在自由軟體推廣演講中進行「合理使用」，請讀者不要更行移置他用。此圖下載於：作者polarpila採用創用CC-姓名標示-非商業性-禁止改作對外釋出；此處特別聲明為在自由軟體推廣演講中進行「合理使用」，請讀者不要更行移置他用。 2014/02/11

2014/02/11 此圖下載於：http://www.flickr.com/photos/leeicep/6891496/sizes/m/
作者icelee採用創用CC-姓名標示-非商業性-禁止改作對外釋出；此處特別聲明為在自由軟體推廣演講中進行「合理使用」，請讀者不要更行移置他用。 2014/02/11

It depends 2014/02/11

2014/02/11

2014/02/11 此圖下載於：http://www.flickr.com/photos/0x0000org/3492093532/
作者0x0000org採用創用CC-姓名標示-非商業性，對外釋出；此處特別聲明為在自由軟體推廣演講中進行「合理使用」，請讀者不要更行移置他用。 2014/02/11

GPL 的另類利用方式：「分開散布．責任轉嫁」
葛冬梅一個常被提出的問題：要如何在利用 GPL 程式碼的同時，避免其他部份的程式碼也被 GPL 感染？之前曾經提過一些抽象的判斷標準，例如採用動態連結 (dynamic link) 利用 GPL 程式碼，因此開發出來的新程式，許多開發者認為可以不用受到 GPL 的拘束，但是採用靜態連結 (static link) 利用 GPL 程式碼，許多開發者認為新程式仍應該採用 GPL 授權。這樣的標準仍是相當抽象，這期的法律園地就來談一個比較具體的方式，筆者稱這樣的方式為「分開散布．責任轉嫁」。所謂「分開散布」是指將 GPL 程式碼與非 GPL 程式碼分開散布，「責任轉嫁」則是將提供原始碼的責任轉嫁到他人身上。聽來這好像是兩件不同的事情，要怎麼樣才能兜在一起呢？現在就說個甲跟乙的故事來說明。 2014/02/11

3. 中介隔離預作區隔 2014/02/11

2014/02/11

Linux Kernel 2014/02/11

User space GPL-2.0 ．感染性特強．佔有率高．可遠觀而不可褻玩焉．Linux Kernel是一個特殊的變態
Linux Kernel主要開發者兼精神領袖Linus Torvalds表態，寬鬆地允許應用程式可以不採用 GPL-2.0 授權。 User space 此圖著作權利歸屬於Google © 2008，特別聲明為自由軟體推廣演講中進行「合理使用」，請讀者不要更行移置他用。 ©Google 2014/02/11

Linux Kernel-COPYING NOTE! This copyright does *not* cover user programs that use kernel services by normal system calls - this is merely considered normal use of the kernel, and does *not* fall under the heading of "derived work". Also note that the GPL below is copyrighted by the Free Software Foundation, but the instance of code that it refers to (the linux kernel) is copyrighted by me and others who actually wrote it. 2014/02/11

Derivative Works 衍生著作 2014/02/11

Open Middleware Open Middle Layer 2014/02/11

≠ Derivative Works ≠ 衍生著作 2014/02/11

Transplant 2014/02/11

Android 的區隔 GPL 拘束機制葛冬梅 2008-10-24
兩個月前談過「分開散佈．責任轉嫁」這種用來避開 GPL 感染的一種方法，今天要談的是另外一種方法：區隔機制。所謂的區隔機制就是在 GPL 程式與 nonGPL 程式中間插入一個中介的介面，這個介面寫得夠好，讓 nonGPL 程式透過介面與 GPL 程式互動，nonGPL 程式因此不會包含任何的 GPL 程式碼，所以 nonGPL 程式不受到 GPL 感染。而這個介面可以是 LGPL、BSD 或 Apache 等任何一份授權條款。 2014/02/11

GPL 條款對於衍生程式的判定標準與其授權拘束性的擴散範圍
林誠夏 (上) 林誠夏 (下) GPL 類別的授權程式，最為人著稱的特性便是其「牽一髮而動全身」的授權拘束性（License Inheritance，註一）。所謂的「授權拘束性」白話來說，指的是當使用者將 GPL 授權的程式碼抄寫到自己的軟體專案時，如果抄寫程度佔專案程式碼的比例很大，或是此一 GPL 授權元件提供了專案的核心功能，並且專案的其他元件在互動上亦無法與其分割，則整個軟體專案便會一體被視為該 GPL 授權元件的衍生著作，嗣後使用者如果再行散布這個軟體專案，便僅能適用 GPL 的授權方式來進行釋出。而由於近年來自由開源軟體元件被產業化利用的比率愈見頻繁，因此授權拘束性所帶來的爭議也愈來愈受到重視，本文便是針對這個議題，先依著作權法的預設說明、再照 GPL 授權條款的文意解釋，接著舉 Linux Kernel 的實際運作狀況佐證，一步步抽絲剝繭的分析 GPL 授權程式在衍生程式方面的判定標準，及此標準在軟體元件的連接關係 (linking) 上，所可能擴散的拘束性範圍。 2014/02/11

是 Δ ？否 □ 自由開源軟體元件A與自行撰寫元件B的互動關係通說認定上，元件B是否為元件A之衍生著作。
通說≠放諸四海皆準。元件B是否為元件A之衍生著作，乃依一般軟體著作權對衍生關係的界線來評判，但此界限在不同自由開源軟體授權條款，其實會被條款內容做進階放鬆或限縮的處理。回歸授權條款的基本面，但特例：Sencha / MySQL，建議尊重著作權利人的預先解釋以避除爭議風險。網路呼叫方式，應先判斷主機端與客戶端是否運作密不可分的結構關係，如兩者承襲一樣的資料結構與縝密無法取代與調整的互動流程，則其仍可能被視為一個統合專案(as a whole)，而必須一體適用同一個授權方式；而若並非這樣的緊密結合，再進一步討論兩者之間的互動關係，是否會讓兩元件授權方式互相影響。通說認定上，元件B是否為元件A之衍生著作。元件B是否須依原始開源授權方式來散布？ BSD-3-Clause Apache-2.0 LGPL-2.1/ LGPL-3.0 GPL-2.0/ GPL-3.0 AGPL-3.0 B、A具不同功能，B透過A之API呼叫其功能，但兩者一同編譯為一個執行檔。是 Δ B採用靜態連結方式與A互動，B在編譯時需要A，B在編譯後產生如Lib的函式庫檔案。？ B採用動態連結方式與A互動，B本身為一可執行檔，專案運作上只有需要的時候才會動態地載入A.dll。否 B與A各自為可執行檔，B在執行時傳遞參數給A，讓A執行之後回傳資料回到B。 □ B採用網路呼叫方式與A互動，A為主機端程式，B為客戶端程式，B執行時會呼叫A，並依據A回傳的結果繼續運作，如Web Service。 ☆ A採用網路呼叫方式與B互動，B為主機端程式，A為客戶端程式，A執行時會呼叫B，並依據B回傳的結果繼續運作，如Web Service。 Δ 衍生著作毋須完全採用原始開源授權方式散布，但仍須服膺踐履該授權條款的其他義務性要件。？是否元件B失去元件A的互動關係則無法運作(質的抽象判斷)；是否元件B失去元件A則失去多數功能(量的抽象判斷)；元件B與元件A之間的互動結構，是否可採用其他元件C代替元件A；若加上這些個案判斷的元素，能主張元件B具有獨立性，則例外地不受到元件A授權方式的拘束，而若不能主張獨立性，則原則上元件B受到元件A授權方式的拘束；在LGPL的狀況下，數字參數、資料結構層級及資料結構存取機制、或是小巨集及微量內嵌功能程式碼並不會開啟授權拘束性，但該被引用的LGPL函式庫必須具更新版本代換性，否則例外地會開啟其授權拘束特性。 □ 原則上為非衍生關係，但必須清楚交待元件B與元件A的互動方式與介面，讓使用者在元件A升級改版之後，能重啟元件A與元件B之間的互動關係；而若不能完成這個機制，則元件B就有可能被列回衍生關係，而必須受到元件A授權方式的拘束。 ☆ AGPL- 3.0授權元件，在「修改後」置於網際網路之上提供服務，依條款規定便需要向使用者提供此元件修改過後的程式源碼。 2014/02/11

openlegal openfoundry
2014/02/12

Ctrl+F: 2014/02/12

THANK YOU 本簡報授權聲明 Website: www.openfoundry.org
除另有聲明外，本簡報內容採用 Creative Commons「姓名標示 - 非商業性」台灣 3.0 版授權條款。歡迎非商業目的的重製、散布或修改本簡報的內容，但請標明：(1)原作者姓名；(2)本簡報標題；(3)演講日期。簡報中所取用的圖形創作乃截取自網際網路，僅供演講者於自由軟體推廣演講時主張合理使用，請讀者不得對其再行取用，除非您本身自忖亦符合主張合理使用之情狀，且自負相關法律責任。 THANK YOU Website: Phone: ext. 1474 2014/02/12 95

GPL Inheritance-QA 中央研究院資訊科技創新研究中心自由軟體鑄造場林誠夏法政研究

Similar presentations

Presentation on theme: "GPL Inheritance-QA 中央研究院資訊科技創新研究中心自由軟體鑄造場林誠夏法政研究"— Presentation transcript:

Similar presentations

About project

反馈

请登录

Auth with social network:

GPL Inheritance-QA 中央研究院 資訊科技創新研究中心 自由軟體鑄造場 林誠夏 法政研究

Similar presentations

Presentation on theme: "GPL Inheritance-QA 中央研究院 資訊科技創新研究中心 自由軟體鑄造場 林誠夏 法政研究"— Presentation transcript:

Similar presentations

About project

反馈

GPL Inheritance-QA 中央研究院資訊科技創新研究中心自由軟體鑄造場林誠夏法政研究

Presentation on theme: "GPL Inheritance-QA 中央研究院資訊科技創新研究中心自由軟體鑄造場林誠夏法政研究"— Presentation transcript: