John Pugh wrote:
>>>> On Thu, Apr 17, 2008 at 3:51 PM, in message
> <200804171551.03053.slitt@troubleshooters.com>, Steve Litt
> <slitt@troubleshooters.com> wrote:
>> On Thursday 17 April 2008 15:18, John Pugh wrote:
>>>>>> On Thu, Apr 17, 2008 at 2:26 PM, in message
>>> <200804171426.24906.slitt@troubleshooters.com>, Steve Litt
>>>
>>> <slitt@troubleshooters.com> wrote:
>>>> On Thursday 17 April 2008 13:19, tom smith wrote:
>>>>> http://www.kernel.org/
>>>> Is that the one where they crippled ndiswrapper? What a stupid decision
>>>> that is!
>>> Well...there was a patch which inadvertently screwed NDISwrapper up and a
>>> nice little argument about fixing the patch so Linus disabled access to
>>> symbols it needed to work. I think that the NDISwrapper folks implemented a
>>> workaround in their latest release, but NDISwrapper is currently hobbled.
>> Is there any reasonable way to work around the current no-ndiswrapper
>> symbols?
>>
>> So much for Linux on laptops. A real piece of strategic thinking by Linus.
>> But
>> hey, we're 100% free software, even if nobody uses it (on a laptop).
>>
>> Those guys whining about the GPL impurity of binary interfaces should be put
>>
>> in a sweatshop and made to reverse engineer every new wnic that comes out,
>> and code a totally free driver for it within a week of its release.
>
> Funny...similar argument on the kernel lists. Some are saying they need to move it to the userspace - not something a sane person would be interested in doing.
> The issue that Linus is holding over their head is the issue surrounding access to GPLONLY symbols. The ndis API technically taints the kernel with the use of GPLONLY symbols, but it has been treated differently and allowed to access these symbols for some time now.
>
> Does not seem to be a fix for now until the other api developers, specifically usb, agree to allow access as a one-off.
>
> JP
>
I have to agree with Linus - one-offs and exceptions are a quick way to
licensing hell, and should be avoided. Just because ndiswrapper plugs an
important hole in functionality, doesn't mean it should be treated
specially.
Also don't forget that broadcom et al are not necessarily holding out
from releasing specs through business paranoia, but the FCC itself deems
that software controlled radio is not to be open. The only reason we
have madwifi is because of the closed HAL that we get to talk to (that
filters channels, power, etc to FCC specs).
Don't get mad at the corporations, get mad at the Government in this case.
This archive was generated by hypermail 2.1.3 : Fri Aug 01 2014 - 20:10:29 EDT