lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20080206213449.6614efea@weinigel.se>
Date:	Wed, 6 Feb 2008 21:34:49 +0100
From:	Christer Weinigel <christer@...nigel.se>
To:	Marcel Holtmann <marcel@...tmann.org>
Cc:	Diego Zuccato <diego@...llo.alma.unibo.it>,
	David Newall <davidn@...idnewall.com>,
	Greg KH <greg@...ah.com>, linux-usb@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] USB: mark USB drivers as being GPL only

On Mon, 04 Feb 2008 22:38:11 +0100
Marcel Holtmann <marcel@...tmann.org> wrote:

> Hi Christer,
> 
> while the HAL case of Atheros might be still true despite the fact
> that an OpenHAL has been around for a long time now. The Intel
> argument is out of the picture since quite some time. The regulatory
> daemon was an interim solution and has been replaced by a proper
> firmware solution. So please get your examples up-to-date.

So how does that invalidate my point?  Intel did jump through a lot of
hoops to avoid giving away the code that controls their radio.  When
the regulatory daemon stuff got too much complaints, they finally
redid their firmware to avoid the daemon.  But they still have not
exposed the details on how to control their radio.

> You might wanna now point to hiding something in firmware, but the
> hardware, firmware, driver separation (with being hardware and
> firmware closed source) is an accepted solution. It is a clean
> separation. Interface wise and license wise. 

Yes, that is a nice solution.  Provided that you have any firmware at
all.  But price is everything, chips become dumber and dumber and more
control functions are pushed to the host.  If you want to sell a device
in Korea, price is everything; if you can shave off 30 cents by putting
the firmware in ROM, or by using 1.5 mbits of flash instead of 2 mbits,
that means an increase in market share or profit margins.  

> Remember that nobody inside the community ever asked for any kind of
> IP or trade secrets. We only want specifications so we can write the
> drivers under an appropriate open source license. If the
> specification describes an API exposed via firmware then that is
> perfectly fine.

I definitely agree.  I think it's stupid of companies to hide away
their documentation out of fear of, well, something.  I find it
extremely frustrating when I bought a device touted as "the first open
Linux mobile", just to find out that it used a binary-only kernel module
for the M-Systems DiskOnChip.  A quite nice phone, but due to that one
module, it was completely impossible to use anything but the ancient
2.4 kernel it came with.

I also think that my customers, that decided to keep their kernel
modules binary only, made a big mistake and have told them so.  But I
still think it's better for the Linux community to be a bit soft on
such companies for a while.  It's better to let them get away with it
for a while, and slowly try to convince them about the error of their
ways, rather than see them go with Windows CE or a BSD.

  /Christer


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ