Hacker News Reader

Comment by rgoulter | Hacker News Reader

"The SDK is open source" Oh, a BLE MCU with open source code SDK?

AFAICT, the BLE code is provided as a binary blob. https://github.com/OpenSiFli/SiFli-SDK/tree/6c82a9b15db49871...

Which isn't a problem. But, I wish if something is described as "open source", you could read the source code for it.

BLE radio device firmware is always going to be provided as binary blobs for a combination of IP and regulatory reasons.

I know very little about bluetooth firmware beyond using it for apps and such, but what kind of regulatory reasons are there that prevent publishing source code for bluetooth radios?

To avoid intentionally or unintentionally interfering with frequency spectrum it should not be.

The BT blob (or WiFi blob, or general radio blob) often controls low level aspects of the actual RF device. So you can often alter frequencies, power levels and other parameters. This results in the device acting out of spec.

Now one might say that's the fault of the person doing the modifications/manipulations, but regulations in various countries require the device to prevent these manipulations.

(N.B. I'm not in the exact business, but that's my take away from looking into the topic some time ago)

Surely it's possible to maintain control over that while still publishing the source code? Seems like security by obscurity.

I don't know, I don't think there are many open-source third-party firmware implementations for these kinds of chipsets out there, so it seems pretty well obscured.

Exactly my thoughts. To avoid out-of-regulation tweaking coudn't they just allow signed code to run? How can I be sure that this closed for, i.e. surveillance reasons? One can publish the source code and still prevent misuse afaik.

Many modern chips do in fact use signed firmware yes.

Technically they could publish the source in that case but I think some patents would prevent them from doing this. Radio stuff is riddled with patents. Also most likely the "why would we" reason. There is no benefit for the manufacturer.

Why would patents prevent open source? As in, they're afraid of patent trolls trawling their code for "infringements"?

If it's concerning their own patents, no need to hide the source code. A patent is literally "letters patent" or public description of an invention. Trade secrets on the other hand I could understand.

It's often a condition of licensing those patents. NDA's, they're huge in the radio and embedded world. It only became a bit more open when the Arduino and Raspberry projects came along. And even there it wasn't fully open, especially with the Raspberry because Broadcom is one of the worst offenders.

I'm surprised how much they were able to open source as-is. I think part of that is that the SoCs powering the raspberry are kinda 'old news', definitely not the bleeding edge kind of embedded tech. The first raspberry basically happened because Broadcom had a whole bunch of old chips they weren't able to sell. Only when it took off they started making some actually for the purpose.

The hardware itself is flexible and relies on software for things like calibration, setting frequencies, and setting power.

> Seems like security by obscurity.

There are legal standards to meet around protecting the system from users modifying things like output power. They don’t literally say that the source code must be private, of course, but keeping it closed source makes it much easier to demonstrate that you were not making it easy for people to exceed the regulatory limits.

If you document the registers for setting output power (for example) then you’re giving the end user a roadmap for changing output power.

That was my takeaway as well when I was working with Bluetooth modules a few years back.

There were a few more reasons too, at least at the time. The companies in the space didn't have a culture of open sourcing, and there's probably no perceived commercial upside to releasing code for a chip like that.

I think often it's also a combination of what you described and big companies being super risk-averse. Why risk breaking regulations if you can just say no?

Then again, lots of Wi-Fi-enabled devices support simply changing their region setting and will happily let you use different Wi-Fi bands or increase signal power.

True but those bands are still official wifi bands somewhere.

On software-defined radios you can often use them way out of spec, way more so than using a forbidden channel. But in a totally different band. A good example is the RTL-SDR stick which was designed to be a TV received but can be used as a wideband SDR these days. That's a receive-only device so it's not that critical to regulators. Once you can transmit, it becomes more of a problem.

An example of a more problematic transmission device is the Raspberry Pi PWM pin. That's been used to transmit all sorts of stuff on many bands. Because it was never designed to transmit anything, it causes all kinds of weird harmonics and artifacts. It's a really bad idea to use it for that. Most people just do it under controlled circumstances.

To be fair, depending on your partnership you actually do get the code to these blobs, and export control comes into play.

I understood the criticism to be about describing it as open source when it isn't, i.e. that

"We say it's open source because we expect the reader to know that we're not telling the truth"

should be replaced by

"It's open source except for the BLE firmware blob, which can't be open source due to regulatory reasons."

To be fair, the article just repeated the claims made on the GitHub page for the SDK.

Not in Zephyr. There's a full BLE Controller in source code form there.

Zephyr provides an open source implementation of all layers of the BLE stack. The radios of some devices are documented extensively, Nordic nRF5 devices are probably the best example.

The Bluetooth SIG requires that you qualify your device if you advertise that you use Bluetooth IP, similar to what is required for the cellular space. Do you have to do this if you’re just “Bluetooth compatible?” Maybe not. Whatever the case you have to conduct FCC part 15C testing (intentional radiator).

> you have to conduct FCC part 15C testing (intentional radiator)

Maybe soon you won’t.

Care to elaborate?

Maybe orange man will abolish the FCC because rules are inefficient

He won't abolish the FCC. It is too efficient at attacking his enemies.

looking at his policy to China and Russia, maybe his enemies are not what we thought

His enemies are Americans that don't bow down.

I have yet to see a real case of "binary blob for regulatory reasons". What law prevents open source RF firmware?

The device needs to operate in spec and if someone reflashes it with out of spec firmware, that's no different than someone soldering a different resistor onto the PCB or feeding the output of the chip into an amplifier and large antenna. It's a modification by the user and so the user is liable for operating out of spec. And all of this really unrelated to source code, just to reflashablitiy. The code could easily be open, but the productions device could be made unflashable if the law really required it. Yet this is not what we see here.

It's IP reasons, and that's fine, but let's not make up additional excuses for them.

> The code could easily be open, but the productions device could be made unflashable if the law really required it.

Excellent point. Many people (myself included) do assume that open source = redeployable, as in GPL3. I guess an e-fuse for read-only is perfectly OK, both from regulatory standpoint, and for ensuring you're running the same code as what you have the source for. That would be cool.

Reply on news.ycombinator.com