[Battlemesh] [bufferbloat-fcc-discuss] Action: fixing *WRT and the FCC

[Mitar]

Hi!

Funny thing, people were saying the same about GPLv2. Why would
companies drop GPLv3 before they realize that they need tivoization? 5
years ago TP-link could use GPLv3 exactly the same as GPLv3. Only when
they would be forced to do tivoization they would realize that they
cannot do something. And they would have a question: do they work with
community and solve the problem, or do they switch to something else.

Now, they didn't have to do any of those, they just flipped tivoization on.


Mitar

> Sorry, Mitar, but no. If Linux was GPLv3, it would have been dropped like
> the proverbial hot potato in favor of something manufacturers could
> actually work with.
> 
> On Thu, Feb 18, 2016 at 9:26 PM, Mitar <mitar at tnode.com> wrote:
> 
>> Hi!
>>
>> I think this is an example of what happens because Linux is not licensed
>> GPLv3. Tivoization was first, and we said we do not care about that. And
>> Linux stayed GPLv2.
>>
>> If it was GPLv3, then manufacturers would have to think a bit more how
>> to address this and maybe work with the community to address the issue.
>>
>>
>> Mitar
>>
>>> David,
>>>
>>> DFS does work now. It's worked for years. The best we can do is make sure
>>> you can't turn off DFS unless you rebuild from kernel.
>>>
>>> The FCC hasn't even said that DFS is the problem or what would satisfy
>>> them. We need the FCC to actually collaborate and to date, they've just
>>> talked past us.
>>>
>>> Eric
>>>
>>> On Thu, Feb 18, 2016 at 4:27 PM, David Hilton <
>> quercus.aeternam at gmail.com>
>>> wrote:
>>>
>>>> Thanks for your input, Rich, Wayne, Moeller and Adrian
>>>>
>>>> Input from a *WRT maintainer would be very welcome. We *do* have funds
>>>> available, so if the FCC is amenable we could use that for hosting,
>>>> licenses (for wifi location data?) or development.
>>>>
>>>> Adrian:
>>>> It is political, but I think that having a solution that works *right
>>>> now*, for *anything open* is an important bargaining chip.
>>>>
>>>> Our initial (not mainline) implementation *would* just disable the
>>>> channels. That's the <2h dev time. As we get traction with the FCC, we
>>>> actually do a smart implementation that goes into trunk. Maybe WiFi
>>>> location data, or allow DFS-capable chips report DFS events (opt-in, of
>>>> course).
>>>>
>>>> We can't just demand that vendors open their code and say "that will
>> make
>>>> things better... because then we can fix it for you!" Let's apply a fix,
>>>> get some political capital, and try and expand what the fix applies to.
>>>> This ultimately will increase openness and security. As we *demonstrate*
>>>> the "secondary" benefits, we can expand the scope.
>>>>
>>>> David
>>>>
>>>> An aside: I am 10 miles from the FCC office in DC (this week (just
>> Friday,
>>>> I guess), and will be here again in another month). I'm willing to go
>> there
>>>> in person and meet with whoever I need to.
>>>>
>>>> On Thu, Feb 18, 2016 at 4:27 PM, Adrian Chadd <adrian at freebsd.org>
>> wrote:
>>>>
>>>>> Ugh!
>>>>>
>>>>> Look, it's not going to work that way. You're expecting everyone is
>>>>> going to have access to a GPS receiver. If you get access to NTP and
>>>>> GeoIP location, people will just disable or spoof it.
>>>>>
>>>>> It's barking up the wrong tree. This is mostly political. We need loud
>>>>> vendor voices advocating for openness. Now, this likely won't be
>>>>> TP-Link, D-Link, etc. My suggestion is to get the vendors that are
>>>>> already doing stuff with open hardware (pfsense, thinkpenguin,
>>>>> 8devices, and all of the kickstarter wifi companies) to get together
>>>>> and advocate on this.
>>>>>
>>>>> This isn't specifically a technical problem. There needs to be a much
>>>>> larger, much louder, much more unified front than the last attempt. If
>>>>> you can get this, then you can ask someone like Google to get
>>>>> involved.
>>>>>
>>>>>
>>>>>
>>>>> -adrian
>>>>> _______________________________________________
>>>>> bufferbloat-fcc-discuss mailing list
>>>>> bufferbloat-fcc-discuss at lists.redbarn.org
>>>>> http://lists.redbarn.org/mailman/listinfo/bufferbloat-fcc-discuss
>>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> bufferbloat-fcc-discuss mailing list
>>>> bufferbloat-fcc-discuss at lists.redbarn.org
>>>> http://lists.redbarn.org/mailman/listinfo/bufferbloat-fcc-discuss
>>>>
>>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Battlemesh mailing list
>>> Battlemesh at ml.ninux.org
>>> http://ml.ninux.org/mailman/listinfo/battlemesh
>>>
>>
>> --
>> http://mitar.tnode.com/
>> https://twitter.com/mitar_m
>> _______________________________________________
>> bufferbloat-fcc-discuss mailing list
>> bufferbloat-fcc-discuss at lists.redbarn.org
>> http://lists.redbarn.org/mailman/listinfo/bufferbloat-fcc-discuss
>>
> 
> 
> 

-- 
http://mitar.tnode.com/
https://twitter.com/mitar_m