Re: GPL issues

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Apr 11, 2006, at 23:18:04, Mark Lord wrote:
Joshua Hudson wrote:
On 4/11/06, David Weinehall <[email protected]> wrote:
OK, simplified rules; if you follow them you should generally be OK:
..
3. Userspace code that uses interfaces that was not exposed to userspace before you change the kernel --> GPL (but don't do it; there's almost always a reason why an interface is not exported to userspace)

4. Userspace code that only uses existing interfaces --> choose license yourself (but of course, GPL would be nice...)

Err.. there is ZERO difference between situations 3 and 4. Userspace code can be any license one wants, regardless of where or when or how the syscalls are added to the kernel.

Not necessarily, there may be grey area. The new splice() syscall, for example; does any other software have a syscall that even remotely resembles it? Could a piece of software that uses the splice () syscall be said to stand on its own as a separate work? Those are the questions you should be asking. For that particular case, the answers are probably yes; _especially_ if the program in question has an abstraction library for file IO. Now let's discuss a binary program specifically designed to read and write several sysfs files. Does any other operating system have anything like sysfs? Could that program be said to stand on its own? Would it work without linux-2.6? It doesn't even work on linux-2.4! Would that be considered a "derivative work"?? I don't know the answers to these questions, and I suspect it would depend a _lot_ on what the software did with those interfaces, how it used the functionality, etc.

A program that doesn't use more than standard SysV/UNIX/POSIX/ANSI/ etc functionality, or provides an abstraction layer so that it works on more than just Linux is definitely OK. It stands distinct from the kernel; does not strictly depend on a particular version of a particular operating system. A module that links directly into the kernel and messes with its internals is most certainly NOT ok. The grey area in between is exceptionally unclear. I don't think we can state for certain until a legal case comes up in the courts, but let's just hope it never comes to that.

Cheers,
Kyle Moffett

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux