linux-kernel - Re: GPL vs non-GPL device drivers

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]

Date:	Wed, 21 Feb 2007 13:45:55 +0100
From:	Helge Hafting <helge.hafting@...el.hist.no>
To:	Helge Hafting <helge.hafting@...el.hist.no>,
	v j <vj.linux@...il.com>, davids@...master.com,
	trent.waddington@...il.com,
	"Michael K. Edwards" <medwards.linux@...il.com>,
	"Linux-Kernel@...r. Kernel. Org" <linux-kernel@...r.kernel.org>,
	Neil Brown <neilb@...e.de>
Subject: Re: GPL vs non-GPL device drivers

Jan-Benedict Glaw wrote:
> On Tue, 2007-02-20 15:36:56 +0100, Helge Hafting <helge.hafting@...el.hist.no> wrote:
>   
>> If you have a need for "secret" source code, stuff most of it
>> in userspace.  Make the drivers truly minimal; perhaps their
>> open/closed status won't matter that much when the bulk
>> of the code and the cleverness is kept safe in userspace.
>>
>> Note that keeping drivers small this way is the recommended
>> way of working anyway. It isn't merely a way to keep your
>> code away from the GPL - you always want a small kernel.
>>     
>
> Keeping the legal stuff out of sight for a second, this'll solve the
> "problem" for the embedded developer, but surely not for the Linux
> community. Would you ever expect that eg. the thin GPL layer used by
> ATI/NVidia would be merged iff the rest would run in userland?
>   
A thin layer - no.  To get merged, a driver would have to
be of good quality.  I didn't think like that - I was thinking of
embedded developers that sometimes implement the
entire embedded application inside their device driver.

Which is crazy from a linux design standpoint, but sometimes
reasonable for an embedded developer when the sole purpose of
the embedded computer is to control the single "device" and
perhaps a little display with a couple of buttons.
The "app" part might not be that much
bigger than the device driver itself - it is then tempting to
cut some corners and put all in one place.

Of course this kind of "driver" ends up containing everything,
and nobody wants to GPL that.  Separating driver and app(s)
properly lets them keep a proprietary app, and a driver or two
that might be small and simple enough to be released.
> It's just a workaround for the
> linking-the-object-file-into-the-kernel-image problem, but after all,
> it doesn't lead to a working driver being freely available.
>
> MfG, JBG

Good point.  Fortunately, most devices are much simpler than
a card with accelerated 3D-graphichs.

Helge Hafting




-
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/