linux-kernel - Re: incorrect taint of ndiswrapper

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20061025213355.GG23256@vasa.acc.umu.se>
Date:	Wed, 25 Oct 2006 23:33:55 +0200
From:	David Weinehall <tao@....umu.se>
To:	Pavel Roskin <proski@....org>
Cc:	Alan Cox <alan@...rguk.ukuu.org.uk>, linux-kernel@...r.kernel.org
Subject: Re: incorrect taint of ndiswrapper

On Wed, Oct 25, 2006 at 05:06:32PM -0400, Pavel Roskin wrote:
> On Wed, 2006-10-25 at 21:30 +0100, Alan Cox wrote:
> > Ar Mer, 2006-10-25 am 16:11 -0400, ysgrifennodd Pavel Roskin:
> > > I don't see any legal reasons behind this restriction.  A driver under
> > > GPL should be able to use any exported symbols.  EXPORT_SYMBOL_GPL is a
> > > technical mechanism of enforcing GPL against non-free code, but
> > > ndiswrapper is free.  The non-free NDIS drivers are not using those
> > > symbols.
> > 
> > The combination of GPL wrapper and the NDIS driver as a work is not free
> > (in fact its questionable if its even legal to ship such a combination
> > together).
> 
> So, the problem is on the legal side.
> 
> But I have to ask - which NDIS driver?  I can write a free NDIS driver
> and use it with ndiswrapper.  You can say it's a stupid thing to do, but
> once you talk about the legality, the only argument should be
> legal/illegal.  Besides, it may be a not such a bad idea for a ReactOS
> developer writing a ReactOS driver to test it with Linux.
> 
> Also, nothing should prevent me from combining ndiswrapper with any
> Windows driver in the privacy of my home as long as I don't distribute
> anything.  GPL doesn't have use restrictions (although the driver may
> have an EULA).
> 
> Since the problem is with USB symbols, I can split the USB part from
> ndiswrapper and call it ndiswrapper-usb.  Then ndiswrapper-usb will be
> calling the GPL-only symbols while ndiswrapper will be loading the
> non-free modules.  Good luck catching that!  It's actually a change that
> makes sense technically.  Imagine what a change specifically intended to
> fool Linux would do!
> 
> I don't see how the kernel can detect the cases where GPL is actually
> violated without creating problem for honest users.  Kernel code is not
> a police department, let alone a court of law.  Let's not create out own
> DRM right in the kernel!
> 
> Companies that ship ndiswrapper with non-free modules may be breaking
> copyright laws already.  But it's not something that should be fought by
> kernel patches.

No matter how the legal situation looks like: do we *want* to support
drivers that use an API totally alien to Linux concepts?

Personally I feel that no matter if they are legal or not, we should not
cater to such drivers in the first place.  If it's trickier to use
Windows API-drivers under Linux than to write a native Linux driver,
big deal...  We don't want Windows-drivers.  We want native drivers.


Regards: David Weinehall
-- 
 /) David Weinehall <tao@....umu.se> /) Northern lights wander      (\
//  Maintainer of the v2.0 kernel   //  Dance across the winter sky //
\)  http://www.acc.umu.se/~tao/    (/   Full colour fire           (/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/