[LEDE-DEV] [bufferbloat-fcc-discuss] FCC killing open platforms and inovations [Was: Re: [PATCH] ar71xx: Add usable, inactive LEDs on OpenMesh devices]
Eric Schultz
eschultz at prplfoundation.org
Mon Nov 21 11:20:24 PST 2016
All,
Since it's relevant to this discussion, I wanted to let folks know that
I've recently joined the Software Controlled Radio sub-group of the
FCC's Technical Advisory Council in my role as prpl Community Manager. A
press release about my participation is at
https://prpl.works/2016/11/21/prpl-foundation-collaborating-with-fcc-working-group/. The
sub-group consists of members of industry and academia with FCC staff
observing. We've been tasked with providing background on and, if
possible, recommendations to the FCC on how to balance reducing
interference with protecting innovation and the flexible addition of
features. I'm coming into the the sub-group late in the process (the
report is supposed to be done this year) but in the first few weeks, I
think I've been able to add some important viewpoints from the open
source community.
While the final report will be public, I've been asked by the chair of
the committee to keep the draft report confidential. If anyone here is
willing to help and will keep the draft confidential, I'd welcome your
assistance.
Thanks,
Eric
On 11/17/2016 11:06 PM, Paul Gardner-Stephen wrote:
> Hello,
>
> I think the fundamental problem is that the FCC wants to:
>
> 1. Make sure no one can run non-vendor-supplied firmware (presumably
> to try to stop harmful interference);
>
> and
>
> 2. Not ban the open-source movement from innovating on wireless using
> commercial wireless routers.
>
> We can all see that using that formulation they are trying to ban and
> allow the same thing at the same time.
>
> This is not unique to the US at the moment. The EU directive
> 2014/53/EU is trying to do the same thing.
>
> I am currently working with a team here at TU-Darmstadt to put a
> submission in to the German government to make sure that their
> implementation of the EU directive doesn't ban open-source firmware
> (actually, our reading of the current draft is that it would also
> accidentally ban a lot of other things due to a couple of small
> oversights). This is also causing me to extend my German vocabulary
> with words like "Zweckbestimmungsänderung,"
> "telekommunikationsendeinrichtungen," , and
> "harmonisierungsrechtsvorschriften."
>
> This is part of a larger project to understand (and hopefully improve)
> the legal situation for wireless ad-hoc emergency and humanitarian
> telecommunications networks. While this use-case may be rather
> specific, it touches on most of the issues that affect the open-source
> wireless community in general.
>
> In this project, we intend to understand the current regulatory
> situation in the USA, Germany/EU, Australia and a handful of other
> countries, to see how they compare, and try to propose a rational
> framework that would be acceptable to national regulators, while not
> undermining the value of the various activities of the open-source
> wireless communities around the world. Anyone who would like to help
> with this effort, feel free to poke me.
>
> Paul.
>
> On Fri, Nov 18, 2016 at 2:26 AM, Wayne Workman
> <wayne.workman2012 at gmail.com <mailto:wayne.workman2012 at gmail.com>> wrote:
>
> I don't understand how this group's efforts weren't successful
> after what TP-Link had to do.
>
> Was it TP-LINK'S choice to support open source in an effort to
> save face and get brownie points or was it mandated by court?
>
> The FCC's stance, to me at least, is even more vague now.
>
> On Nov 17, 2016 10:03 AM, "Dave Taht" <dave.taht at gmail.com
> <mailto:dave.taht at gmail.com>> wrote:
>
> The linked document below is the same document we attacked, I
> thought
> successfully, last year,
>
> http://www.computerworld.com/article/2993112/security/vint-cerf-and-260-experts-give-fcc-a-plan-to-secure-wi-fi-routers.html
> <http://www.computerworld.com/article/2993112/security/vint-cerf-and-260-experts-give-fcc-a-plan-to-secure-wi-fi-routers.html>
>
> with the ultimate response from the fcc being
>
> https://www.fcc.gov/news-events/blog/2015/11/12/clearing-air-wi-fi-software-updates
> <https://www.fcc.gov/news-events/blog/2015/11/12/clearing-air-wi-fi-software-updates>
>
> Merely being asked to describe how the regdb works is all I
> see as the
> current FCC requirement. More than one manufacturer has got
> through
> this process since. Also, the context of that whole original
> debate
> was a dispute with tp-link, which only came out after the
> legal dust
> had settled.
>
> http://arstechnica.com/information-technology/2016/08/fcc-forces-tp-link-to-support-open-source-firmware-on-routers/
> <http://arstechnica.com/information-technology/2016/08/fcc-forces-tp-link-to-support-open-source-firmware-on-routers/>
>
> On Wed, Nov 16, 2016 at 2:15 PM, Simon Wunderlich
> <simon.wunderlich at open-mesh.com
> <mailto:simon.wunderlich at open-mesh.com>> wrote:
> > Hi David,
> >
> > On Tuesday, November 15, 2016 4:49:40 PM CET David Lang wrote:
> >> > Well, we are. We can't change the fact that the devices
> need to be locked
> >> > to be sold in the US. But if you google a little, you
> will find a lot of
> >> > patches for various Open Source projects signed by
> @open-mesh.com <http://open-mesh.com> mail
> >> > addresses (LEDE, Linux, hostapd, etc) ... Feel free to
> compare that with
> >> > other WiFi vendors. I don't think we are doing that bad. :)
> >>
> >> except that they don't need to be locked down to be sold in
> the US.
> >>
> >> The FCC posted a proposed rule that would require such a
> lockdown, but then
> >> have repeatedly made public statements that they do not
> intend to prevent
> >> different firmware from being loaded on the devices and the
> proposed rule
> >> that would have required lockdowns have basically been stopped.
> >>
> >> However, multiple vendors are imposing restriction and
> claiming that the FCC
> >> is requiring them, even after the FCC says that it's not.
> >
> > You are right, the FCC doesn't explicitly requires to
> prevent third-party
> > firmware loading anymore. However, they still require to
> explain how a vendor
> > makes sure that US RF limits are not violated [1]. Since a
> third-party firmware
> > can be anything including a firmware with a patched ath9k
> where DFS is disabled
> > etc, we (as Open-Mesh) can't really prevent that those RF
> limits are violated.
> > Thus we can not give a convincing explanation there, and the
> situation stays
> > the same.
> >
> > If you have any constructive idea, I would love to propose
> it internally.
> >
> > Thanks,
> > Simon
> >
> > [1] From
> https://apps.fcc.gov/kdb/GetAttachment.html?id=zXtrctoj6zH7oNEOO6De6g
> <https://apps.fcc.gov/kdb/GetAttachment.html?id=zXtrctoj6zH7oNEOO6De6g>
> > %3D%3D&desc=594280%20D02%20U-NII%20Device%20Security
> > %20v01r03&tracking_number=39498
> >
> > "Describe, if the device permits third-party software or
> firmware installation,
> > what mechanisms are provided by the manufacturer to permit
> integration of
> > such functions while ensuring that the RF parameters of the
> device cannot be
> > operated outside its authorization for operation in the U.S
> . In the
> > description include what controls and/or agreements are in
> place with
> > providers of third-party functionality to ensure the
> devices’ underlying RF
> > parameters are unchanged and how the manufacturer verifies
> the functionality. "
> > _______________________________________________
> > Lede-dev mailing list
> > Lede-dev at lists.infradead.org
> <mailto:Lede-dev at lists.infradead.org>
> > http://lists.infradead.org/mailman/listinfo/lede-dev
> <http://lists.infradead.org/mailman/listinfo/lede-dev>
> >
>
>
>
> --
> Dave Täht
> Let's go make home routers and wifi faster! With better software!
> http://blog.cerowrt.org
> _______________________________________________
> bufferbloat-fcc-discuss mailing list
> bufferbloat-fcc-discuss at lists.redbarn.org
> <mailto:bufferbloat-fcc-discuss at lists.redbarn.org>
> http://lists.redbarn.org/mailman/listinfo/bufferbloat-fcc-discuss
> <http://lists.redbarn.org/mailman/listinfo/bufferbloat-fcc-discuss>
>
>
> _______________________________________________
> bufferbloat-fcc-discuss mailing list
> bufferbloat-fcc-discuss at lists.redbarn.org
> <mailto:bufferbloat-fcc-discuss at lists.redbarn.org>
> http://lists.redbarn.org/mailman/listinfo/bufferbloat-fcc-discuss
> <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
More information about the Lede-dev
mailing list