From: Marcus Brinkmann Subject: Re: Future of ext2 support in the Hurd? Date: Mon, 13 Aug 2007 02:02:11 +0200 Message-ID: <878x8g5mkc.wl%marcus.brinkmann@ruhr-uni-bochum.de> References: Mime-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: linux-ext4@vger.kernel.org, bug-hurd@gnu.org To: "Theodore Ts'o" Return-path: In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: bug-hurd-bounces+gnu-bug-hurd=m.gmane.org@gnu.org Errors-To: bug-hurd-bounces+gnu-bug-hurd=m.gmane.org@gnu.org List-Id: linux-ext4.vger.kernel.org At Sun, 12 Aug 2007 17:40:00 -0400, "Theodore Ts'o" wrote: > There is definitely still code in the ext2 > filesystem translator which is GPLv2 only, since it is derived from > Linux. And as we all know, GPLv2 and GPLv3 code are licensing > incompatible, and that the FSF has claimed that the GPL will infect > across a wide variety of linking mechanisms, up to and including dynamic > linking. Yes. To my understanding, the GPL is not about technical methods, but seeks for maximum protection available under law, irregardless of technical methods to create a derived work. The files you are referring to, ext2_fs.h and ext2_fs_i.h, can easily be replaced by clean-room implementations, if relicensing the ext2fs translator is desired. However, we have other parts in the Hurd where that is not possible (drivers in the kernel, network stack in our network server). So the questions you raise are still interesting. In fact, I just searched for your name, and it pops up in the network stack, but not in the ext2fs translator (the above files are copyright Remy Card and Linus Torvald). > Indeed, in the case of GCC, RMS has made the claim (when > pursuading NeXT to release the Objective C front-end under the GPL), > that the GPL infects across a Unix pipe! I don't know any details about that case, but I can easily imagine that being true, so I will just take your word for it. The GPL FAQ states that "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). 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. 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." This matches my best understanding of the issues involved. Beyond that, I can not say anything that applies particularly to the Hurd or its RPC interfaces. > The reason why I ask this > question is it seems extremely important whether or not the FSF has made > a determination if the GPL infects across HURD IPC calls. If the GPLv2 > does in fact infect across Hurd calls, and the Hurd is going GPLv3, it > seems that will be a need to either drop the ext2 filesystem, or rewrite > those portions of the ext2 filesystem which are derived from Linux code. That is an important question, but for now the Hurd is GPLv2, for exactly that reason. There are other significant parts of the Hurd taken from Linux, so we can't do a complete switch at this time. To make a partial switch, we would have to address the issues you raised. Beside the FSF' position, your position (and Remy Cards', Linus Torvalds' etc) matters as well, of course. As a side not, personally I am confident that most of these cases can be resolved quickly and amicably, and will have exactly the outcome that common sense suggests. The other cases I will happily leave to the lawyers to sort out. Thanks, Marcus