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 for Android: free password hash cracker in your pocket

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

Date:	Fri, 16 Feb 2007 03:19:49 -0500
From:	Valdis.Kletnieks@...edu
To:	"linux-os (Dick Johnson)" <linux-os@...logic.com>
Cc:	Manu Abraham <abraham.manu@...il.com>,
	Mws <mws@...sted-brains.org>, v j <vj.linux@...il.com>,
	linux-kernel@...r.kernel.org
Subject: Re: GPL vs non-GPL device drivers

On Thu, 15 Feb 2007 09:32:30 EST, "linux-os (Dick Johnson)" said:
> There are a lot of device drivers that will never make it into the
> mainline kernel because they are for one-of-a-kind devices or boards
> that companies embed into their products. Nobody would even want a
> copy of the software to interface with something that they would
> never even have. When Version 2.6 started, it became necessary to
> use special tools and procedures to compile a module that was not
> inside the mainline kernel. However, it was still quite easy. Recently,
> somebody, apparently with an advanced degree in obfuscation, has made
> that more difficult. This is abuse, pure and simple. That, in my
> opinion, is one of the major reasons why people who use Linux in
> embedded systems end up using very old versions.

Actually, the *real* reason embedded systems end up using old versions is
much simpler.

They start developing their code on release 2.X.Y, and they keep their code
out-of-tree.  Then, when they come up for air, and it's at 2.X.(Y+15), they
discover that we weren't kidding when we shipped stable_api_nonsense.txt,
and since their code isn't in the tree, they have to do all the API cleanup
themselves, because no flock of nit-picking kernel janitor monkeys swarmed
over their code and magically fixed it up for them.

And unless Y+15 has some *very* compelling reasons to move forward, just
sticking at Y suddenly starts looking very good, because watching somebody
else's kernel janitor monkeys fix your code is fairly cheap, but paying your
own kernel janitor monkeys gets expensive really fast....

Content of type "application/pgp-signature" skipped