From: "jdow" <jdow@earthlink.net>
To: "Willy Tarreau" <w@1wt.eu>
Cc: "Matthew" <jackdachef@gmail.com>, <greg@kroah.com>,
"Linux Kernel" <linux-kernel@vger.kernel.org>,
"Linus Torvalds" <torvalds@linux-foundation.org>
Subject: Re: [ANNOUNCE] Position Statement on Linux Kernel Modules
Date: Fri, 27 Jun 2008 20:28:21 -0700 [thread overview]
Message-ID: <05d401c8d8cf$04627390$0125a8c0@wednesday> (raw)
In-Reply-To: 20080625231107.GA21889@1wt.eu
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.
next prev parent reply other threads:[~2008-06-28 3:28 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-06-23 13:02 [ANNOUNCE] Position Statement on Linux Kernel Modules Matthew
2008-06-23 13:21 ` Willy Tarreau
2008-06-25 22:45 ` jdow
2008-06-25 23:11 ` Willy Tarreau
2008-06-28 3:28 ` jdow [this message]
2008-06-23 18:11 ` Greg KH
-- strict thread matches above, loose matches on Subject: below --
2008-06-23 5:01 Greg KH
2008-06-23 10:00 ` Jiri Kosina
2008-06-23 14:24 ` Greg KH
2008-06-23 11:29 ` Greg Louis
2008-06-23 13:09 ` Willy Tarreau
2008-06-24 11:33 ` Greg Louis
2008-06-24 15:02 ` David Newall
2008-06-23 18:12 ` Greg KH
2008-06-23 18:15 ` Måns Rullgård
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='05d401c8d8cf$04627390$0125a8c0@wednesday' \
--to=jdow@earthlink.net \
--cc=greg@kroah.com \
--cc=jackdachef@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@linux-foundation.org \
--cc=w@1wt.eu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox