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
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
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) |
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
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
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
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
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
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
Greg KH <[email protected]> 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
[email protected]
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) |
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.
From: "Willy Tarreau" <[email protected]>
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
On Wed, Jun 25, 2008 at 03:45:01PM -0700, jdow wrote:
> From: "Willy Tarreau" <[email protected]>
> 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
From: "Willy Tarreau" <[email protected]>
Sent: Wednesday, 2008, June 25 16:11
> On Wed, Jun 25, 2008 at 03:45:01PM -0700, jdow wrote:
>> From: "Willy Tarreau" <[email protected]>
>> 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.