Additional maintainers

[webmonkey]

Hi @T-vK,

Would you consider allowing additional maintainers to this project to help update and improve it?

Thanks!

[robertlipe]

I see this library mentioned a lot. It's unfortunate that it's fallen into disrepair as it was well liked. Now there is a large number of duplicate PRs are stacking up where other SWEs are investing in maintenance. This would normally be a good thing and a case of open source working as intended!

With all the new Espressif chips unsupported on Arduino 2, anyone trying to enter the ecosystem in the last year and a half will be on current Arduino (which means ESP-IDF5 instead of 4) is going to have to patch in the equivalent of #366, #362, #343 #322 #315 #303 #324 (which are all effectively duplicates) and #329 and #372 (which are dups + some slight almost trivial extra hygiene)

I was going to say that you don't actually need permission to just fork it, but unfortunately, because of #60, you actually do. This is why GitHub makes it hard to put a new project up WITHOUT a stated license. :-( It's hard to identify ownership and licensing retroactively. This means everything is still owned by the original authors and there is no stated right to share or modify distributed works. It seems there are two authors, @T-vK and @chegewara, of this project and an attempt to define license terms coasted to a halt about five years ago. If they choose GPLv3, that's a big problem for users of this code. It looks like everything came from Apache-2.0 (which is pretty permissive) or LGPL-3, which is mostly permissive enough. That L is important.

It seems the path forward is for those to identify what parts are owned by and even partially copyrighted by someone else and either marking those files individually with copyright dates and owner names and license or claim ownership of their own, choose a license (if you mostly don't care what people do with it, but you don't want to be responsible, I'd recommend Apache 2.0) and mark up the rest.

Then, anyone that wanted to make a public fork of the project (there are currently 514 forks; it's hard to tell how many are modified and redistributing with unclear rights to do so) and start the process of picking a new leader (or no leader and everyone just scratches their own itch) and once that project is established, redirecting traffic to them.

Successful example in ESP32/Arduino-land of high-profile projects that were "adopted out" for similar reasons include:
https://github.com/me-no-dev/ESPAsyncWebServer
https://github.com/me-no-dev/ESPAsyncTCP
(it still needs to happen to rankyoldgit/IRremoteESP8266 and a few others...)

I'm not familiar with the project and I'm absolutely not angling for a takeover. I'm just familiar with how these things work and care a lot about ESP32 and open source and am trying to help nudge things. My name here is also my gmail name if you want to contact me privately for help or questions.

T-vK, chegewara, can you please find the 15 minutes to identify the issues and push commits clearly identifying every copyrightable file (I can help with the mechanics if you don't want to bulk edit a zillion files - make a PR with the text you want and a list of files, assign it to me, and I'll send one back marked up if that's helpful). That can give you a clear exit and give everyone else a chance to move forward.

If there are volunteers that are knowledgeable and helpful with the project that would be good candidates to promote a clear replacement (like me-no-dev did) that would be helpful to the built up community, but even if it's a clear flag of changing the license and hanging out a "Gone out of business", that's helpful to everyone.

Thank you everyone that listens and double so for those that have made open source awesome.

[T-vK]

That's not a 15 minute task unfortunately. The code has changed a lot over the years and it would probably take a lawyer to get a definitieve answer. Honestly, the easiest way would be to rewrite or change the code to the point that the original code is replaced entirely.
The problem with all the PRs and issues is that the code base isn't clean to begin with and there is no easy way to test if a change breaks compatibility with some Apple devices again.
In my opinion this library needs a clean re-write that shares a common core with ESP32-BLE-Keyboard, ESP32-BLE-Mouse etc. And it needs some sort of automated integration testing to ensure compatibility with problematic devices.
I have started to work on a re-write a couple months ago, but I am still in the architectural design phase (which honestly is 90% of the work). Language specific keyboard layouts for all existing layouts for example is such a complex topic that it might not even be possible to implement some of them due to memory contraints and the way some asian languages work. Media keys are also notneasily solved because if i added supoort for all media keys during runtime it would easily exceed the memory contraints.
I'm likely not gonna be finished by the end of this year, but next year seems realistic. I just don't have a lot of time at the moment.

Additional maintainers are always welcome. You just need to prove that you know what you're doing. Unfortunately this particular library requires very specific expertise that most developers just don't have. Back when I used to just accept any PR, this library was constantly broken for Apple devices.

[robertlipe]

Unless you've had major contributions from copyright holders that are likely to retroactively assert copyright claims, (i.e. corporate) I'd take the stance that any contributions to the code had copyright waived or assigned to you and that licensing is yours to decide. Any hobbyist that contributed a hundred line fix or enhancement clearly intended it to be shared. As the project owner, you can make that decision. For code that's strongly derived from others, you'll have to follow that, of course, assuming the new code is a derivative work. Please seriously consider putting a license so that others can safely fork or use the code as it stands. If you make that decision, executing it is a minor task. That would at least allow others to fork it to solve their immediate needs. Even if you want to keep the code locked up, please at least merge that mechanical syntax fix that's been contributed a half dozen times that would allow the code to actually compile with current environments. Replacing String with std:: string isn't exactly copyrightable, as indicated by a nearly identical fix being submitted by multiple authors. That's a button click. Slightly more if you make a GitHub release. P.S. I've run a GPLed program for almost 25 years that runs on multiple OSes and interfaces with a couple hundred GPS receivers. I relate to the legal and technical problems you're describing. I get it. But having a top ranked search result that doesn't compile and can't be forked surely isn't the result that anyone that's worked on the project actually wants.

…

On Sun, Sep 21, 2025, 6:41 AM T-vK ***@***.***> wrote: *T-vK* left a comment (T-vK/ESP32-BLE-Keyboard#370) <#370 (comment)> That's not a 15 minute task unfortunately. The code has changed a lot over the years and it would probably take a lawyer to get a definitieve answer. Honestly, the easiest way would be to rewrite or change the code to the point that the original code is replaced entirely. The problem with all the PRs and issues is that the code base isn't clean to begin with and there is no easy way to test if a change breaks compatibility with some Apple devices again. In my opinion this library needs a clean re-write that shares a common core with ESP32-BLE-Keyboard, ESP32-BLE-Mouse etc. And it needs some sort of automated integration testing to ensure compatibility with problematic devices. I have started to work on a re-write a couple months ago, but I am still in the architectural design phase (which honestly is 90% of the work). Language specific keyboard layouts for all existing layouts for example is such a complex topic that it might not even be possible to implement some of them due to memory contraints and the way some asian languages work. Media keys are also notneasily solved because if i added supoort for all media keys during runtime it would easily exceed the memory contraints. I'm likely not gonna be finished by the end of this year, but next year seems realistic. I just don't have a lot of time at the moment. Additional maintainers are always welcome. You just need to prove that you know what you're doing. Unfortunately this particular library requires very specific expertise that most developers just don't have. Back when I used to just accept any PR, this library was constantly broken for Apple devices. — Reply to this email directly, view it on GitHub <#370 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACCSD37AVZU6H2PXFSHUKQD3T2FFBAVCNFSM6AAAAACB4UMBI6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTGMJVHEZTSOBWGY> . You are receiving this because you commented.Message ID: ***@***.***>