Kernel source

Bryan J. Smith b.j.smith at ieee.org
Mon Apr 17 14:58:23 UTC 2006


Arjan van de Ven <arjan at fenrus.demon.nl> wrote:
> but ndiswrapper isn't static linked

Are you sure about that?  Just because it uses external object code
doesn't mean it's dynamically linked.

And even if it's dynamically linked, that does _not_ address the GPL
issue.

> atheros IS a problem.

And so is the FCC.  Get over it.
And so is IP in general.  Get over it.

Furthermore, it is impossible to write any OpenGL driver these days
without infringing on IP.  Luckily, Xorg is MIT licensed and doesn't
fall under the GPL.

Unfortunately, some of the crucial IP used in the kernel-memory
management is someone's IP (largely Intel).  So ATI and nVidia can
choose to:  
A)  [GPL] Don't implement anything (which Intel itself does)
B)  [GPL]Implement a Linux-specific, non-infringing, cleanroom module
(if possible or feasible)
C)  [GPL + non-derived] Build a GPL wrapper around non-Linux object
code
D)  [non-GPL] Build a Linux-specific, GPL infringing module

I have not personally verified if "C" is what nVidia does.  Many
people I know in the industry says "C" is what nVidia has done, now
that they've GPL'd their AGPgart (thanx to Intel no longer enforcing
IP on that).  But it could be "D".

Have no idea what ATI does.

> For static linking to GPL? I've not even found a single lawyer who
> thinks there is a gray area there. Dynamic linking to the kernel..
> yes.  But not static linking.

Ummm, last time I checked, "static v. dynamic" _only_ matters in the
LGPL, _not_ the GPL.  I've followed much of the litigation on this
matter.  IANAL, but it's not about "static v. dynamic" but whether or
not it is a _derived_work_!

Something is _not_ a "derived work," according to Linus himself, if
it runs on another OS _unmodified_ in binary form.

> actually the test here is not "derived work". Derived work matters
> for clause 3 but not for clause 2. That's where there is a
> difference between static and dynamic linking. Static linking 
> doesn't "need" the derived work part.

Again, I think you have the GPL v. LGPL confused.

Furthermore, what's the difference if you have kernel (GPL) + module
ndiswrapper (GPL) + NDIS driver (non-GPL) and kernel (GPL) + module
whatever (non-GPL).  Is that not "dynamically linked" too?!?!?!

> And there is a gray area on at what point something stops being for
> another OS... like how much are you allowed to change/add in other
> code (and mind you, the "glue layer" then cannot be GPL or you 
> violate clause 2 again, so if your glue layer is derived you have
> lost again anyway)

Really?  Then doesn't that prevent NDIS wrapper too?!



-- 
Bryan J. Smith   Professional, Technical Annoyance
b.j.smith at ieee.org    http://thebs413.blogspot.com
--------------------------------------------------
I'm a Democrat.  No wait, I'm a Republican.  Hmm,
it seems I'm just whatever someone disagrees with.




More information about the amd64-list mailing list