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 ...
[ message continues ]

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

--

I have no objection if anyone wishes to start such a list, just that I

don't want to do it myself :)
thanks,
greg k-h

--

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

That is Utopian, I fear.  For example, what notebook supports the

installation of alternative hardware?  Go to another notebook, you

suggest?  Easy said: when I was buying the machine on which this is

being written, the choice of notebooks with 1920x1200 displays (a sine

qua non as far as I was concerned) was _extremely_ limited.  (There

actually was an open-source driver for the video of the one I picked,

but I could never get it to work.)  Similar difficulties exist for a

lot of special-purpose hardware; viable alternatives are rare.  Your

proposed list could certainly help ferret out such rarities, but I

doubt that it would suffice to make the problem go away.  I suspect,

too, that it would be a beast to maintain, given the need to track all

the features of all the versions of all the hardware items that were

listed.
Then again, my proposed list (a parallel to Greg KH's developer list,

but for end-users) probably wouldn't suffice either.  But it would be

relatively easy to create, and if it got big enough, and if some

manufacturers were hesitating about going open-source, it might tip a

scale or two.
In another message on this list, Greg KH says he has no objection to my

proposal but doesn't want to do it himself (a reasonable position given

the workload he's carrying already).  I'll try to set something up and

will ANNOUNCE it here if I succeed.
--

| G r e g  L o u i s         | gpg public key:         0x6D9E3E64 |

|  http://www.bgl.nu/~glouis |   (on my website or any keyserver) |

--

Yet, in non-mobile platforms, alternative hardware is sometimes an

option, and so the suggestion does have utility.  But it's use goes

beyond those situations, as it engenders a new mindset amongst

manufacturers, a mindset in which they have to play by our rules or lose

market share, and once they start doing that they'll find there's no

reason not to keep doing it.  Then, even mobile platforms will have a

full set of open drivers.
So I think a public list of alternative hardware is an excellent suggestion.

--

Just a sidenote: It would probably be nice to have this linked from the

main LF page (News?), I don't seem to see it there ... ?
Thanks,
--

Jiri Kosina

SUSE Labs
--

Yes, for some reason it hasn't shown up there, I don't know why.  I've

pinged them about this, but they might not be awake just yet :)
thanks,
greg k-h

--