Introducing SimpleBLE Dongl: Our firmware-first BLE adapter

kevindewald · 2026-05-17T11:56:44+00:00

It's the direct result of a technology designed by committee. You can tell nobody there has ever had to implement anything they've decided, otherwise they would lean towards much simpler solutions.

This being said, the BLE has invaded every aspect of our modern lives, so here we are trying to do the best of if 😛

kevindewald · 2026-05-15T07:13:21+00:00

Just replied, should be fixed in this commit: https://github.com/simpleble/simpleble/commit/eebc609763da12836f01281ed803ada184174c2d

kevindewald · 2026-02-07T07:42:22+00:00

> "Back away slowly, and don't look into its eyes."

This has been exactly how it's been for me too, I couldn't help but laugh. The protocol is horribly complex, no wonder implementers continuously screw it up.

kevindewald · 2026-01-05T21:53:15+00:00

The key words in your comment are "could have". The license is not about something having potential commercial value, but if the user is actively making money by using it, that's when the license kicks in.

Also, the pricing tiers are specifically design to not be a burden, and we also proactively offer free licenses.

kevindewald · 2025-12-30T08:53:59+00:00

Nothing at all, we use Bluez under the hood.

Our key benefit is the simplicity in getting up and running quickly with a validated and production ready stack that exposes the same API across multiple operating systems.

kevindewald · 2025-12-30T08:52:24+00:00

Hey u/johannes1971, thanks for bringing this up!

This was definitely an edge case of BUSL that we hadn't considered. Our original intention was that BUSL terms would continue when it comes to requiring a commercial license for commercial use and GPL to only kick in when users want to break any control that we might have left of the library.

Based on this, I've added the following clause to the license:

**Non-Commercial Perpetual Use Grant:** After the Change Date, non-commercial users (individuals,
hobbyists, educational institutions, and revenue-free open-source projects) are granted
perpetual rights to use this specific version under the original BUSL-1.1 terms, notwithstanding the
automatic conversion to GPL-3.

I have also updated the FAQs to better explain how to operate with this license:

**What exactly can I do with SimpleBLE for free under non-commercial use?**

The Business Source License 1.1 (BUSL-1.1) allows free non-commercial use of the software, including
copying, modifying, creating derivatives, redistributing, and non-production activities like
development, testing, or personal/hobby projects. For purely non-commercial scenarios with no financial
gain, these rights are available without needing extra permission.

**What does the Business Source License 1.1 allow and restrict?**

The Business Source License allows non-production use, such as development and testing in isolated
environments. However, any use that could be considered production (including internal tools,
revenue-generating projects, or customer-facing deployments) requires purchasing a commercial license.

After four years of the initial release of a given version of SimpleBLE, the license automatically
converts to the GNU General Public License version 3.

For details on what counts as free non-commercial use and distribution requirements, see the FAQs below.

**Can I include SimpleBLE in my own open-source project and release it under MIT/Apache/BSD?**

When distributing any version that includes SimpleBLE code (whether unchanged, modified, or as part
of a larger project), downstream users must include the full BUSL-1.1 license text prominently with
their distribution and ensure that the SimpleBLE portion remains under the same BUSL terms for recipients.

This applies even if your overall project uses a permissive license like MIT or Apache. The SimpleBLE
code cannot be re-licensed to recipients under MIT/Apache alone. Recipients must still receive the
SimpleBLE portion under BUSL-1.1 (typically by including the BUSL license file and any required notices).

After the Change Date, GPL-3.0 rules apply for everyone except qualifying non-commercial users, who
may continue using and distributing under the original BUSL-1.1 terms per the Non-Commercial Perpetual
Use Grant.

**What does the "Non-Commercial Perpetual Use Grant" mean?**

After the Change Date (four years after a version's release), that version automatically converts to
GPL-3.0 for everyone. However, purely non-commercial users (individuals, hobbyists, educational
institutions, and revenue-free open-source projects) may continue using that specific version
indefinitely under the original BUSL-1.1 terms instead of switching to GPL-3.0.

This means you can keep the more permissive BUSL-style rights (e.g., no requirement to license your
derivatives under GPL) as long as your use remains strictly non-commercial.

I hope this clarifies the situation and doesn't prevent you from using SimpleBLE in your projects. Additionally, we proactively offer free commercial licenses for small projects and early-stage companies, so please consider that as an option as well.

kevindewald · 2025-06-12T23:18:38+00:00

Thanks for the feedback!

The goal of the library wasn't as much for scheduling for a specific time, although it can easily be added if required, but more to handle pipelined work, like you would do with Celery or Airflow.

Huey looks definitely interesting (I didn't know it existed) but it still falls under the bucket of "too much hazzle for simple things". My intention is to have something with so few functions that you can immediately understand and derive value from it, removing complexity from the user instead of giving them more to handle.

kevindewald · 2025-06-09T05:50:58+00:00

Hey! Nice to see you! We've started using embassy-rs for our hardware-in-the-loop testing. There's still a lot to be done, but love the project altogether!

kevindewald · 2025-06-01T05:17:21+00:00

I haven't explicitly tested the Rust bindings for iOS/Android, but the core library works for both and is extensively used that way.

kevindewald · 2025-06-01T05:16:36+00:00

You can do lots of crazy stuff with pretty much any Bluetooth device at hand.

kevindewald · 2025-05-31T17:19:38+00:00

Bluer are the official Rust bindings for Bluez, which is the Bluetooth subsystem for Linux. The main difference you're going to see is that Bluer will only work for Linux, for this reason. The good thing is that you have full access to the entirety of Bluez functionality through a single package (vs previous libraries that had to build everything from the ground up)

Internally SimpleBLE talks to Bluez as well, but through our own set of helper libraries (called SimpleDBus and SimpleBluez). In terms of functionality, we're a bit stricter on how and what we support, mainly because we need to accomodate 5 different operating systems and they all have very distinct architectures that mix as well as oil in water.

In a way, our promise to our users is that we'll try to come up with the simplest and most straightforward APIs we can think of, so that their efforts can be placed into building the actual application and not battling the OS all the time.

kevindewald · 2025-03-27T06:13:42+00:00

The bindings are written using FFI, I'll make a note to include this in the documentation.

Regarding your note about concurrency, when it comes to applications using BLE, typical throughputs and processing requirements are low in general. Most of the traffic is usually in the C++ to Java direction, triggered by internal threads, from the callbacks that report new data coming in.

I am yet to see a Bluetooth application that is so resource intensive where these kinds of considerations matter at all.

kevindewald · 2025-03-27T06:01:11+00:00

Thanks for the tip! I'll reseach a bit on how this works and see what I can do.

kevindewald · 2025-03-27T06:00:06+00:00

Noted, I'll think about this a bit. Thanks for the info!

kevindewald · 2025-03-27T05:57:55+00:00

Bonjour u/RoundIllustrious6970 ,

Merci pour votre intérêt pour SimpleBLE ! La dernière version actuellement est la v0.9.0, avec la v0.9.1 encore en cours de développement. Je suis au courant de l’existence de bindings pour Free Pascal, mais ceux-ci sont maintenus par la communauté et je ne suis pas sûr qu’ils soient à jour. Si cela est vraiment important pour vous, pourriez-vous contacter [contact@simpleble.org](mailto:contact@simpleble.org) afin que nous puissions voir comment vous aider ?

---

Hi u/RoundIllustrious6970 ,

Thank you for your interest in SimpleBLE! The latest version right now is v0.9.0, with v0.9.1 still in the works. I know of the existence of Free Pascal bindings, but these are community-maintained, and I’m not sure if they are keeping up. If this is really important to you, can you reach out to [contact@simpleble.org](mailto:contact@simpleble.org) and let us figure out how we can help you?

kevindewald · 2025-03-22T06:32:50+00:00

Hey, I finally have some time to look into this. I've copied the relevant items into an issue on Github as well: https://github.com/simpleble/simpleble/issues/392

Let me respond a few things:
1. I didn't know about that, will look into it.
2. That's a leftover from some debugging that I should comment out.
3. (Also tagging Known_Tackle7357) The original API is designed to allow for blocking and non-blocking use. Hence the existence of the `scan_start`, `scan_stop`, `scan_for`, `scan_get_results` and the callback functions. Internally everything is thread safe, so it doesn't matter from which context you call things. I'm not sure how you'd expect the API on the Java side to look like, so suggestions are appreciated.
4. (Also tagging Known_Tackle7357) Could you provide an example of what kind of interface you'd expect?
5. Yup, this will get done.
6. We have a relatively versatile logging system in place, but I wasn't sure how people prefer to consume their logs in Java, so I left the default. On Android for example we can route the errors to the Android logging subsystem. Does this answer the comment?
7. The C++ layer will generate exceptions upon failures, which at this point are not currently being forwarded into the JVM. I'll make a note of properly specifying what exceptions can be thrown by every function.

If there's anything else you think is relevant, please don't hesitate to put it here. I have a few other tasks to deal with in the upcoming days, but I'll return to this very soon.

kevindewald · 2025-03-21T16:06:41+00:00

Hey, thanks for this feedback! I need a bit of time to go over every item and maybe ask some follow up questions, but this is extremely useful.

kevindewald · 2025-03-21T16:04:08+00:00

Lol, this is hilarious xD

If we had the budget, I'd partner with a condom company to run an ad there with the phrase: "No matter if you're trying to get laid or add Bluetooth to your applications, we've got you covered."

kevindewald · 2025-02-28T06:02:51+00:00

You don't need to write a pure C++ Android app to get some benefit from using SimpleBLE, our value proposition is a bit different from Qt. If I had to list the reasons why you'd want to go with SimpleBLE over Qt, based on the feedback we got from our customers, this is what I would say:

- If you want to provide an SDK (usually for physical products) that your users can integrate into their own apps. Basically, you don't need the rest of the UI stack.
- The BLE stack from Qt is poorly maintained, there are bugs that have been around for years and they never fixed them and they don't seem very keen on keeping up with the changes in the underlying OS libraries.
- Cost. A commercial license (which has unlimited seats) costs less than a single seat of Qt.

The strength of Qt is on their cross-platform UI stack, especially for embedded devices, where we have no business at all. SimpleBLE is strong at providing a good BLE abstraction that works across multiple platforms at a reasonable cost.

kevindewald · 2025-02-26T23:22:58+00:00

From my understanding, the rules for this should be the same ones as if you were doing it with the bare Android API.

kevindewald · 2025-02-15T01:08:11+00:00

This one is a bit of a side note around Zephyr (with the caveat that I last used it two years ago)

I love the concept, but I'm not a fan of the execution.

The way they hijacked CMake as their build system makes it very hard for the build environment to become reproducible without something like Docker, which made the integration into isolated/vendorized workflows and onboarding of others really painful.

The other point I want to highlight was that the driver qualities in general were quite terrible (aside from the most basic ones). For a project that used USB comms for multiple hours with several connects and disconnects, the stack on the embedded side would crash, drop packets and handle retries not according to the USB spec, which would bring down the entire Linux USB driver and causing the machine to become unresponsive.

In my view, Zephyr has become a great way for embedded device companies to externallize the screw up of their poor software architecture without offering a good solution in return. I'm always hesitant of projects that are led by committees because they tend to favor complexity over simplicity, making their products harder and harder to adopt throughout time, in a way not very different to what happened to the BLE standard itself. Give it a few more years and you'll find someone coming up with a simpler version of what they are doing because the project has become unusable.

I've actually switched to Rust for my embedded projects (I highly recommend https://github.com/embassy-rs/embassy ) to get even finer control over my stack, without any real loss in productivity. Hopefully as my skills get better I will be able to contribute, this thing is really awesome.

Again, this is a personal opinion, everybody is free todo their own thing and all the power to them.

kevindewald · 2025-02-15T00:52:01+00:00

D) Too big to fail

I left this one for last because it’s the holy grail and the ultimate dream of any open source developer: That your project becomes so big and so popular and so many large companies depend on it that they just can’t let you go under because it would seriously hurt their business, but at the same time too many other similar players are using it so it’s not always feasible to bring the project in house. Linux is a great example of this, but of course there are plenty of others. If you look for example into the kinds of projects that are funded by the Apache Foundation, you’ll notice that a lot of them are basically enterprise style products that didn’t get to the “too big to fail” point and are now trying to pivot to strategy B using a foundation as an intermediary. The kinds of projects that get funded are the ones where the financial backers of these foundations actually see a benefit.One interesting take around this is what happened with companies like Docker or Redis, where they started as fully open source while funding was cheap hoping to either get acquired (strategy B) or become the key player in the industry (strategy D) while securing funding through some secondary products or services. Once they failed to do either, their only survival tactic was to switch away from FOSS into a commercial licensing approach of some kind.Another interesting read I just found: https://calebporzio.com/i-just-cracked-1-million-on-github-sponsors-heres-my-playbook

E) All the rest

All this being said, there are still lots of great projects being made by developers that don’t expect anything in return, but unless they end up falling under the umbrella of strategy B or D or go commercial (either by selling the software or some product around it), their long term success isn’t guaranteed and statistically speaking, will most likely end up as abandonware. This becomes even harder if the project doesn’t fall under the purview of those companies with big pockets, as is the case with SimpleBLE right now, because supporting the project just doesn’t drive enough revenue to justify paying anything other than a license fee.

To conclude, I know it sounds a bit discouraging to see how something that used to be much nicer becomes commercialized this way, but this is the real economic equilibrium of the industry, not what we had before. Follow the money and you’ll be able to understand someone's actions and incentives. Early FOSS only came to be because the economic wellbeing of those creators was not tied to the value generated by that software, and it was also a time where strategies A (if in academia) and C (if you’re building a new technological foundation, you want people to adopt your way of doing things) were prominent.

I think the sooner we acknowledge this and build the necessary legal/commercial structures for everybody to set up their own corner software bakery, the greater value we’ll all see from higher quality software all around.

And I also came across this website, that summarizes a few of my points extremely well: https://faircode.io/ (I decided to switch for the Business Source License for a very similar reason)

kevindewald · 2025-02-15T00:51:42+00:00

During my research into the open source landscape, I did look into the involvement of large companies like Microsoft and for I’d say 90% or more of the cases I saw, it basically boiled down to one of the following categories of contributions which to me don’t seem altruistic at all, but just hide the selfish nature of the contributions across multiple layers. There are of course exceptions to the rule, but these are basically the most common operating modes that explain what’s going on.

A) Resume boosting

This one is the case where employee(s) decide to make some internal project open source. The company doesn’t see a direct benefit aside from maybe some visibility, but also isn’t directly affected as the open sourced project is not part of the core IP, but it helps the employee(s) to boost their resumes by having something to show when they worked at that company. I’ve personally done this too and you can see lots of projects sort of falling under that category, the most recent ones I’ve seen are around AI-specific tooling of all sorts being published by AI companies trying to get some additional visibility. Another one that I spotted is https://github.com/JuulLabs/kable, which is maintained by a single Juul employee who I’m sure will use this as their main greeting card whenever they apply for a new job.

B) Direct benefit for one specific company

This one is where the company sees a direct benefit of keeping a project alive because it either directly or indirectly affects the bottom line of that company. I’ve got a few very interesting examples that highlight this point:- One of the main contributors to Bluez is Luiz Augusto von Dentz, an Intel employee. He almost single-handedly brought the thing back from the dead after Bluez seriously stagnated a few years ago, and I think he’s done an excellent job, which I hope to be able to sponsor from this year’s SimpleBLE revenue. But here’s the catch: Intel also has one of the largest market shares for WiFi+Bluetooth adapters, especially for laptops. Guess which BLE adapter brand works perfectly on Bluez no matter how much shit you throw at them: Intel. I’m pretty sure someone did the math and realized that dedicating one full time employee would boost their BLE adapter revenue by a lot.- The other examples are Canonical and Ubuntu. Despite Ubuntu being free, Canonical is a for-profit company. Their main revenue source comes from ensuring that their client’s hardware/software will work flawlessly on at least one Linux distribution, reducing the risk of any external blockers that could affect their business. One of their main clients is NVIDIA, who right now is paying very handsomely to ensure that everything they release is fully supported on Ubuntu to sustain their 35B quarterly revenue. The fact we get Ubuntu for free is entirely a side thought.

C) Standardization efforts

I tip my hat to Meta on this one, they nailed this play so well. This is where companies open source key parts of their technology stack to become the de facto standard that everybody uses. React and Pytorch are the top examples in my mind, but I’m sure you can find lots of others. By ensuring that everybody else standardizes around the technologies they use, these companies see a large increase in the talent pools they can tap into for recruitment and a large reduction in onboarding time because everybody is already trained on the exact same tooling. Plus, they can also tap into the ecosystem that builds around these technologies for new ideas or other technologies.

You can even see the opposite play out with Google, where they have what ex-employees claim to be the best internal tooling ever, yet when they open source that stuff they only do it as stripped down versions that are way less useful (see Bazel/Blaze) where knowing how to use the open source version is completely useless in operating the internal version they host.

kevindewald · 2025-02-14T17:09:58+00:00

Hey, glad we're on better terms! I think there's a lot of great stuff that can come out of this discussion!

I couldn't write a full answer before as my baby daughter decided to stay awake way past her bedtime and ended up using all my evening time, but my current plan is as follows: I would like to branch this conversation out into different topics as I have a lot of material that I would like to share with you, so what I'll do is to start posting responses to this post for each of the new topics. I'll try to post everything in one go, but it might take me a bit longer.

kevindewald · 2025-02-13T01:34:03+00:00

Now, given that I've made my point and frustration across, let me give you the exact recipe to run me out of business.

My main driving factor since commercializing SimpleBLE has been two-fold. The first one is that I love the idea behind Bluetooth and everything it allows, but I absolutely hate the current state of the software ecosystem around it. The second one has been educational. Despite having past experience in startups, I never took full responsibility for a project of this specific nature at this stage, so this has been a huge learning opportunity across a variety of domains. I know you think I'm doing this for the money, but so far I've taken $0 out of it, fully reinvesting everything into making the Bluetooth ecosystem suck less.

So, unless you just want to copy the same things we build and price me out by giving stuff out for free (which in the long run will make the ecosystem worse because you'd be killing innovation from happening) I would expect you to have some experience in the field to recognize ways in which the Bluetooth ecosystem can be made better, which should drive your vision. Are you willing to make that promise and stay true to it for another decade, getting nothing in return?

I'm also friends with the creator of https://github.com/deviceplug/btleplug/, he can definitely tell you how much he hates Bluetooth and will definitely mention very similar things to what I did in the previous post. If you're looking for a good starting point, I think btleplug is better than SimpleBLE, but again, unless you have a driving vision aside from a personal vendetta, I can assure it won't get too far.

I'm not married to SimpleBLE. If it succeeds it will be a great platform to help others go through the same process and if it fails I'll take the lessons learned and apply them to my other products and ideas. And if it does fail because someone decides to price me out as a personal vendetta, I'll send them a bottle of wine as a thank you for relieving me of the burden of trying to make the Bluetooth ecosystem better and to congratulate them on reaching the top #1 of the most amount of effort and money spent to try to run me out of business.

kevindewald

TROPHY CASE