VIA integration with ZMK

[lental]

Hey - Couldn't find a good place to ask this question. Feel free to redirect me to the best place to ask things like this.

It seems like most of the heavy lifting of a basic ZMK integration with VIA would be on ZMK - implementing the relevant APIs for discovery, EEPROM dynamic keymap storage, and then usage of the dynamic keymap. Is there anything principally improper with attempting to perform this integration (Licensing issues? Implicit or explicit agreements with QMK-TMK maintainers? Inability to guarantee parity over QMK integration?) or is this just a matter of execution and contributions?

Thanks!

[olivia]

IMO, there isn't any reason as to why it would be disallowed. The protocol that VIA communicates with isn't patented or licensed in itself. Given that ZMK is MIT licensed and QMK is GPLv2, there might be some provisions around sublicensing if you ended up lifting code directly from the QMK repo. There would be the trouble with keeping the protocol in lock-step with both QMK and ZMK, but such is the way of dependencies 🤷

In short, I would be supportive of such an initiative if there were folks on ZMK willing to build the protocol into the firmware on that side.

[drashna]

The biggest issue is licensing and policy: https://zmk.dev/docs/development/clean-room

• Implementations of features for ZMK MUST NOT reuse any existing code from any projects not licensed with the MIT license.
• Contributors MUST NOT study or refer to any GPL licensed source code while working on ZMK.
• Contributors MAY read the documentation from other GPL licensed projects, to gain a broad understanding of the behavior of certain features in order to implement equivalent features for ZMK.
• Contributors MAY refer to the QMK Configurator to inspect existing layouts/keymaps for keyboards, and re-implement them for ZMK.

So while there is no technical issue with it ... unless somebody on zmk's dev team works on it, it most likely will not be implemented or accepted.