From: Greg KH <greg@...>
Subject: [ANNOUNCE] Position Statement on Linux Kernel Modules
Date: Jun 23, 1:01 am 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_statem...

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 <glouis@...>
Subject: Re: [ANNOUNCE] Position Statement on Linux Kernel Modules
Date: Jun 23, 7: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 <w@...>
Subject: Re: [ANNOUNCE] Position Statement on Linux Kernel Modules
Date: Jun 23, 9: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 <jackdachef@...>
Subject: Re: [ANNOUNCE] Position Statement on Linux Kernel Modules
Date: Jun 23, 9: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 <w@...>
Subject: Re: [ANNOUNCE] Position Statement on Linux Kernel Modules
Date: Jun 23, 9: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
--