Question about the new Picco app - license (is the app even necessary?) #245

Open
opened 2026-01-09 06:59:01 +08:00 by cinehorse · 22 comments
cinehorse commented 2026-01-09 06:59:01 +08:00 (Migrated from github.com)

I, and I'm sure some others, are still a bit confused about this.

Let's stay in the "noob" phase for now.

I found Pico Keys on the web, and I think the project is great. So I decided to give it a try.

I followed the Pico-Fido branch.

I read through everything and saw that I need a Pico board or an ESP32 S3.

Great! I have several 2340s, 2350 Ones, and 2350 Zeros lying around.

So I went to the download page.

Here I wanted to look for my boards. And so far, I only found Raspberry Pi and Pico/Pico 2.

Ah, okay, the 2340 is Pico and the 2350 is Pico 2; I can't find anything for the two Waveshare boards.

So I downloaded the file for the Pico first. Put the Pico into boot mode and copy the file over. The device boots up and identifies itself as Picokey. Great, now what? Oh yeah, there's the Pico app for configuration, handy. Okay, it costs money, €30, but that's a gift; I can configure my boards with it. So, read through everything again, and wait a minute, 2340 isn't supported? But it says RP2340 everywhere before it. What have I just wasted my time on?

I can't find an image for the One or Zero directly.

Wait a minute, the downloaded files are 6.6 files, but it says 7.2 above.

The Pico app also says 7.2 because older versions are NOT supported.

But if you click on 7.2 above, you end up on GitHub.

From here on, a normal user is completely lost.


If you have a bit more experience and know GitHub, you can also find version 7.2, but again, only for Pico and Pico 2.

What's the point of UF2 for Pico 1 (RP2340) if you can no longer configure it with the app?

When I update my 2350 Zero or One with version 7.2, the VID and serial number thankfully remain the same, and the YubKey Manager still works, but the LED is dead. Luckily, I was able to revert back to version 7.0, and everything is back to normal.

In other words, an update from 6.6 or 7.0 is not possible without the Pico app!

If the hardware breaks, you can still flash the existing UF2, but configuration is impossible. Therefore, the image is essentially useless!


Up until now, the Picokey project was fantastic and a real alternative to all other keys. You could experiment, download the firmware, install it, and configure it via the website. If it worked as desired, you could optionally activate the security options—perfect. If it didn't work or you weren't satisfied with the hardware, you bought a new board (e.g., a Waveshare instead of a Pico 2 because it was smaller), flashed the new firmware, and configured it again.

Then suddenly everything was gone. Not a beep, not a hint, nothing. Everyone was left with a question mark. Eventually, it was announced that everything would be back as an app.

My first thought was, "The good things get better," and the app certainly wouldn't be free, but given the previous possibilities, I was happy to pay something and had prepared myself for €20-25.

Then the app arrived, and I was pleased. Okay, €30—more than expected—but you knew what you could do with it, and still can.

But after reading everything, I was more than disappointed.

The license is tied to the device, meaning it's no longer possible to configure, test, and potentially discard different boards!

I'm also very confused about one thing: does "one device" mean only a single key, or does it refer to any number of devices of the same type? In other words, if I tie the license to a Waveshare 2350 Zero board, can I then configure an unlimited number of Zeros?

If I also want to configure WS2350 Ones, do I buy another license, and can I then use that to configure any number of Ones?

I've asked this question before, but the answer wasn't entirely clear. I'd like a clear and unambiguous answer here.

If the license fee really is only for a single device, then in my opinion, the project is essentially dead.

Why bother buying a circuit board for around €10, 3D printing a case, flashing the firmware, and then paying another €30 for the app? The hardware/software costs plus the effort involved are completely disproportionate, and for just €10 more you could buy a ready-made key from Yubi or Nitro and get NFC built in, and ideally even USB-A and USB-C ports simultaneously.

However, if the license covers any number of devices, like Waveshare RP2350 Zeros, the price would still be too high, but it would be worth considering.

For what you've created here, a financial future is both right and important. However, in my opinion, the path you've chosen is the wrong one.

I have the following idea, which could definitely be successful:

The app is being expanded. You buy a license for €30, then set up and configure your board in the app, and the UF2 file is created. You can then easily flash this file to any number of identical boards. If you want to flash other boards, you can expand the app for another €20 to include a different board type. Each additional board type costs an extra €10.

I would gladly pay for such a licensing model; it would definitely be a no-brainer. Above all, it would appeal to the average user.

Buy, configure, upload to RP, and be happy.

(Of course, you can compile it yourself, but that requires some skills. Simply following the clone and make instructions unfortunately doesn't lead to success, and how and where to find all the parameters that can be passed to the make command doesn't seem to be properly documented anywhere, at least I haven't found anything so far.)

I, and I'm sure some others, are still a bit confused about this. Let's stay in the "noob" phase for now. I found Pico Keys on the web, and I think the project is great. So I decided to give it a try. I followed the Pico-Fido branch. I read through everything and saw that I need a Pico board or an ESP32 S3. Great! I have several 2340s, 2350 Ones, and 2350 Zeros lying around. So I went to the download page. Here I wanted to look for my boards. And so far, I only found Raspberry Pi and Pico/Pico 2. Ah, okay, the 2340 is Pico and the 2350 is Pico 2; I can't find anything for the two Waveshare boards. So I downloaded the file for the Pico first. Put the Pico into boot mode and copy the file over. The device boots up and identifies itself as Picokey. Great, now what? Oh yeah, there's the Pico app for configuration, handy. Okay, it costs money, €30, but that's a gift; I can configure my boards with it. So, read through everything again, and wait a minute, 2340 isn't supported? But it says RP2340 everywhere before it. What have I just wasted my time on? I can't find an image for the One or Zero directly. Wait a minute, the downloaded files are 6.6 files, but it says 7.2 above. The Pico app also says 7.2 because older versions are NOT supported. But if you click on 7.2 above, you end up on GitHub. From here on, a normal user is completely lost. ------------------------------- If you have a bit more experience and know GitHub, you can also find version 7.2, but again, only for Pico and Pico 2. What's the point of UF2 for Pico 1 (RP2340) if you can no longer configure it with the app? When I update my 2350 Zero or One with version 7.2, the VID and serial number thankfully remain the same, and the YubKey Manager still works, but the LED is dead. Luckily, I was able to revert back to version 7.0, and everything is back to normal. In other words, an update from 6.6 or 7.0 is not possible without the Pico app! If the hardware breaks, you can still flash the existing UF2, but configuration is impossible. Therefore, the image is essentially useless! --------------------------------- Up until now, the Picokey project was fantastic and a real alternative to all other keys. You could experiment, download the firmware, install it, and configure it via the website. If it worked as desired, you could optionally activate the security options—perfect. If it didn't work or you weren't satisfied with the hardware, you bought a new board (e.g., a Waveshare instead of a Pico 2 because it was smaller), flashed the new firmware, and configured it again. Then suddenly everything was gone. Not a beep, not a hint, nothing. Everyone was left with a question mark. Eventually, it was announced that everything would be back as an app. My first thought was, "The good things get better," and the app certainly wouldn't be free, but given the previous possibilities, I was happy to pay something and had prepared myself for €20-25. Then the app arrived, and I was pleased. Okay, €30—more than expected—but you knew what you could do with it, and still can. But after reading everything, I was more than disappointed. The license is tied to the device, meaning it's no longer possible to configure, test, and potentially discard different boards! I'm also very confused about one thing: does "one device" mean only a single key, or does it refer to any number of devices of the same type? In other words, if I tie the license to a Waveshare 2350 Zero board, can I then configure an unlimited number of Zeros? If I also want to configure WS2350 Ones, do I buy another license, and can I then use that to configure any number of Ones? I've asked this question before, but the answer wasn't entirely clear. I'd like a clear and unambiguous answer here. If the license fee really is only for a single device, then in my opinion, the project is essentially dead. Why bother buying a circuit board for around €10, 3D printing a case, flashing the firmware, and then paying another €30 for the app? The hardware/software costs plus the effort involved are completely disproportionate, and for just €10 more you could buy a ready-made key from Yubi or Nitro and get NFC built in, and ideally even USB-A and USB-C ports simultaneously. However, if the license covers any number of devices, like Waveshare RP2350 Zeros, the price would still be too high, but it would be worth considering. For what you've created here, a financial future is both right and important. However, in my opinion, the path you've chosen is the wrong one. I have the following idea, which could definitely be successful: The app is being expanded. You buy a license for €30, then set up and configure your board in the app, and the UF2 file is created. You can then easily flash this file to any number of identical boards. If you want to flash other boards, you can expand the app for another €20 to include a different board type. Each additional board type costs an extra €10. I would gladly pay for such a licensing model; it would definitely be a no-brainer. Above all, it would appeal to the average user. Buy, configure, upload to RP, and be happy. (Of course, you can compile it yourself, but that requires some skills. Simply following the clone and make instructions unfortunately doesn't lead to success, and how and where to find all the parameters that can be passed to the make command doesn't seem to be properly documented anywhere, at least I haven't found anything so far.)
polhenarejos commented 2026-01-09 07:15:48 +08:00 (Migrated from github.com)

Thanks for taking the time to write such a detailed explanation — this kind of feedback is genuinely useful.

Let me clarify a few points, because I agree that some things were confusing, especially during the transition.

Versions / downloads

You’re right about the version mismatch. The links themselves were correct, but the download script was not updated, which caused the confusion between 6.6 and 7.2. That has already been fixed. Sorry about that — this one is on me.

Why the license is tied to a device

This is not an arbitrary business decision, but a technical one.

On RP Pico–based boards it is currently not possible to reliably detect the exact board variant (vendor, LED GPIO, button wiring, polarity, etc.) at runtime.
To give users a “plug and forget” experience, the app generates an offline configuration schema that defines all flash parameters, LED behavior, button wiring, and related quirks automatically, without requiring the user to touch low-level settings. In the past I uploaded separated but it scaled very bad (last time there were 100+ different firmwares), adding noise and increasing the complexity unnecessarily.

To do this safely and transparently, the configuration must be tied to the board type, and the unique serial number of that device.

This is why the current model is per device. It is what allows the app to remain simple and robust for non-expert users.

RP2040 (not RP2340) support

Just to clarify the naming first: RP2340 is actually RP2040.

RP2040 is a delicate topic. It’s not that it is "blocked" — the app should still work — but from a security standpoint it is fundamentally weaker, and I cannot recommend it anymore for a security key. I have to discourage its use for security purpose.
That said, this is a security recommendation, not an artificial restriction.

About the licensing model going forward

Your suggestion is reasonable, and you’re not the only one to raise it.

The current model was chosen for simplicity and to get a first stable version out.
However, I am actively considering introducing additional seats (for example 10–15€ each), allowing multiple devices to be registered under the same license.

This is technically feasible. I want to see how the current model is received before changing it, but it’s absolutely on the table.

Final note

I fully agree that a financial future for the project is necessary, but it should not come at the cost of usability. Feedback like this helps refine that balance.

Despite recent discussions, I want to stress that the firmware remains fully open, and the app is not strictly required. Skilled users, students, and developers can continue building and flashing their own firmware without restrictions.

As the project grew -including adoption in third-party commercial contexts outside the PicoKeys ecosystem- the number of supported boards, users, and support demands increased significantly. To keep the project reliable and maintainable, it needs a sustainable way to scale. The app exists to make configuration accessible for a broader audience while keeping the core firmware open.

Thanks again for the constructive input.

Thanks for taking the time to write such a detailed explanation — this kind of feedback is genuinely useful. Let me clarify a few points, because I agree that some things were confusing, especially during the transition. ### Versions / downloads You’re right about the version mismatch. The links themselves were correct, but the download script was not updated, which caused the confusion between 6.6 and 7.2. That has already been fixed. Sorry about that — this one is on me. ### Why the license is tied to a device This is not an arbitrary business decision, but a technical one. On RP Pico–based boards it is currently not possible to reliably detect the exact board variant (vendor, LED GPIO, button wiring, polarity, etc.) at runtime. To give users a “plug and forget” experience, the app generates an offline configuration schema that defines all flash parameters, LED behavior, button wiring, and related quirks automatically, without requiring the user to touch low-level settings. In the past I uploaded separated but it scaled very bad (last time there were 100+ different firmwares), adding noise and increasing the complexity unnecessarily. To do this safely and transparently, the configuration must be tied to the board type, and the unique serial number of that device. This is why the current model is per device. It is what allows the app to remain simple and robust for non-expert users. ### RP2040 (not RP2340) support Just to clarify the naming first: RP2340 is actually RP2040. RP2040 is a delicate topic. It’s not that it is "blocked" — the app should still work — but from a security standpoint it is fundamentally weaker, and I cannot recommend it anymore for a security key. I have to discourage its use for security purpose. That said, this is a security recommendation, not an artificial restriction. ### About the licensing model going forward Your suggestion is reasonable, and you’re not the only one to raise it. The current model was chosen for simplicity and to get a first stable version out. However, I am actively considering introducing additional seats (for example 10–15€ each), allowing multiple devices to be registered under the same license. This is technically feasible. I want to see how the current model is received before changing it, but it’s absolutely on the table. ### Final note I fully agree that a financial future for the project is necessary, but it should not come at the cost of usability. Feedback like this helps refine that balance. Despite recent discussions, I want to stress that the firmware remains fully open, and the app is not strictly required. Skilled users, students, and developers can continue building and flashing their own firmware without restrictions. As the project grew -including adoption in third-party commercial contexts outside the PicoKeys ecosystem- the number of supported boards, users, and support demands increased significantly. To keep the project reliable and maintainable, it needs a sustainable way to scale. The app exists to make configuration accessible for a broader audience while keeping the core firmware open. Thanks again for the constructive input.
zyp114514 commented 2026-01-09 07:45:33 +08:00 (Migrated from github.com)

You should build the frimware by your self from source code

You should build the frimware by your self from source code
metabo7000 commented 2026-01-09 16:26:11 +08:00 (Migrated from github.com)

You should build the frimware by your self from source code

Does everyone who is on gibhub understand this? Funny concept! To this day I have not been able to compile any cmake source under Windows or Ubuntu Linux, and I have followed the instructions, proving the errors with videos and pictures, but no one has taken the trouble to help me with this! But here I don't see how a tutorial video could be made about the entire process, even after a year and a half!

> You should build the frimware by your self from source code Does everyone who is on gibhub understand this? Funny concept! To this day I have not been able to compile any cmake source under Windows or Ubuntu Linux, and I have followed the instructions, proving the errors with videos and pictures, but no one has taken the trouble to help me with this! But here I don't see how a tutorial video could be made about the entire process, even after a year and a half!
zyp114514 commented 2026-01-09 16:29:59 +08:00 (Migrated from github.com)

You should build the frimware by your self from source code

Does everyone who is on gibhub understand this? Funny concept! To this day I have not been able to compile any cmake source under Windows or Ubuntu Linux, and I have followed the instructions, proving the errors with videos and pictures, but no one has taken the trouble to help me with this! But here I don't see how a tutorial video could be made about the entire process, even after a year and a half!

maybe the repo is so cold

you need compile the pico-keys-sdk first
cd pico-keys-sdk
cmake .
make -j$(nproc)

> > You should build the frimware by your self from source code > > Does everyone who is on gibhub understand this? Funny concept! To this day I have not been able to compile any cmake source under Windows or Ubuntu Linux, and I have followed the instructions, proving the errors with videos and pictures, but no one has taken the trouble to help me with this! But here I don't see how a tutorial video could be made about the entire process, even after a year and a half! maybe the repo is so cold you need compile the pico-keys-sdk first `cd pico-keys-sdk` `cmake .` `make -j$(nproc)`
metabo7000 commented 2026-01-09 17:00:12 +08:00 (Migrated from github.com)

A frimware-t saját magadnak kell felépítened forráskódból.

Mindenki, aki a gibhubon van, érti ezt? Vicces koncepció! A mai napig nem sikerült lefordítanom semmilyen cmake forráskódot Windows vagy Ubuntu Linux alatt, pedig követtem az utasításokat, videókkal és képekkel bizonyítva a hibákat, de senki sem vette a fáradtságot, hogy segítsen nekem ebben! De itt nem látom, hogyan lehetne egy oktatóvideót készíteni a teljes folyamatról, még másfél év után sem!

talán a repo annyira hideg

Először le kell fordítanod a pico-keys-sdk-t cd pico-keys-sdk cmake . make -j$(nproc)

Only the entire process can be used! I will only go into details!
A complete process of building from scratch tutorial video here, which leads to results, would be of interest to others, so everyone would understand what they saw!

> > > A frimware-t saját magadnak kell felépítened forráskódból. > > > > > > Mindenki, aki a gibhubon van, érti ezt? Vicces koncepció! A mai napig nem sikerült lefordítanom semmilyen cmake forráskódot Windows vagy Ubuntu Linux alatt, pedig követtem az utasításokat, videókkal és képekkel bizonyítva a hibákat, de senki sem vette a fáradtságot, hogy segítsen nekem ebben! De itt nem látom, hogyan lehetne egy oktatóvideót készíteni a teljes folyamatról, még másfél év után sem! > > talán a repo annyira hideg > > Először le kell fordítanod a pico-keys-sdk-t `cd pico-keys-sdk` `cmake .` `make -j$(nproc)` Only the entire process can be used! I will only go into details! A complete process of building from scratch tutorial video here, which leads to results, would be of interest to others, so everyone would understand what they saw!
wlatendresse commented 2026-01-09 19:09:53 +08:00 (Migrated from github.com)

This is not an arbitrary business decision, but a technical one.

On RP Pico–based boards it is currently not possible to reliably detect the exact board variant (vendor, LED GPIO, button wiring, polarity, etc.) at runtime. To give users a “plug and forget” experience, the app generates an offline configuration schema that defines all flash parameters, LED behavior, button wiring, and related quirks automatically, without requiring the user to touch low-level settings. In the past I uploaded separated but it scaled very bad (last time there were 100+ different firmwares), adding noise and increasing the complexity unnecessarily.

To do this safely and transparently, the configuration must be tied to the board type, and the unique serial number of that device.

I really don't see any technical reason why an app/website/whatever shouldn't be able to do exactly that, in order to create a configuration for the firmware, which is then parsed once by the firmware at the beginning. However, that has little to do with the app's licensing. It seems to me that the app is just a pretext to force this very license on the user through the app itself.

...

Final note

I fully agree that a financial future for the project is necessary, but it should not come at the cost of usability. Feedback like this helps refine that balance.

So, the quality of the project benefits from its users, yet at the same time, it tries to impose a forced license on these very users in the sense of "take and take" (take feedback and take money)?

I'm sure there are much better financing models than this one.

> > This is not an arbitrary business decision, but a technical one. > > On RP Pico–based boards it is currently not possible to reliably detect the exact board variant (vendor, LED GPIO, button wiring, polarity, etc.) at runtime. To give users a “plug and forget” experience, the app generates an offline configuration schema that defines all flash parameters, LED behavior, button wiring, and related quirks automatically, without requiring the user to touch low-level settings. In the past I uploaded separated but it scaled very bad (last time there were 100+ different firmwares), adding noise and increasing the complexity unnecessarily. > > To do this safely and transparently, the configuration must be tied to the board type, and the unique serial number of that device. > I really don't see any technical reason why an app/website/whatever shouldn't be able to do exactly that, in order to create a configuration for the firmware, which is then parsed once by the firmware at the beginning. However, that has little to do with the app's licensing. It seems to me that the app is just a pretext to force this very license on the user through the app itself. ... > ### Final note > > I fully agree that a financial future for the project is necessary, but it should not come at the cost of usability. Feedback like this helps refine that balance. > So, the quality of the project benefits from its users, yet at the same time, it tries to impose a forced license on these very users in the sense of "take and take" (take feedback and take money)? I'm sure there are much better financing models than this one.
zyp114514 commented 2026-01-09 19:30:45 +08:00 (Migrated from github.com)

Also, you need build&install picotool

Also, you need build&install picotool
polhenarejos commented 2026-01-09 20:07:46 +08:00 (Migrated from github.com)

This is not an arbitrary business decision, but a technical one.
On RP Pico–based boards it is currently not possible to reliably detect the exact board variant (vendor, LED GPIO, button wiring, polarity, etc.) at runtime. To give users a “plug and forget” experience, the app generates an offline configuration schema that defines all flash parameters, LED behavior, button wiring, and related quirks automatically, without requiring the user to touch low-level settings. In the past I uploaded separated but it scaled very bad (last time there were 100+ different firmwares), adding noise and increasing the complexity unnecessarily.
To do this safely and transparently, the configuration must be tied to the board type, and the unique serial number of that device.

I really don't see any technical reason why an app/website/whatever shouldn't be able to do exactly that, in order to create a configuration for the firmware, which is then parsed once by the firmware at the beginning. However, that has little to do with the app's licensing. It seems to me that the app is just a pretext to force this very license on the user through the app itself.

...

Final note

I fully agree that a financial future for the project is necessary, but it should not come at the cost of usability. Feedback like this helps refine that balance.

So, the quality of the project benefits from its users, yet at the same time, it tries to impose a forced license on these very users in the sense of "take and take" (take feedback and take money)?

I'm sure there are much better financing models than this one.

I understand the concern, but this is not about enforcing a license through artificial constraints.

The firmware is open and can be built and configured without the app. Nothing prevents anyone from doing so. The app exists to provide a reliable, automated configuration path for non-expert users across multiple board variants, under real hardware constraints.

Licensing the app is simply the way I chose to sustain that effort. It is optional, not forced, and alternatives remain available for those who prefer them.

Different financing models exist, but this is the one I maintain and support.

> > This is not an arbitrary business decision, but a technical one. > > On RP Pico–based boards it is currently not possible to reliably detect the exact board variant (vendor, LED GPIO, button wiring, polarity, etc.) at runtime. To give users a “plug and forget” experience, the app generates an offline configuration schema that defines all flash parameters, LED behavior, button wiring, and related quirks automatically, without requiring the user to touch low-level settings. In the past I uploaded separated but it scaled very bad (last time there were 100+ different firmwares), adding noise and increasing the complexity unnecessarily. > > To do this safely and transparently, the configuration must be tied to the board type, and the unique serial number of that device. > > I really don't see any technical reason why an app/website/whatever shouldn't be able to do exactly that, in order to create a configuration for the firmware, which is then parsed once by the firmware at the beginning. However, that has little to do with the app's licensing. It seems to me that the app is just a pretext to force this very license on the user through the app itself. > > ... > > > ### Final note > > I fully agree that a financial future for the project is necessary, but it should not come at the cost of usability. Feedback like this helps refine that balance. > > So, the quality of the project benefits from its users, yet at the same time, it tries to impose a forced license on these very users in the sense of "take and take" (take feedback and take money)? > > I'm sure there are much better financing models than this one. I understand the concern, but this is not about enforcing a license through artificial constraints. The firmware is open and can be built and configured without the app. Nothing prevents anyone from doing so. The app exists to provide a reliable, automated configuration path for non-expert users across multiple board variants, under real hardware constraints. Licensing the app is simply the way I chose to sustain that effort. It is optional, not forced, and alternatives remain available for those who prefer them. Different financing models exist, but this is the one I maintain and support.
polhenarejos commented 2026-01-09 22:49:38 +08:00 (Migrated from github.com)

Please avoid promoting third-party tools repeatedly in this thread. Alternative projects are fine, but they should be discussed in their own channels. Thanks.

Please avoid promoting third-party tools repeatedly in this thread. Alternative projects are fine, but they should be discussed in their own channels. Thanks.
lockedmutex commented 2026-01-09 22:50:14 +08:00 (Migrated from github.com)

Please avoid promoting third-party tools repeatedly in this thread. Alternative projects are fine, but they should be discussed in their own channels. Thanks.

Sorry deleted my comment.

> Please avoid promoting third-party tools repeatedly in this thread. Alternative projects are fine, but they should be discussed in their own channels. Thanks. Sorry deleted my comment.
metabo7000 commented 2026-01-09 23:03:18 +08:00 (Migrated from github.com)

Szükséged lesz a picotool build és install programjára is.

The big solution to all problems is to close it!

https://github.com/polhenarejos/pico-fido/issues/58

> Szükséged lesz a picotool build és install programjára is. The big solution to all problems is to close it! https://github.com/polhenarejos/pico-fido/issues/58
shpinog commented 2026-01-11 06:33:38 +08:00 (Migrated from github.com)

Strange updates. It’s not clear whether I can take a file from the releases, like before, and flash it. Is there now one file for all devices? As I understand it — no. Now I have to build it myself for my specific board?

The new application is interesting, but again, strange. As I understand it, I’m being offered to buy a €30 license for 15 days for a single device?

I have a question for the author: do they understand that for €30 plus the cost of the board (without a case or anything else — just a bare PCB), I could just as well buy a finished product on many marketplaces? (I’m not naming them, but anyone who wants can find them on Ali, etc.)

I would see the point if it cost €15 and provided a personal, unlimited license for private use, or at least a reasonable number of allowed devices (3–5) that could be used with this software. I think this could be implemented via a license server and writing encrypted, individual files to the dongle that would serve as an identifier.

Strange updates. It’s not clear whether I can take a file from the releases, like before, and flash it. Is there now one file for all devices? As I understand it — no. Now I have to build it myself for my specific board? The new application is interesting, but again, strange. As I understand it, I’m being offered to buy a €30 license for 15 days for a single device? I have a question for the author: do they understand that for €30 plus the cost of the board (without a case or anything else — just a bare PCB), I could just as well buy a finished product on many marketplaces? (I’m not naming them, but anyone who wants can find them on Ali, etc.) I would see the point if it cost €15 and provided a personal, unlimited license for private use, or at least a reasonable number of allowed devices (3–5) that could be used with this software. I think this could be implemented via a license server and writing encrypted, individual files to the dongle that would serve as an identifier.
zyp114514 commented 2026-01-11 09:42:49 +08:00 (Migrated from github.com)

https://www.waveshare.net/wiki/RP2350-One
3.7euro in china
and a 3d print case cost less than 1 euro in china
but the app cost 30 euro =/

https://www.waveshare.net/wiki/RP2350-One 3.7euro in china and a 3d print case cost less than 1 euro in china but the app cost 30 euro =/
MadMechatronic commented 2026-01-11 10:46:37 +08:00 (Migrated from github.com)

Why the license is tied to a device

This is not an arbitrary business decision, but a technical one.

On RP Pico–based boards it is currently not possible to reliably detect the exact board variant (vendor, LED GPIO, button wiring, polarity, etc.) at runtime. To give users a “plug and forget” experience, the app generates an offline configuration schema that defines all flash parameters, LED behavior, button wiring, and related quirks automatically, without requiring the user to touch low-level settings. In the past I uploaded separated but it scaled very bad (last time there were 100+ different firmwares), adding noise and increasing the complexity unnecessarily.

To do this safely and transparently, the configuration must be tied to the board type, and the unique serial number of that device.


The current model was chosen for simplicity and to get a first stable version out. However, I am actively considering introducing additional seats (for example 10–15 € each), allowing multiple devices to be registered under the same license.

This is technically feasible. I want to see how the current model is received before changing it, but it’s absolutely on the table.

Final note

I fully agree that a financial future for the project is necessary, but it should not come at the cost of usability. Feedback like this helps refine that balance.

Despite recent discussions, I want to stress that the firmware remains fully open, and the app is not strictly required. Skilled users, students, and developers can continue building and flashing their own firmware without restrictions.

As the project grew -including adoption in third-party commercial contexts outside the PicoKeys ecosystem- the number of supported boards, users, and support demands increased significantly. To keep the project reliable and maintainable, it needs a sustainable way to scale. The app exists to make configuration accessible for a broader audience while keeping the core firmware open.

For my personal use case, this is a dealbreaker.

My intention with these keys was to experiment with and evaluate security-related features such as TOTP and FIDO2/WebAuthN. Requiring a 30 € license for an application of unknown quality, combined with keys that are still, in parts, effectively in a beta state, makes this setup economically and practically unjustifiable for me.

I tested the very first pico-fido for less than 30 minutes before discovering issue #241. You fixed it quickly, and fortunately this happened in a test environment. Had actual credentials been lost in an enterprise context, the consequences would have been catastrophic. This highlights how critical maturity, stability, and trust are in this domain.

On top of that, fully utilizing available hardware resources, for example using all flash storage on boards with 16 MB, requires building custom firmware. That already implies a board cost of at least 5 €, plus development time, plus the friction of incomplete or outdated documentation, at least when I played around with it. In total, this easily ends up in the 35–40 € range per device, before even considering the time and frustration involved. For just 10 € more, I get a fully audited product with a long history of reliable operation, NFC support, and a ready-to-use device.

The situation is made worse by how communication around the commissioner topic was handled. The commissioner was dropped, the community was left without clarity, and questions on this subject were avoided or ignored for weeks. This is a textbook example of how trust and reputation are damaged. The message it sends is that community feedback is welcome when it helps improve code and fix bugs, but the same community is not trusted enough to fully use the product without workarounds, such as spoofing USB IDs just to access existing tooling like the YubiKey app.

I do understand the desire, and the need, to monetize the project. That is not the issue. The problem is how this transition was handled and who ultimately ends up paying the price for it.

Kicking the community that helped build and harden the project is not a smart long-term strategy.

A suggested alternative approach

A more sustainable and community-friendly model could look like this:

Open Source Community Edition (free, faster widespread adoption, roughly comparable to the functionality of the YubiKey app):

  • Basic app functionality
  • FIDO2 key management
  • TOTP management
  • PIN configuration (LED/button)
  • maybe PIV Certificate handling

Pro / Enterprise Edition (paid):

  • License per app installation
  • Centralized key management
  • Remote key revocation
  • Ability to bind keys to authorized enterprise environments only
  • Only permit enterprise-issued keys, for example via certificate pinning
  • Automatic wipe and reset of revoked keys when connected to an enterprise-issued app
  • Enforced password and PIN policies, including expiring PINs
  • Security-focused audits and compliance features
  • Sale of ready-to-use, pre-flashed keys
    Realistically, no large organization wants to flash RP2350 or ESP microcontrollers themselves.

This kind of split would allow hobbyists, students, and developers to continue using and trusting the platform, while giving enterprises a clear value proposition they are willing to pay for.

Right now, the current direction alienates exactly the people who helped make the project viable in the first place.

At the end of the day, this is just a cheaper and less secure alternative to existing, well-adopted solutions. What the project needs is innovation. New ideas that solve real problems companies actually have, not another copy of a copy.

> ### Why the license is tied to a device > > This is not an arbitrary business decision, but a technical one. > > On RP Pico–based boards it is currently not possible to reliably detect the exact board variant (vendor, LED GPIO, button wiring, polarity, etc.) at runtime. To give users a “plug and forget” experience, the app generates an offline configuration schema that defines all flash parameters, LED behavior, button wiring, and related quirks automatically, without requiring the user to touch low-level settings. In the past I uploaded separated but it scaled very bad (last time there were 100+ different firmwares), adding noise and increasing the complexity unnecessarily. > > To do this safely and transparently, the configuration must be tied to the board type, and the unique serial number of that device. > --- > > The current model was chosen for simplicity and to get a first stable version out. However, I am actively considering introducing additional seats (for example 10–15 € each), allowing multiple devices to be registered under the same license. > > This is technically feasible. I want to see how the current model is received before changing it, but it’s absolutely on the table. > > ### Final note > > I fully agree that a financial future for the project is necessary, but it should not come at the cost of usability. Feedback like this helps refine that balance. > > Despite recent discussions, I want to stress that the firmware remains fully open, and the app is not strictly required. Skilled users, students, and developers can continue building and flashing their own firmware without restrictions. > > As the project grew -including adoption in third-party commercial contexts outside the PicoKeys ecosystem- the number of supported boards, users, and support demands increased significantly. To keep the project reliable and maintainable, it needs a sustainable way to scale. The app exists to make configuration accessible for a broader audience while keeping the core firmware open. For my personal use case, this is a dealbreaker. My intention with these keys was to experiment with and evaluate security-related features such as TOTP and FIDO2/WebAuthN. Requiring a 30 € license for an application of unknown quality, combined with keys that are still, in parts, effectively in a beta state, makes this setup economically and practically unjustifiable for me. I tested the very first pico-fido for less than 30 minutes before discovering issue **#241**. You fixed it quickly, and fortunately this happened in a test environment. Had actual credentials been lost in an enterprise context, the consequences would have been catastrophic. This highlights how critical maturity, stability, and trust are in this domain. On top of that, fully utilizing available hardware resources, for example using all flash storage on boards with 16 MB, requires building custom firmware. That already implies a board cost of at least 5 €, plus development time, plus the friction of incomplete or outdated documentation, at least when I played around with it. In total, this easily ends up in the 35–40 € range per device, before even considering the time and frustration involved. For just 10 € more, I get a fully audited product with a long history of reliable operation, NFC support, and a ready-to-use device. The situation is made worse by how communication around the commissioner topic was handled. The commissioner was dropped, the community was left without clarity, and questions on this subject were avoided or ignored for weeks. This is a textbook example of how trust and reputation are damaged. The message it sends is that community feedback is welcome when it helps improve code and fix bugs, but the same community is not trusted enough to fully use the product without workarounds, such as spoofing USB IDs just to access existing tooling like the YubiKey app. I do understand the desire, and the need, to monetize the project. That is not the issue. The problem is how this transition was handled and who ultimately ends up paying the price for it. Kicking the community that helped build and harden the project is not a smart long-term strategy. ### A suggested alternative approach A more sustainable and community-friendly model could look like this: **Open Source Community Edition (free, faster widespread adoption, roughly comparable to the functionality of the YubiKey app):** * Basic app functionality * FIDO2 key management * TOTP management * PIN configuration (LED/button) * maybe PIV Certificate handling **Pro / Enterprise Edition (paid):** * License per app installation * Centralized key management * Remote key revocation * Ability to bind keys to authorized enterprise environments only * Only permit enterprise-issued keys, for example via certificate pinning * Automatic wipe and reset of revoked keys when connected to an enterprise-issued app * Enforced password and PIN policies, including expiring PINs * Security-focused audits and compliance features * Sale of ready-to-use, pre-flashed keys Realistically, no large organization wants to flash RP2350 or ESP microcontrollers themselves. This kind of split would allow hobbyists, students, and developers to continue using and trusting the platform, while giving enterprises a clear value proposition they are willing to pay for. Right now, the current direction alienates exactly the people who helped make the project viable in the first place. At the end of the day, this is just a cheaper and less secure alternative to existing, well-adopted solutions. What the project needs is innovation. New ideas that solve real problems companies actually have, not another copy of a copy.
metabo7000 commented 2026-01-11 16:51:43 +08:00 (Migrated from github.com)

https://www.waveshare.net/wiki/RP2350-Egy 3,7 euró Kínában , egy 3D nyomtatós tok pedig kevesebb, mint 1 euróba került Kínában , de az alkalmazás 30 euróba került =/

Ebay used y5 nfc 2 level security support also cost ~30 euro! And no problem!:)
Mass production is something you can't compete with! If someone invents a new device a few months later, they sell it in "China" and copy it, they don't care about your input!

> [https://www.waveshare.net/wiki/RP2350-Egy](https://www.waveshare.net/wiki/RP2350-One) 3,7 euró Kínában , egy 3D nyomtatós tok pedig kevesebb, mint 1 euróba került Kínában , de az alkalmazás 30 euróba került =/ Ebay used y5 nfc 2 level security support also cost ~30 euro! And no problem!:) Mass production is something you can't compete with! If someone invents a new device a few months later, they sell it in "China" and copy it, they don't care about your input!
zyp114514 commented 2026-01-12 10:52:07 +08:00 (Migrated from github.com)

https://www.waveshare.net/wiki/RP2350-Egy 3,7 euró Kínában , egy 3D nyomtatós tok pedig kevesebb, mint 1 euróba került Kínában , de az alkalmazás 30 euróba került =/

Ebay used y5 nfc 2 level security support also cost ~30 euro! And no problem!:) Mass production is something you can't compete with! If someone invents a new device a few months later, they sell it in "China" and copy it, they don't care about your input!

but the chip is offical rp2350 chip

> > [https://www.waveshare.net/wiki/RP2350-Egy](https://www.waveshare.net/wiki/RP2350-One) 3,7 euró Kínában , egy 3D nyomtatós tok pedig kevesebb, mint 1 euróba került Kínában , de az alkalmazás 30 euróba került =/ > > Ebay used y5 nfc 2 level security support also cost ~30 euro! And no problem!:) Mass production is something you can't compete with! If someone invents a new device a few months later, they sell it in "China" and copy it, they don't care about your input! but the chip is offical rp2350 chip
metabo7000 commented 2026-01-14 16:31:45 +08:00 (Migrated from github.com)

https://www.waveshare.net/wiki/RP2350-Egy 3,7 euró Kínában , egy 3D nyomtatós tok pedig kevesebb, mint 1 euróba került Kínában , de az alkalmazás 30 euróba került =/

Az eBayen használt y5 nfc 2 szintű biztonsági támogatás is ~30 euróba került! És semmi gond!:) A tömegtermeléssel nem lehet versenyezni! Ha valaki néhány hónappal később feltalál egy új eszközt, azt "Kínában" eladja és lemásolja, nem érdekli őket a te véleményed!

de a chip hivatalosan RP2350 chip.

I understand, but a used yubico y5! You don't have to do anything for 30 euros! You don't have to compile complicated projects, which is complicated even for beginners and advanced levels! There is no competition for this, but there are no buyers either!

> > > [https://www.waveshare.net/wiki/RP2350-Egy](https://www.waveshare.net/wiki/RP2350-One) 3,7 euró Kínában , egy 3D nyomtatós tok pedig kevesebb, mint 1 euróba került Kínában , de az alkalmazás 30 euróba került =/ > > > > > > Az eBayen használt y5 nfc 2 szintű biztonsági támogatás is ~30 euróba került! És semmi gond!:) A tömegtermeléssel nem lehet versenyezni! Ha valaki néhány hónappal később feltalál egy új eszközt, azt "Kínában" eladja és lemásolja, nem érdekli őket a te véleményed! > > de a chip hivatalosan RP2350 chip. I understand, but a used yubico y5! You don't have to do anything for 30 euros! You don't have to compile complicated projects, which is complicated even for beginners and advanced levels! There is no competition for this, but there are no buyers either!
My1 commented 2026-01-15 01:36:22 +08:00 (Migrated from github.com)

honestly for a per individual board license especially if these can be expected to fail catastrophically and get bricked which would nuke the license the price should be really in the sub-10 euro area, maybe even around 5€

especially as how often would most users use this on each board past flashing it the first few times.

things like 30€ or whatever should cover multiple devices at the very least.

honestly for a per individual board license especially if these can be expected to fail catastrophically and get bricked which would nuke the license the price should be really in the sub-10 euro area, maybe even around 5€ especially as how often would most users use this on each board past flashing it the first few times. things like 30€ or whatever should cover multiple devices at the very least.
OAltr commented 2026-01-20 08:02:02 +08:00 (Migrated from github.com)

I understand the concern, but this is not about enforcing a license through artificial constraints.

It is optional, not forced, and alternatives remain available for those who prefer them.

Creating additional friction where there was little before leaves a bitter taste to these words.

E.g. the python packages pypicohsm & pypicokey used by the pico-hsm-tool were removed from Github and pypi further breaking existing alternatives in the project and obscuring how an alternative command could be constructed.

Not wanting to maintain these solutions for free, reducing the stress of backwards and forwards compatibility and hosting a free set of tools that compete with ones own paid solution is completely understandable. But wiping out all traces of those alternatives, instead of marking repos as deprecated and archiving them and not giving other people the option to step up and maintain or host these tools themselves, honestly feels like the wrong choice for a security product that basically relies on trust of its users and the community.

(Never the less: Thank you for all the effort put into this project so far and giving me (and hopefully a lot more people out there) a chance to learn about security devices, their inner workings and having the option to use inexpensive Hardware to test a bunch of things)

> I understand the concern, but this is not about enforcing a license through artificial constraints. > It is optional, not forced, and alternatives remain available for those who prefer them. Creating additional friction where there was little before leaves a bitter taste to these words. E.g. the python packages pypicohsm & pypicokey used by the pico-hsm-tool were removed from Github and pypi further breaking existing alternatives in the project and obscuring how an alternative command could be constructed. Not wanting to maintain these solutions for free, reducing the stress of backwards and forwards compatibility and hosting a free set of tools that compete with ones own paid solution is completely understandable. But wiping out all traces of those alternatives, instead of marking repos as deprecated and archiving them and not giving other people the option to step up and maintain or host these tools themselves, honestly feels like the wrong choice for a security product that basically relies on trust of its users and the community. (Never the less: Thank you for all the effort put into this project so far and giving me (and hopefully a lot more people out there) a chance to learn about security devices, their inner workings and having the option to use inexpensive Hardware to test a bunch of things)
Camis commented 2026-01-27 16:24:29 +08:00 (Migrated from github.com)

Deleted pypicokey-mirror is on Github now :)

Deleted pypicokey-mirror is on Github now :)
shpinog commented 2026-02-09 04:44:09 +08:00 (Migrated from github.com)

I picked up four keys: two YubiKey 5Cs and two YubiKey 5 Nanos. On a local marketplace similar to eBay, there are plenty of new keys available. These were brand new, original, and still in their blister packs. I paid around $60–$70 for all four. You can easily find individual new keys for $15–$30. From now on, I’m switching to these. I’m grateful to the project for pushing me to stop being a cheapskate and finally buy a proper, ready-made product.

The author simply didn't want to develop or build out paid/commercial features. But they still wanted the money. 'Let’s turn free features into paid ones, Karl!' What’s most disappointing is that if this happened with a game or some other random project, it would be one thing—but this project inspired trust and felt like something substantial. Usually, you don’t expect this kind of move from something so complex. I can’t imagine if, say, systemd went paid tomorrow and I had to buy a license just to run my own scripts.

I picked up four keys: two YubiKey 5Cs and two YubiKey 5 Nanos. On a local marketplace similar to eBay, there are plenty of new keys available. These were brand new, original, and still in their blister packs. I paid around $60–$70 for all four. You can easily find individual new keys for $15–$30. From now on, I’m switching to these. I’m grateful to the project for pushing me to stop being a cheapskate and finally buy a proper, ready-made product. The author simply didn't want to develop or build out paid/commercial features. But they still wanted the money. 'Let’s turn free features into paid ones, Karl!' What’s most disappointing is that if this happened with a game or some other random project, it would be one thing—but this project inspired trust and felt like something substantial. Usually, you don’t expect this kind of move from something so complex. I can’t imagine if, say, systemd went paid tomorrow and I had to buy a license just to run my own scripts.
maximka1812 commented 2026-02-20 03:49:23 +08:00 (Migrated from github.com)

Author of the project just made accidental error that can kill whole thing.
May be it happened due to private talks to avoid litigation. To silently kill popularity of the product.
As it makes no sense at all from business side of things.

Yubikey 5 on discount places or good chinese keys are cheaper than license here.

On ali ready key using this project code is around $8-9 shipped. And Yubico certainly is not happy.
As chinese can add soon not 3d printed but injection molded case, make it $10-11.
And in few months it could affect Yubico consumer sales significantly (due to app compatibility also!).
Firmware still has bugs, but with large customer base they'll be fixed fast.

Author of the project just made accidental error that can kill whole thing. May be it happened due to private talks to avoid litigation. To silently kill popularity of the product. As it makes no sense at all from business side of things. Yubikey 5 on discount places or good chinese keys are cheaper than license here. On ali ready key using this project code is around $8-9 shipped. And Yubico certainly is not happy. As chinese can add soon not 3d printed but injection molded case, make it $10-11. And in few months it could affect Yubico consumer sales significantly (due to app compatibility also!). Firmware still has bugs, but with large customer base they'll be fixed fast.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: dearsky/pico-fido#245