I think some kernel developers take to much responsibility, is there a bug in a
binary driver? Send it upstream and explain to the user that it's a closed
source driver and is up to said company to fix it.
For what it's worth, I don't see any problem with binary drivers from hardware
manufacturers.
Just because nvidia makes a closed source driver doesn't mean that we can't also
create an open source driver(limited functionality, reverse engineered,
etc.,etc.). I firmly believe that the choice should be up to the user and/or
distro. I'm not a kernel dev, I don't know c...but I understand the concepts and
I should have the right to do what I want with this GPL code. Restricting me
only frustrates me. Should the default be open source, definitely; should binary
drivers be blocked from running on a linux kernel...certainly not.
I personally like nvidia's products, they have spent a lot of money in R&D. One
example is SLI, if their spec was open what would stop ATI from stealing their
work(patents?, gotta love those). Personally I think nvidia has excellent
support for linux, I have actually convinced people to use linux(desktop and
server) just by showing them beryl with the nvidia beta drivers.
Lastly I think it's ridiculous to create,diplay, and distribute "Free" as in
freedom and "Free" as in cost software only to later consider limiting my
freedom...want to know why a lot of large companies don't support
linux...exactly threads like this. Why make the effort to use "Free" software
only to have the rug pulled out from under you. This is what makes the BSDs so
attractive.
> I personally like nvidia's products, they have spent a lot of money in R&D. One
> example is SLI, if their spec was open what would stop ATI from stealing their
3DFx invented SLI many years ago. The SLI programming information for the
3DFx cards is public. Nvidia are a bit late to the party except on the PR
front.
Alan
On Fri, Dec 15, 2006 at 09:20:58PM +0000, James Porter wrote:
> I think some kernel developers take to much responsibility, is there a bug in a
> binary driver? Send it upstream and explain to the user that it's a closed
> source driver and is up to said company to fix it.
>
> For what it's worth, I don't see any problem with binary drivers from hardware
> manufacturers.
Binary drivers from hardware manufacturers are crap. Learn it by heart.
> Just because nvidia makes a closed source driver doesn't mean that we can't also
> create an open source driver(limited functionality, reverse engineered,
> etc.,etc.).
We can.
> I firmly believe that the choice should be up to the user and/or
> distro. I'm not a kernel dev, I don't know c...
but you can't.
> but I understand the concepts and
> I should have the right to do what I want with this GPL code.
You don't have a right to do what you want with GNU GPL'ed code.
Read the fucking license, already.
> Restricting me only frustrates me.
Nobody is restricting you.
> Should the default be open source, definitely; should binary
> drivers be blocked from running on a linux kernel...certainly not.
But users of binary drivers should be blocked from sending bug reports
to kernel developers.
> I personally like nvidia's products, they have spent a lot of money in R&D. One
> example is SLI, if their spec was open what would stop ATI from stealing their
> work(patents?, gotta love those).
I lost a nice quote about 10-20% of the community stopping making
excuses for vendors. Sad, sad, nice quote definitely.
> Personally I think nvidia has excellent
> support for linux, I have actually convinced people to use linux(desktop and
> server) just by showing them beryl with the nvidia beta drivers.
beryl on server?
> Lastly I think it's ridiculous to create,diplay, and distribute "Free" as in
> freedom and "Free" as in cost software only to later consider limiting my
> freedom...
Nobody is limiting you.
> want to know why a lot of large companies don't support
> linux...exactly threads like this.
You asked them?
> Why make the effort to use "Free" software
> only to have the rug pulled out from under you. This is what makes the BSDs so
> attractive.
So use BSD.
On Dec 15 2006 21:59, Alan wrote:
>
>> I personally like nvidia's products, they have spent a lot of money in R&D. One
>> example is SLI, if their spec was open what would stop ATI from stealing their
>
>3DFx invented SLI many years ago. The SLI programming information for the
>3DFx cards is public. Nvidia are a bit late to the party except on the PR
>front.
...and there are enough people to take the PR. (Meaning they don't check
if "SLI" existed before and hence reveal foul PR.)
-`J'
--
Alexey Dobriyan wrote:
> On Fri, Dec 15, 2006 at 09:20:58PM +0000, James Porter wrote:
>> For what it's worth, I don't see any problem with binary drivers from hardware
>> manufacturers.
>
> Binary drivers from hardware manufacturers are crap. Learn it by heart.
>
That's your personal opinion! A lot other people (including me) have had
excellent experience with binary drivers!
>> Just because nvidia makes a closed source driver doesn't mean that we can't also
>> create an open source driver(limited functionality, reverse engineered,
>> etc.,etc.).
>
> We can.
>
The day you show me that the open-source driver is faster and more
stable then the binary driver, I'll switch. But until then I'll stay
with my binary driver. I haven't had any serious problems with it, in
fact, I'm very happy, so why should I want to switch?
I don't see Linux in such a political way like some of you do, for me
Linux is just like any other OS. There are good drivers and bad drivers.
And I don't care if they are open source or binary, I don't judge them
based on that, but based on how well they work and how good the support is.
> But users of binary drivers should be blocked from sending bug reports
> to kernel developers.
>
Most end-users will never get directly in touch with the kernel
developers. They'll first go to their distribution. Most Ubuntu users
don't even know what a kernel is (not that I use Ubuntu, but it's a
distribution that is widespread among the less experienced end-users and
people who switch to Linux from the windows world).
tom
From: "Alexey Dobriyan" <[email protected]>
> On Fri, Dec 15, 2006 at 09:20:58PM +0000, James Porter wrote:
>> I think some kernel developers take to much responsibility, is there a
>> bug in a
>> binary driver? Send it upstream and explain to the user that it's a
>> closed
>> source driver and is up to said company to fix it.
>>
>> For what it's worth, I don't see any problem with binary drivers from
>> hardware
>> manufacturers.
>
> Binary drivers from hardware manufacturers are crap. Learn it by heart.
So are the Linux drivers in some cases. My ATI Radeon Mobility video
in my laptop is an example.
If you are going to mount a sanctimonious high horse it is a wise idea
to mount a horse instead of a donkey.
{^_^}
On 12/16/06, jdow <[email protected]> wrote:
> From: "Alexey Dobriyan" <[email protected]>
>
> > On Fri, Dec 15, 2006 at 09:20:58PM +0000, James Porter wrote:
> >> I think some kernel developers take to much responsibility, is there a
> >> bug in a
> >> binary driver? Send it upstream and explain to the user that it's a
> >> closed
> >> source driver and is up to said company to fix it.
> >>
> >> For what it's worth, I don't see any problem with binary drivers from
> >> hardware
> >> manufacturers.
> >
> > Binary drivers from hardware manufacturers are crap. Learn it by heart.
>
> So are the Linux drivers in some cases. My ATI Radeon Mobility video
> in my laptop is an example.
>
Open drivers aren't magic.. if the vendor doesn't give us the
information how specific chips are screwed, there isn't anything we
can do about it, ATI don't support the open drivers for anything but
RN50s from Dell and their support is quite brutal even on those (every
patch is a dirty hack...), the thing is with the open drivers we can
say hey ATI that is a dirty hack, with the closed ones they just stick
it in and ship it..
Dave.
Hi!
> I think some kernel developers take to much responsibility, is there a bug in a
> binary driver? Send it upstream and explain to the user that it's a closed
> source driver and is up to said company to fix it.
ANd deal with users screaming at you 'I'm sure nvidia is not a problem
because it dies when I use suspend, but is rock solid otherwise'?
> Just because nvidia makes a closed source driver doesn't mean that we can't also
> create an open source driver(limited functionality, reverse engineered,
> etc.,etc.). I firmly believe that the choice should be up to the user and/or
> distro. I'm not a kernel dev, I don't know c...but I understand the concepts and
So you can't write code...
> work(patents?, gotta love those). Personally I think nvidia has excellent
> support for linux, I have actually convinced people to use linux(desktop and
> server) just by showing them beryl with the nvidia beta drivers.
...still you convince people to use code noone is going to fix? Sweet!
Pavel
--
Thanks for all the (sleeping) penguins.
Hi!
> >Binary drivers from hardware manufacturers are crap.
> >Learn it by heart.
>
> So are the Linux drivers in some cases. My ATI Radeon
> Mobility video
> in my laptop is an example.
>
> If you are going to mount a sanctimonious high horse it
> is a wise idea
> to mount a horse instead of a donkey.
High horses are common and easy to ride. But a donkey... :-).
[Searching for donkey to ride somewhere near Prague. Also searching
for donkey stallion, preferably tall one -- have high horse and want
some donkey-horse foals.]
Pavel
--
Thanks for all the (sleeping) penguins.
Dear Linux Kernel ML,
I am writing as a Linux-only user of over 2 years to express my concern with
the recent proposal to block out closed source modules from the kernel.
While, I understand and share your sentiments over open source software and
drivers. I fear however, that trying to steamroll the industry into
developing open source drivers by banning closed source drivers is going to
have a completely different result. They will simply abandon Linux support
for some of their products altogether.
Take the high-end graphic cards that are prevalent in most of today's
home/SOHO hardware- desktops and laptops. Would I be wrong in saying that the
Linux market share in this market is no more than 5%?
These companies have already demonstrated that the support they provide is
proportional to the market share.
The open source driver development is promising but it has been mentioned
several times that the project is undermanned and the vendors are not
forthcoming with the necessary information.
My hardware as it stands today is still not working with the open-source
drivers. Perhaps this is the case of PEBCAK and not the open-source drivers
per se but with a 1-4 hour turnaround to test a new version of the r300
driver it is not a small effort on my part. Still, I'm eagerly awaiting the
day that I'll be able to use an open-source driver that is on par with the
ati one.
The bottom line is that the proposed 1st Jan 2008 dead line is unlikely to
make any corporations tremble. It is likely to be the day when I will be no
longer able to run the latest version of the kernel.
Finally, I'd like to thank you for reading my email and on your work on the
fantastic work and community that Linux is.
I hope you will take this user and others like me under consideration when
making the final decision on whether or not to include the proposed patch and
whether to undertake work on code that will prevent binary drivers from
loading.
Warmest regards,
Marek Wawrzyczny
On Dec 16 2006 01:57, Tomas Carnecky wrote:
> Alexey Dobriyan wrote:
>> On Fri, Dec 15, 2006 at 09:20:58PM +0000, James Porter wrote:
>> > For what it's worth, I don't see any problem with binary drivers from
>> > hardware
>> > manufacturers.
>>
>> Binary drivers from hardware manufacturers are crap. Learn it by heart.
>
> That's your personal opinion! A lot other people (including me) have had
> excellent experience with binary drivers!
Either way.
* NVIDIA blob on a desktop box
Ability to deadlock the machine, proved so in the past, but
has not happened >= 1.0.7xxx so far.
* Free "radeon" driver on a laptop
The _second_ time (relative to starting the X binary) I switch
from Xorg 6.x to the console, the screen fades from black to
white. System remains operational, switching back to X gives me
my graphics mode back, but no way to go back to console.
-`J'
--
On Dec 16 2006 08:12, Pavel Machek wrote:
>>
>> If you are going to mount a sanctimonious high horse it
>> is a wise idea
>> to mount a horse instead of a donkey.
>
>High horses are common and easy to ride. But a donkey... :-).
The next thing that happens is that nvidia and ati
undermine us a Trojan Rabbit.
-`J'
--
On Sat, 16 Dec 2006, Alexey Dobriyan wrote:
> On Fri, Dec 15, 2006 at 09:20:58PM +0000, James Porter wrote:
> > but I understand the concepts and
> > I should have the right to do what I want with this GPL code.
>
> You don't have a right to do what you want with GNU GPL'ed code.
> Read the fucking license, already.
Actually, the license doesn't restrict your rights.
Copryight law restricts your rights. The license grants you additional rights
not granted by copyright law.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
On Saturday 16 December 2006 10:07, Marek Wawrzyczny wrote:
> The open source driver development is promising but it has been mentioned
> several times that the project is undermanned and the vendors are not
> forthcoming with the necessary information.
> My hardware as it stands today is still not working with the open-source
> drivers. Perhaps this is the case of PEBCAK and not the open-source drivers
> per se but with a 1-4 hour turnaround to test a new version of the r300
> driver it is not a small effort on my part. Still, I'm eagerly awaiting the
> day that I'll be able to use an open-source driver that is on par with the
> ati one.
I buy the hardware. I actually want to get enough information about it
so that I can write a driver for it for my homegrown OS.
In the "old days" hardware was accompanied with such info.
For example, printers had control ESC sequences listed, etc.
These days, printers come with elaborate idiot-proof manuals
"how to properly connect your printer to the AC outlet"
and "how to properly insert Windows driver CD".
Ever met those Windows-only "GDI" printers which do not speak
any known open standard (they eat proprietary bitmap input instead)?
Why vendor has a right to restrict me to a few existing OSes?
I think that something is wrong here. Are there countries where
such practuce (of not providing tech info for writing drivers)
is illegal?
--
vda
On Fri, 2006-12-15 at 21:20 +0000, James Porter wrote:
> I think some kernel developers take to much responsibility, is there a bug in a
> binary driver? Send it upstream and explain to the user that it's a closed
Plaese name them. AFAICS if there is a response, it is similar to "your
kernel is tainted, please report the report elsewhere".
> source driver and is up to said company to fix it.
>
> For what it's worth, I don't see any problem with binary drivers from hardware
> manufacturers.
You are probably not looking at the right places.
> Just because nvidia makes a closed source driver doesn't mean that we can't also
^^
Please send patches.
> create an open source driver(limited functionality, reverse engineered,
> etc.,etc.). I firmly believe that the choice should be up to the user and/or
> distro. I'm not a kernel dev, I don't know c...but I understand the concepts and
^^^^^^^^^^
Then become one if you are serious with the "we" above.
> I should have the right to do what I want with this GPL code. Restricting me
Then you should discuss this with law makers, politicians and the
various pressure groups about copyright and/or authors rights and you
surely *must* deal beforehand with the patent plague since this is even
more restricting in any sense than author rights ever was (let alone
copyright).
And for such political debate LKML is probably not a good place.
> only frustrates me. Should the default be open source, definitely; should binary
> drivers be blocked from running on a linux kernel...certainly not.
They are not blocked - it is up to the users to decide and live with the
consequences.
[...]
> only to have the rug pulled out from under you. This is what makes the BSDs so
> attractive.
Why are you then here?
Bernd
--
Firmix Software GmbH http://www.firmix.at/
mobil: +43 664 4416156 fax: +43 1 7890849-55
Embedded Linux Development and Services
On Fri, Dec 15, 2006 at 09:59:43PM +0000, Alan wrote:
> 3DFx invented SLI many years ago. The SLI programming information for the
> 3DFx cards is public. Nvidia are a bit late to the party except on the PR
> front.
Well they do work differently. 3Dfx just did alternate line rendering,
while nvidia does a lot more methods of dividing the work load (many of
which are likely to be more efficient than alternate line rendering in
general). No doubt why they picked the name SLI though. They did also
buy out 3Dfx so I guess by that they can claim to have "invented" it. :)
--
Len Sorensen
Tomas Carnecky <[email protected]> writes:
> Alexey Dobriyan wrote:
>> On Fri, Dec 15, 2006 at 09:20:58PM +0000, James Porter wrote:
>>> For what it's worth, I don't see any problem with binary drivers from
> hardware
>>> manufacturers.
>>
>> Binary drivers from hardware manufacturers are crap. Learn it by heart.
>>
>
> That's your personal opinion! A lot other people (including me) have had
> excellent experience with binary drivers!
Almost all software is crap. Binary drivers are just unreviewed unfixable
crap. Things don't get better if you encourage crap.
The practical problem with simple testing for detecting problems is that
you don't frequently test the corner cases, and corner cases are what
developers often get wrong, often make software a security hazard, and
are often what developers spend most of their time building
infrastructure for so that we can get the corner cases right.
One such corner case that causes me to run in fear of binary only
kernel drivers are times when drivers accidentally write to variables
used for something else. Which can cause failure somewhere else
someplace a long time after it has happened. Like driving over a
tack in the road and having your tire go flat 1000 miles later because
of a slow leak.
These are the kinds of problems you have to address if you want
everyone to have a good experience with their hardware. These are
precisely the kinds of problems that cannot be addressed with
binary only drivers.
We have a process that has worked for centuries to improve our
knowledge base. The scientific method and peer review. We use a
variation of this proven process for writing software in linux. The
binary only vendors are being rude and refusing to participate.
Do you understand why we have no sympathy for their efforts, no desire
to make their lives easier.
In general people doing binary only drivers are being rude.
> The day you show me that the open-source driver is faster and more stable then
> the binary driver, I'll switch. But until then I'll stay with my binary
> driver. I haven't had any serious problems with it, in fact, I'm very happy, so
> why should I want to switch?
Oh. So you have had problems with it. The goal for system software
is quality so high you can not find problems with it. That doesn't
always happen but we try. The fact you have minor problems indicates
there are problems in the driver, and which probably means that
it is indeed crap.
Anytime an end user has to be aware of drivers and not the problem
at hand it is a problem.
> I don't see Linux in such a political way like some of you do, for me Linux is
> just like any other OS. There are good drivers and bad drivers. And I don't care
> if they are open source or binary, I don't judge them based on that, but based
> on how well they work and how good the support is.
A very reasonable attitude. But a binary driver is an automatic
negative on the support side. It fundamentally reduces the number and
quality of the people who can support you. The developers are not
being cooperative with other developers so the system as a whole
cannot improve to support it better.
Eric
Marek Wawrzyczny wrote:
> Dear Linux Kernel ML,
>
> I am writing as a Linux-only user of over 2 years to express my concern with
> the recent proposal to block out closed source modules from the kernel.
>
> While, I understand and share your sentiments over open source software and
> drivers. I fear however, that trying to steamroll the industry into
> developing open source drivers by banning closed source drivers is going to
> have a completely different result. They will simply abandon Linux support
> for some of their products altogether.
>
As a developer of some "closed source" drivers I can confirm that this
is exactly the case. I would never consider open sourcing my work just
because somebody is pointing pistol to my neck. I would leave the whole
IT business and start doing something else rather than accept this kind
of mafia-like negotiation methods.
For a professional developer of any software the decision of open
sourcing it is not easy. "Just for fun" developers have no problems
because they don't expect to be able to live on their work anyway.
However a professional developer can release software under GPL only if
it's considered invaluable or if there is some way to guarantee
sufficient income. Releasing something under GPL without a guaranteed
backup plan is like jumping from an airplane without parasuit. If
somebody forces me to jump form an airplane without a parasuit then what
would this be called?
> The bottom line is that the proposed 1st Jan 2008 dead line is unlikely to
> make any corporations tremble. It is likely to be the day when I will be no
> longer able to run the latest version of the kernel.
To us this decision would mean that after Jan 1 2008 we will be out of
business (at least in the Linux market). Due to the nature of our
product (kernel level sound API) there is no alternative way to get USB
working. We could try to develop an alternative API that is user land
based but this is not going to work. We could also develop an artifical
user land driver that would require application->kernel->deamon->kernel
type looping which kills performance and causes massive latencies but it
doesn't make any sense.
Our alternatives are to leave the Linux market or to release our code
under GPL. GPLing means that we will have to give to the major Linux
companies full rights to do whatever they like with our code. They will
have complete freedom to adapt our product for their purposes and to
sell it for profit. There is no law that would require them to pay
anything to us. There is also no way we could compete with them because
the current device/module model makes it completely impossible to ship
precompiled binary modules for all possible kernel
distributions/versions. At this moment only the companies controlling
the Linux distributions can sell binary drivers.
Developers contributing their software to Linux kernel have full right
to decide if other kernel code using their work is derived or not.
However is it not fair that developers of some key subsystem like USB
use this right? There is no alternative USB subsystem that the others
could use. Of course we could take the earlier USB subsystem before the
EXPORT_SYMBOL_GPL change and ship it together with our software. However
is this going to work or is it benefit of anybody? No.
Using EXPORT_SYMBOL_GPL is fair to protect code such as checksum or
encryption/decryption algorithms is fair. Developers of independent
kernel modules can use their own code. But the USB subsystem is
different case because there is no alternative.
Isn't it somehow suspicious if this kind of decisions are made by
employees of companies that develop a product which directly competes
with ours. Maybe this is the way how the free Linux community works.
I would suggest the Linux kernel developer community should write down
some rules the developers should agree _before_ they contribute anything
to the kernel. It's not good to anybody that different developers can
set different rules for the usage of their code. In particular it's not
good that anybody can put additional restrictions to
subsystems/interfaces that have been freely usable for years. The rest
of the IT industry can then examine the rules and decide if there is any
idea in investing on Linux based products.
Best regards,
Hannu
On 18/12/06, Hannu Savolainen <[email protected]> wrote:
> Marek Wawrzyczny wrote:
> > Dear Linux Kernel ML,
> >
> > I am writing as a Linux-only user of over 2 years to express my concern with
> > the recent proposal to block out closed source modules from the kernel.
> >
> > While, I understand and share your sentiments over open source software and
> > drivers. I fear however, that trying to steamroll the industry into
> > developing open source drivers by banning closed source drivers is going to
> > have a completely different result. They will simply abandon Linux support
> > for some of their products altogether.
> >
> As a developer of some "closed source" drivers I can confirm that this
> is exactly the case. I would never consider open sourcing my work just
> because somebody is pointing pistol to my neck. I would leave the whole
> IT business and start doing something else rather than accept this kind
> of mafia-like negotiation methods.
>
Why is this dead horse still kicking?
Linus already spoke on this issue (
http://lkml.org/lkml/2006/12/13/370 ,
http://lkml.org/lkml/2006/12/14/218 ) and Greg KH already withdrew his
patch ( http://lkml.org/lkml/2006/12/14/63 ), so could we please just
let this dead horse rest in peace?
--
Jesper Juhl <[email protected]>
Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please http://www.expita.com/nomime.html
On Mon, 18 Dec 2006 23:34:53 +0200, Hannu Savolainen wrote:
> For a professional developer of any software the decision of open
> sourcing it is not easy. "Just for fun" developers have no problems
> because they don't expect to be able to live on their work anyway.
> However a professional developer can release software under GPL only if
> it's considered invaluable or if there is some way to guarantee
> sufficient income. Releasing something under GPL without a guaranteed
> backup plan is like jumping from an airplane without parasuit.
Except that we're talking about *hardware* companies here, not
*software* companies. *Hardware* companies make money by selling
*hardware*, not the software that drives it: in fact, they always
distribute the 'software' they write (the drivers) for free (gratis).
So while what you say is perfectly sensible for *software* developers,
it has absolutely nothing to do with the closed source drivers
*hardware* companies distribute.
This all being said, I think that the only thing that can shake
companies such as nVidia and ATI is a project such as the Open
Graphics Card
http://wiki.duskglow.com/tiki-index.php?page=Open-Graphics
to succeed.
--
Giuseppe "Oblomov" Bilotta
Hic manebimus optime
--- Giuseppe Bilotta <[email protected]> wrote:
> Except that we're talking about *hardware* companies
> here, not
> *software* companies. *Hardware* companies make
> money by selling
> *hardware*, not the software that drives it: in
> fact, they always
> distribute the 'software' they write (the drivers)
> for free (gratis).
>
> So while what you say is perfectly sensible for
> *software* developers,
> it has absolutely nothing to do with the closed
> source drivers
> *hardware* companies distribute.
The argument that a hardware company usually
invokes is that, while they don't give a horse's
pitute about the software itself, they do care
about the information the software contains
about their hardware. The concern is that
publishing the software under any form of open
or free license would be seen as publishing
the details of the hardware, thus making any
claims that they attempted to protect thier
intellectual property void. They would sell
less hardware because they would have no legal
recourse against anyone who "stole" the secrets
to their hardware.
I make no claims to understanding the legal
basis for this position. I don't even know if
I think it makes sense. I have heard it often
enough to understand that many people believe
it though.
Casey Schaufler
[email protected]
On Wed, 2006-12-20 at 16:38 -0800, Casey Schaufler wrote:
[...]
> The argument that a hardware company usually
> invokes is that, while they don't give a horse's
> pitute about the software itself, they do care
> about the information the software contains
> about their hardware. The concern is that
> publishing the software under any form of open
> or free license would be seen as publishing
> the details of the hardware, thus making any
> claims that they attempted to protect thier
> intellectual property void. They would sell
> less hardware because they would have no legal
> recourse against anyone who "stole" the secrets
> to their hardware.
The more realistic and more expensive threat is not the above (yes, one
can "copy" an already released product after reverse enginnering and
also try to sell it but how long - in calendar time - does this take?
And during that time the original is sold all the time) but it is much
easier to detect (real or potential) patent violations and the fun
begins probably.
And ATM is is practically not possible to build anything remotely
"technical" without violating hundreds of patents somewhere (they may be
legal or "illegal" or trivial or software as such but if a patent is
granted it is there).
> I make no claims to understanding the legal
> basis for this position. I don't even know if
> I think it makes sense. I have heard it often
> enough to understand that many people believe
> it though.
Bernd
--
Firmix Software GmbH http://www.firmix.at/
mobil: +43 664 4416156 fax: +43 1 7890849-55
Embedded Linux Development and Services
Denis Vlasenko wrote:
> Why vendor has a right to restrict me to a few existing OSes?
Manufacturers design product as they see fit and offer it on the market; I
don't see nVidia or ATI thugs twisting your arm behind you as you walk down
the aisle of Fry's Electronics saying "buy this nice card we made or I'll
break your arm."
The bottom line is this: companies speak dollarese expertly. If you don't
like product X because it does not include specs or don't like the policies of
its manufacturer towards the community then vote with your wallet.
-n
On 12/18/06, Eric W. Biederman <[email protected]> wrote:
>
> We have a process that has worked for centuries to improve our
> knowledge base. The scientific method and peer review. We use a
> variation of this proven process for writing software in linux. The
> binary only vendors are being rude and refusing to participate.
>
> Do you understand why we have no sympathy for their efforts, no desire
> to make their lives easier.
>
> In general people doing binary only drivers are being rude.
---
Which is more rude:
(a) "Thank you for requesting a driver to support our hardware on
Linux. Unfortunately, we don't have time either to provide such a
driver or write the documentation that would allow you do so. The
Linux market is not big enough to justify the work, and as a result we
cannot offer you any support.", or
(b) "Thank you for requesting a driver to support our hardware on
Linux. Unfortunately, we don't have time either to provide such a
driver or write the documentation that would allow you do so. The
Linux market is not big enough to justify the legal and technical
expense involved. However, we can provide you with this binary driver
that we believe will allow you to use the hardware in your system,
just as we provide binary drivers for other hardware platforms."
You say "It's rude to not play by our rules". They say "It's rude of
you to expect us to change our business model to support your niche
market differently from the way we support everyone else." Neither is
wrong...
scott
scott
On Thu, Dec 21, 2006 at 10:33:10AM -0600, Scott Preece wrote:
> (b) "Thank you for requesting a driver to support our hardware on
> Linux. Unfortunately, we don't have time either to provide such a
> driver or write the documentation that would allow you do so. The
> Linux market is not big enough to justify the legal and technical
> expense involved. However, we can provide you with this binary driver
> that we believe will allow you to use the hardware in your system,
> just as we provide binary drivers for other hardware platforms."
You forgot to add:
"However, we thought the legal and technical expense involved in
writing this binary driver and possibly violating the Linux kernel
copyright was well spend."
My 0.02 EUR.
Erik
--
+-- Erik Mouw -- http://www.harddisk-recovery.com -- +31 70 370 12 90 --
| Lab address: Delftechpark 26, 2628 XH, Delft, The Netherlands
On Wed, 20 Dec 2006 23:06:43 +0100, Giuseppe Bilotta said:
> So while what you say is perfectly sensible for *software* developers,
> it has absolutely nothing to do with the closed source drivers
> *hardware* companies distribute.
The problem is that the software drivers reveal an awful lot about the
innards of the hardware, which is something the hardware companies *do*
want to protect.
> This all being said, I think that the only thing that can shake
> companies such as nVidia and ATI is a project such as the Open
> Graphics Card
At least nVidia *does* actually Get It, they just don't have a choice in
implementing it, because all their current hardware includes patents that
they licensed from other companies (I believe some of the OpenGL stuff that
originated at SGI and got bought by Microsoft is involved, but I have no
hard references for actual patent numbers). And then they have the big
problem - do they keep using the patent in order to boost performance,
or no?
If they produce a blazing-fast card and they manage to sell to 30% of the
Windows users, they've sold to about 27% of all computer users. If they
skip the patent and produce a slower card to please the Linux users, even if
they sell to half the Linux users, that's only 5-6% of the market.
Which course of action is any CFO going to choose?
(And let's not underestimate the possibility that some yet-undisclosed
submarine patent will torpedo the Open Graphics Card if they unwittingly
re-invent something owned by a company that wants the card to fail....)
Erik Mouw wrote:
>
> "However, we thought the legal and technical expense involved in
> writing this binary driver and possibly violating the Linux kernel
> copyright was well spend."
>
So Microsoft is right, the legal status of Linux software _is_ unclear.
You just gave them every reason to continue their campaign against
Linux. <Don't use Linux, its legal status is unclear, you may get sued>.
The problem is, nobody wants to decide what to do with closed source
software in Linux. I don't care how you decide, for or against binary
drivers (well, actually I do but my opinion doesn't matter), just decide
already!
tom
James Porter wrote:
> I'm pretty sure Linus has decided, basically he said the patches to
> prevent non-gpl binary drivers are not going into his tree unless every
> other tree adopts it. Of course the few supporting won't get off their
> high horse and try it on a different tree.
.. unfortunately, that doesn't make the legal status any clearer.
tom
"Scott Preece" <[email protected]> writes:
> Which is more rude:
> (a) "Thank you for requesting a driver to support our hardware on
> Linux. Unfortunately, we don't have time either to provide such a
> driver or write the documentation that would allow you do so. The
> Linux market is not big enough to justify the work, and as a result we
> cannot offer you any support.", or
>
> (b) "Thank you for requesting a driver to support our hardware on
> Linux. Unfortunately, we don't have time either to provide such a
> driver or write the documentation that would allow you do so. The
> Linux market is not big enough to justify the legal and technical
> expense involved. However, we can provide you with this binary driver
> that we believe will allow you to use the hardware in your system,
> just as we provide binary drivers for other hardware platforms."
But as it happens that driver does not work for a large segment
percentage of linux users who potentially could place the card in
their system. Did that driver support all 23 architectures?
> You say "It's rude to not play by our rules". They say "It's rude of
> you to expect us to change our business model to support your niche
> market differently from the way we support everyone else." Neither is
> wrong...
Every market is different, and you have to different things in
different markets. It is close to incompetent not to acknowledge
the fact that rules are different in different markets and different
places. That is one of the reasons why people try to harmonize laws
so there is not too much of this going on.
Usually it is also the case that binary vs source release does nothing
to a hardware manufacturers business model they sell hardware after
all, and usually having a helping hand in writing the necessary
software and making it work (the source release) is a plus for the
hardware manufacturer.
The difference is that we don't expect the hardware manufactures to do
anything we only hope they will support linux. Once they support
linux we do expect they will play well with others and if they don't
then it is rude.
Please none of this amoral Neither is wrong crap.
Eric
Tomas Carnecky <[email protected]> writes:
> The problem is, nobody wants to decide what to do with closed source software in
> Linux. I don't care how you decide, for or against binary drivers (well,
> actually I do but my opinion doesn't matter), just decide already!
The decision from Linus was simple. Linus will not merge a patch that
attempts to prevent this from at a technical level. No one has made
any exceptions to the GPL to say that GPL incompatible drivers are
allowed. Therefore on a legal level kernel drivers with GPL
incompatible drivers are as illegal as the derivative works clause in
copyright law will allow us to make them. If you want something
firmer you can go talk to your appropriate government about taking the
fuzz out of what is a derivative work.
As a practical matter people not releasing source aren't playing well with us
so we are not likely to play well with them.
Eric
> You say "It's rude to not play by our rules". They say "It's rude of
> you to expect us to change our business model to support your niche
> market differently from the way we support everyone else." Neither is
> wrong...
Honestly, I think it *is* wrong to sell someone a physical product and then
not tell them how to make it work. If you're not actually selling them the
physical product but selling them a way to get a particular thing done, then
don't represent that you're selling them physical product because that would
presumably include the right to use it any way they wanted provided it was
lawful.
How would you feel if you bought a car and then discovered that the
manufacturer had welded the hood shut? How many people still do their own
oil changes anyway?
If you sell a physical product, you should also include the information
necessary to make that physical product *work*. If you don't, you aren't
actually selling the physical product, that is, the person is buying a right
to use that physical product some particular way and not the product itself.
The law may come around on this issue. It has definitely done so on
companies that claim to be selling you cellphones but then later claim that
you need to pay them additional money if you want the access code to unlock
it and make it work with another carrier. If you own a physical phone, it
should come with the right to use it with any carrier it can be made to work
with, and a company with no ownership interest in the phone has no right to
withhold the information needed to make it do that so as to force you to use
their service.
The same applies when you buy a graphics card and don't want to use it with
the manufacturer's drivers. If it's *your* graphics card, the manufacturer
has no legitimate interest in forcing you to use their drivers by
withholding information about what *you* bought.
DS
On Thu, 21 Dec 2006, David Schwartz wrote:
>> You say "It's rude to not play by our rules". They say "It's rude of
>> you to expect us to change our business model to support your niche
>> market differently from the way we support everyone else." Neither is
>> wrong...
>
> Honestly, I think it *is* wrong to sell someone a physical product and then
> not tell them how to make it work. If you're not actually selling them the
> physical product but selling them a way to get a particular thing done, then
> don't represent that you're selling them physical product because that would
> presumably include the right to use it any way they wanted provided it was
> lawful.
>
> How would you feel if you bought a car and then discovered that the
> manufacturer had welded the hood shut? How many people still do their own
> oil changes anyway?
there are cars out there where the owner cannot change or add transmission fluid
(I had a rental car spring a leak and found this out the hard way)
some people like this, some don't. vote with your money
David Lang
On Thu, 21 Dec 2006 12:50:00 PST, David Schwartz said:
> How would you feel if you bought a car and then discovered that the
> manufacturer had welded the hood shut? How many people still do their own
> oil changes anyway?
I know of at least one use case where a car *has* to have the doors welded
shut - stock car racing. And there's requirements regarding how the hood
is fastened as well...
David wrote:
> Honestly, I think it *is* wrong to sell someone a physical product and then
> not tell them how to make it work. If you're not actually selling them the
> physical product but selling them a way to get a particular thing done, then
> don't represent that you're selling them physical product because that would
> presumably include the right to use it any way they wanted provided it was
> lawful.
>
> How would you feel if you bought a car and then discovered that the
> manufacturer had welded the hood shut? How many people still do their own
> oil changes anyway?
I think he is right. The linux kernel is free software and there should be no closed source in it.
When Windows uses closed-source drivers, it doesn´t matter, but the in the linux kernel should be only open-source.
______________________________________________________________________________
"Ein Herz f?r Kinder" - Ihre Spende hilft! Aktion: http://www.deutschlandsegelt.de
Unser Dankesch?n: Ihr Name auf dem Segel der 1. deutschen America's Cup-Yacht!
On 12/21/06, Eric W. Biederman <[email protected]> wrote:
> "Scott Preece" <[email protected]> writes:
>
> But as it happens that driver does not work for a large segment
> percentage of linux users who potentially could place the card in
> their system. Did that driver support all 23 architectures?
---
Do they claim it does? There is NO moral obligation that they support
every piece of hardware in the world. They are offering a product
under certain terms. You can choose to buy it or not. If you have
standing, and believe that their driver infringes the Linux
copyrights, then you could also sue, but the most you could hope to
win is making the driver unavailable, which makes the hardware
unavailable. That still feels like a Pyrrhic victory to me.
---
> The difference is that we don't expect the hardware manufactures to do
> anything we only hope they will support linux. Once they support
> linux we do expect they will play well with others and if they don't
> then it is rude.
---
Not everyone agrees that it is better to not have the device available
for Linux at all than to have it with a closed driver. Again, note
that the manufacturer services all other OS platforms with closed
drivers, so you're asking them to do something different, that
probably costs them something in startup cost, and potentially costs
them something in downstream support.
---
>
> Please none of this amoral Neither is wrong crap.
---
It's not a moral question. The hardware vendor says - "This is what we
make. You can buy it if you like and we will support it to the extent
defined in our support policy. If those terms don't work for you, or
it doesn't work with your hardware, then we're sorry; we can't help
you at this time."
scott
On 12/21/06, David Schwartz <[email protected]> wrote:
>
> > You say "It's rude to not play by our rules". They say "It's rude of
> > you to expect us to change our business model to support your niche
> > market differently from the way we support everyone else." Neither is
> > wrong...
>
> Honestly, I think it *is* wrong to sell someone a physical product and then
> not tell them how to make it work. If you're not actually selling them the
> physical product but selling them a way to get a particular thing done, then
> don't represent that you're selling them physical product because that would
> presumably include the right to use it any way they wanted provided it was
> lawful.
>
> How would you feel if you bought a car and then discovered that the
> manufacturer had welded the hood shut? How many people still do their own
> oil changes anyway?
---
But there is no legal or moral obligation for the carmake to sell you
the service manual for the vehicle or provide you with their periodic
service bulletins...
---
>
> If you sell a physical product, you should also include the information
> necessary to make that physical product *work*. If you don't, you aren't
> actually selling the physical product, that is, the person is buying a right
> to use that physical product some particular way and not the product itself.
---
The information needed to make it work does not necessarily include
any information about how it works. A closed driver is a perfectly
valid part of the product.
Try this thought experiment: suppose the "driver" were actually
implemented by firmware loaded into the device in the factory and not
field replaceable. Do you consider that to be immoral? Why should the
technological accident of the driver being plugged into the OS change
the appropriateness?
---
>
> The law may come around on this issue. It has definitely done so on
> companies that claim to be selling you cellphones but then later claim that
> you need to pay them additional money if you want the access code to unlock
> it and make it work with another carrier. If you own a physical phone, it
> should come with the right to use it with any carrier it can be made to work
> with, and a company with no ownership interest in the phone has no right to
> withhold the information needed to make it do that so as to force you to use
> their service.
---
No such change has occurred. There was a very limited legal change to
say that it did not violate copyright to attempt to circumvent the
protection of the lock. There is no legal requirement that the carrier
unlock the device (at least in the US). [I personally believe that
they should be required to, but I'm only responding to your assertion
that there has been a major change on this point.]
---
> The same applies when you buy a graphics card and don't want to use it with
> the manufacturer's drivers. If it's *your* graphics card, the manufacturer
> has no legitimate interest in forcing you to use their drivers by
> withholding information about what *you* bought.
---
I disagree. The manufacturer has a right to choose to sell its devices
under any legal business model. Part of that model is deciding what
level of support to provide and what systems to support in selling it.
It's not a question of whether they "have a legitimate interest in "
doing anything - they have the complete right to choose where to spend
their development dollars. Choosing not to write technical manuals for
the public is a completely valid choice. It's your option whether to
buy or not, knowing the manufacturer's choice.
scott
On 12/21/06, Tomas Carnecky <[email protected]> wrote:
> James Porter wrote:
> > I'm pretty sure Linus has decided, basically he said the patches to
> > prevent non-gpl binary drivers are not going into his tree unless every
> > other tree adopts it. Of course the few supporting won't get off their
> > high horse and try it on a different tree.
>
> .. unfortunately, that doesn't make the legal status any clearer.
Well, FWIW, neither does some "decision" from the kernel authors; it
hinges on what is and what is not a derived work of the kernel, and
the only parties whose opinion matters here (the courts in the various
jurisdictions) haven't ruled on that yet, and won't until such time as
a copyright holder in the kernel sues someone for copyright
infringement.
Dave
Hello!
> I disagree. The manufacturer has a right to choose to sell its devices
> under any legal business model. Part of that model is deciding what
> level of support to provide and what systems to support in selling it.
At the very least, if they decide that they wish to provide a binary-only
driver for i386, then their claims that they support Linux (without telling
that they in fact support a single specific variant of Linux) are
(a) blatant lie, and (b) false advertising.
Have a nice fortnight
--
Martin `MJ' Mares <[email protected]> http://mj.ucw.cz/
Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth
COBOL -- Compiles Only Because Of Luck
On Thu, 21 Dec 2006 16:12:57 CST, Scott Preece said:
> On 12/21/06, David Schwartz <[email protected]> wrote:
> > How would you feel if you bought a car and then discovered that the
> > manufacturer had welded the hood shut? How many people still do their own
> > oil changes anyway?
> ---
>
> But there is no legal or moral obligation for the carmake to sell you
> the service manual for the vehicle or provide you with their periodic
> service bulletins...
As a matter of fact, at least in the US, the carmakers *do* have to supply
relevant information for emissions-control systems to alll repair shops:
42 U.S.C. ? 7521(m)(5)
http://www.law.cornell.edu/uscode/html/uscode42/usc_sec_42_00007521----000-.html
Efforts to vastly expand that have been surfacing every Congressional session
for the last few years. The most recent incarnation:
http://www.govtrack.us/congress/bill.xpd?bill=h109-2048
Am Donnerstag, 21. Dezember 2006 21:50 schrieb David Schwartz:
> Honestly, I think it *is* wrong to sell someone a physical product
> and then not tell them how to make it work. If you're not actually
> selling them the physical product but selling them a way to get a
> particular thing done, then don't represent that you're selling
> them physical product because that would presumably include the
> right to use it any way they wanted provided it was lawful.
My opinion, too. I wasted months to get specifications for a
particular HW once and I've heared them all:
* "We can't publish documentation due to 3rd party patents" (Unh, I
thought, that patents are there, _that_ you can safely publish).
* "It would be expensive for us to publish documentation" (Wouldn't
that save the in house development of drivers, the kernel developers
would that for you _and_ maintain it).
* "We've lost the documentation" (Aaahaaa, lame excuse)
And sometimes they are honest: "We don't want to publish". If it is
rare, special hardware, like measurement interfaces I found out, that
you can put a lot of pressure on them, if you return them their
hardware, and claim your money back telling them the reason, why
their product is inapropriate. If they don't accept that, sue them
for fraud (you expected a working product, but it doesn't work with
your system). But most of the time they fear to loose one of their
precious customers and get quite talkative. But in the consumer
market a margin of +/-0.5M users doesn't put force on vendors selling
~10M units, so not buying is not an option.
Personally I've given up to tell HW manufators directly. Instead I
tell people what to buy and what not and to send protest letters the
hardware vendors - hey for something that registration cards coming
with the product must be good for.
On the long term I think, that the only way to force hardware vendors
to publish all documentation is by going the legislative way, i.e.
getting politically active, with the goal being a law, that anyone,
selling a product _must_ provide detailed documentation for free,
that enable one to understand use and maintain the product and it's
individual components without requiring additional restricted
information from the manufactor.
Anything else creates a maintenance and support monopoly for the
manufactor, which distorts the free market.
IMHO hardware documentation disclosure is of uttermost importance,
since if the manufactor goes out of buisnes you mostly have some bad
luck.
2 years ago I bought on eBay a small DECT PCI adapter with the
intention to connect it with Asterisk someday - knowing that there
are no Linux drivers and that the manufactor got bankrupt and was
bought by a competitor. I didn't even got replies to my documentation
requests addressed at the new owner of the IP. Quite disappointing.
At least the driver CD contains also VxD drivers, which are quite
easy to reverse engineer, but I haven't yet found the time to do so.
BTW: Does anybody know a not too expensive way to have some silicon
created from a VHDL? Eventually it would be easier to design our own
hardware, than being dependent on some manufactor. But there are
plenty of quite trivial patents, like this one, making you "aaarghh":
<http://tinyurl.com/yl4d2n>
But I think, that Linux can also add some force on the manufactors if
we want a little bit: Already Linux is a vital component in many
operations. For example Hollywood: There are virtually none rendering
farms running not under Linux, there, a few MacOS X, a few Solaris
and a few Irix. The same goes for the workstations. Now give Linux
another 2 years to diffuse into widespread market. I'm quite sure,
that within the next year a lot of users will look for alternative
OS, when their Windows Vista refuses to reactivate, once they changed
their hardware for the 2nd time. WinXP support is said to be
cancelled a lot earlier. People still have their hardware then, not
wanting to invest into a Mac, just to get a good OS. Instead they
will remeber that free Knoppix/Kanotix/Ubuntu LiveCD, wich came with
their computing magazine and that they tried out, found it nice but
didn't migrate fearing the effort. But the isntalled OS refuses to
work, demanding reactivation and that LiveCD is a comfortable way to
continue work. Then they install it, and at some point HW manufactors
_must_ provide Linux drivers. It doesn't matter if they are OSS yet.
Just let them deliver and gain Linux a not neglectible consumer
market share. Then forbid CSS drivers in the kernel, not aprupt, but
with enough migration time. Hardware manufactors will have to
disclose information, if they don't want to loose customers. But
since the migration is done smoothly customers will experience their
systems failing - due to the older CSS only drivers. But HW vendors
are forced to open the spec for new products, to that the drivers are
not illegal and may be delivered with the product/integrated into the
kernel. Without working drivers the product is worthless and people
using Linux won't buy a product not supported. It's a pervasive long
time plan, but it might work - if Microsoft plays along and keeps
it's user gaging restrictions.
This is purely politics, I know, but unfortunately this is probably
the only way to get it done. Marketeers and attornerys are technical
illiterates numb to technical argumentation. I don't like it, but it
seems, that we've to adopt some of their methods...
Wolfgang Draxinger
On Thu, Dec 21, 2006 at 01:16:15PM -0500, [email protected] wrote:
> At least nVidia *does* actually Get It, they just don't have a choice in
> implementing it, because all their current hardware includes patents that
> they licensed from other companies (I believe some of the OpenGL stuff that
> originated at SGI and got bought by Microsoft is involved, but I have no
> hard references for actual patent numbers). And then they have the big
> problem - do they keep using the patent in order to boost performance,
> or no?
Wasn't the whole idea about patents that you publish your invention?
Erik
--
+-- Erik Mouw -- http://www.harddisk-recovery.com -- +31 70 370 12 90 --
| Lab address: Delftechpark 26, 2628 XH, Delft, The Netherlands
Hi!
Maybe this does not belong to this thread, but I am wondering why
manufactorers doesn't want to release specifications about drivers.
They have decided to develop some hardware for, let say 3D accelaration.
Now they are selling hardware and users are buying hardware. Users are
not buying hardware because they want to run mighty drivers, they want
to use hardware.
1. Why they do not reveal spec. if user allready bought hardware, though
they give driver for free but not specs.
2. Who can contribute if they reveal specifications (how to use hardware) ?
Can anyone answer does questions?
PS: I am not talking about NVIDIA and ATI, but let's say intel and
2700G multimedia accelerator IC. They sell IC without specifications
how to use it!?
Cheers,
Rok Markovic
Nikolaos D. Bougalis wrote:
> Manufacturers design product as they see fit and offer it on the
> market; I don't see nVidia or ATI thugs twisting your arm behind you as
> you walk down the aisle of Fry's Electronics saying "buy this nice card
> we made or I'll break your arm."
If you need high-performance 3D they might as well be, as realistically
ATI and NVIDIA are the only providers of high-performance video for the
consumer market. Nobody else makes anything that competes, not even
onboard video chipsets like Intel, SiS, etc.
--
Robert Hancock Saskatoon, SK, Canada
To email, remove "nospam" from [email protected]
Home Page: http://www.roberthancock.com/
Am Freitag, 22. Dezember 2006 20:22 schrieb Rok Markovic:
> Hi!
>
> Maybe this does not belong to this thread, but I am wondering why
> manufactorers doesn't want to release specifications about drivers.
> They have decided to develop some hardware for, let say 3D
> accelaration. Now they are selling hardware and users are buying
> hardware. Users are not buying hardware because they want to run
> mighty drivers, they want to use hardware.
You're not alone, I think everybody who knows, how things in a
computer work shares this view.
> 1. Why they do not reveal spec. if user allready bought hardware,
> though they give driver for free but not specs.
>
> 2. Who can contribute if they reveal specifications (how to use
> hardware) ?
>
>
> Can anyone answer does questions?
A few years ago I had some closer contact with a driver developer of a
well known consumer HW manufacturer hunting down some nasty bugs I
discovered and developed workarounds for. From him I know, that most
developers and engineers would have no problem to disclose the
hardware specifications. The real hinderers are legal affairs and -
suprisingly - marketing departments; with little more knowledge about
the internals of their products, for them _everything_ created within
the company is considered as not to be leaked, valuable information
by them.
Wolfgang Draxinger
On 12/22/06, Wolfgang Draxinger <[email protected]> wrote:
> Am Freitag, 22. Dezember 2006 20:22 schrieb Rok Markovic:
> > Hi!
> >
> > Maybe this does not belong to this thread, but I am wondering why
> > manufactorers doesn't want to release specifications about drivers....
>
> You're not alone, I think everybody who knows, how things in a
> computer work shares this view.
---
Two of the specific arguments I've heard are (a) that the board (and
its hardware interfaces that the documentation would describe) involve
IP licensed from a third party, which the board manufacturer does not
have a legal right to disclose, or (b) that there is, in fact, no
suitable documentation, because the boards are developed somewhat
fluidly and the driver is developed directly from low-level knowledge
that simply isn't written down in a form suitable for passing on.
If you're building products with no expectation of supporting outside
driver developers, both of those are quite possible.
scott
Robert Hancock wrote:
> Nikolaos D. Bougalis wrote:
>> Manufacturers design product as they see fit and offer it on the
>> market; I don't see nVidia or ATI thugs twisting your arm behind you
>> as you walk down the aisle of Fry's Electronics saying "buy this nice
>> card we made or I'll break your arm."
>
> If you need high-performance 3D they might as well be, as realistically
> ATI and NVIDIA are the only providers of high-performance video for the
> consumer market. Nobody else makes anything that competes, not even
> onboard video chipsets like Intel, SiS, etc.
My point was that nowadays most manufacturers, as a matter of course, do not
provide full details on how the hardware is programmed, and there appears to
be no significant market for high-performance 3D graphics with an open
specification.
I do not like owning a space heater with nifty DVI outputs, and that is a
fact I take into account when I make a purchasing decision for graphics cards
I will be using with Linux.
But I realize that ultimately, companies respond to markets, and not idealism
and know that ACME Hardware will publish the specs for their rocket-shoes when
the piece of the Linux rocket-shoe pie becomes lucrative enough. And because I
do, I try to change the market and educate consumers -- not browbeat companies
or turn the piece into a crumble by limiting what consumers can do.
-n
> Two of the specific arguments I've heard are (a) that the board (and
> its hardware interfaces that the documentation would describe) involve
> IP licensed from a third party, which the board manufacturer does not
> have a legal right to disclose,
If they can't disclose it, they can't sell it. If they can't sell it, it's
fraud to tell someone that they can buy it. If a contract with a third party
limits your ability to sell something to someone, you have to *tell* *them*
that they do not get all of the rights of ownership because you don't own
some of them and hence can't transfer them.
If I can't tell you what you're buying, I can't sell it to you. It's really
that simple. I might be able to make some kind of agreement with you that's
something like a sale, but it is not a normal sale and you are not buying
the expected type of ownership. To claim it's a sale is fraud.
> or (b) that there is, in fact, no
> suitable documentation, because the boards are developed somewhat
> fluidly and the driver is developed directly from low-level knowledge
> that simply isn't written down in a form suitable for passing on.
You can't sell something that doesn't exist. If you sell a car even though
you can't explain how anyone could drive it, that's fraud. A person who buys
something is entitled to be told how to operate it and make it work (and not
just the one way you think they should use it, they have the right to use it
any way they want if the transaction is a normal sale including all rights).
If you can't tell them that, then they are not actually buying all of the
thing.
> If you're building products with no expectation of supporting outside
> driver developers, both of those are quite possible.
And they're both quite fraudulent. You cannot both sell something and keep
its construction a secret. A person who owns something has a right to be
told what they're buying. If you are only selling some of the rights that
normally come with buying something, you cannot claim you are selling it
free and clear.
As I said before, this same thing used to happen with cell phones. I bought
a Primeco phone, fully believing that I fully owned it. However, Primeco
refused to tell me the code to unlock the phone, demanding $200 to do so.
That's simply fraud -- if I fully own the phone, free and clear, they have
no right to sell access to it to me. You can't sell the car and then charge
for the keys.
DS
David Schwartz <[email protected]> wrote:
[...]
> Honestly, I think it *is* wrong to sell someone a physical product and then
> not tell them how to make it work.
Right. And the driver *is* the "information to make it work", in a
convenient package.
[...]
> How would you feel if you bought a car and then discovered that the
> manufacturer had welded the hood shut? How many people still do their own
> oil changes anyway?
If people don't do this, what sense does it make to tell them how to do it
anyway?
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 2654431
Universidad Tecnica Federico Santa Maria +56 32 2654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513
David Schwartz <[email protected]> wrote:
> > Two of the specific arguments I've heard are (a) that the board (and
> > its hardware interfaces that the documentation would describe) involve
> > IP licensed from a third party, which the board manufacturer does not
> > have a legal right to disclose,
> If they can't disclose it, they can't sell it. If they can't sell it, it's
> fraud to tell someone that they can buy it. If a contract with a third party
> limits your ability to sell something to someone, you have to *tell* *them*
> that they do not get all of the rights of ownership because you don't own
> some of them and hence can't transfer them.
They aren't /selling/ you the rights to the driver, just charging you for
its /use/.
[...]
> > or (b) that there is, in fact, no
> > suitable documentation, because the boards are developed somewhat
> > fluidly and the driver is developed directly from low-level knowledge
> > that simply isn't written down in a form suitable for passing on.
> You can't sell something that doesn't exist. If you sell a car even though
> you can't explain how anyone could drive it, that's fraud.
Nonsense.
[...]
> > If you're building products with no expectation of supporting outside
> > driver developers, both of those are quite possible.
> And they're both quite fraudulent. You cannot both sell something and keep
> its construction a secret.
It is quite regularly done, so this argument won't fly.
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 2654431
Universidad Tecnica Federico Santa Maria +56 32 2654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513
On Fri, 22 Dec 2006 12:59:21 +0100, Erik Mouw said:
> On Thu, Dec 21, 2006 at 01:16:15PM -0500, [email protected] wrote:
> > At least nVidia *does* actually Get It, they just don't have a choice in
> > implementing it, because all their current hardware includes patents that
> > they licensed from other companies (I believe some of the OpenGL stuff that
> > originated at SGI and got bought by Microsoft is involved, but I have no
> > hard references for actual patent numbers). And then they have the big
> > problem - do they keep using the patent in order to boost performance,
> > or no?
>
> Wasn't the whole idea about patents that you publish your invention?
(Argh - I was too busy coming down with the flu to carefully read what I
wrote, and as a result I was a tad less that totally specific and accurate.
Hopefully I get it closer to right this time. ;)
Patent licenses are also a good place to hang all sorts of side agreements on -
and I'm pretty sure that the *actual* intellectual property involved is a
witches' brew of patents, copyrights, and trade secrets, all wrapped up with a
nice "thou shalt not disclose *any* of it" wrapper.
In any case, there isn't much that *any* company can do to open-source
something when they've got any sort of legally binding NDA attached to
3rd-party intellectual property. At best, they can design an entirely
new product that totally avoids the IP in question - but as I noted last
time, the company *does* have to do a sanity check when 90% of the market
doesn't care in the slightest.
On Fri, 22 Dec 2006 23:19:09 PST, David Schwartz said:
> You can't sell something that doesn't exist. If you sell a car even though
> you can't explain how anyone could drive it, that's fraud.
Are they allowed to sell a car that incorporates a computer that uses a
trade-secret algorithm for controlling the fuel injection to get 20 more
horsepower and 5% better mileage?
Am Sonntag, 24. Dezember 2006 07:46 schrieb [email protected]:
> Are they allowed to sell a car that incorporates a computer that
> uses a trade-secret algorithm for controlling the fuel injection to
> get 20 more horsepower and 5% better mileage?
That would be a propritary fuel injection driver then.
What we want however is access to the documentation, the
specifications, that allows us to develop a very own driver,
independently from the propritary one. We don't want source code or
anything. Of course if the hardware manufactor supplies us with
source code, that's great.
Probably any customly written driver will be suboptimal in the first
place, but OTOH there are so many skilled people around in the OSS
scene, that such a driver would surely soon catch up, if not even
surpass the propritary one.
Happy holydays
Wolfgang Draxinger
--
"sooner or later we'll reverse engineer you."
> On Fri, 22 Dec 2006 23:19:09 PST, David Schwartz said:
> > You can't sell something that doesn't exist. If you sell a car
> > even though
> > you can't explain how anyone could drive it, that's fraud.
> Are they allowed to sell a car that incorporates a computer that uses a
> trade-secret algorithm for controlling the fuel injection to get 20 more
> horsepower and 5% better mileage?
I assume that's a rhetorical question. Of course they are.
Now, let's try it another way: Are they allowed to sell a car that
incorporates a computer that uses a trade-secret algorithm for controlling
the fuel injection to get 20 more horsepower and 5% better mileage if it's
impossible to *start* the car without knowing that algorithm?
Then, I think it's obvious the answer is, of course, no. If you buy the car,
they have to tell you the algorithm.
If knowledge of the algorithm is required to use the car in a reasonable
way, even if it's not the normal expected way, then they can't keep it
secret. They can't sell something while keeping secret how to *use* it. And
that doesn't just mean the normal expected use. Buying something free and
clear allows you to use it even in unusual ways.
Perhaps that wasn't the best example. Let's try another one. You buy a car,
and then discover that the car computer has a lockout and a code needs to be
entered on the alarm panel to start the car between 4 AM and 4:15 AM on
Tuesdays. You ask the manufacturer for that code, since you would like to
start your car between 4 AM and 4:15 AM on Tuesdays even though many people
don't.
How many of the following answers would you consider fair:
1) We never wrote the code down. We knew it, but we didn't put it in a form
in which we can give it to you. Most people don't need it anyway. Sorry.
2) We're sorry. We know the code, but our contract with another company
prohibits us from disclosing it.
And so on.
Buying the car includes the right to start it between 4 AM and 4:15 AM on
Tuesdays if that's what you want to do. If the manufacturer couldn't sell
you the right or ability to do that, it couldn't sell you the car.
Owning a video card includes the right to make it work with Linux if that's
what you want to do. If the manufacturer couldn't sell you the right or
ability to do that, it couldn't sell you the video card.
DS
On Sun, 2006-24-12 at 09:33 -0800, David Schwartz wrote:
> > On Fri, 22 Dec 2006 23:19:09 PST, David Schwartz said:
>
> > > You can't sell something that doesn't exist. If you sell a car
> > > even though
> > > you can't explain how anyone could drive it, that's fraud.
>
> > Are they allowed to sell a car that incorporates a computer that uses a
> > trade-secret algorithm for controlling the fuel injection to get 20 more
> > horsepower and 5% better mileage?
>
> I assume that's a rhetorical question. Of course they are.
>
> Now, let's try it another way: Are they allowed to sell a car that
> incorporates a computer that uses a trade-secret algorithm for controlling
> the fuel injection to get 20 more horsepower and 5% better mileage if it's
> impossible to *start* the car without knowing that algorithm?
>
> Then, I think it's obvious the answer is, of course, no. If you buy the car,
> they have to tell you the algorithm.
>
> If knowledge of the algorithm is required to use the car in a reasonable
> way, even if it's not the normal expected way, then they can't keep it
> secret. They can't sell something while keeping secret how to *use* it. And
> that doesn't just mean the normal expected use. Buying something free and
> clear allows you to use it even in unusual ways.
>
> Perhaps that wasn't the best example. Let's try another one. You buy a car,
> and then discover that the car computer has a lockout and a code needs to be
> entered on the alarm panel to start the car between 4 AM and 4:15 AM on
> Tuesdays. You ask the manufacturer for that code, since you would like to
> start your car between 4 AM and 4:15 AM on Tuesdays even though many people
> don't.
>
> How many of the following answers would you consider fair:
>
> 1) We never wrote the code down. We knew it, but we didn't put it in a form
> in which we can give it to you. Most people don't need it anyway. Sorry.
>
> 2) We're sorry. We know the code, but our contract with another company
> prohibits us from disclosing it.
>
> And so on.
>
> Buying the car includes the right to start it between 4 AM and 4:15 AM on
> Tuesdays if that's what you want to do. If the manufacturer couldn't sell
> you the right or ability to do that, it couldn't sell you the car.
>
> Owning a video card includes the right to make it work with Linux if that's
> what you want to do. If the manufacturer couldn't sell you the right or
> ability to do that, it couldn't sell you the video card.
>
Here's my personal favourite example:
You walk into a car dealership to buy a new car, because your old car
is too slow to drive on the freeway; you need something faster.
The salesman shows you a great vehicle. He tells you all about how this
car is the pinnacle of automotive technology. It's got muscle. It's got
finesse. It's got tons of state of the art bells and whistles. Your
friends will be soooo jealous. Chicks will dig you. You have to have it.
You pay the man and have it delivered to you house.
When it arrives, you can't figure out how to open the door. The front
windows are opaque, so you can't see inside.
You: "Hey, delivery guy. How do I open the door on this thing?".
Guy: "I'm not the delivery guy. I'm your driver."
You: "Huh? Look, I don't need a driver, OK? I'll drive it myself. So how
do I open the door?"
Driver: "I'm sorry sir, but I can't tell you that. It's secret car
company stuff. If I told you, then our competition might find out how we
do it, and we would lose our competitive advantage."
You: "Whatever. I need to get to work. Let's go."
You get in the back seat, but there is an opaque barrier between you
and the front of the car.
Driver: "Just talk into the speaker on your left, sir, and I'll go where
you tell me to."
You get out on the freeway, but you're only going 30 kph.
You: "What the hell is wrong with this thing? I thought this car was the
fastest thing on the road. Pick it up, why don't you?"
Driver: "I'm sorry sir. I don't really know how to make the car go
faster than 30 kph. This is a new model, and the company hasn't yet
taught us how to drive it fast. Check in with them next month. They're
always training new drivers, and they might have a replacement for you
by then."
You: "Well that's just great. Let's get off the freeway. Take a left on
Broadway, at the bottom of the off-ramp."
You exit the freeway, but as you are turning left onto Broadway, your
car stalls in the intersection.
You: "Hey driver, WTF?"
Driver: "Sorry Sir, I seem t0 baeo ++_?+CFY^K$# ekbae."
The driver stumbles out of the car and starts spazzing out on the
ground. After a couple of minutes he's OK and you get back on the road.
There's an uncomfortable silence in the car. You don't tell him to turn
left any more.
Six months later, the company sends you a replacement driver.
Driver2: "Sorry it took so long sir. You see, there's not much call for
drivers who know the streets in this neighbourhood, or that speak your
language. Most of our clients speak Esperanto, and are over in the
business district. They have priority when drivers are trained."
The new driver can reach 70kph and he turns left by turning right three
times, so things are looking up. Still, the salesman told you this baby
can go 300kph, and you want to see it happen. You go to the company HQ
to talk with someone.
When you get there, the office is cleaned out, and there are eviction
notices plastered on the doors. Oh well, at least you still have a
driver. As long as the city doesn't alter the street layout in your
neighbourhood, he'll do just fine.
David Schwartz <[email protected]> wrote:
[...]
> Now, let's try it another way: Are they allowed to sell a car that
> incorporates a computer that uses a trade-secret algorithm for controlling
> the fuel injection to get 20 more horsepower and 5% better mileage if it's
> impossible to *start* the car without knowing that algorithm?
It is done regularly. Current cars control the fuel injection etc via an
onboard computer, without this control the engine just won't start. Did you
get the specs for the exact fuel control algorithm with your car? Should
you be able to fool around with that, thus violating emission control
measures (this would damage not only you, but everybody)?
Almost everything around you is controlled by a uP nowadays (it is much
cheaper/preciser to control e.g. the washing machine that way than via the
customary rotating wheels with notches). Did you get the specs for that?
Can you get them?
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 2654431
Universidad Tecnica Federico Santa Maria +56 32 2654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513
It seems that debate around cars and drivers has gone too far (IMHO). I
do not think
that there is a question if we have any right to demand details about
hardware from
manufactorers -> we are NOT. But I think that we have right to know how
to use it.
I will translate this to CAR language - We have to know how to drive
the car but
not all the details how is this done, so we can drive a car without the
"driver". We
do not need an exact knowledge about engine, ECU, suspension,...
Now the real question:
Why are manufatorers afraid to give us this information?
and
Who can benefit from this?
Let's that our manufactorer is not bound on licenced part of hardware.
If we would know the answers on those questions we could start thinking
how can we
convince Them to give us information we need to develop our own drivers.
Cheers
Rok Markovic
Rok Markovic <[email protected]> wrote:
> It seems that debate around cars and drivers has gone too far (IMHO).
Ditto.
> I
> do not think that there is a question if we have any right to demand
> details about hardware from manufactorers -> we are NOT.
OK.
> But I think that
> we have right to know how to use it.
The card is designed for use with /Windows/, you get a /Windows/ driver.
That your PC is able to also run, say, Plan 9, is not the manufacturer's
business at all, it is /your/ choice, and /your/ problem if what the
manufacturer provides doesn't help you there.
The manufacturer is keeping his part of the deal. You don't like the deal,
tough luck.
> I will translate this to CAR
> language - We have to know how to drive the car but not all the details
> how is this done, so we can drive a car without the "driver". We do not
> need an exact knowledge about engine, ECU, suspension,...
Exactly.
> Now the real question:
>
> Why are manufatorers afraid to give us this information?
Not "afraid". It is more expensive to them:
- Because they would have to pick developer's brains and write it down,
make sure it is complete, check it for publishing, etc. That costs money
(and ties up key developers, and...) for /very/ little gain (open source
systems is something like a 5 to 10% of all systems, mostly servers where
highest performance isn't asked for, so the market for current high-end
cards (where the brains are there at all for picking) is /extremely/
small).
- Because they would have to get permission to do so from third parties,
that means paying real money for little gain
- Because sometimes it is just "we tried several combinations, this one(s)
happen to work, dunno why". How do you write something like that down?
- Because wrong settings might break the hardware, people fiddling around
would then want a replacement, a very real cost
- Because you can't write any software at all without violating some
patent. In this area, it is probable that everybody is violating
everybody else's patents, and making that easy to find out (via source
code or specs) opens you up to lawsuits. Lawyers (and common sense) will
tell yo not to go there unless it is very worthwhile. And it isn't (see
above)
- See the bletcherous workarounds for many device bugs (or downright design
braindamage) in the in-kernel drivers. They might be just embarrased by
the junk they shove out the door (We all know it happens with software,
right? Hardware is much the same...). And they can't just work a year or
so longer to get them ironed out, by then they could be right out of
business.
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 2654431
Universidad Tecnica Federico Santa Maria +56 32 2654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513
Am Sonntag, 24. Dezember 2006 21:20 schrieb Horst H. von Brand:
> It is done regularly. Current cars control the fuel injection etc
> via an onboard computer, without this control the engine just won't
> start. Did you get the specs for the exact fuel control algorithm
> with your car? Should you be able to fool around with that, thus
> violating emission control measures (this would damage not only
> you, but everybody)?
You won't get access to the software source code, but the car
manufactors are required to document and publish the interfaces to
their hardware, so that also independent car workshops are able to do
maintenance and repair on it.
You have ever heared of chip tuning? Chip tuning is a replacement of
the original firmware with a 3rd party one, that will give higher
power and torque.
So your gave a perfect example from another industry, where the specs
are actually published.
Again: We don't want the original drivers being open sourced. All we
want is access to the hardware interface documentation, so that we
can develop our very own drivers. And heck: With a custom driver for
some RAID controller or a graphics card you will hardly violate any
regulations.
There might be issues with radio hardware, but surprisingly the
drivers for the good stuff (i.e. not those cheapo cards with lousy
range and throughput) are open source (Prism/HostAP).
I'd even say, that selling hardware without giving documentation is
illegal also from a competitions law point of view. By supplying a
driver only for a small range of operating systems you, as the
factual owner of a piece of hardware are hindered to use it in the
way you like, e.g. use it with the homebrew operating system you
wrote (or a finnish student wrote in 1991 ;-)). Thus the HW
manufactor delivering drivers only for a small range of operating
systems can be assumed to distort the market by biasing one specific
operting system manufactor _and_ hardware manufactors. Remember, that
many binary only drivers for Linux are only avaliable for the x86
variant. Only few are also avaliable for x86_64 (AMD64), even fewer
for IA64 and for other architectures it's getting homeopathic. This
is IMHO a extreme distortion of the free market.
Happy holydays
Wolfgang Draxinger
> > Now, let's try it another way: Are they allowed to sell a car that
> > incorporates a computer that uses a trade-secret algorithm for
> > controlling
> > the fuel injection to get 20 more horsepower and 5% better
> > mileage if it's
> > impossible to *start* the car without knowing that algorithm?
> It is done regularly. Current cars control the fuel injection etc via an
> onboard computer, without this control the engine just won't
> start.
So? You don't need to know the algorithm to start the car.
> Did you
> get the specs for the exact fuel control algorithm with your car? Should
> you be able to fool around with that, thus violating emission control
> measures (this would damage not only you, but everybody)?
If I bought the car from the manufacturer, it also must include any rights
the manufacturer might have to the car's use. That includes using the car to
violate emission control measures. If I didn't buy the right to use the car
that way (insofar as that right was owned by the car manufacturer), I didn't
buy the whole care -- just *some* of the rights to use it.
If I buy a device that has a safety of some kind, the manufacturer cannot
prohibit me from removing or disabling the safety unless some law gives them
that authority. Otherwise, I didn't buy all of the rights to that device,
just some of them. If the manufacturer kept the right to keep the safety
there, then they didn't sell me the whole product. It's no conceptually
different than if they kept the right to drive the car on Tuesdays.
If you bought the car, and it's a normal free and clear sale, then the
manufacturer retains no rights to say how the car is used. Any they might
have had, you bought from them. The exception is where operation of some
specific law changes the rules. (For example, you know that when you buy a
DVD of a movie, you do not get the right to charge admission to see the DVD.
But that's because a specific law retains that right for the copyright
holder.)
> Almost everything around you is controlled by a uP nowadays (it is much
> cheaper/preciser to control e.g. the washing machine that way than via the
> customary rotating wheels with notches). Did you get the specs for that?
> Can you get them?
So long as you don't *need* them to use the device, there's no issue. The
problem is when you need them to use the device (and not just the ordinary
expected way, any reasonable way). Then you are entitled to them.
James C. Georgas made this point better than I did with his example of a car
that includes a "driver".
DS
On 12/25/06, David Schwartz <[email protected]> wrote:
>
> If I bought the car from the manufacturer, it also must include any rights
> the manufacturer might have to the car's use. That includes using the car to
> violate emission control measures. If I didn't buy the right to use the car
> that way (insofar as that right was owned by the car manufacturer), I didn't
> buy the whole care -- just *some* of the rights to use it.
---
I have no idea why you assume that "having the right to do X" implies
"must be told how to do X". The have the right (except as laws
prohibit it) to modify the car's systems, but (except for some
specific legal requirements) the manufacturer is not required to
explain anything, even basic operation.
---
> If I buy a device that has a safety of some kind, the manufacturer cannot
> prohibit me from removing or disabling the safety unless some law gives them
> that authority. ...
---
Yes, I agree. However, they are completely allowed to make it
arbitrarily hard for you to remove (by, for instance, welding the
safety in place).
---
> > Almost everything around you is controlled by a uP nowadays (it is much
> > cheaper/preciser to control e.g. the washing machine that way than via the
> > customary rotating wheels with notches). Did you get the specs for that?
> > Can you get them?
>
> So long as you don't *need* them to use the device, there's no issue. The
> problem is when you need them to use the device (and not just the ordinary
> expected way, any reasonable way). Then you are entitled to them.
---
Again, (IANAL), I think this is simply a misconception. Buyng a
physical object gives you the right to do anything with it that the
law allows, but imposes no obligation on the seller to explain it
(other than specific restrictions hte law may apply to specific
classes of objects for safety or other reasons). It's up to you, in
deciding whether to buy it, to decide whether it comes with sufficient
documentation to satisfy your needs.
scott
> I have no idea why you assume that "having the right to do X" implies
> "must be told how to do X". The have the right (except as laws
> prohibit it) to modify the car's systems, but (except for some
> specific legal requirements) the manufacturer is not required to
> explain anything, even basic operation.
It's really common sense. Imagine if you buy the right to use my car, but I
don't give you the key. Can I say, "yes, you have the right to use my car,
you bought that, but that doesn't mean I have to tell you how to use my
car."
> > If I buy a device that has a safety of some kind, the
> > manufacturer cannot
> > prohibit me from removing or disabling the safety unless some
> > law gives them
> > that authority. ...
> Yes, I agree. However, they are completely allowed to make it
> arbitrarily hard for you to remove (by, for instance, welding the
> safety in place).
I do not think they can. You cannot at the same time argue that they sold me
the right to remove the safety and that they can take active steps to stop
me from using the safety.
Again, the same example -- you buy the right to use my car, but I shoot at
you every time you step on my property. Or I sell you my car, but right
before I do, I put on a lock that only I can unlock and make it deliberately
hard for you to remove it.
> Again, (IANAL), I think this is simply a misconception. Buyng a
> physical object gives you the right to do anything with it that the
> law allows,
Exactly.
> but imposes no obligation on the seller to explain it
> (other than specific restrictions hte law may apply to specific
> classes of objects for safety or other reasons). It's up to you, in
> deciding whether to buy it, to decide whether it comes with sufficient
> documentation to satisfy your needs.
I think that simply defies common sense. If I sold you a house and then
refused to provide you the keys, and made you break down the doors to get
in, you'd have every right to sue me. A house *has* *to* come with keys. If
not, the seller should bear the cost of your inability to use the house in a
reasonable way without damaging it.
You cannot sell something and then claim that you retained certain rights
over the thing you sold unless you either negotiated for those rights or
some law allows you to keep those rights. If you sell a computer, and it is
password-protected, the password has to come with it. You cannot keep it a
secret. You cannot negligently "happen to" lose it.
When you buy a video car, you are *not* buying the right to use that video
card with Windows. You are buying all the rights to the video card, to use
it any way you please. The manufacturer has no right (because it sold that
right when it sold the video card) to interfere or obstruct your right to
use it as you please.
If you retain some rights over something, then you are not selling it in the
normal sense. You are selling a subset of the rights to it, and the buy must
be told what rights he is getting and what rights he is not getting.
DS
Oh, if only for Christmas - stop this stupid car comparisons. They are
just that - utter nonsense.
>> I have no idea why you assume that "having the right to do X"
implies
>> "must be told how to do X". The have the right (except as laws
>> prohibit it) to modify the car's systems, but (except for some
>> specific legal requirements) the manufacturer is not required to
>> explain anything, even basic operation.
>It's really common sense. Imagine if you buy the right to use my
>car, but I don't give you the key.
I would sue you for fraud, because the key is "key" in using the car.
>Can I say, "yes, you have the right to use my car, you bought
>that, but that doesn't mean I have to tell you how to use my
>car."
You don't need to tell me how to use your car. I know that. All you
have to do is hand over the car, all the papers and of course the key.
You do not have to tell me how the motor-control is programmed. That
knowledge is not needed to operate the car.
>>> If I buy a device that has a safety of some kind, the
>>> manufacturer cannot prohibit me from removing or disabling the
>>> safety unless some law gives them that authority. ...
They might be obliged to make it as hard as possible to tamper with
the safety to prevent their (in the sense they made and sold it)
devices being used in illegal ways. Otherwise they could end up in
court themselves.
>> Yes, I agree. However, they are completely allowed to make it
>> arbitrarily hard for you to remove (by, for instance, welding the
>> safety in place).
> I do not think they can. You cannot at the same time argue that
> they sold me the right to remove the safety and that they can take
> active steps to stop me from using the safety.
The are not stopping you from using the safety. They are stopping you
from misusing it. And common sense does not show why they would be
required to help you in breaking the law. So, any of this is OK in my
opinion:
* voiding the warranty (and stating so) if you tamper with the safety
* block the function of the device if the safety has been tampered with
* not telling you how the thing works at all (unless you are a
certified car maintainer under NDA).
>Again, the same example -- you buy the right to use my car, but
>I shoot at you every time you step on my property.
Oh, come on. This is such utter nonsense. What has it to do with the
topic?
>Or I sell you my car, but right before I do, I put on a lock
>that only I can unlock and make it deliberately hard for you
>to remove it.
If it blocks me from using the car, I sue you for fraud. Because you
prevent the common sense use of my property.
>> Again, (IANAL), I think this is simply a misconception. Buyng a
>> physical object gives you the right to do anything with it that the
>> law allows,
>
>Exactly.
>> but imposes no obligation on the seller to explain it
>> (other than specific restrictions hte law may apply to specific
>> classes of objects for safety or other reasons).
Absolutely correct.
>>It's up to you, in deciding whether to buy it, to decide
>>whether it comes with sufficient documentation to satisfy
>>your needs.
>
>I think that simply defies common sense. If I sold you a house
>and then refused to provide you the keys, and made you break
>down the doors to get in, you'd have every right to sue me.
>A house *has* *to* come with keys. If not, the seller should
>bear the cost of your inability to use the house in a
>reasonable way without damaging it.
Another completely nonsensical example. Of course, if I sell you a
house and keep the keys after you have paid the agreed upon price, you
can sue me for fraud. But I do not have to explain how the lock works?
Do I?
>You cannot sell something and then claim that you retained
>certain rights over the thing you sold unless you either
>negotiated for those rights or some law allows you to keep those
>rights. If you sell a computer, and it is password-protected, the
>password has to come with it. You cannot keep it a secret. You
>cannot negligently "happen to" lose it.
Sure, I need to give you the password or a means to legally reset it.
But I do not have to explain the password algorithm to you. I don't
even have to tell you which algorithm is used, or which language it is
implemented in.
>When you buy a video car, you are *not* buying the right to use
>that video card with Windows. You are buying all the rights to
>the video card, to use it any way you please. The manufacturer
>has no right (because it sold that right when it sold the video
>card) to interfere or obstruct your right to use it as you please.
It depends what is written on the box, or what is in the contract. If
it says "works with XXX" (and it does), you have no right to demand
that it works with YYY, or that the manufacturer has to help you make
it work with YYY.
The manufacturer may not be allowed to *actively* prevent you from
making it work with YYY, but I see no legal problem (IANAL, in any
jurisdiction of the wolrd) if they make it hard for you by being
*passive*.
If they promised that it works with YYY, it is another story. They are
obliged to make it work or compensate you. How they make it work is up
to them, as long as they keep the promise. Whether you are satisfied is
up to you.
>If you retain some rights over something, then you are not selling it
>in the normal sense. You are selling a subset of the rights to it,
>and the buy must be told what rights he is getting and what rights
>he is not getting.
They are not keeping any right from you. They are just not being
helpful.
And now lets stop the car nonsense !!!! :-)
Martin
------------------------------------------------------
Martin Knoblauch
email: k n o b i AT knobisoft DOT de
www: http://www.knobisoft.de
On 12/25/06, David Schwartz <davids@xxxxxxxxxxxxx> wrote:
> If I bought the car from the manufacturer, it also must
> include any rights the manufacturer might have to the car's use.
> That includes using the car to violate emission control measures.
> If I didn't buy the right to use the car that way (insofar as
> that right was owned by the car manufacturer), I didn't
> buy the whole care -- just *some* of the rights to use it.
just to be dense - what makes you think that the car manufacturer has
any legal right to violate emission control measures? What an utter
nonsense (sorry).
So, lets stop the stupid car comparisons. They are no being funny any
more.
Martin
------------------------------------------------------
Martin Knoblauch
email: k n o b i AT knobisoft DOT de
www: http://www.knobisoft.de
On 12/26/06, Martin Knoblauch <[email protected]> wrote:
>
> Oh, if only for Christmas - stop this stupid car comparisons. They are
> just that - utter nonsense.
>
> And now lets stop the car nonsense !!!! :-)
I agree, if you really want to talk about cars, I can relate the woes
I've heard from mechanics about how impossible it is to service new
model Fords these days. Without the engine management systems
diagnostics devices they can't do anything. Ford controls who gets
these devices and demands a cut of every service, essentially setting
the price. Service centers that don't play ball don't get the devices
or get the devices taken away from them if they question Ford's
pricing policies. Of course, this should be illegal, and our
governments should be enforcing antitrust laws, but Ford is a big
company and has lots of lawyers..
Repco and other after market manufacturers can't easily make a clone
of these devices like they do every other part, because reverse
engineering software is not really as advanced as reverse engineering
spare parts.. or maybe software reverse engineering is just so much
more expensive than automotive reverse engineering that it is not cost
effective to clone these devices.. or maybe they're just afraid of the
lawyers too.
Trent
On Tue, 2006-26-12 at 03:20 -0800, Martin Knoblauch wrote:
> On 12/25/06, David Schwartz <davids@xxxxxxxxxxxxx> wrote:
>
> > If I bought the car from the manufacturer, it also must
> > include any rights the manufacturer might have to the car's use.
> > That includes using the car to violate emission control measures.
> > If I didn't buy the right to use the car that way (insofar as
> > that right was owned by the car manufacturer), I didn't
> > buy the whole care -- just *some* of the rights to use it.
>
> just to be dense - what makes you think that the car manufacturer has
> any legal right to violate emission control measures? What an utter
> nonsense (sorry).
>
> So, lets stop the stupid car comparisons. They are no being funny any
> more.
Let's summarize the current situation:
1) Hardware vendors don't have to tell us how to program their products,
as long as they provide some way to use it (i.e. binary blob driver).
2) Hardware vendors don't want to tell us how to program their products,
because they think this information is their secret sauce (or maybe
their competitor's secret sauce).
3) Hardware vendors don't tell us how to program their products, because
they know about (1) and they believe (2).
4) We need products with datasheets because of our development model.
5) We want products with capabilities that these vendors advertise.
6) Products that satisfy both (4) and (5) are often scarce or
non-existent.
So far, the suggestions I've seen to resolve the above conflict fall
into three categories:
a) Force vendors to provide datasheets.
b) Entice vendors to provide datasheets.
c) Reverse engineer the hardware and write our own datasheets.
Solution (a) involves denial of point (1), mostly through the use of
analogy and allegory. Alternatively, one can try to change the law
through government channels.
Solution (b) requires market pressure, charity, or visionary management.
We can't exert enough market pressure currently to make much difference.
Charity sometimes gives us datasheets for old hardware. Visionary
management is the future.
Solution (c) is what we do now, with varying degrees of success. A good
example is the R300 support in the radeon DRM module.
Did I miss anything?
--- James C Georgas <[email protected]> wrote:
> On Tue, 2006-26-12 at 03:20 -0800, Martin Knoblauch wrote:
> > On 12/25/06, David Schwartz <davids@xxxxxxxxxxxxx> wrote:
> >
> > > If I bought the car from the manufacturer, it also must
> > > include any rights the manufacturer might have to the car's use.
> > > That includes using the car to violate emission control measures.
> > > If I didn't buy the right to use the car that way (insofar as
> > > that right was owned by the car manufacturer), I didn't
> > > buy the whole care -- just *some* of the rights to use it.
> >
> > just to be dense - what makes you think that the car manufacturer
> has
> > any legal right to violate emission control measures? What an utter
> > nonsense (sorry).
> >
> > So, lets stop the stupid car comparisons. They are no being funny
> any
> > more.
>
> Let's summarize the current situation:
>
> 1) Hardware vendors don't have to tell us how to program their
> products, as long as they provide some way to use it
> (i.e. binary blob driver).
>
Correct, as far as I can tell.
> 2) Hardware vendors don't want to tell us how to program their
> products, because they think this information is their secret
> sauce (or maybe their competitor's secret sauce).
>
- or they are ashamed to show the world what kind of crap they sell
- or they have lost (never had) the documentation themselves. I tend
to no believe this
> 3) Hardware vendors don't tell us how to program their products,
> because they know about (1) and they believe (2).
>
- or they are just ignorant
> 4) We need products with datasheets because of our development model.
>
- correct
> 5) We want products with capabilities that these vendors advertise.
>
we want open-spec products that meet the performance of the high-end
closed-spec products
> 6) Products that satisfy both (4) and (5) are often scarce or
> non-existent.
>
unfortunatelly
>
> So far, the suggestions I've seen to resolve the above conflict fall
> into three categories:
>
> a) Force vendors to provide datasheets.
>
> b) Entice vendors to provide datasheets.
>
> c) Reverse engineer the hardware and write our own datasheets.
>
> Solution (a) involves denial of point (1), mostly through the use of
> analogy and allegory. Alternatively, one can try to change the law
> through government channels.
>
good luck
> Solution (b) requires market pressure, charity, or visionary
> management.
> We can't exert enough market pressure currently to make much
> difference.
> Charity sometimes gives us datasheets for old hardware. Visionary
> management is the future.
>
- Old hardware is not interesting in most markets
- Visionary mamangement is rare
> Solution (c) is what we do now, with varying degrees of success. A
> good example is the R300 support in the radeon DRM module.
>
But the R300 does not meet 5)
Cheers
Martin
------------------------------------------------------
Martin Knoblauch
email: k n o b i AT knobisoft DOT de
www: http://www.knobisoft.de
--- Trent Waddington <[email protected]> wrote:
> On 12/26/06, Martin Knoblauch <[email protected]> wrote:
> >
> > Oh, if only for Christmas - stop this stupid car comparisons. They
> are
> > just that - utter nonsense.
> >
> > And now lets stop the car nonsense !!!! :-)
>
> I agree, if you really want to talk about cars, I can relate the woes
> I've heard from mechanics about how impossible it is to service new
> model Fords these days.
A behaviour that is not very different from gthe GMs, BMWs,
daimler-Chryslers, Toyota, "you name them" of this world.
I never said I liked the attitude.
> Without the engine management systems
> diagnostics devices they can't do anything. Ford controls who gets
> these devices and demands a cut of every service, essentially setting
> the price. Service centers that don't play ball don't get the
> devices or get the devices taken away from them if they question
> Ford's pricing policies. Of course, this should be illegal, and our
> governments should be enforcing antitrust laws, but Ford is a big
> company and has lots of lawyers..
>
Actually we have/had a similar situation here in Germany. We are used
to having "licensed dealerships" which are only allowed to sell one car
brand. This might be illegal by EU laws now.
> Repco and other after market manufacturers can't easily make a clone
> of these devices like they do every other part, because reverse
> engineering software is not really as advanced as reverse engineering
> spare parts.. or maybe software reverse engineering is just so much
> more expensive than automotive reverse engineering that it is not
> cost effective to clone these devices.. or maybe they're just afraid
> of the lawyers too.
>
Understanding software is more difficult, because you also have to
understand the working prinziple of the underlying hardware, which you
often have no specs for either. So you have to reverse engineer both
layers.
Cheers
Martin
------------------------------------------------------
Martin Knoblauch
email: k n o b i AT knobisoft DOT de
www: http://www.knobisoft.de
Combined responses:
> > If I bought the car from the manufacturer, it also must
> > include any rights the manufacturer might have to the car's use.
> > That includes using the car to violate emission control measures.
> > If I didn't buy the right to use the car that way (insofar as
> > that right was owned by the car manufacturer), I didn't
> > buy the whole care -- just *some* of the rights to use it.
> just to be dense - what makes you think that the car manufacturer has
> any legal right to violate emission control measures? What an utter
> nonsense (sorry).
That's why I said "insofar as that right was owned by the car manufacturer".
The example of emission control measures wasn't mine. I'm responding to a
silly hypothetical.
> So, lets stop the stupid car comparisons. They are no being funny any
> more.
They were never intended to be funny. They only become stupid when people
deliberately pointed out the cases where the examples differ from the case
we're realling interested in. I agree that examples involving cases where
there are specific laws (such as emissions control) are silly.
The point is that any rights the manufacturer may have had to the car should
have been sold along with the car, otherwise it's not a normal free and
clear sale. A normal free and clear sale includes all rights to the item
sold, except those specific laws allows the manufacturer to retain.
All the issues about whether the manufacturer has the right to break the law
or whether the manufacturer has to help you break the law are not in any way
relevant to the hardware issue we were discussion. Someone brought them up
just to sidetrack the analogies.
That's a very good way to make an analogy seem irrelevent, but it's
cheating. So long as you stick to the issues that relate, the analogy is
nearly perfect. See, for examlek, James C. Georgas post.
--
>Solution (a) involves denial of point (1), mostly through the use of
>analogy and allegory. Alternatively, one can try to change the law
>through government channels.
One doesn't need to change the law, just enforce it.
I simply do not accept the argument that it is lawful for a manufacturer to
sell a physical object in a normal free and clear sale and then refuse to
disclose the knowledge necessary to use it. (And by that I mean necessary to
use it any reasonable way, not just the way the manufacturer intended it to
be used.)
This same issue has been pressed in other areas and I think it's time it be
pressed with graphics cards.
DS
On 12/26/06, David Schwartz <[email protected]> wrote:
>
> It's really common sense. Imagine if you buy the right to use my car, but I
> don't give you the key. Can I say, "yes, you have the right to use my car,
> you bought that, but that doesn't mean I have to tell you how to use my
> car."
---
I have to agree with Martin, that the car analogies really bear little
relationship with the question of closed-source drivers...
My point was that you buy what you buy, under the terms that you agree
to. For a house, or a car, the "normal" terms would include any
associated accessories, including keys. Keys also have a certain
common-law "specialness", because they historically corresponded to
the right to access. If you were buying a house or car and the seller
was retaining keys (perhaps because they have some historical or
personal significance), that would have to be disclosed and it would
have to be clear that no rights were associated with the retained
keys.
---
> ... Skipping the rest of the house/car analogies...
> When you buy a video car, you are *not* buying the right to use that video
> card with Windows. You are buying all the rights to the video card, to use
> it any way you please. The manufacturer has no right (because it sold that
> right when it sold the video card) to interfere or obstruct your right to
> use it as you please.
---
There is a notion of "fitness for purpose" that sometimes applies - if
the seller describes the object as fit for a particular purpose, then
the seller has an obligation to make sure the object is, in fact, fit
for that purpose. However, that's a very limited requirement - it's
not required to be fit for any other purpose and being fit for that
purpose would not require documentation unless that purpose normally
required it. Note that selling a card as suitable for use with Windows
would not suggest, in any way, that it was offered as suitable for use
with Linux. Again, you buy the right to do anything you like with the
object, but the seller has no obligation beyond the agreed terms.
---
> If you retain some rights over something, then you are not selling it in the
> normal sense. You are selling a subset of the rights to it, and the buy must
> be told what rights he is getting and what rights he is not getting.
---
Again, while some of the car/house analogies may describe situations
where the seller has not conveyed all the rights, the video card
situation is completely different. You have the right to do what you
like with it and the seller retains no rights. Lack of documentation
is not an imposition on your rights, unless you had a specific promise
of documentation from the seller.
scott
> Again, while some of the car/house analogies may describe situations
> where the seller has not conveyed all the rights, the video card
> situation is completely different. You have the right to do what you
> like with it and the seller retains no rights. Lack of documentation
> is not an imposition on your rights, unless you had a specific promise
> of documentation from the seller.
I'm curious if you really believe this. So let me set up one last
hypothetical.
You buy a phone for $200. The manufacturer only represents that it works
with CarrierCo. (You do not buy the phone form CarrierCo.)
Two months later, CarrierCo stops supporting your phone's configuration. You
need to make a configuration change to the phone to get it to work on
CarrierCo's "newly upgraded" network.
You go to change the phone's configuration and you discover it requires a
code. You call the manufacturer of the phone and say "hey, it's my phone,
give me my lock out code". The manufacturer says, "sure, for $450".
You have the right to do what you like with the phone, of course. It's a
great doorstop and a reasonable paper weight. The manufacturer didn't
promise the phone's configuration wouldn't become obsolete or that you would
be able to change the configuration. Lack of documentation is not an
imposition on your rights, and you had no specific promise of documentation
from the seller.
I have to say, it honestly astonishes me that would people would make
arguments like these. Are we so used to these kinds of one-sided
arrangements that we've lost our common sense?
DS
James C Georgas <[email protected]> wrote:
[...]
> Let's summarize the current situation:
> 1) Hardware vendors don't have to tell us how to program their products,
> as long as they provide some way to use it (i.e. binary blob driver).
No. They have absolutely no obligation to tell you anything. If they sell
you a card with a binary driver that /only/ works with, say, Minix, it is
up to you to buy it or not.
> 2) Hardware vendors don't want to tell us how to program their products,
> because they think this information is their secret sauce (or maybe
> their competitor's secret sauce).
And lots of other reasons, including that with detailed specs you might be
able to continue using the same card for 3 or 5 years, when they'd love to
sell you a replacement next year... Creating, vetting and maintaining specs
is /hard/ work, and costs money. If it won't bring a measurable increase in
income, why do it?
> 3) Hardware vendors don't tell us how to program their products, because
> they know about (1) and they believe (2).
The law says (1), and they know (2) for a fact.
> 4) We need products with datasheets because of our development model.
Yep.
> 5) We want products with capabilities that these vendors advertise.
Yep.
> 6) Products that satisfy both (4) and (5) are often scarce or
> non-existent.
Just too bad.
> So far, the suggestions I've seen to resolve the above conflict fall
> into three categories:
> a) Force vendors to provide datasheets.
How?
> b) Entice vendors to provide datasheets.
How?
> c) Reverse engineer the hardware and write our own datasheets.
Not always legal...
> Solution (a) involves denial of point (1), mostly through the use of
> analogy and allegory.
These are big companies, who deal in hard realities and cold cash. Poetry
won't get you anywhere.
> Alternatively, one can try to change the law
> through government channels.
Won't happen before open source is so prevalent that the point has long
become moot.
> Solution (b) requires market pressure,
Will happen once open source has a large enough slice of a lucrative pie.
I.e., it is happening today with "server class" machines.
> charity,
A company is bound /by law/ to make as much profit as possible. Whoever
wants to go this route might spend some time as a neighbor to the Enron et
al folks.
> or visionary management.
This cuts both ways... visionary management made small companies big, and
huge companies dissappear from the face of the earth.
> We can't exert enough market pressure currently to make much difference.
OK.
> Charity sometimes gives us datasheets for old hardware.
OK.
> Visionary
> management is the future.
Don't they tell that all aspiring MBAs...
> Solution (c) is what we do now, with varying degrees of success. A good
> example is the R300 support in the radeon DRM module.
And others.
And this is not the only avenue persued, not by far. Some developers are
chummy with the engineers behind the devices they support, and get some
help that way. There are people who convinced their companies to let them
work on Linux drivers on their own time (with access to the people in the
know and datasheets, one would presume), others have gone so far as to be
able to work part-time on Linux drivers. Some companies have hired
developers under NDA to develop drivers, others have given out datasheets
(and access to sample hardware) under NDA (or just "don't give this out too
freely") to interested developers. Then there are others (IBM comes to
mind) where the company itself is officially developing drivers for their
hardware. Sure, most of the more backstage deals you won't ever hear about,
and for some of the other cases you might have absolutely no interest. Fact
is, Linux has /by far/ the best hardware support of all operating systems
out there. You only notice the (small) minority of devices that don't work
(yet). Sure, it is mostly in the latest glitter where support is currently
lacking, and this distorts the perspective quite a bit.
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 2654431
Universidad Tecnica Federico Santa Maria +56 32 2654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513
David Schwartz <[email protected]> wrote:
[..]
.
> The point is that any rights the manufacturer may have had to the car should
> have been sold along with the car, otherwise it's not a normal free and
> clear sale. A normal free and clear sale includes all rights to the item
> sold, except those specific laws allows the manufacturer to retain.
This is complete nonsense. The car manufacturer can very well agree with
you to sell you the right to only drive the car on weekdays, and rent it
off on weekends. Nothing forces them to sell "all rights they have on the
car".
[...]
> I simply do not accept the argument that it is lawful for a manufacturer to
> sell a physical object in a normal free and clear sale and then refuse to
> disclose the knowledge necessary to use it.
Ask a lawyer about this, don't impose your wacky legal theories on us.
> (And by that I mean necessary to
> use it any reasonable way, not just the way the manufacturer intended it to
> be used.)
Define "reasonable way". The manufacturer could very well define it as "use
the XYZ graphics card on Windows XP service pack 2", as it was designed
specifically for that environment. Everything else (use on Linux, for
example) is then "unreasonable use", and need not be supported at all.
> This same issue has been pressed in other areas
Examples?
> and I think it's time it be
> pressed with graphics cards.
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 2654431
Universidad Tecnica Federico Santa Maria +56 32 2654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513
On 12/26/06, David Schwartz <[email protected]> wrote:
>
> You buy a phone for $200. The manufacturer only represents that it works
> with CarrierCo. ...
>
> You have the right to do what you like with the phone, of course. It's a
> great doorstop and a reasonable paper weight. The manufacturer didn't
> promise the phone's configuration wouldn't become obsolete or that you would
> be able to change the configuration. Lack of documentation is not an
> imposition on your rights, and you had no specific promise of documentation
> from the seller.
>
> I have to say, it honestly astonishes me that would people would make
> arguments like these. Are we so used to these kinds of one-sided
> arrangements that we've lost our common sense?
---
If the manufacturer knew about the forthcoming configuration change,
you might have a fraud claim. Otherwise it's just bad luck, which
happens sometimes.
I'm not familiar with any situations where the manufacturer locks the
phone. Locks are usually applied by the carrier in return for a
subsidy. Once any contract restrictions are over, you would have the
right to attempt to unlock the phone or to find someone who could do
so. For most phones in the market today, I understand that to be a
relatively easy thing to find. In the US, the Copyright office
recently ruled that there should be an exception to the DMCA so that
circumventing the lock would not be a DMCA violation.
I don't know why you think of this as a particularly unfair situation.
There's at least a chance that the phone might be reconfigurable. The
phone might as easily have been physically unable to work with the new
configuration. If you bought, for instance, an Iridium phone (which
worked only on the Iridium satellite network and had no other useful
function), it became a paperweight when the network ceased operation.
You could sell the device on ebay or attempt to salvage parts of it
for other purposes, but otherwise you're just out of luck.
scott
Horst H. von Brand wrote:
> David Schwartz <[email protected]> wrote:
>
> [..]
> .
>> The point is that any rights the manufacturer may have had to the car should
>> have been sold along with the car, otherwise it's not a normal free and
>> clear sale. A normal free and clear sale includes all rights to the item
>> sold, except those specific laws allows the manufacturer to retain.
>
> This is complete nonsense. The car manufacturer can very well agree with
> you to sell you the right to only drive the car on weekdays, and rent it
> off on weekends. Nothing forces them to sell "all rights they have on the
> car".
You failed to notice the "free and clear" part of David's post.
-n
Do we have a right to reverse engineer hardware, or they are protected by
patents or something similar that would prevent you from publishing results
adn/or drivers (open source).
Are there any restrictions in how you obtain information - signal analyser,
disassembly of windows driver, etc.
Rok Markovic
On 12/28/06, Rok Markovic <[email protected]> wrote:
> Do we have a right to reverse engineer hardware, or they are protected by
> patents or something similar that would prevent you from publishing results
> adn/or drivers (open source).
This is a pretty good resource:
http://www.chillingeffects.org/reverse/faq.cgi
Yes, there are probably patents covering this hardware stuff.. and
that's why we have all those open source companies that have given
their patents to an entity that promises to sue in retalitation if
they try to use their patents against open source. So let's not worry
about patents ok? They'd be screwed more than us if they try to use
them.
>
> Are there any restrictions in how you obtain information - signal analyser,
> disassembly of windows driver, etc.
Not as far as I am aware. Obviously if you were to disassemble a
windows driver, add a wrapper and reassemble, that would be copying..
but if you are trying to figure out how something works by reverse
engineering a windows driver then that's ok. At least it is where I
live (Australia) because we have laws that allow us to ignore license
restrictions that say "thou shalt not reverse engineer" for most
interesting purposes. Maybe you have similar laws where you live.
Maybe not.
Hope that helps,
Trent
> Do we have a right to reverse engineer hardware, or they are protected by
> patents or something similar that would prevent you from
> publishing results
> adn/or drivers (open source).
As I understand the issues, you have the right to reverse engineer hardware except where the DMCA applies. I don't see any way a patent or similar could prevent you from publishing results. Again, the DMCA might.
> Are there any restrictions in how you obtain information - signal
> analyser,
> disassembly of windows driver, etc.
There are a few things that might be able to impose such a restriction on you. If none of these apply, I think you should be okay: Any EULA, shrink-wrap, or click-through type agreement that might apply to the software (whether the driver, OS, analyzer, or whatever). Also, any actual agreement you entered into.
Patents don't provide any ability to keep things secret. Copyright doesn't apply to a creative work you made yourself, even if it describes the creative work of another in *functional* detail.
IANAL, and I might have missed something. IMO, the DMCA or a driver EULA are the only things you really need to worry about. It's hard to see how the DMCA would apply if we're not talking about some kind of content protection scheme.
DS
On Thu, 28 Dec 2006, David Schwartz wrote:
> Patents don't provide any ability to keep things secret. Copyright doesn't
> apply to a creative work you made yourself, even if it describes the creative
> work of another in *functional* detail.
in fact, to get a Patent you are required to explain the invention in sufficant
detail for somone 'normally skilled' in the field to be able to duplicate it.
the Patent protection is a reward for _not_ keeping thing secret and publicising
the details.
at least in that's how it's supposed to work.
David Lang
On Fri, 2006-12-22 at 12:59 +0100, Erik Mouw wrote:
> On Thu, Dec 21, 2006 at 01:16:15PM -0500, [email protected] wrote:
> > At least nVidia *does* actually Get It, they just don't have a choice in
> > implementing it, because all their current hardware includes patents that
> > they licensed from other companies (I believe some of the OpenGL stuff that
> > originated at SGI and got bought by Microsoft is involved, but I have no
> > hard references for actual patent numbers). And then they have the big
> > problem - do they keep using the patent in order to boost performance,
> > or no?
>
> Wasn't the whole idea about patents that you publish your invention?
Of course.
But it is much better for the patent-interested parties if it wouldn't
be necessary (and said parties are actually complaining about the "must
publish" thing).
And the times are long gone when a patent was actually "publishing".
They use since ages there own secret language so
- the patent system as such doen not enforce "publisching" (except you
are one of speakers of "patent quak").
- that even the most trivial idea looks like it is very complicated.
- that even an already implemented idean looks like it is very new.
Bernd
--
Firmix Software GmbH http://www.firmix.at/
mobil: +43 664 4416156 fax: +43 1 7890849-55
Embedded Linux Development and Services
> > On Thu, Dec 21, 2006 at 01:16:15PM -0500, [email protected] wrote:
> > > At least nVidia *does* actually Get It, they just don't have a choice in
> > > implementing it, because all their current hardware includes patents that
> > > they licensed from other companies
What makes you think they "get it"?
In a recent interview
(http://bsdtalk.blogspot.com/2006/07/bsdtalk054-interview-with-andy-ritger.html)
the nvidia developer had this to say:
"Quite honestly we have a lot of ip sorrounding both our hardware and
our software. And so the driver we provide is binary only, ya know, to
protect that intellectual property. You know, I guess, on a software
side, so much of what we do, err, of the code that comprises that
drivers is common and leveraged across all the operating systems and I
think that is a big benefit. You know we are able to accomplish a lot
with a fairly small, err, unix specific engineering team because we're
able to leverage so much common code. Ya know, that really is a big
win for us and our users, and so, ya know, we provide a binary only
driver to protect that ip. Umm, that said, we do try to, ya know,
provide source for, err, ya know, for things when it makes sense and
its possible to do so. I guess for our various unix graphics drivers,
the interface between *cough* excuse me, the core of the binary, err
the core of the kernel module is operating system neutral .. is
shipped binary only but anything that, ya know, interacts directly
with, with unix kernel, be it linux or freebsd or whatever, we provide
the source code to that interface layer. Similarly, err, I guess, up
in user space, umm, you know, we were talking either about, umm, the
nvida X extension and our control panel nvidia-settings. The source
code for that is provided as GPL. We provide a command line tool
nvidia-xconfig for manipulating your xconfiguration files. We provide
that as GPL. So we do try to provide source code to those sorts of
utilities and things like that when it makes sense. Umm, but the core
of our driver, we only provide as binary."
Yeah, really sounds like he "gets it".
Why don't you release source? To protect the intellectual property.
Well, duh! That's why everyone holds back source. So allow me to
translate..
Why don't you release source? Because we don't believe in freedom, we
don't "get it" and we don't want you to have it.
That wasn't some marketting stooge they were interviewing either, it
was two of the guys who work on the unix porting team for the nvidia
drivers.
They don't get it.
Trent
> Why don't you release source? To protect the intellectual property.
> Well, duh! That's why everyone holds back source. So allow me to
> translate..
That IP story is for the most part not even credible. If they were worried
about "software IP" they would release hardware docs and let us get on
with writing drivers that may well not be as cool as theirs but would
work. If they had real IPR in their hardware then they would hold patents
on it and would be able to take action against (or license it) to anyone
else making hardware. That would apply even outside the USA where
software patents are generally not valid.
The only hardware IP they'd need to protect would appear to be anything
that revealed they used other people's IPR without permission or
licenses. Given the Nvidia/3Dfx affair I can see why they would be
worried about that given it cost them $70M and 1 million shares.
Alan
Hi!
> >You're not alone, I think everybody who knows, how
> >things in a
> >computer work shares this view.
> ---
>
> Two of the specific arguments I've heard are (a) that
> the board (and
> its hardware interfaces that the documentation would
> describe) involve
> IP licensed from a third party, which the board
> manufacturer does not
> have a legal right to disclose, or (b) that there is, in
> fact, no
> suitable documentation, because the boards are developed
> somewhat
> fluidly and the driver is developed directly from
> low-level knowledge
> that simply isn't written down in a form suitable for
> passing on.
So just opensource the driver. It is usually easy to port it, and
possible to clean it up.
I have once ported cd-rom driver from DOS to linux (do you still
remember cdroms not talking ATA?) -- in 2days or so, and the comments
in driver were in korean.
Pavel
--
Thanks for all the (sleeping) penguins.
On Sun, 31 Dec 2006 17:09:43 GMT, Alan said:
> That IP story is for the most part not even credible. If they were worried
> about "software IP" they would release hardware docs and let us get on
> with writing drivers that may well not be as cool as theirs but would
> work. If they had real IPR in their hardware then they would hold patents
> on it and would be able to take action against (or license it) to anyone
> else making hardware. That would apply even outside the USA where
> software patents are generally not valid.
>
> The only hardware IP they'd need to protect would appear to be anything
> that revealed they used other people's IPR without permission or
> licenses. Given the Nvidia/3Dfx affair I can see why they would be
> worried about that given it cost them $70M and 1 million shares.
Hey, I started out *up front* pointing out they can't open-source the
drivers because some of the IP is other people's, didn't I? :)
On Sun, 31 Dec 2006 23:03:27 +1000, Trent Waddington said:
> Why don't you release source? To protect the intellectual property.
> Well, duh! That's why everyone holds back source. So allow me to
> translate..
>
> Why don't you release source? Because we don't believe in freedom, we
> don't "get it" and we don't want you to have it.
There's believing in freedom, and there's wanting to be able to ship code
without getting sued...
The binary blob in question is several megabytes in size. Now, even
totally *ignoring* who knowingly licensed/stole/whatever IP from who,
that *still* leaves the problem of trying to write several megabytes of
code that doesn't infringe on anybody's IP - particularly some of those
vague submarine patents that should have been killed on "prior art" or
"obviousness" grounds.
So tell me - how *do* you release that much code without worrying about IP
issues?
Remember - somebody *can* "get it" but be unable to actually *deploy*.
I *get* the whole global warming thing - but I'm not in a position to buy
a hybrid car unless somebody else kicks in US$15K or $20K or so.
On Mon, Jan 01, 2007 at 11:04:49PM -0500, [email protected] wrote:
> On Sun, 31 Dec 2006 23:03:27 +1000, Trent Waddington said:
> > Why don't you release source? To protect the intellectual property.
> > Well, duh! That's why everyone holds back source. So allow me to
> > translate..
> >
> > Why don't you release source? Because we don't believe in freedom, we
> > don't "get it" and we don't want you to have it.
>
> There's believing in freedom, and there's wanting to be able to ship code
> without getting sued...
>
> The binary blob in question is several megabytes in size. Now, even
> totally *ignoring* who knowingly licensed/stole/whatever IP from who,
> that *still* leaves the problem of trying to write several megabytes of
> code that doesn't infringe on anybody's IP - particularly some of those
> vague submarine patents that should have been killed on "prior art" or
> "obviousness" grounds.
You know, not releasing source code doesn't make "IP" violations
magically disappear, so if anything you should be more suspicious about
closed source drivers infringing others patents than anything.
> So tell me - how *do* you release that much code without worrying about IP
> issues?
If you have to worry about "IP", you're screwed no matter if you release
source or not. The only problem is that it might be trickier for the
other party to prove. The only case where a closed source driver makes
some kind of sense from an "IP" point of view is when you're trying to
protect your own code (or code you have licensed).
> Remember - somebody *can* "get it" but be unable to actually *deploy*.
> I *get* the whole global warming thing - but I'm not in a position to buy
> a hybrid car unless somebody else kicks in US$15K or $20K or so.
Well, you can always make a contribution by using public transportation
or switching to low energy light bulbs. Every little thing counts =)
Regards: David
--
/) David Weinehall <[email protected]> /) Northern lights wander (\
// Maintainer of the v2.0 kernel // Dance across the winter sky //
\) http://www.acc.umu.se/~tao/ (/ Full colour fire (/
On 1/2/07, [email protected] <[email protected]> wrote:
> The binary blob in question is several megabytes in size. Now, even
> totally *ignoring* who knowingly licensed/stole/whatever IP from who,
> that *still* leaves the problem of trying to write several megabytes of
> code that doesn't infringe on anybody's IP - particularly some of those
> vague submarine patents that should have been killed on "prior art" or
> "obviousness" grounds.
>
> So tell me - how *do* you release that much code without worrying about IP
> issues?
I'm going to try really hard to ignore how flammable your response
is.. I guess I deserve it.
I think you're repeating a myth that has become a common part of
hacker lore in recent years. It's caused by how little we know about
software patents. The myth is that if you release source code which
violates someone's patent that is somehow worse than if you release
binaries that violate someone's patent. This is clearly, obviously,
false. If you're practising the invention without a license in your
source code then you're practising the invention without a license in
binaries compiled from that source code. Period.
Nvidia are not releasing source code to their drivers for one reason:
it's not their culture. They don't see the need. They don't see the
benefit.
Trent
On Tue, 2007-01-02 at 16:30 +1000, Trent Waddington wrote:
[...]
> I think you're repeating a myth that has become a common part of
> hacker lore in recent years. It's caused by how little we know about
> software patents. The myth is that if you release source code which
> violates someone's patent that is somehow worse than if you release
> binaries that violate someone's patent. This is clearly, obviously,
> false. If you're practising the invention without a license in your
> source code then you're practising the invention without a license in
> binaries compiled from that source code. Period.
While this is true (at last in theory), there is one difference in
practice: It is *much* easier to prove a/the patent violation if you
have (original?) source code than to reverse engineer the assembler dump
of the compiled code and prove the patent violation far enough to get to
a so-called "agreement" on the costs.
> Nvidia are not releasing source code to their drivers for one reason:
> it's not their culture. They don't see the need. They don't see the
> benefit.
Which also may well be true.
Bernd
--
Firmix Software GmbH http://www.firmix.at/
mobil: +43 664 4416156 fax: +43 1 7890849-55
Embedded Linux Development and Services
> I think you're repeating a myth that has become a common part of
> hacker lore in recent years. It's caused by how little we know about
> software patents. The myth is that if you release source code which
> violates someone's patent that is somehow worse than if you release
> binaries that violate someone's patent. This is clearly, obviously,
> false. If you're practising the invention without a license in your
> source code then you're practising the invention without a license in
> binaries compiled from that source code. Period.
You are forgetting the 11th commandment - thou shalt not get caught.
Most software patents (actually quite probably most patents) are held by
people who don't have the skills to go disassembling megabytes of code in
search of offenders.
Alan
On 1/2/07, Bernd Petrovitsch <[email protected]> wrote:
> While this is true (at last in theory), there is one difference in
> practice: It is *much* easier to prove a/the patent violation if you
> have (original?) source code than to reverse engineer the assembler dump
> of the compiled code and prove the patent violation far enough to get to
> a so-called "agreement" on the costs.
On 1/2/07, Alan <[email protected]> wrote:
> You are forgetting the 11th commandment - thou shalt not get caught.
> Most software patents (actually quite probably most patents) are held by
> people who don't have the skills to go disassembling megabytes of code in
> search of offenders.
The list of features which the driver supports is going to be
sufficient evidence for 99% of patents that relate to computer
graphics hardware.
Regardless, in the *millions* of dollars that it costs to prosecute a
patent violation case I think they can find a few grand to throw at a
disassembler jockey.
So I'll take back what I said.. it does make some difference whether
you release patent violating source code or patent violating binaries.
It makes about a 1% difference to the overall cost of prosecuting a
patent lawsuit.
Now if you are done speculating why nvidia might have a reasonable
reason for not releasing source code, can we just take it as read that
the most likely reason is that they simply don't want to because they
don't see the benefit? If that's the case, what benefit can we offer
them?
Trent
On Tue, 2007-01-02 at 21:26 +1000, Trent Waddington wrote:
> On 1/2/07, Bernd Petrovitsch <[email protected]> wrote:
> > While this is true (at last in theory), there is one difference in
> > practice: It is *much* easier to prove a/the patent violation if you
> > have (original?) source code than to reverse engineer the assembler dump
> > of the compiled code and prove the patent violation far enough to get to
> > a so-called "agreement" on the costs.
>
> On 1/2/07, Alan <[email protected]> wrote:
> > You are forgetting the 11th commandment - thou shalt not get caught.
> > Most software patents (actually quite probably most patents) are held by
> > people who don't have the skills to go disassembling megabytes of code in
> > search of offenders.
>
> The list of features which the driver supports is going to be
> sufficient evidence for 99% of patents that relate to computer
> graphics hardware.
>
> Regardless, in the *millions* of dollars that it costs to prosecute a
> patent violation case I think they can find a few grand to throw at a
> disassembler jockey.
Most of the cases (more or less "almost all" AFAIK) are handled/closed
without really going to court (since it is cheaper for all - especially
if the alleged patent violator is substantially smaller than the patent
holder and will not survive the law suit. See it as "protection money").
So there are no real statistics available on this issue.
I don't know about others but I wouldn't write an offer with a fixed
price for "look into assembler dumps, reverse engineer it and find an
infringement on a list of given patents" so the patent holder has to
list the patents and the amount of my time to invest (and then he will
get a price for it and no guarantees of success).
Thus the patent holder takes the whole risk that I don't find anything
useful (independent of the presence of a patent violation or my
inability to find/identify it).
And you need people wo are literate in "patent quak" and the technical
side so it will IMHP not work if you get someone not very expensive[0].
> So I'll take back what I said.. it does make some difference whether
> you release patent violating source code or patent violating binaries.
> It makes about a 1% difference to the overall cost of prosecuting a
> patent lawsuit.
Given the above, the difference (measured in money/effort/....) is in
IMHO much larger than 1%.
> Now if you are done speculating why nvidia might have a reasonable
> reason for not releasing source code, can we just take it as read that
> the most likely reason is that they simply don't want to because they
> don't see the benefit? If that's the case, what benefit can we offer
> them?
I don't know.
For network cards it helped to recommend hardware with open drivers. In
the graphic card department this didn't worked up to now.
Bernd
[0]: That doesn't imply that hiring someone expensive guarantees
success.
--
Firmix Software GmbH http://www.firmix.at/
mobil: +43 664 4416156 fax: +43 1 7890849-55
Embedded Linux Development and Services
On Tue, Jan 02, 2007 at 09:26:14PM +1000, Trent Waddington wrote:
> The list of features which the driver supports is going to be
> sufficient evidence for 99% of patents that relate to computer
> graphics hardware.
Nope, not necessarily. Recall that Patent Office has issued a patent
on the concept of using "XOR" in graphics operations (for dealing with
a cursor that's moving around). There are plenty of patents involving
optimizations that can't be proven unless you have access to the
low-level source code or are willing to spend a huge amount of money
disassembling megabytes of binaries. In fact, there are rumors
floating around that pthe reason why no one is willing to release
source code is that both sides are almost certainly violating each
other's trivial patents, and defending against a patent lawsuit can
take years, millions of dollars, and even if the patent is completely
and totally bogus, can put a company out of business. Witness what
happened with Research in Motion and the patents allegedly covering
the Blackberry. Even though the USPTO had already provisionally ruled
that there was prior art (the patent troll still had appeals to file),
the judge wasn't willing to wait for the USPTO process to finish, and
was prepared to issue a ruling that would put a 23 BILLION dollar
company out of business. So RIMM ended up paying over half a billion
dollars of blackmail money to settle a patent lawsuit where the
patents may end up getting ruled completely bogus a year or two from
now anyway.
In any case, the rumor that was going around was that the reasn why
neither side is willing to release sources is because whoever did
would be committing potential corporate suicide first....
I can very easily believe it. The US patent system and "justice"
system in the US is completely and totally insane, and companies often
feel they have to act accordingly. Remember this is the country that
has issued multi-million dollar awards to people who spill hot coffee
in their lap and my favorite, to an idiot who lifted up a lawnmover to
trim their hedges, dropped the lawnmover on his foot and lost his foot
as a result. The lawn mover company had to pay $$$ because they
hadn't thought to put in a idiot switch to stop the lawnmower blade
from spinning when it was lifted off the ground....
- Ted
P.S. The opinions expressed in this e-mail are completely my own; I'm
not important enough to decide the corporate position of my employer. :-)
On Tue, 2 Jan 2007, Theodore Tso wrote:
> I can very easily believe it. The US patent system and "justice"
> system in the US is completely and totally insane, and companies
> often feel they have to act accordingly. Remember this is the
> country that has issued multi-million dollar awards to people who
> spill hot coffee in their lap ...
MASSIVELY OFF TOPIC: can we please stop using this "hot coffee in
lap" story as an example of the idiocy of the justice system? i'm
guessing there's more to this story than most folks are aware of, and
you're welcome to read the details here:
http://www.lectlaw.com/files/cur78.htm
as you can see, there are two salient points that change the
complexion of this story thoroughly:
1) mcdonald's was not merely serving their coffee "hot," but
*scalding* hot (180 to 190 degrees Fahrenheit), a temperature that
will produce third-degree burns almost immediately, and
2) there had, for a decade prior, been some *700* cases where people
had burned themselves with mcdonald's coffee, so it's not as if
mcdonald's was unaware of the danger, yet continued to ignore it.
yes, the american system of justice is brain-damaged. but it's time
to find another example to use as the evidence, ok?
rday
On Tue, Jan 02, 2007 at 08:22:21AM -0500, Robert P. J. Day wrote:
> On Tue, 2 Jan 2007, Theodore Tso wrote:
>
> > I can very easily believe it. The US patent system and "justice"
> > system in the US is completely and totally insane, and companies
> > often feel they have to act accordingly. Remember this is the
> > country that has issued multi-million dollar awards to people who
> > spill hot coffee in their lap ...
>
> MASSIVELY OFF TOPIC: can we please stop using this "hot coffee in
> lap" story as an example of the idiocy of the justice system? i'm
> guessing there's more to this story than most folks are aware of, and
> you're welcome to read the details here:
>
> http://www.lectlaw.com/files/cur78.htm
>
> as you can see, there are two salient points that change the
> complexion of this story thoroughly:
>
> 1) mcdonald's was not merely serving their coffee "hot," but
> *scalding* hot (180 to 190 degrees Fahrenheit), a temperature that
> will produce third-degree burns almost immediately, and
That's less than 90?C. Water boils at 100?C. How the hell do
people expect coffee to be made without boiling water? Magic?
> 2) there had, for a decade prior, been some *700* cases where people
> had burned themselves with mcdonald's coffee, so it's not as if
> mcdonald's was unaware of the danger, yet continued to ignore it.
No, the customers continued to prove to be total morons by total
ignorance of the fact that coffee *is* hot when fresh. If they
cannot handle hot coffee, they can order ice coffee or ask for a refill
of their cola.
[snip]
Regards: David
--
/) David Weinehall <[email protected]> /) Northern lights wander (\
// Maintainer of the v2.0 kernel // Dance across the winter sky //
\) http://www.acc.umu.se/~tao/ (/ Full colour fire (/
On Tue, Jan 02 2007, David Weinehall wrote:
> On Tue, Jan 02, 2007 at 08:22:21AM -0500, Robert P. J. Day wrote:
> > On Tue, 2 Jan 2007, Theodore Tso wrote:
> >
> > > I can very easily believe it. The US patent system and "justice"
> > > system in the US is completely and totally insane, and companies
> > > often feel they have to act accordingly. Remember this is the
> > > country that has issued multi-million dollar awards to people who
> > > spill hot coffee in their lap ...
> >
> > MASSIVELY OFF TOPIC: can we please stop using this "hot coffee in
> > lap" story as an example of the idiocy of the justice system? i'm
> > guessing there's more to this story than most folks are aware of, and
> > you're welcome to read the details here:
> >
> > http://www.lectlaw.com/files/cur78.htm
> >
> > as you can see, there are two salient points that change the
> > complexion of this story thoroughly:
> >
> > 1) mcdonald's was not merely serving their coffee "hot," but
> > *scalding* hot (180 to 190 degrees Fahrenheit), a temperature that
> > will produce third-degree burns almost immediately, and
>
> That's less than 90?C. Water boils at 100?C. How the hell do
> people expect coffee to be made without boiling water? Magic?
I guess selling sharp kitchen knifes in the US is a law suit waiting to
happen as well then, people could seriously hurt themselves with those
things! Talk about corporate irresponsibility.
--
Jens Axboe
> > > > I can very easily believe it. The US patent system and "justice"
> > > > system in the US is completely and totally insane, and companies
> > > > often feel they have to act accordingly. Remember this is the
> > > > country that has issued multi-million dollar awards to people who
> > > > spill hot coffee in their lap ...
> > >
> > > MASSIVELY OFF TOPIC: can we please stop using this "hot coffee in
> > > lap" story as an example of the idiocy of the justice system? i'm
> > > guessing there's more to this story than most folks are aware of, and
> > > you're welcome to read the details here:
> > >
> > > http://www.lectlaw.com/files/cur78.htm
> > >
> > > as you can see, there are two salient points that change the
> > > complexion of this story thoroughly:
> > >
> > > 1) mcdonald's was not merely serving their coffee "hot," but
> > > *scalding* hot (180 to 190 degrees Fahrenheit), a temperature that
> > > will produce third-degree burns almost immediately, and
> >
> > That's less than 90?C. Water boils at 100?C. How the hell do
> > people expect coffee to be made without boiling water? Magic?
>
> I guess selling sharp kitchen knifes in the US is a law suit waiting to
> happen as well then, people could seriously hurt themselves with those
> things! Talk about corporate irresponsibility.
http://news.bbc.co.uk/2/hi/health/4581871.stm
On Jan 2 2007 16:15, David Weinehall wrote:
>On Tue, Jan 02, 2007 at 08:22:21AM -0500, Robert P. J. Day wrote:
>> On Tue, 2 Jan 2007, Theodore Tso wrote:
>>
>> 1) mcdonald's was not merely serving their coffee "hot," but
>> *scalding* hot (180 to 190 degrees Fahrenheit), a temperature that
>> will produce third-degree burns almost immediately, and
>
>That's less than 90°C.
[1]
>Water boils at 100°C. How the hell do
>people expect coffee to be made without boiling water? Magic?
Boil or not - I've done a test some years ago with some friend
arguing about what the best temperature for tea is. Result of an
experiment involving actual temperature sensors: my default tea is 40
deg celsius. Theirs was about 60. And to note, drinking 60 deg water
already starts to scald my tongue slightly so that it 'itches' for a
while. So nothing[1] is unreasonable.
>> 2) there had, for a decade prior, been some *700* cases where people
>> had burned themselves with mcdonald's coffee, so it's not as if
>> mcdonald's was unaware of the danger, yet continued to ignore it.
>
>No, the customers continued to prove to be total morons by total
>ignorance of the fact that coffee *is* hot when fresh. If they
>cannot handle hot coffee, they can order ice coffee or ask for a
>refill of their cola.
Reminds me of http://qdb.us/4753
-`J'
--
David Weinehall <[email protected]> wrote:
> On Tue, Jan 02, 2007 at 08:22:21AM -0500, Robert P. J. Day wrote:
>> 1) mcdonald's was not merely serving their coffee "hot," but
>> *scalding* hot (180 to 190 degrees Fahrenheit), a temperature that
>> will produce third-degree burns almost immediately, and
>
> That's less than 90?C. Water boils at 100?C. How the hell do
> people expect coffee to be made without boiling water? Magic?
The recommendet _serving_ temperature for coffe is 55 ?C or below.
>> 2) there had, for a decade prior, been some *700* cases where people
>> had burned themselves with mcdonald's coffee, so it's not as if
>> mcdonald's was unaware of the danger, yet continued to ignore it.
>
> No, the customers continued to prove to be total morons by total
> ignorance of the fact that coffee *is* hot when fresh.
So everybody at McDrive should wait for five minutes to let it cool down.
--
Ich danke GMX daf?r, die Verwendung meiner Adressen mittels per SPF
verbreiteten L?gen zu sabotieren.
http://david.woodhou.se/why-not-spf.html
On Tue, 2007-01-02 at 08:22 -0500, Robert P. J. Day wrote:
> On Tue, 2 Jan 2007, Theodore Tso wrote:
>
> > I can very easily believe it. The US patent system and "justice"
> > system in the US is completely and totally insane, and companies
> > often feel they have to act accordingly. Remember this is the
> > country that has issued multi-million dollar awards to people who
> > spill hot coffee in their lap ...
>
> MASSIVELY OFF TOPIC: can we please stop using this "hot coffee in
> lap" story as an example of the idiocy of the justice system? i'm
> guessing there's more to this story than most folks are aware of, and
> you're welcome to read the details here:
>
> http://www.lectlaw.com/files/cur78.htm
Thanks for the pointer.
"The jury awarded Liebeck $200,000 in compensatory damages. This amount
was reduced to $160,000 because the jury found Liebeck 20 percent at
fault in the spill. The jury also awarded Liebeck $2.7 million in
punitive damages, which equals about two days of McDonalds' coffee
sales."
Although the punitive damages was later brought down to $480,000 (still
extreme for the case) it wasn't just the law suit that caused the
uproar. It was the $2.7 million that was (initially) rewarded. And for
what? Spilling hot substance on your lap. I highly doubt that this
would have been big news if the reward was just the $200,000. Since
that's not really a life changing reward now a days. But there's too
much "sue for the money" attitude in the US that the $2.7 mill got
people upset.
>
> as you can see, there are two salient points that change the
> complexion of this story thoroughly:
>
> 1) mcdonald's was not merely serving their coffee "hot," but
> *scalding* hot (180 to 190 degrees Fahrenheit), a temperature that
> will produce third-degree burns almost immediately, and
>
> 2) there had, for a decade prior, been some *700* cases where people
> had burned themselves with mcdonald's coffee, so it's not as if
> mcdonald's was unaware of the danger, yet continued to ignore it.
I'll admit that I burnt myself while driving and drinking McD's coffee,
but I never even thought about complaining about it.
>
> yes, the american system of justice is brain-damaged. but it's time
> to find another example to use as the evidence, ok?
OK, I like Ted's example of the lawnmower :)
Well, the coffee one has gotten world news, and is just the "poster boy"
for the frivolous lawsuits that are done in America. A while back I met
a guy and he told me that he was working on his motorcycle, and disabled
the breaks. Someone came by and stole the bike when he went in his house
to get some tools. The thief crashed the bike (totaling it) and received
some major injuries. Then the thief sued the guy because of the faulty
breaks! He was in the middle of the case when I met him, so I don't
know how it ended. But the fact that this wasn't laughed out of court
just shows that the US system is screwed up.
-- Steve
Bernd Petrovitsch <[email protected]> wrote:
[...]
> I don't know about others but I wouldn't write an offer with a fixed
> price for "look into assembler dumps, reverse engineer it and find an
> infringement on a list of given patents" so the patent holder has to
> list the patents and the amount of my time to invest (and then he will
> get a price for it and no guarantees of success).
And them you'd have to testify (as an expert witness, AFAIU). Having
legally demostrable expertise in the area isn't easy, I suppose.
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 2654431
Universidad Tecnica Federico Santa Maria +56 32 2654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513
On Tue, 2 Jan 2007, David Weinehall wrote:
> On Tue, Jan 02, 2007 at 08:22:21AM -0500, Robert P. J. Day wrote:
> > 1) mcdonald's was not merely serving their coffee "hot," but
> > *scalding* hot (180 to 190 degrees Fahrenheit), a temperature that
> > will produce third-degree burns almost immediately, and
>
> That's less than 90?C. Water boils at 100?C. How the hell do
> people expect coffee to be made without boiling water? Magic?
Ah, many thanks for converting from Fahrenheit to Celsius!
> > 2) there had, for a decade prior, been some *700* cases where people
> > had burned themselves with mcdonald's coffee, so it's not as if
> > mcdonald's was unaware of the danger, yet continued to ignore it.
Given the population size of Fahrenheit-country, 700 burns must be an
understatement...
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
On Tue, 02 Jan 2007 20:30:17 +0100, Geert Uytterhoeven said:
> > > 2) there had, for a decade prior, been some *700* cases where people
> > > had burned themselves with mcdonald's coffee, so it's not as if
> > > mcdonald's was unaware of the danger, yet continued to ignore it.
>
> Given the population size of Fahrenheit-country, 700 burns must be an
> understatement...
And keep in mind, that's not 700 burns. That's 700 complaints that went far
enough that the lawyers were able to find documentation in McDonald's records.
The people who got burned and didn't complain, or just went in and gave the
manager an earful, aren't counted in that 700....
On Tue, Jan 02, 2007 at 07:44:24PM +0100, Bodo Eggert wrote:
> David Weinehall <[email protected]> wrote:
> > On Tue, Jan 02, 2007 at 08:22:21AM -0500, Robert P. J. Day wrote:
>
> >> 1) mcdonald's was not merely serving their coffee "hot," but
> >> *scalding* hot (180 to 190 degrees Fahrenheit), a temperature that
> >> will produce third-degree burns almost immediately, and
> >
> > That's less than 90?C. Water boils at 100?C. How the hell do
> > people expect coffee to be made without boiling water? Magic?
>
> The recommendet _serving_ temperature for coffe is 55 ?C or below.
>
> >> 2) there had, for a decade prior, been some *700* cases where people
> >> had burned themselves with mcdonald's coffee, so it's not as if
> >> mcdonald's was unaware of the danger, yet continued to ignore it.
> >
> > No, the customers continued to prove to be total morons by total
> > ignorance of the fact that coffee *is* hot when fresh.
>
> So everybody at McDrive should wait for five minutes to let it cool down.
Don't drink and drive just got another application =)
Regards: David
--
/) David Weinehall <[email protected]> /) Northern lights wander (\
// Maintainer of the v2.0 kernel // Dance across the winter sky //
\) http://www.acc.umu.se/~tao/ (/ Full colour fire (/
> The recommendet _serving_ temperature for coffe is 55 ?C or below.
Nonsense! 55C (100F) is ludicrously low for coffee.
70C (125F) is the *minimum* recommended serving temperature. 165-190F is the
preferred serving range. I can cite source after source for this. For
example:
http://www.bunn.com/pages/coffeebasics/cb6holding.html
http://www.millcreekcoffee.com/holding.htm
Can we stop repeating a ridiculous myth? Coffee is supposed to be served
hot, very hot, hot enough to cause third-degree burns in seconds. Yes,
really.
Don't spill coffee on yourself or you could wind up in the hospital with
severe burns. This is a simple fact even if coffee is served at the ideal
serving temperature.
The fact that coffee is dangerous means that it is a virtual certainty that
dozens of people will be seriously burned by coffee every year. If this
scares or bothers you, don't drink coffee.
>1) mcdonald's was not merely serving their coffee "hot," but
>*scalding* hot (180 to 190 degrees Fahrenheit), a temperature that
>will produce third-degree burns almost immediately, and
Right, 175 is the generally-recommended serving temperature and will also
produce third-degree burns almost immediately. Coffee served *anywhere*
inside the generally-accepted serving range will cause third degree burns
almost immediately. Consumer studies show that people generally like their
coffee more the hotter you serve it, with 190-200 degrees (the practical
maximum) consistently winning over lower temperature ranges.
Car manufacturers make cars that don't just go "fast" but *dangerously* fast
(100 to 120 MPH), a speed that can result in death almost immediately.
>2) there had, for a decade prior, been some *700* cases where people
>had burned themselves with mcdonald's coffee, so it's not as if
>mcdonald's was unaware of the danger, yet continued to ignore it.
Right, coffee is dangerous. It has always been and always will be if it's
served at the proper temperature. Thousands of people hurt themselves skiing
every year, yet the resorts stay open.
The danger of burns is inherent to the serving of hot beverages. If you
don't want to take that risk, don't order hot beverages.
How many people die each year in car accidents? Is this in any way evidence
that the car manufacturers are doing anything wrong?
>yes, the american system of justice is brain-damaged. but it's time
>to find another example to use as the evidence, ok?
This is a *perfect* example. The tort system is meant to correct wrongdoing.
McDonald's served coffee at the temperature customers prefer it, in holders
that were perfectly suitable for beverages served at that temperature. The
justice system made them pay because someone was *hurt*, not because anyone
did something *wrong*.
http://www.overlawyered.com/2005/10/urban_legends_and_stella_liebe.html
DS
On 1/2/07, [email protected] <[email protected]> wrote:
> On Tue, 02 Jan 2007 20:30:17 +0100, Geert Uytterhoeven said:
>
> > > > 2) there had, for a decade prior, been some *700* cases where people
> > > > had burned themselves with mcdonald's coffee, so it's not as if
> > > > mcdonald's was unaware of the danger, yet continued to ignore it.
> >
> > Given the population size of Fahrenheit-country, 700 burns must be an
> > understatement...
>
> And keep in mind, that's not 700 burns. That's 700 complaints that went far
> enough that the lawyers were able to find documentation in McDonald's records.
> The people who got burned and didn't complain, or just went in and gave the
> manager an earful, aren't counted in that 700....
>
How many of them stuffed the cup between their legs though? I think it
she would have sqeezed the cup too hard and burned her hand and sued
McDonalds for that people would be more understainding...
--
Dmitry
On Tue, Jan 02, 2007 at 06:13:46PM +0100, Jan Engelhardt wrote:
>
> On Jan 2 2007 16:15, David Weinehall wrote:
> >On Tue, Jan 02, 2007 at 08:22:21AM -0500, Robert P. J. Day wrote:
> >> On Tue, 2 Jan 2007, Theodore Tso wrote:
> >>
> >> 1) mcdonald's was not merely serving their coffee "hot," but
> >> *scalding* hot (180 to 190 degrees Fahrenheit), a temperature that
> >> will produce third-degree burns almost immediately, and
> >
> >That's less than 90?C.
> [1]
>
> >Water boils at 100?C. How the hell do
> >people expect coffee to be made without boiling water? Magic?
>
> Boil or not - I've done a test some years ago with some friend
> arguing about what the best temperature for tea is. Result of an
> experiment involving actual temperature sensors: my default tea is 40
> deg celsius. Theirs was about 60. And to note, drinking 60 deg water
> already starts to scald my tongue slightly so that it 'itches' for a
> while. So nothing[1] is unreasonable.
For tea, you're not supposed to boil the water, only let it seethe, as
far as I know. But yes, drinking scalding hot beverages is quite
stupid. I'm not arguing against that. But not realising that something
you need to at the very least seethe to prepare might be hot when served
is showing total ignorance.
> >> 2) there had, for a decade prior, been some *700* cases where people
> >> had burned themselves with mcdonald's coffee, so it's not as if
> >> mcdonald's was unaware of the danger, yet continued to ignore it.
> >
> >No, the customers continued to prove to be total morons by total
> >ignorance of the fact that coffee *is* hot when fresh. If they
> >cannot handle hot coffee, they can order ice coffee or ask for a
> >refill of their cola.
>
> Reminds me of http://qdb.us/4753
Sounds quite reasonable. Things have gone too far when there are
warnings about even the most obvious things.
Regards: David
--
/) David Weinehall <[email protected]> /) Northern lights wander (\
// Maintainer of the v2.0 kernel // Dance across the winter sky //
\) http://www.acc.umu.se/~tao/ (/ Full colour fire (/
On Tuesday January 2, [email protected] wrote:
> On Tue, Jan 02, 2007 at 08:22:21AM -0500, Robert P. J. Day wrote:
> > On Tue, 2 Jan 2007, Theodore Tso wrote:
> >
> > > I can very easily believe it. The US patent system and "justice"
> > > system in the US is completely and totally insane, and companies
> > > often feel they have to act accordingly. Remember this is the
> > > country that has issued multi-million dollar awards to people who
> > > spill hot coffee in their lap ...
> >
> > MASSIVELY OFF TOPIC: can we please stop using this "hot coffee in
> > lap" story as an example of the idiocy of the justice system? i'm
> > guessing there's more to this story than most folks are aware of, and
> > you're welcome to read the details here:
> >
> > http://www.lectlaw.com/files/cur78.htm
> >
> > as you can see, there are two salient points that change the
> > complexion of this story thoroughly:
> >
> > 1) mcdonald's was not merely serving their coffee "hot," but
> > *scalding* hot (180 to 190 degrees Fahrenheit), a temperature that
> > will produce third-degree burns almost immediately, and
>
> That's less than 90?C. Water boils at 100?C. How the hell do
> people expect coffee to be made without boiling water? Magic?
We have a coffee chain down here (.au) called "92degrees". They claim this
is the optimal temperature for pumping the water through the ground
coffee beans to get ideal coffee. So it doesn't need to be boiling.
Of course if people would just put milk in their coffee, we would have
this problem :-)
[We now return you to our regular program of filesystem corruption
and flame wars].
NeilBrown
On Wed, 3 Jan 2007 08:11:21 +1100 Neil Brown wrote:
> Of course if people would just put milk in their coffee, we would have
> this problem :-)
>
> [We now return you to our regular program of filesystem corruption
> and flame wars].
Yes, PLEEZE!
---
~Randy
> How many of them stuffed the cup between their legs though? I think it
> she would have sqeezed the cup too hard and burned her hand and sued
> McDonalds for that people would be more understainding...
How would what she did have any bearing on the key issue, which is whether
or not McDonald's was in any way negligent or serving a defective or
unreasonably dangerous product? This case should never have gotten past the
earliest stages, and numerous factually similar cases were properly
dismissed.
There is simply no way you can argue that McDonald's failed to warn people
about the risks. The cup says "hot" on it, and nobody can reasonably claim
they didn't know coffee was served hot. People might not realize that coffee
is hot enough to cause third-degree burns, but McDonald's can't include an
education with each cup of coffee, and the plaintiff's never suggest what
warning they think would have been appropriate. Any "failure to warn" type
argument is absurd on its face. (Does anyone honestly think anything would
change if McDonald's included some kind of notice on the cups?)
There is similarly no way you can argue that the product is unreasonably
dangerous or defective. McDonald's serves coffee at the temperature people
want their coffee served, well within industry standards. Hot coffee is
inherently dangerous, and asking McDonald's to make their coffee colder than
industry standards just to make it less dangerous is to argue that stores
should sell dull knives.
McDonald's serves coffee at the temperature consumers want it, within
accepted standards, that makes any danger inherent in that temperature
reasonable. There is no suggestion that the cups or lids are somehow
unsuitable. Any "defective product" or "unreasonably dangerous" argument is
absurd on its face.
What type of legal claim does this leave?
The claim that McDonald's settled "similar cases" and is thus being
arbitrary or trying to hide anything is nonsense. McDonald's, and other
coffee sellers, have settled cases where they *did* do something wrong, such
as failing to properly close the lid or where an employee actually dropped
or spilled the coffee on a customer.
The Stella Liebeck case, however, is a textbook example of a jury finding
for a plaintiff in a completely meritless case for no reason other than that
the defendant had deep pockets and the plaintiff was badly hurt. That there
is no plausible connection between anything the defendant did wrong and the
plaintiff's injuries was totally ignored. That none of the plaintiff's
claims had even one shred of legal merit was totally ignored.
What really amazes me though is that people continue to try to find some way
to justify this crazy case. That ATLA defends the case with a series of
confusing "almost sort of true" statements is embarassing.
DS
PS: In my previous post I made a few temperature conversion errors between
Farenheit and Celsius. All temperatures were correct in the first specified
units and the errors didn't affect the reasoning. My apologies, and thanks
to those who caught it.
On Tue, 2007-01-02 at 12:14 -0800, David Schwartz wrote:
> > The recommendet _serving_ temperature for coffe is 55 °C or below.
>
> Nonsense! 55C (100F) is ludicrously low for coffee.
>
> 70C (125F) is the *minimum* recommended serving temperature. 165-190F is the
> preferred serving range. I can cite source after source for this. For
> example:
> http://www.bunn.com/pages/coffeebasics/cb6holding.html
> http://www.millcreekcoffee.com/holding.htm
Do you actually read your citations? Your cited sources both give the
SERVING temp as 155 - 175 F.
--
Brian Beattie
Firmware Engineer
APCON, Inc.
[email protected]
> On Tue, 2007-01-02 at 12:14 -0800, David Schwartz wrote:
> > > The recommendet _serving_ temperature for coffe is 55 °C or below.
> >
> > Nonsense! 55C (100F) is ludicrously low for coffee.
> >
> > 70C (125F) is the *minimum* recommended serving temperature.
> 165-190F is the
> > preferred serving range. I can cite source after source for this. For
> > example:
> > http://www.bunn.com/pages/coffeebasics/cb6holding.html
> > http://www.millcreekcoffee.com/holding.htm
>
> Do you actually read your citations? Your cited sources both give the
> SERVING temp as 155 - 175 F.
The conversion was incorrect. 70C is about 160F, and 55C is about 130F. As I said in the correction, every number is correct in the unit it was first posted in, and all the claims are correct.
160F is the mininum recommended serving temperature and 165-190F is the preferred range. 130F is a ludicrously low serving temperature for coffee. 180F seems to be about ideal.
Stella Liebeck's lawyers argued that coffee should never be served hotter than 140F. This is no different from arguing that knives should be dull.
DS
On Tue, 02 Jan 2007 12:14:54 PST, David Schwartz said:
>
> > The recommendet _serving_ temperature for coffe is 55 ?C or below.
>
> Nonsense! 55C (100F) is ludicrously low for coffee.
>
> 70C (125F) is the *minimum* recommended serving temperature. 165-190F is the
100F == 37C
125F == 52C
55C == 131F
70C == 158F
Yes, 100F *is* ludicrously low for coffee. :)
On Tue, 02 Jan 2007 15:01:56 PST, David Schwartz said:
> There is simply no way you can argue that McDonald's failed to warn people
> about the risks. The cup says "hot" on it,
Actually, the "HOT" on the cup and the sticker in the drive-through that
says "Warning: Coffee is served very hot" were added after that lawsuit.
On Tue, 2007-01-02 at 16:23 -0300, Horst H. von Brand wrote:
> Bernd Petrovitsch <[email protected]> wrote:
> [...]
> > I don't know about others but I wouldn't write an offer with a fixed
> > price for "look into assembler dumps, reverse engineer it and find an
> > infringement on a list of given patents" so the patent holder has to
> > list the patents and the amount of my time to invest (and then he will
> > get a price for it and no guarantees of success).
>
> And them you'd have to testify (as an expert witness, AFAIU). Having
Probably if
-) I actually found something and
-) the patent holder also believes in it (and he will - IMHO very
probably -
pay another expert to verify the findings) and
-) the patent holder actually persues the infringements and
-) the law suit goes that far and.
> legally demostrable expertise in the area isn't easy, I suppose.
At least in .at you need some kind of "official approval" to become an
"expert in court" (in German: "Gutachter" - Is "assessor" the correct
translation? http://dict.leo.org/ lists 9 different words).
Actually this is a somewhat different job ....
Bernd
--
Firmix Software GmbH http://www.firmix.at/
mobil: +43 664 4416156 fax: +43 1 7890849-55
Embedded Linux Development and Services
> On Tue, 02 Jan 2007 15:01:56 PST, David Schwartz said:
> > There is simply no way you can argue that McDonald's failed to
> > warn people
> > about the risks. The cup says "hot" on it,
> Actually, the "HOT" on the cup and the sticker in the drive-through that
> says "Warning: Coffee is served very hot" were added after that lawsuit.
Yes. And pretty much everyone agrees that these warnings serve no purpose.
Everyone knows that hot coffee is served hot.
What people probably don't know is that if you spill hot coffee on yourself
and remain in contact with the coffee for more than about 45 seconds, a
third-degree burn can result. This warning doesn't convey that information.
I find it almost impossible to believe that anyone is going to alter their
behavior in any significant way as a result of that warning.
DS