| |||||||||||||
|
| |||||||||||||
ParasitismParasitismPosted Feb 19, 2008 8:31 UTC (Tue) by khim (subscriber, #9252)In reply to: Parasitism by xoddam Parent article: Reverse engineering: more than NVIDIA deserves?
If something 'built on top of' a free work is not a derivative work,
it is not subject to the free work's copyright licence.
(Log in to post comments)
Parasitism Posted Feb 19, 2008 13:45 UTC (Tue) by flewellyn (subscriber, #5047) [Link] Xoddam seems a bit confused. I think I understand the source of the confusion, though. One of the most prominent free software projects, the Linux kernel, explicitly states that the boundary between "derived work" and "mere aggregation" for the kernel is at the system call boundary (and presumably the /proc and /sys filesystem interfaces as well). Any user-space program that uses the system calls is not bound by the kernel's GPLv2 license, but kernel modules and other code which interact with internal kernel interfaces is operating inside the kernel's "license domain", if you will. The same does not necessarily hold true for other projects, though! If the license for a particular user-space library is GPL, or some equivalent copyleft license, you must abide by that license's terms if you link it to your code. This isn't the case for libraries that are LGPL, or under a non-copyleft permissive license like the BSD or X11 licenses. So you can write programs that link to GLIBC without having to make them GPL, and of course you can write X programs under any license too. But the idea that all free software allows you to build "on top" of it without license concerns is not even wrong; it's too vague to be evaluated.
/proc - may be, /sys - not in your life Posted Feb 19, 2008 14:39 UTC (Tue) by khim (subscriber, #9252) [Link] When you are poking files in /sys directory you are directly playing with kernel internals, there are no clear well-defined API. There are talks about declaring some parts of /sys as some sort of stable API, but certainly not the whole /sys. Otherwise you can say that "my program which used clearly defined API over /dev/kmem is not derived work" even if said program in fact injected huge kernel module this way...
/proc - may be, /sys - not in your life Posted Feb 19, 2008 15:47 UTC (Tue) by flewellyn (subscriber, #5047) [Link] Okay, that makes sense. Thanks for the correction. It doesn't change the rest of what I said, though. :-)
Parasitism Posted Feb 21, 2008 1:37 UTC (Thu) by jdivine (guest, #18042) [Link] Defining the boundary between "derivative work" and "mere aggregation" is not a matter for the kernel people to decide. It's a matter of copyright law. I have no idea how a court would actually rule on this issue, but I thought I'd point out that it's not really for the kernel people to decide. I suspect, however, that a court might think any arbitrary technical "boundary" -- whether that be system calls, dynamic linking, whatever -- is irrelevant. US Copyright law says that derivative status depends on whether the work in question is "based upon" preexisting work. Imagine the following scenario: A video card manufacturer writes a Windows driver for its product. Later, they decide that they'll port the existing Windows driver to run on Linux. (Whether that is actually feasible is not relevant to this thought experiment.) So using the "clean room" approach, one engineer documents the Linux system calls that the driver needs to hook into, and posts that information publicly. A second engineer takes that documentation and uses it to port the driver. Is this driver now "based upon" the Linux kernel? The bulk of the software existed before the kernel entered the picture, and the guy who developed it never even looked at the kernel code. Is the API documentation itself a "derived work?" That being said, I don't approve of (and try to avoid) proprietary kernel modules and proprietary software in general. I just doubt that there can be a "technical test" to determine what is and is not a derived work as a matter of copyright.
|
|
||||||||||||