[Starlink] resuming the right to repair fight in particular

[Dave Taht <dave.taht@gmail.com>]

Early on in the FLOSS podcast (
https://twit.tv/shows/floss-weekly/episodes/638?autostart=false ) I
harped on what is basically my biggest issue with the world of IoT -
home routers only being a tiny subset - being able to fix the stuff
you bought, and KNOWING that the stuff you bought isn't going to
betray you. The cell phone universe is about as well handled in this
department as seems feasible, but the rest... ugh!

I know our lists are mostly technically oriented but does anyone know
of a site, a forum, a slack channel, a linked in group, a faceboook
group, some legal advisory group... somewhere??, where I, at least,
could vent in something in a productive direction? I'm very happy to
finally be in BITAG but that's just about lag.

I often look back on our 2015 fcc fight with remorse, as we didn't
have enough capital to capitalize on it, and I just went back to
finishing up our research. We knocked 'em down FLAT with that one
broadside but nobody read the filing itself, just the press release,
and the vogons got up again, like a tarbaby, and resumed bad
governance of the future as usual.

For the record, if you haven't read:

http://fqcodel.bufferbloat.net/~d/fcc_saner_software_practices.pdf

Our proposal buried on page 12:

1. Any vendor of SDR, wireless, or Wi­Fi radio must make public the
full and maintained source
code for the device driver and radio firmware in order to maintain FCC
compliance. The source
code should be in a buildable, change controlled source code
repository on the Internet,
available for review and improvement by all.

2. The vendor must assure that secure update of firmware be working at
shipment, and that update streams be under ultimate control of the
owner of the equipment. Problems with compliance can then be fixed
going forward by the person legally responsible for the router being
in compliance.

3. The vendor must supply a continuous stream of source and binary
updates that must respond to regulatory transgressions and Common
Vulnerability and Exposure reports (CVEs) within 45
days of disclosure, for the warranted lifetime of the product, the
business lifetime of the vendor,
or until five years after the last customer shipment, whichever is longer.

4. Failure to comply with these regulations should result in FCC
decertification of the existing
product and, in severe cases, bar new products from that vendor from
being considered for
certification.

5. Additionally, we ask the FCC to review and rescind any rules for
anything that conflict with
open source best practices, produce unmaintainable hardware, or cause
vendors to believe they
must only ship undocumented “binary blobs” of compiled code or use
lockdown mechanisms
that forbid user patching. This is an ongoing problem for the Internet
community committed to
best practice change control and error correction on safety­ critical systems


-- 
Fixing Starlink's Latencies: https://www.youtube.com/watch?v=c9gLo6Xrwgw

Dave Täht CEO, TekLibre, LLC