On July 12, 2025, in the OpenDV forum, Jonathan Naylor G4KLX announced that support for M17 had been removed from Multi Mode Digital Voice Modem (MMDVM) package – apparently some days earlier.

Thus, when this change went into effect, it was sudden and unannounced. Because many MMDVM units automatically update with Naylor’s updates to MMDVM (to automatically patch security issues, bugs, etc.), Naylor’s removal of M17 broke the functionality of MMDVM hotspots and modems (such as used in repeaters) to operate M17.

While the M17 Foundation respects Naylor’s decision to make changes to MMDVM, which is a completely separate project from M17, in his post, Naylor made a number of personal, highly opinionated statements directed at M17, its principals, and M17’s technology choices.

What follows is M17 Foundation’s (M17F) formal response to Naylor’s points, by M17 Foundation Board Member Wojciech Kaczmarski SP5WWP.

---

Naylor: Firstly the administrative side of M17 is very worrying, and even more so in recent months. A couple of years ago, M17 received $478,900 in grants from the ARDC to develop M17. I very much feel that ARDC should take a closer look at how this money was spent.

M17F Response: We in fact received two grants from ARDC:

Grant: M17 Open Protocol

Grant: M17 Project Popularization, Research and Development

Both grant budgets were accepted. ARDC received reports at the end of each granting period. Additionally, in 2023-2024, Kaczmarski also submitted monthly reports to ARDC and DARC, as the second grant was used by DARC CQ DL GmbH for the salary of Kaczmarski. There is no reason for ARDC to analyze our spending again, as they have already done so.

Naylor: The new M17 Foundation isn’t much better. A number of the M17 stalwarts were excluded from it when it was formed, rather more sadly, the M17 Foundation make no mention of a number of people or organisations that helped them to get where they are now. This is particularly troubling as it is a rewriting of history and not apportioning praise where it is due. A lot of people put a lot of time and effort into M17 and to not get their due is dishonest of the M17 team. An example is the fact that only one commercial entity has put their money where their mouth is, and that is Jerry of Connect Systems Inc. however his contribution to the project has been belittled online by the M17 team (as has mine), despite it being the only way to get a commercial M17 radio, he should be praised not dismissed out of hand.

M17F Response: We never removed any credit or commit history from GitHub, effectively “making no mention of a number of people (…) that helped them”. Feel free to browse through our X or Mastodon entries to find out if credit is given to the authors publicly.

Kaczmarski publicly stated that, in his opinion, the M17 hardware offered by CSI is slightly overpriced and might not be purchased by many. CSI offers solid, sturdy radios with bulletproof RF circuitry. Kaczmarski kept saying that too, every time someone asked him but this was somehow overlooked by Naylor. M17 Foundation advertises CSI’s M17 products pro bono at every ham fair or club meeting we attend.

Naylor: I have heard rumours that the M17 Foundation is looking at charging commercial entities a royalty to include M17 in their equipment and to use their logo. This is not in the spirit of open source, and has not been the route followed by the MMDVM.

M17F Response: In our opinion, using gossip is a very low rhetoric figure. Let us focus on facts instead. M17 Foundation never required, and will not require any commercial entity to pay royalties of any form for M17 protocol use. The use of M17 logo will be free for non-commercial use, we are still figuring out the details behind licensing. The Foundation does not currently hold any IP rights over it, the logo is being registered under Kaczmarski’s name, as a physical person (simply verifiable through WIPO search). All IP rights will be transferred to M17 Foundation once the process is complete (CN and US are two pending jurisdictions). The registration is a preventive measure, mitigating unauthorized use of the logo. M17 Foundation doesn’t believe that registering the M17 logo breaks any open-source philosophy values. See this Linux Foundation entry (in this case, a piece of text is protected, not image).

Naylor: Secondly technical. When started, M17 was proudly created by people who said that they brought fresh thinking to digital voice, I would say that it was characterised more by a combination of arrogance and stupidity. The fact that none of them had ever operated a digital voice radio, let alone studied a DV mode, was seen as a positive.

M17F Response: Ad personam. Kaczmarski studied TETRA, DMR, and NXDN (and he repeats that in basically every interview given) along with the ACELP voice codec, back in 2018. Right off the bat false statement.

Naylor: One of the key members designed it like a packet radio system where each block (or packet) of information needed to be received perfectly.

M17F Response: This is incorrect. M17 uses Forward Error Coding (FEC) schemes similar to the ones seen in other modes.

Naylor: As originally designed the synchronization patterns were literally one bit different from each other, which is useless in an environment where signals are routinely corrupted to a greater or lesser extent. Over the first six months of my involvement I managed to get them to change the synchronization vectors to be something more reasonable (…)

M17F Response: Synchronization patterns are based on Barker codes and guarantee zero cross-correlation. Invalid argument. See Section 1.4.2 of the specification document. The idea to use those was proposed by Rob Riggs, WX9O.

Naylor: (…) and got them to add the CAN (Channel Access Number) to allow for some sort of channel sharing between M17 systems.

M17F Response: Kaczmarski doesn’t remember who proposed the CAN, therefore we won’t argue this point.

Naylor: I also added things that we take for granted in other DV modes like embedded GPS data and short text messages. These both run in parallel with the audio like in D-Star and other DV modes.

M17F Response: This is a true statement. Naylor offered a way to encode text messages and GNSS data using the META field (slow-speed data transfer alongside the main data stream).

Naylor: A networking protocol designed before the RF protocol had stabilised and included ideas that didn’t make sense later in development.

M17F Response: The networking protocol is still under development, as most of the ecosystem we offer: https://github.com/M17-Project/M17_inet

Naylor: A very weak end of message indicator, a single bit, which I argued against and got them to change but then they retained in the official specification. This is an exceptionally weak part of the protocol and the fact that they couldn’t see that showed that many of the M17 team needed to attend Digital Voice 101. 

M17F Response: Naylor is incorrect. M17 signals the end of transmission using two independent mechanisms: an End of Transmission bit (mentioned) and through transmission of at least one End of Transmission frame. See Section 1.4 of the specification document.

Naylor: Inclusion of optional strong encryption, this is against regulations in most countries and shouldn’t even be thought about. Oddly enough encrypted M17 wouldn’t pass through an MMDVM based repeater.

M17F: Any form encryption is optional, as in practically any other digital voice mode used by radio amateurs worldwide, including the most popular of them – DMR. We condemn the use of encryption where it’s illegal. Enabling strong encryption in M17 requires extensive knowledge and can’t be simply done using any of M17 gear available, as it’s not implemented in OpenRTX.

Naylor may be conflating Kaczmarski’s experiments to add digital authentication to M17 transmissions, with encryption. Authentication is entirely within Amateur Radio regulations in all countries.

Naylor: An orphaned vocoder, it doesn’t sound very good either. AMBE in all its forms is considerably better. Indeed later versions of Codec2 which take considerably less bandwidth than the 3200 mode chosen for M17 sound far better.

M17F Response: We regard “it doesn’t sound very good either” as a Naylor’s personal opinion and thus won’t discuss.

Naylor: The wrong type of FEC, applied badly.

M17F Response: This technical point needs some more detail. Assuming Naylor means the convolutional encoder used in M17 – there are two approaches if it comes to its use. Zero-filled and tail-biting. M17 uses the former, as it makes sure that the end of the trellis always ends at a known state. Tail-biting offers better coding rates for short blocks of data, but our encoded payloads are ~270 bits. With the constraint length of K=5, the gain offered by tail-biting is negligible. Next – our convolutional coding scheme is based on that seen in NXDN, using the same (optimal) polynomials. See Appendix C of the specification document.

Naylor: At various times I have brought all of these items up, but no-one seemed to be interested.

M17F Response: Kaczmarski remembers some of them being raised by Naylor, and each time Kaczmarski replied in a constructive manner, either asking for clarification, proposed solution, or (for invalid arguments, such as “unnecessary” encryption support) rejected as such.

Naylor: It shouldn’t really be a problem since the M17 team have said that my software isn’t important.

M17F Response: Please provide substantive references to this statement that “my software isn’t important”. Where? When? Who?

In fact, MMDVM’s support of M17 (was) a critical, important element in the evolution of M17 as an ecosystem. See Steve Stroh N8GNJ’s article M17 Is a Complete System.

Naylor: They [OpenRTX] have worked hard to get M17 running on undocumented hardware and have done wonders

M17F Response: True! Good work done, definitely. All the credit goes to OpenRTX, and it was never due.

Naylor: [OpenRTX has] been the real workers behind the M17 project and have probably not received the praise, nor the renumeration, that they so richly deserve. To my mind, and to others, they are the real developers behind M17 and they deserve better.

M17F Response: Kaczmarski considers that M17 ecosystem is a success, and it’s a result of all of us working on it, not only him or OpenRTX. It’s called teamwork. We donated quite a lot of hardware to our friends in Italy, and always gave them credit for all the work done. It’s easily verifiable by reaching out to them directly and asking.

Naylor: There is a need for an open source DV mode, however M17 is not that mode.

M17F: That is Naylor’s opinion, thus we have no comment.

---

Conclusion

As the above information reflects, M17 Foundation considers most of Naylor’s administrative and technical criticisms invalid. Naylor is, of course, entitled to his opinions, technical and otherwise, but most of his comments regarding M17 are opinions, not (many) statements of fact.

Followups to M17 Foundation may be directed to: contact@m17foundation.org