[ANNOUNCE] Position Statement on Linux Kernel Modules

[ANNOUNCE] Position Statement on Linux Kernel Modules

[Greg KH]

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_statement.pdf
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

Re: [ANNOUNCE] Position Statement on Linux Kernel Modules

[Jiri Kosina]

On Sun, 22 Jun 2008, Greg KH wrote:

> 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

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

Re: [ANNOUNCE] Position Statement on Linux Kernel Modules

[Greg Louis]

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

Re: [ANNOUNCE] Position Statement on Linux Kernel Modules

[Matthew]

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

Re: [ANNOUNCE] Position Statement on Linux Kernel Modules

[Willy Tarreau]

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

Re: [ANNOUNCE] Position Statement on Linux Kernel Modules

[Willy Tarreau]

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

Re: [ANNOUNCE] Position Statement on Linux Kernel Modules

[Greg KH]

On Mon, Jun 23, 2008 at 12:00:02PM +0200, Jiri Kosina wrote:
> On Sun, 22 Jun 2008, Greg KH wrote:
>
>> 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
>
> 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 ... ?

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

Re: [ANNOUNCE] Position Statement on Linux Kernel Modules

[Greg KH]

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:

This statement is not "preventing" anything, it is merely stating the
fact that a very large number of Linux kernel developers feel that
closed source Linux kernel modules are harmful for users, companies, and
the Linux kernel community overall.

thanks,

greg k-h

Re: [ANNOUNCE] Position Statement on Linux Kernel Modules

[Greg KH]

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.

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

Re: [ANNOUNCE] Position Statement on Linux Kernel Modules

[Måns Rullgård]

Greg KH <greg@kroah.com> writes:

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

> [...]

I can't help noticing Linus Torvalds is missing from the list of
names...

-- 
Måns Rullgård
mans@mansr.com

Re: [ANNOUNCE] Position Statement on Linux Kernel Modules

[Greg Louis]

Willy Tarreau wrote:

> > (Of course, the best way to rebut that argument [ that outside the
> > developer community, nobody cares whether drivers are proprietary ]
> > 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.
...
> 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) |

Re: [ANNOUNCE] Position Statement on Linux Kernel Modules

[David Newall]

Greg Louis wrote:
> Willy Tarreau wrote
>>> (Of course, the best way to rebut that argument [ that outside the
>>> developer community, nobody cares whether drivers are proprietary ]
>>> 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.
>
> That is Utopian, I fear.  For example, what notebook supports the
> installation of alternative hardware?

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.

Re: [ANNOUNCE] Position Statement on Linux Kernel Modules

[jdow]

From: "Willy Tarreau" <w@1wt.eu>
Sent: Monday, 2008, June 23 06:21


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

Willy, you make a bold assertion here. Your assertion would hold a
lot more weight if you defended it with some facts.

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

That is why there are the closed, and flakey, drivers for so many
products. Rather than make ideological assertions sit down and prove
your points. Address cases where there is an intellectual property
holder involved who has chosen Trade Secret rather than Patent as a
protection on their proprietary code. Show how they will stay in
business if they give away their code. Presume that their modules are
in clean enough shape that making money with a profitable service desk
is not going to fly.

> Willy

{^_^}   Jo

Re: [ANNOUNCE] Position Statement on Linux Kernel Modules

[Willy Tarreau]

On Wed, Jun 25, 2008 at 03:45:01PM -0700, jdow wrote:
> From: "Willy Tarreau" <w@1wt.eu>
> Sent: Monday, 2008, June 23 06:21
> 
> 
> >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.
> 
> Willy, you make a bold assertion here. Your assertion would hold a
> lot more weight if you defended it with some facts.
> 
> >>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.
> 
> That is why there are the closed, and flakey, drivers for so many
> products. Rather than make ideological assertions sit down and prove
> your points. Address cases where there is an intellectual property
> holder involved who has chosen Trade Secret rather than Patent as a
> protection on their proprietary code. Show how they will stay in
> business if they give away their code.

Your statements clearly indicate that you have never worked yet and
are slowly discovering the business world. I would like to return
the challenge to you : show me one software company still in business
and making profit who has not set a few patents on (provably obvious)
methods they rely on. Trade secrets don't work anymore because once
discovered, you're attacked by their patent holder (since everything
is patented in this crappy world).

There are no trade secrets in software, everything is disassemblable
and decompilable. There are no trade secrets in hardware. Chips get
acid-washed, photographed, recomposed and decompiled every day. Trying
to hide a hardware trade secret inside a binary driver is completely
silly and useless.

> Presume that their modules are
> in clean enough shape that making money with a profitable service desk
> is not going to fly.

Releasing source costs less than maintaining and releasing binaries for
every version of every distro.

However, what *does* happen is that some editors don't want to see
their sources released as GPL or BSD and get stolen^Wcleaned up by
someone who pretends to provide a clean rewrite by playing cut'n'paste.
But I don't think it is a real problem in the driver world. Once the
driver gets merged, it's on the rails.

Willy

Re: [ANNOUNCE] Position Statement on Linux Kernel Modules

[jdow]

From: "Willy Tarreau" <w@1wt.eu>
Sent: Wednesday, 2008, June 25 16:11


> On Wed, Jun 25, 2008 at 03:45:01PM -0700, jdow wrote:
>> From: "Willy Tarreau" <w@1wt.eu>
>> Sent: Monday, 2008, June 23 06:21
>> 
>> 
>> >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.
>> 
>> Willy, you make a bold assertion here. Your assertion would hold a
>> lot more weight if you defended it with some facts.
>> 
>> >>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.
>> 
>> That is why there are the closed, and flakey, drivers for so many
>> products. Rather than make ideological assertions sit down and prove
>> your points. Address cases where there is an intellectual property
>> holder involved who has chosen Trade Secret rather than Patent as a
>> protection on their proprietary code. Show how they will stay in
>> business if they give away their code.
> 
> Your statements clearly indicate that you have never worked yet and
> are slowly discovering the business world. I would like to return
> the challenge to you : show me one software company still in business
> and making profit who has not set a few patents on (provably obvious)
> methods they rely on. Trade secrets don't work anymore because once
> discovered, you're attacked by their patent holder (since everything
> is patented in this crappy world).
> 
> There are no trade secrets in software, everything is disassemblable
> and decompilable. There are no trade secrets in hardware. Chips get
> acid-washed, photographed, recomposed and decompiled every day. Trying
> to hide a hardware trade secret inside a binary driver is completely
> silly and useless.
> 
>> Presume that their modules are
>> in clean enough shape that making money with a profitable service desk
>> is not going to fly.
> 
> Releasing source costs less than maintaining and releasing binaries for
> every version of every distro.
> 
> However, what *does* happen is that some editors don't want to see
> their sources released as GPL or BSD and get stolen^Wcleaned up by
> someone who pretends to provide a clean rewrite by playing cut'n'paste.
> But I don't think it is a real problem in the driver world. Once the
> driver gets merged, it's on the rails.

I'll bet I am older than you, perhaps by a factor of two, from your
rhetoric.

Yes, chips get decompiled and then the instructions that run on the
chips get decompiled. The time it takes to do that is the period that
the trade secret holds. I don't think that any of the chip manufacturers
for widgets that have proprietary drivers are building in hard protection
of the chip's features, yet. So I'll give you that scenario. But I note
that it is not a low man hours proposition. The time would probably be
better spent building upon the hardware you already have.  If it wasn't
then nVidia and ATI would be running on the same GPUs.

(For the record I have been involved with chips that "resist" efforts to
figure out what is on them. Once wrapped in their "box" efforts to take
them apart were supposed to effectively destroy the chip such that the
code stored on it was not going to be readable. It was a little GPS
receiver encryption tool in the 80s.)

{^,^}   Joanne formally sticks her tongue out at you for your patronizing
        air. Religious zealots are tiresome.