From: Greg KH
Subject: [ANNOUNCE] Position Statement on Linux Kernel Modules
Date: Jun 22, 10:01 pm 2008

Hi,

As part of the Linux Foundation Technical board, we confront the issue
of closed source Linux kernel modules all the time, and we wanted to do
something that could be seen as a general "public statement" about them
that is easy to understand and point to when people have questions.

So, after working on this for a while, and asking some of the other
major contributors and maintainers of the kernel, what we have is below.

There is also a site at:
	http://www.linuxfoundation.org/en/Device_driver_statement
that contains a link to a statement from the Linux Foundation about this
topic, as well as some more descriptions and background information, and
a copy of the full statement as well.

I've also put a pretty pdf version at:
	http://www.kernel.org/pub/linux/kernel/people/gregkh/lkm_position_statement/lkm_pos_st...
in case people want to print it out :)

If there are any kernel developers who want to add their names to this
statement, please let me know by private email and I will be glad to add
it.

thanks,

greg k-h

------------------------------

Position Statement on Linux Kernel Modules
June 2008

We, the undersigned Linux kernel developers, consider any closed-source
Linux kernel module or driver to be harmful and undesirable.  We have
repeatedly found them to be detrimental to Linux users, businesses, and
the greater Linux ecosystem.  Such modules negate the openness,
stability, flexibility, and maintainability of the Linux development
model and shut their users off from the expertise of the Linux
community.  Vendors that provide closed-source kernel modules force
their customers to give up key Linux advantages or choose new vendors.
Therefore, in order to take full advantage of the cost savings and
shared support benefits open source has to offer, we urge vendors to
adopt a policy of supporting their customers on Linux with open-source
kernel code.

We speak only for ourselves, and not for any company we might work for
today, have in the past, or will in the future.

	Dave Airlie
	Jens Axboe
	Ralf Baechle
	Arnd Bergmann
	Vitaly Bordug
	James Bottomley
	Josh Boyer
	Neil Brown
	Mark Brown
	David Brownell
	Michael Buesch
	Franck Bui-Huu
	Adrian Bunk
	Ralph Campbell
	Mauro Carvalho Chehab
	Denis Cheng
	Jonathan Corbet
	Glauber Costa
	Alan Cox
	Magnus Damm
	Ahmed S. Darwish
	Robert P. J. Day
	Helge Deller
	Jean Delvare
	Mathieu Desnoyers
	Alexey Dobriyan
	Daniel Drake
	Alex Dubov
	Randy Dunlap
	Michael Ellerman
	Jan Engelhardt
	Mark Fasheh
	J. Bruce Fields
	Larry Finger
	Jeremy Fitzhardinge
	Mike Frysinger
	Kumar Gala
	Robin Getz
	Liam Girdwood
	Thomas Gleixner
	Brice Goglin
	Cyrill Gorcunov
	Andy Gospodarek
	Thomas Graf
	Harvey Harrison
	Stephen Hemminger
	Michael Hennerich
	Tejun Heo
	Benjamin Herrenschmidt
	Kristian Høgsberg
	Henrique de Moraes Holschuh
	Marcel Holtmann
	Mike Isely
	Takashi Iwai
	Olof Johansson
	Dave Jones
	Jesper Juhl
	Matthias Kaehlcke
	Kenji Kaneshige
	Jan Kara
	Jeremy Kerr
	Russell King
	Olaf Kirch
	Roel Kluin
	Hans-JÃŒrgen Koch
	Auke Kok
	Jiri Kosina
	Mariusz Kozlowski
	Greg Kroah-Hartman
	Michael Krufky
	Aneesh Kumar
	Clemens Ladisch
	Christoph Lameter
	Grant Likely
	John W. Linville
	Yinghai Lu
	Tony Luck
	Pavel Machek
	Matt Mackall
	Roland McGrath
	Patrick McHardy
	Kyle McMartin
	Paul Menage
	Thierry Merle
	Eric Miao
	Akinobu Mita
	Ingo Molnar
	Andrew Morton
	Paul Mundt
	Oleg Nesterov
	Luca Olivetti
	Pierre Ossman
	Venkatesh Pallipadi
	Nick Piggin
	Nicolas Pitre
	Richard Purdie
	Mike Rapoport
	Sam Ravnborg
	Gerrit Renker
	Stefan Richter
	David Rientjes
	Stefan Roese
	Francois Romieu
	Stephen Rothwell
	Maciej W. Rozycki
	Mark Salyzyn
	Yoshinori Sato
	Holger Schurig
	Yoshihiro Shimoda
	Sergei Shtylyov
	Kay Sievers
	Alexey Starikovskiy
	Alan Stern
	Hirokazu Takata
	Eliezer Tamir
	Doug Thompson
	FUJITA Tomonori
	Dmitry Torokhov
	Marcelo Tosatti
	Steven Toth
	Theodore Tso
	Geert Uytterhoeven
	Arjan van de Ven
	Ivo van Doorn
	Wim Van Sebroeck
	Hans Verkuil
	Anton Vorontsov
	Daniel Walker
	Dan J. Williams
	Darrick J. Wong
	David Woodhouse
	Chris Wright
	Bryan Wu
	Rafael J. Wysocki
	Herbert Xu
	Vlad Yasevich
	Peter Zijlstra
	Bartlomiej Zolnierkiewicz

--

From: Greg Louis
Subject: Re: [ANNOUNCE] Position Statement on Linux Kernel Modules
Date: Jun 23, 4:29 am 2008

On 20080622 (Sun) at 2201:18 -0700, Greg KH wrote:
> 
> If there are any kernel developers who want to add their names to this
> statement, please let me know by private email and I will be glad to add
> it.
> 
> Position Statement on Linux Kernel Modules
> June 2008
> 
> We, the undersigned Linux kernel developers...

Do you think it might be a good idea to start a similar list, in the
form of a petition to manufacturers, for end users?  The hope would be
that the number of petitioners grow big enough to let us effectively
rebut the argument that nobody outside the developer community really
cares.

(Of course, the best way to rebut that argument would be for end-users
to vote with their feet, but for a lot of us, me included, that's not a
practical option.)

-- 
| G r e g  L o u i s         | gpg public key:         0x6D9E3E64 |
|  http://www.bgl.nu/~glouis |   (on my website or any keyserver) |
--


From: Willy Tarreau
Subject: Re: [ANNOUNCE] Position Statement on Linux Kernel Modules
Date: Jun 23, 6:09 am 2008

On Mon, Jun 23, 2008 at 07:29:34AM -0400, Greg Louis wrote:
> On 20080622 (Sun) at 2201:18 -0700, Greg KH wrote:
> > 
> > If there are any kernel developers who want to add their names to this
> > statement, please let me know by private email and I will be glad to add
> > it.
> > 
> > Position Statement on Linux Kernel Modules
> > June 2008
> > 
> > We, the undersigned Linux kernel developers...
> 
> Do you think it might be a good idea to start a similar list, in the
> form of a petition to manufacturers, for end users?  The hope would be
> that the number of petitioners grow big enough to let us effectively
> rebut the argument that nobody outside the developer community really
> cares.
>
> (Of course, the best way to rebut that argument would be for end-users
> to vote with their feet, but for a lot of us, me included, that's not a
> practical option.)

The problem is exactly what you describe in your last sentence. Hardware
manufacturers are well aware of that and make no effort to provide correct
drivers when they (think they) have a monopoly in certain areas.

What would be needed would be a public list of alternative hardware for
known existing hardware. When big manufacturers will see their hardware
listed there in the "bad" column, with their small competitors on the
same line in the "good" column and with a lower price, they may start
to think a little bit. Also, small manufacturers could use this for
marketting purposes, because they would be listed as direct competitors
for other well-established products.

It should be made with notebooks too. It's a shame to see how you're
nearly forced to have an nvidia graphics card in a notebook nowadays.
It is needed to put a bad reputation to products which embed closed
hardware, and to give a good one to other ones.

If such a list is exhaustive and public, it may become a reference for
new buyers.

Willy

--

From: Matthew
Subject: Re: [ANNOUNCE] Position Statement on Linux Kernel Modules
Date: Jun 23, 6:02 am 2008

Hi Greg,

I largely agree to this statement,

there are however some downsides if you're preventing driver
manufacturers (e.g. nvidia, ...) from the possibility to offer their
customers proprietary drivers:

1) One big and important point for me (and more and more future
linux-users) is powersaving features on GPUs like powermizer (by
nvidia) and powerplay (by AMD/ATI) or other hardware. I haven't seen
this working on newer graphics cards models with the opensource
drivers to the present day :(

Take an example with laptops: where with the proprietary drivers it is
possible to work 6 hours of uptime, you'll only get 1.5 hours of
battery time on laptops; additionally / or on desktops you'll be
getting a fan which will always run on the highest velocity,
considering the big generation of heat on your lap and you're getting
a very uncomfortable work device.
Isn't this also at odds with the green direction linux is heading
towards right now?

This surely also applies to manufacturers of future linux-powered
devices such as handsets (cell phones), routers, etc etc
if those companies can't use their own closed proprietary drivers
utilizing patented routines they are "forced" to use, they might think
over it and switch to another operating system ...

2) How will this affect performance, if all of those drivers are
limited to an user-space interface?

I'm not a kernel hacker and don't have much insight into the kernel
and kernel-development, so I can only reflect, what I've read:
much of you kernel hackers are supposed to have said (read that on
blogs, forums etc.) that nvidia's drivers are hackish and that it uses
routines which shouldn't be used by this kind of drivers

other voices are saying nvidia is doing this because the linux-kernel
lacks a common interface (yet) which disallows effective usage of the
graphics cards which would result in abysmal bad performance not using
their hacking ...

so perhaps sitting together with those companies and creating such an
effective interface might be the solution ? :)

3) I know that desktop users are not THAT important for you (linux is
mainly oriented towards industrial usage)
but think of the desktop users as of additional testers and potential
new kernel-hackers which would one day work for the common good
(having great new ideas, e.g. filesystems, io-schedulers, etc etc)
preventing those users/future developers from using their (needed)
devices will drive them away from using GNU/Linux and also those young
talented minds, those drivers are "necessary evil", after all

4) We should never forget who / what allowed this kind of development
and openness: the GPL, GNU and Richard Stallman, Linus Torvalds (only
to name a few)

We are deeply obliged to ensure this freedom in development and usage,
this however shouldn't go that far to prevent users of the code to
combine with it what they need to

This were just a few of the feelings floating in my head after having
read your position statement,

you're heading towards the right direction but please, please don't
forget the community, after all :)

this is about ideology to a big fraction, yes, but we shouldn't forget
the freedom after all

Thanks,

Regards,

Mat
--


From: Willy Tarreau
Subject: Re: [ANNOUNCE] Position Statement on Linux Kernel Modules
Date: Jun 23, 6:21 am 2008

On Mon, Jun 23, 2008 at 03:02:58PM +0200, Matthew wrote:
> Hi Greg,
> 
> I largely agree to this statement,
> 
> there are however some downsides if you're preventing driver
> manufacturers (e.g. nvidia, ...) from the possibility to offer their
> customers proprietary drivers:
> 
> 1) One big and important point for me (and more and more future
> linux-users) is powersaving features on GPUs like powermizer (by
> nvidia) and powerplay (by AMD/ATI) or other hardware. I haven't seen
> this working on newer graphics cards models with the opensource
> drivers to the present day :(

I think that's one of the reasons of Greg's post.

(...)
> if those companies can't use their own closed proprietary drivers
> utilizing patented routines they are "forced" to use

You're wrong here. If they have patented routines, they don't need
their drivers to be closed, since there routines are protected by
patents. And even if they are not patented, not releasing the source
will not prevent a competitor from disassembling the code anyway.
So there's really no point in remaining closed. Some of them might
have signed NDAs before using some technologies, but by this time,
they should have sorted that our.

> they might think over it and switch to another operating system ...

Do you know many products with closed Linux drivers which are not
supported by at least one closed OS ? If they chose to support
Linux, it's not for your pleasure, just because they know they will
sell 5-10% more when a penguin is stuck on the box.

> 2) How will this affect performance, if all of those drivers are
> limited to an user-space interface?
> 
> I'm not a kernel hacker and don't have much insight into the kernel
> and kernel-development, so I can only reflect, what I've read:
> much of you kernel hackers are supposed to have said (read that on
> blogs, forums etc.) that nvidia's drivers are hackish and that it uses
> routines which shouldn't be used by this kind of drivers
> 
> other voices are saying nvidia is doing this because the linux-kernel
> lacks a common interface (yet) which disallows effective usage of the
> graphics cards which would result in abysmal bad performance not using
> their hacking ...

That has nothing to do with open/close. They may as well continue to
use their dirty hacks when the sources are public. That just means that
owners of such cards on other platforms (PPC, etc...) might be able to
build the drivers for those platforms. I think that most users don't
care about the fact that a driver is dirty. They want something which
simply builds for their platform. Also, publishing their dirty hacks
will encourage kernel developers to propose some cleaner alternatives
or to extend the kernel in order to ease integration of such drivers.

Willy

--