Plugging into GCC
Plugging into GCC
Posted Oct 4, 2008 21:44 UTC (Sat) by chromatic (guest, #26207)In reply to: Plugging into GCC by drag
Parent article: Plugging into GCC
Posted Oct 5, 2008 7:39 UTC (Sun)
by khim (subscriber, #9252)
[Link] (2 responses)
This is real-world proof of successfull circunvention: nVidia is
clearly in the clear here. No one ever said otherwise. Why?
Simple: they distribute this "binary blob" as two parts: big closed-source
driver and "public domain" glue code. The driver itself is not in violation
of copyrights: it's not a derived work since the same blob can be used, for
example, in Windows driver. Nothing Linux-specific there. Glue code
is probably a derivative work of the Linux kernel, but... it's distributed
without ANY restrictions and so is GPL-compliant. The real
toxic thing is actual loadable kernel module - but nVidia does not
distribute that (Canonical does), so nVidia is in the clear... The tiny amount of doubt remains: are binary blob and glue code really
separate works? Court will decide but since both were created by nVidia
problems in the interface (which can lead to derivativennes) are easy to
fix...
Posted Oct 5, 2008 12:34 UTC (Sun)
by paulj (subscriber, #341)
[Link] (1 responses)
What's the evidence for this btw? I know it's the generally accepted view, but what evidence is there for it, besides NVidias' confidence in being able to distribute this driver and the circumstantial evidence of some "looks like Windows programming style" symbol names? Is there any real independent evidence for this belief, or is being taken on trust?
Posted Oct 5, 2008 12:44 UTC (Sun)
by khim (subscriber, #9252)
[Link]
Actually I think this blob differs slightly from what they ship in Windows driver. And I'm pretty sure even nVidia does not have Windows driver which uses this blob - but apparently they believe they can create such driver if court demands this. Realistically I do not expect deception here: if you have driver for Windows it's much easier to introduce glue code which will take it more-or-less unmodified then it's to create Linux-native driver. Think NDISwrapper. Linux developers will NEVER accept such driver in mainline - but this is not an issue for nVidia... Thus I'm pretty sure nVidia's blob IS what they have used for Windows driver - plus few small modifications here and there. Probably not enough to qualify as derivative of Linux kernel. And since the only reliable way to know (via court) is quite expensive... nobody bothers to actually check. Basically it all boils down the following three-step thought process:
Have you actually looked on what nVidia REALLY distributes?
This question is most interesting when considering NVIDIA's
binary blob kernel module
Have you actually looked on what nVidia REALLY distributes?
it's not a derived work since the same blob can be used, for example, in Windows driver. Nothing Linux-specific there.
No evidence. And it's probably not even true :-)
1. It's easier to keep this blob as separate non-derivative work (then you can ship the same code for Windows and Linux and save on Q&A).
2. They are legally required to keep it in non-derivative state.
3. If it's both easier and required - then why nVidia will do it in any other way?