This sound like the nvdia driver
This sound like the nvdia driver
Posted May 12, 2014 19:30 UTC (Mon) by Cyberax (✭ supporter ✭, #52523)In reply to: This sound like the nvdia driver by jhhaller
Parent article: Garrett: Oracle continue to circumvent EXPORT_SYMBOL_GPL()
Posted May 12, 2014 19:33 UTC (Mon)
by jhhaller (guest, #56103)
[Link] (6 responses)
Posted May 12, 2014 19:38 UTC (Mon)
by Cyberax (✭ supporter ✭, #52523)
[Link] (5 responses)
But in this case Oracle's own arguments that API is copyrightable undermines this argument. There's no way in hell that DTrace-on-Linux is NOT a derivative work of Linux kernel _API_. And they have no license for this.
Posted May 12, 2014 20:00 UTC (Mon)
by khim (subscriber, #9252)
[Link] (4 responses)
The relation “if module uses this And shim is GPL-licensed, so… what's your problem?
Posted May 12, 2014 20:04 UTC (Mon)
by Cyberax (✭ supporter ✭, #52523)
[Link] (3 responses)
If DTrace has "#include <linux/kernel.h>" somewhere in its source code then it's a derived work of Linux _API_. And in this case they can't argue about 'mere aggregation' - their code is not functional without Linux API and they don't have a license for it.
Moreover, even NVidia loophole with local compilation is not available for them because they ship already compiled code.
PS: please note, that userspace use of Linux kernel headers is explicitly allowed by Linux kernel developers.
Posted May 12, 2014 21:28 UTC (Mon)
by khim (subscriber, #9252)
[Link] (2 responses)
Really? News to me. For such “explicit grant” to be meaningful just in one, very narrow case it must be added to the license. Like this. If/when kernel developers clarify that they don't think that inclusion of kernel headers from userspace program makese them derived work of kernel but not explicitly change the license they are creating precedent which can be applied to D-Trace equally well.
Posted May 12, 2014 21:41 UTC (Mon)
by Cyberax (✭ supporter ✭, #52523)
[Link] (1 responses)
However, various countries' contract laws have a notion of 'convention estoppel' ( http://en.wikipedia.org/wiki/Estoppel#Convention ).
It has always been a common knowledge among Linux developers that userspace API usage of which kernel headers are a part does not make a derived work. Indeed, kernel developers even took pains to make kernel headers usable for userspace software from early days of Linux.
Posted May 12, 2014 22:06 UTC (Mon)
by khim (subscriber, #9252)
[Link]
Posted May 12, 2014 20:03 UTC (Mon)
by PaXTeam (guest, #24616)
[Link]
This sound like the nvdia driver
This sound like the nvdia driver
This sound like the nvdia driver
_GPL is a statement from developers that they believe it's impossible NOT to create a derived work by using GPL-only symbols.
_GPL symbol then it must be so intimately tied to kernel that it's impossible to make it non-derived work” is non-transitive (othwerwise it'll make no sense: all modules are tied directly or indirectly to kernel proper which obviously uses _GPL symbols).This sound like the nvdia driver
This sound like the nvdia driver
PS: please note, that userspace use of Linux kernel headers is explicitly allowed by Linux kernel developers.
This sound like the nvdia driver
Indeed. But if grant is implicit and not explicit then one can not just go an say “it's Ok to do This sound like the nvdia driver
#include <linux/kernel.h> in userspace program and it does not make your program a derivative of kernel but it's not Ok to do #include <linux/kernel.h> in your module because it does make you module a derivative of kernel”, because, you see, these lines are identical and if you have no formal grant in writing which exludes one yet permits another then you'll need to prove that they, indeed, are materially different.
This sound like the nvdia driver