Signs of life from GNU Hurd [LWN.net]

Signs of life from GNU Hurd

Posted Aug 9, 2011 18:56 UTC (Tue) by sthibaul (✭ supporter ✭, #54477)
In reply to: Signs of life from GNU Hurd by viro
Parent article: Signs of life from GNU Hurd

Oops, I missed that comment.

Yes, there are licence concerns with taking existing code. And that's exactly where the Hurd architecture helps: it doesn't make a kernel of it. It runs it in separate processes in userland. Thus no licence issue at all, you can even have processes running proprietary code.

to post comments

Signs of life from GNU Hurd

Posted Aug 10, 2011 6:41 UTC (Wed) by paulj (subscriber, #341) [Link] (3 responses)

So where exactly in the GPLv2 does it say that it's ok to take GPL licensed code and mix it with incompatibly licensed code if the GPLed code is run as a separate process? I can't find such an exception anywhere. It's a fallacy to think that you can just wash away copyright derivation and license issues by inserting purely technical shims, like IPC (hallo Android and BlueZ), or processes and some custom message passing syscalls.

If you're thinking of the Linux exception that clarifies that the normal Linux syscall interface is generally a boundary for GPL derivation, so that it's 100% clear that userspace processes running on the Linux kernel aren't bound the kernel's licence: that clearly does not apply to the kernel's own code.

Signs of life from GNU Hurd

Posted Aug 10, 2011 7:29 UTC (Wed) by viro (subscriber, #7872) [Link] (2 responses)

That depends... One could, e.g. take fs code and write a userland implementation of the same fs derived from it, speaking 9P or e.g. FUSE. Derived as in "uses block allocator functions copied verbatim from the original". Leaving it under GPLv2, of course. Now, 9P is network-transparent. You've got yourself a server for a network filesystem, Linux boxen can connect to it and mount the sucker. *Can* we use the license to prohibit e.g. Plan 9 clients from connecting to such server? I seriously suspect that it would qualify as additional restriction (not to mention being utterly obnoxious).

Depends on the nature of API they are exposing... Hell, nevermind 9P; suppose somebody implements userland nfsd using block device and using something like libe2fs for fs access. Put that sucker under GPL; are you seriously claiming that mounting from such server makes your nfs client a derivative? Or that one is not allowed to use any kind of GPLed code in such a project?

Signs of life from GNU Hurd

Posted Aug 10, 2011 9:00 UTC (Wed) by paulj (subscriber, #341) [Link]

To be clear, I'm making the point that technical tricks, like moving code to separate processes, does not of itself change the licensing situation. I'm replying to the implication in sthibaul's comment (an implication he may not have intended) that the Hurd's micro-kernel + user-space server architecture inherently provides some kind of license-washing function.

What exactly the licensing implications are of taking Linux fses, wrapping them in user-space daemon code and having them talk to some general FS-namespace muxing daemon in a micro-kernel, such that it effectively depended on that Linux fs code, I couldn't quite say. Your word would carry some weight on that issue though.

Signs of life from GNU Hurd

Posted Aug 10, 2011 10:59 UTC (Wed) by nix (subscriber, #2304) [Link]

It is plain that in such a situation, the client code could *not* be considered a derived work: it might not have changed while the GPL serverside code was written. (Also, GPL NFS servers and non-GPL clients talk to each other every day without legal issue.)

Since the server and client code are not even necessarily running on the same machine, you probably couldn't use the reasoning that the combinaton of both linked together is a derived work of the GPLed part, because there *is* no such version.

(but IANAL and even if I were an L I'd be a UK L in any case. So my blatherings are doubly irrelevant.)