Manufacturers distributing without source code -- wireless tri-mode boards, missing functionality such as HE matrix etc.

[tzarc]

TL:DR; Vendors who submit PRs whilst not providing full sources for all of their shipping boards will be put on hold until source code for all violating keyboards are provided. Intentional deception may result in boards being removed from QMK and all future PRs for that manufacturer being denied outright.

This issue is limited to reports of non-compliant vendors -- asking for support or complaining about boards being unavailable (apart from reporting them) will be hidden as off-topic. For maintainers, once a vendor has been added to the list below, please mark the comment as "outdated".

If QMK identifies any licensing violation, all current and future PRs from that manufacturer will be put on hold until sources are provided. QMK's license requires full disclosure of source code for any firmware which is based on QMK, includes any part of QMK, or derives from QMK in any way. This source code disclosure is not negotiable and is automatically agreed to by any designer when they choose to use QMK.

Given the recent ramping-up of Chinese vendors disregarding QMK's license, QMK now actively chooses to prevent merges when violations are found.

Vendors may rectify the situation by providing full source code for their boards, even if it's in their own fork of QMK Firmware.

Current list of vendors who need to provide source code before any new PRs will be considered:

• BBB Keyboard
• Chillkey
• CIDOO
• Darmoshark
• Epomaker
• KiiBOOM
• Luminkey
• Meletrix
• mmd
• owlab
• qwertykeys
• Royal Kludge
• Shortcut Studio
• Tacworks
• TKD / Vertex
• WOBKEY
• Weikav
• Womier
• Wuque Studio
• Zuoya

---

Initial post reporting Royal Kludge boards

Royal Kludge has issued a bunch of PRs recently with significant ambiguity as to whether or not submitted keyboards are tri-mode wireless or not.
So far there has been insufficient evidence supplied stating "no", they're wired-only boards -- comments on PRs when querying this fact have been ambiguous at best.

Additionally, with the fact that Royal Kludge is currently distributing VIA definitions for tri-mode keyboards based on QMK here -- including the rk839, also known as RK-R65, which shares the Product ID 0xE453 listed in PR #23559, we can only assume that Royal Kludge is submitting wired board definitions to QMK in order to satisfy VIA's requirement that keyboards must exist in QMK's master branch, with no intention to supply source code for wireless boards as per QMK's licensing requirements.

As of the posting of this issue, QMK is putting a hold on all PRs from vendor ID 0x342D until all sources are made available for the corresponding QMK-based boards listed on the above page (inclusive of wireless bindings where relevant):

• RK61 QMK Wired RGB ANSI (PID 0x6461)
• R65 QMK/VIA Tri-Mode RGB ANSI (PID 0xE453)
• R65 QMK/VIA Tri-Mode RGB ISO (PID 0xE47F)
• R65 QMK/VIA Wired RGB ANSI (PID 0xE453)
• R65 QMK/VIA Wired RGB ISO (PID 0xE480)
• R75 QMK/VIA Wired RGB ANSI (PID 0xE484)
• R75 QMK/VIA Wired RGB ISO (PID 0xE483)
• R75Pro QMK/VIA Tri-Mode RGB ANSI (PID 0xE487)
• R75Pro QMK/VIA Tri-Mode RGB ISO (PID 0xE485)

Additionally, the VIA definitions on the same page also list the following combinations which also need full sources provided, including wireless:

• R75Pro QMK (Tri-mode) - vendor ID 0xBB3F, product ID 0x0001
• R75 QMK (Tri-mode) - vendor ID 0x342D, product ID 0xE482

[tzarc]

For clarity, the vendor ID is Westberry Technology, which is also in use by Epomaker, KiiBOOM and others.
There is sufficient evidence that these manufacturers are all subcontracting out to the same third-party firmware provider - @sdk66 seems to be listed as maintainer for all.

Manufacturers other than Royal Kludge are also going to be put on hold for this reason -- the third-party firmware provider must supply source code for all QMK-based boards.

[Cipulot]

I will review all the affected board makers and boards in VIA to be sure that nothing slipped through and got merged accidentally w/o due diligence. Any violation of the licenses and attempts to bypass the license requirements will result in removal from the VIA repo.
A couple of PRs were already rejected because they were trying to merge JSONs pointed to boards mentioned in the opening comment.

[drashna]

Does "VIA-compatible" mean the firmware must be QMK thus abiding GPL-3?

This one is complicated. In theory, they could have properly reverse engineered it. But if they took via.c, and retooled it to work with whatever firmware, then the code is still covered by GPL (2+) and source code still needs to be produced or to be in voliation.

https://www.gnu.org/licenses/gpl-faq.en.html#GPLRequireSourcePostedPublic

But if you release the modified version to the public in some way, the GPL requires you to make the modified source code available to the program's users, under the GPL.

In this case, releasing the binaries/firmware is releasing to the public. And:

https://www.gnu.org/licenses/gpl-faq.en.html#TranslateCode

Under copyright law, translation of a work is considered a kind of modification. Therefore, what the GPL says about modified versions applies also to translated versions. The translation is covered by the copyright on the original program.

[tzarc]

But if they took via.c, and retooled it to work with whatever firmware, then the code is still covered by GPL (2+) and source code still needs to be produced or to be in voliation.

For clarity's sake, the modified code isn't the only code that needs to be produced -- the entire firmware is considered a derived work, and thus the source for the entire firmware needs to be produced, even if it's overall not based on QMK. Any use of a modified via.c results in this outcome.

[yulei]

if the wireless firmware runs on a seperate mcu(do not use any QMK related source codes) and communicated the other mcu (runs QMK based firmware) through peripherals such as spi, uart (like the adafruit uart friends used in many keyboard). I'd thought in such cases, only released the source codes in the MCU which runs QMK should be enough. Is this right?

[drashna]

if the wireless firmware runs on a seperate mcu(do not use any QMK related source codes) and communicated the other mcu (runs QMK based firmware) through peripherals such as spi, uart (like the adafruit uart friends used in many keyboard). I'd thought in such cases, only released the source codes in the MCU which runs QMK should be enough. Is this right?

Correct. In the case of via stuff, taking the GPL licensed code, and modifying it to work with a different firmware/code would require disclosure of that source too.

[JackyJia73]

#23982
Wireless code added. Although this board is not wireless.

[vinorodrigues]

Add Chosfox CF81 that slipped in last year. Clearly advertised as a tri-mode https: // chosfox.com /products/cf81-pro-prebuilt-keyboard

alexotos just did a review on their Fox65 and that will be the same if that comes up.

[Cipulot]

Add Chosfox CF81 that slipped in last year. Clearly advertised as a tri-mode https: // chosfox.com /products/cf81-pro-prebuilt-keyboard

alexotos just did a review on their Fox65 and that will be the same if that comes up.

In connection to this, 0xFFFE as a VID seems to be used by multiple keebs that have been merged, not provide full code and do have wireless functionality.

Here are boards that are merged, w/o required code disclosure:

• CHOSFOX CF81 (mentioned by @vinorodrigues )

Then there are muddy cases that I'm not 100% sure about, since there are versions with added letters in the name that are wireless, but may not share the same base FW, like:

• Akko 5108 variants
• Inland V83P (here some online manuals show wireless support with the same name, but there was one occurrence of a case with simple win/mac switch)

Comment for tracking purposes for the time being.

[zvecr]

Add #21437 that slipped in last year. Clearly advertised as a tri-mode

https://switchandclick.com/chosfox-cf81/ suggests a non pro version exists, which is not wireless.

[vinorodrigues]

suggests a non pro version exists

You're correct.

I suppose the question is: for transgressors now/future will their priors be removed? or rather, should they be to force compliance?