linux-kernel - Re: [GIT PATCH] more Driver core patches for 2.6.19

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: <f2b55d220612131420l5f956e05qb10ef233670fb588@mail.gmail.com>
Date:	Wed, 13 Dec 2006 14:20:35 -0800
From:	"Michael K. Edwards" <medwards.linux@...il.com>
To:	"Andrew Morton" <akpm@...l.org>
Cc:	"Martin Bligh" <mbligh@...igh.org>, "Greg KH" <gregkh@...e.de>,
	"Linus Torvalds" <torvalds@...l.org>, linux-kernel@...r.kernel.org
Subject: Re: [GIT PATCH] more Driver core patches for 2.6.19

On 12/13/06, Andrew Morton <akpm@...l.org> wrote:
> On Wed, 13 Dec 2006 13:32:50 -0800
> Martin Bligh <mbligh@...igh.org> wrote:
>
> > So let's come out and ban binary modules, rather than pussyfooting
> > around, if that's what we actually want to do.
>
> Give people 12 months warning (time to work out what they're going to do,
> talk with the legal dept, etc) then make the kernel load only GPL-tagged
> modules.

IIRC, Linus has deliberately and explicitly estopped himself from
claiming that loading a binary-only driver is a GPL violation.  Do you
really want to create an arbitrage opportunity for intermediaries who
undo technical measures that don't match Linus's declared policy or,
in many people's opinion, the law in at least some jurisdictions?
(I'm not going to go all amateur-lawyer on you, but the transcript of
oral argument at the Supreme Court level in Lotus v. Borland makes
really interesting reading no matter where you live or what your
stance is on GPL-and-linking.)

> I think I'd favour that.  It would aid those people who are trying to
> obtain device specs, and who are persuading organisations to GPL their drivers.

I don't think it would.  There is a strong argument that GPL drivers
in the mainline kernel are a good idea on technical and business
grounds.  Making a federal case out of it is a distraction at best.

There is a widespread delusion that closed driver code is an asset in
an accounting sense.  It costs a lot of money to create and even more
to maintain in any kind of usable condition.  As long as managers of
chip development projects get away with shifting some of the real cost
of creating yet another buggy undocumented one-off CPU interface onto
a "software" team in a different cost center, the pressure to label
the code base an intangible asset is overwhelming.  It usually takes a
reorg or two to diffuse the responsibility enough to call it a sunk
cost, at which point someone might be brave enough to argue that
opening it up would save money and/or sell more chips.

As things stand, there is a slippery slope (in a good way) from a
totally-closed, one-off, buggy vendor driver to a GPL'ed driver in the
mainline kernel.  Customers get impatient for drivers that work, the
vendor allows a customer or a mutually acceptable third party to work
on the code, the sky doesn't fall.  There are some situations where
the business strategy of keeping the driver closed is defensible on
both engineering and regulatory/barrier-to-entry grounds, but they're
fairly rare; and some fraction of vendors come around to that view in
time.

> (Whereas the patch which is proposed in this thread hinders those people)

There we agree.

Cheers,
- Michael
-
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/