The big three manufactures could never be persuaded to do this on their own.

开云体育

I can't remember if it was here that someone was recently mentioning "little green check marks", so this has already been discussed. I don't remember by whom, but I would like to fill this out a bit, and, at the same time, discuss why an open source environment is key to the success of innovative digital ham methods. The Linux / Windows / MacOS paradigm is a great starting point...

?

Isn't it interesting that nearly all high security web servers run on Linux? How can that be? If the code for the Linux kernel is available to anyone, wouldn't it be easy to find a flaw and break into such a server?

?

Well no, it's not that easy. Why?

?

Because the the open source community has a thousand eye constantly looking over every line of that code. When chinks in the armor are found, or when a break-in (hack) has occurred, a team will create a security update that will be made available to all the flavors of Linux. There are strict rules for how pull requests are reviewed and accepted to the repository that holds that code. Everyone who want's to see the process can closely follow it, and, like I said, there's a lot of eyes on both the process and the code.

?

Fun fact There is actually a very that occurs every year in Las Vegas where security experts, governments and hackers get together and talk about such things. That becomes part of the open source environment and it's an important reason why companies that require security use Linux based servers and not Windows or MacOS. The best open source programmers (and hackers) that attend that meeting are aggressively recruited by companies that also attend that meeting. The open source development system works and it works well. Drop . the . mic .

?

Now, let's switch gears...

?

If you've been a ham long enough, you've probably encountered an outrageous, profane or obnoxious operator, maybe a rouge operator, using a made up callsign, or, even worse one who didn't own the callsign he was using. Or sadly, maybe it's a ham who has snapped for some awful, personal reason and is now behaving poorly. Or maybe your an EMCOMM net controller and need to be sure about your information sources.

?

Wouldn't it be nice if you could quickly identify those situations? Well, Wojciech Kaczmarski SP5WWP has already opened the door to providing a solution. I first saw his a few months ago. This is big, really big! He shows that in just a little over 8 ms, you can transmit a digital signature on an M17 transmission with a private key. Anyone listening to that transmission with access to the public the key can verify the signature. I know, it confusing. of how digital signature works.

?

So what do we need to work out the details? First, the the originator needs to attach a unique digital signature, based on the transmission and the private key. Well mvoice is open source. So is DroidStar. The CS7000-M17 firmware is open source. MMDVM is open source!

?

Okay, that's doable! Note that I'm not saying it's easy, but we've had great examples where open source folk have worked miracles (see the Linux kernel discussion above). For an amateur radio miracle example, Jonathan Naylor G4KLX pretty much alone worked out the open source solution to dealing not only with the complex DMR data stream, but also the incredibly convoluted Yaesu data stream. Another example you ask? How about the OPEN RTX team developing M17 firmware for the MD-380. The MD-380 manufacturer doesn't supply supply manuals for how to do this.

?

The key pairs are easy to generate, the tools are all ready there. Anyone can generate a unique private/public key pair.

?

So the final piece that is needed is for the receiver to use the signer's public key to verify the signature matches the transmission. The signature verifies that the transmission data is signed by the holder of the private key and using the public key is the only way to verify that transmission. But wait, where does he get the public key? Ideally for US callsigns, it would come from a already verified source, like a field in the FCC's callsign lookup or from ARRL, or maybe from the DMR ID registration org. It's got to be somebody that knows the public key belongs to you.

?

Yikes, you say! How are you ever going to make that happen? Yeah, I admit, that might take a while. But in the meantime, we are in an open source environment with M17. A few cleaver programmers could set up a demonstration public key server. This could be used by open source reflectors and repeaters to display a little green check mark on the dashboard of their last heard page verifying that that transmission has a unique and correct signature.

?

Wow! That's really something very awesome. and is something that could only happen in an open source world. The big three manufactures could never be persuaded to do this on their own.

?

The fact that I can even think about this is the coolest part of an open source development.

-- 
73 de Tony VK3JED/VK3IRL

On 17/8/24 5:13 am, Peter Laws via groups.io wrote:

Yeah, and more and more I get that it's not worth trying to sell M17
to folks who think it's OK to run XP on a public-facing device. :)

Yeah, I don't even have any XP boxes in service, oldest Windows in
regular use here is 10.

*I* get it (even as an #IcomFanboy/#DSTAR fan) I'm just looking for
ways to sell it to those that are not Of A Clue. And that may not be
worth it.

I take the approach of get the message out there, show people what it's
all about and invite them to jump on board.? Also keep an eye out for
the traditional objections (so many over the years have complained about
proprietary components in other DV modes, back to the early days of
D-STAR.? These people are the perfect audience, because I can say "M17
is different, it's 100% open, vocoder and all". :)

Right now, the CS7000 is a key point of interest, because now we have an
off the shelf radio that can do M17 without needing hardware
modifications.? I personally have seen the difficulty of the MD380(UV)
approach.? I'm not equipped for fine SMD work and have fine motor and
other subtle issues that make the mods very risky (for the radio) for me
to do.? CS7000 solves that problem, albeit at a (monetary) price.

--
73 de Tony VK3JED/VK3IRL

On 17/8/24 5:25 am, Peter Laws via groups.io wrote:

I'm helping with the local D-STAR Gateway and expect to install the
"g2_link" link once the dev folks get some ALMA 9 things straightened
out. That will give our users use of the full range of "reflectors"
including, presumably, yours?

I did some ground work to get g2_link installed on a repeater, but it's
still on the todo list their end.?? I have no idea what "ALMA 9" or "IOP
prefix" is, haven't seen either of those terms used in this context before.

I wonder if I could encourage devs of non-DPlus schemes to use the IOP
prefix on "reflectors" that bridge between modes? Just to call out
the fact that they are a bridge from whatever to whatever.

Read above - "IOP prefix?"

At least until every radio supports M17 natively.

I do have an older Pi-Star-based hotspot and the version of Pi-Star it
supports (vendor is gone so no new firmware support) *will* do M17 but
it doesn't transcode so I can't listen on my D-STAR radios. AFAIK.

At this stage, there's no end user solution for transcoding between
D-STAR and M17.? Other than needing an AMBE chip for handling the D-STAR
side audio, this should be a relatively straightforward gateway, because
the addressing schemes are so similar (callsign based).? In fact, I
suspect you could design such a gateway so that you use a D-STAR radio
just like you would a native M17 radio, except needing the RPT1 and RPT2
settings configured.? Just needs someone interested in developing such a
gateway.? Starting with a MMDVM based system (M17Gateway would likely
not need modification) and adding the gateway/transcoding components
could be one approach.? Plug in a ThumbDV or similar to get the D-STAR
audio working.

So in theory it could be done, just needs developers to make it happen.

--
73 de Tony VK3JED/VK3IRL

On Wed, Aug 14, 2024 at 6:28?PM Tony Langdon via groups.io
<vk3jed@...> wrote:

On 15/8/24 5:30 am, Peter Laws via groups.io wrote:

For your list, #1 and #2 are *not* wrong. I've not seen a DV <->
analog "reflector" yet, but there isn't a good reason there couldn't
be one. There are bridges between the other DV methods. My problem

There's heaps, I run several myself!

I'm helping with the local D-STAR Gateway and expect to install the
"g2_link" link once the dev folks get some ALMA 9 things straightened
out. That will give our users use of the full range of "reflectors"
including, presumably, yours?

I wonder if I could encourage devs of non-DPlus schemes to use the IOP
prefix on "reflectors" that bridge between modes? Just to call out
the fact that they are a bridge from whatever to whatever.

At least until every radio supports M17 natively.

I do have an older Pi-Star-based hotspot and the version of Pi-Star it
supports (vendor is gone so no new firmware support) *will* do M17 but
it doesn't transcode so I can't listen on my D-STAR radios. AFAIK.



--
Peter Laws | VE[23]UWY / N5UWY | plaws0 gmail com | Travel by Train!

On Wed, Aug 14, 2024 at 6:29?PM Tony Langdon via groups.io
<vk3jed@...> wrote:

They'll either fall behind or run after the bandwagon and jump on board
late, if the penny drops. :)

Yeah, and more and more I get that it's not worth trying to sell M17
to folks who think it's OK to run XP on a public-facing device. :)

*I* get it (even as an #IcomFanboy/#DSTAR fan) I'm just looking for
ways to sell it to those that are not Of A Clue. And that may not be
worth it.


--
Peter Laws | VE[23]UWY / N5UWY | plaws0 gmail com | Travel by Train!

On 15/8/24 5:38 am, Peter Laws via groups.io wrote:

No, but it's an important statement. Bringing new people in is
actually quite critical to the hobby, and people who *do* understand
"the codec and protocol are open and most code is under GPL/LGPL" is
the kind of people we need to keep the hobby moving forward. This is
good - I'm just trying to craft a pitch for those that *don't*
understand ... still leaning towards letting go of the rope. :-)

They'll either fall behind or run after the bandwagon and jump on board
late, if the penny drops. :)

--
73 de Tony VK3JED/VK3IRL

On 15/8/24 5:30 am, Peter Laws via groups.io wrote:

For your list, #1 and #2 are *not* wrong. I've not seen a DV <->
analog "reflector" yet, but there isn't a good reason there couldn't
be one. There are bridges between the other DV methods. My problem

There's heaps, I run several myself!

with reflectors, other than the silly name, is that they require
"on-shore" facilities. You can't, and likely won't ever be able to,
talk simplex between any of the 3 predominant DV methods plus analog.
Certainly both Yaesu and Icom (newer D-STAR modules) can switch
between analog and DV but I don't see that as helpful in any way. So
you need a box somewhere to transcode.

Yeah a multimode radio is needed for simplex? Bring on the CS7000 Plus. :)

*I* get the whole IP and licensing thing but most people including
most hams do not. I was trying to come up with a way to pitch M17 to
them without falling back on "it's open source!". That's true, of
course, but means nothing to a LOT of people not on this list. I just
think we need a pitch for them that avoids that issue.

It takes imagination to understand the full implications of open source,
and the people who understand have both the most to gain and the most to
contribute to the future here.

--
73 de Tony VK3JED/VK3IRL

On 15/8/24 4:38 am, Ben Kuhn via groups.io wrote:

To users of other digital modes, M17 offers voice *and* data (yeah, so can D-Star), not just silly pictures from an overpriced webcam mic accessory and GPS positioning. Isn't vendor locked (again, it can be added to anything with a proper data port). It supports hotspots and all the other features digital users are used to. As far as ease of use is concerned, which is the selling point for the worst of the current crop of digi modes, that's an implementation detail that's up to the team adding M17 to a given radio's firmware. I think it's very important to get this right.

Current M17 implementations use an addressing scheme similar to D-STAR
(callsign based), but it's a lot more simplified and implicit
disconnection on destination change is built in.? And users can either
send to the desired destination or ALL to participate in a
conversation.? I know some D-STAR implementations appear to have
implicit disconnection (eg ircDDBGateway), but it's not as universal as
M17 can be.

Also, M17 is a mode where a duplex hotspot is a big advantage.? It's
super easy to switch from a busy reflector, just hit PTT with the
destination of your choice anytime!? I found this one out at a
demonstration in the field.? No waiting for a long winded over to
finish, the change happens as soon as the transmission is processed.

--
73 de Tony VK3JED/VK3IRL

On 15/8/24 3:54 am, Peter Laws via groups.io wrote:

For those of us that do keep up (mostly): Source code is considered a
published work and can be copyrighted. Who owns the copyright on
CODEC2 Has Dave Whose-VK-call-escapes me patented any of the methods
within it (ideas can be patented)? If so, what license are they
released under? Same question, really, for the copyright.

There will be a copyright statement in the various source repositories
stating who owns the copyright of each piece of code.? You'll also find
that the code is licensed under an open source licence, such as GPL V2
or V3, LGPL or another OSS licence.? I'm not aware of any patents
relating to Codec2, though of course that doesn't mean there aren't any.

On selling to the majority of amateurs that *don't* keep up what is
the elevator pitch? DV exists and people are either using it or
shunning it. **Without talking about intellectual property** what is
the big deal about M17?

It's a bit like Linux.? M17 is built by the amateur community for the
amateur community.? People can play with the protocol.? M17 also had
fully formed data capabilities built into the base specification - not
just GNSS or messaging or images, but ANY arbitrary data that can be
shoved down the pipe.? Just an hour or so, there was a discussion of?
M17 "paging transceiver", which grew out of a comment about M17 being
able to run on a Gameboy Advance (which it can).

Linux started out as a Unix clone on x86 hardware, today it runs on a
dizzying array of platforms from light bulbs to supercomputers.? That's
the implications of open source - others can come along and bend it to
fit their wishes.

Like Linux, M17 has the potential to be scaled and use to fit the wishes
of hackers and developers, whether it be made to run on custom built
pocket pagers, game consoles, SDRs, repeaters in the cloud, smartwatches
(with Bluetooth attached transceivers), whatever!? We hams are supposed
to be communications experimenters and M17 allows us the opportunity to
further that aim, as well as attract more coders and other IT types, who
could contribute a lot more to our activities.


--
73 de Tony VK3JED/VK3IRL

On Wed, Aug 14, 2024 at 2:51?PM Steve Stroh N8GNJ via groups.io
<steve.stroh@...> wrote:

Codec 2 is licensed as LGPL-2.1 -
The primary developer of Codec 2 was David Rowe VK5DGR.

M17 Protocol specification () is copyrighted 2024 by M17 Project.

And the primary driver is Wojciech Kaczmarski SP5WWP, who is here on
the list, happily.

Basically, that M17 is open is singlehandedly causing people who do live open source to pay attention to Amateur Radio because with M17 they can now do (VHF / UHF) Amateur Radio that’s compatible with their open source ethos.

That is bringing a lot of new people into Amateur Radio that previously had no interest.

Yeah, that’s too wordy for a proper elevator pitch, but “I didn’t have enough time to write a short note, so I wrote a long one”. (Sorry, old writer’s joke.)

No, but it's an important statement. Bringing new people in is
actually quite critical to the hobby, and people who *do* understand
"the codec and protocol are open and most code is under GPL/LGPL" is
the kind of people we need to keep the hobby moving forward. This is
good - I'm just trying to craft a pitch for those that *don't*
understand ... still leaning towards letting go of the rope. :-)


--
Peter Laws | VE[23]UWY / N5UWY | plaws0 gmail com | Travel by Train!

On Wed, Aug 14, 2024 at 2:38?PM Ben Kuhn via groups.io
<ku0hn@...> wrote:

I am not a lawyer, just followed lots of open-source stuff for the past 25 years. My understanding is that, at least in the US, copyright is automatically assigned to the author unless they specifically re-assign it. In the context of open source, that means that one project might have many copyright holders. The initial author decides on a license for the project, and all future contributions comply with and accept that license as part of their contribution.

Looking through the Codec2 repo, I do not see any specific copyright (re)assignment required anywhere. The project is released under the GNU LGPL v2.1.

I'm the same way but don't write code so probably miss some nuances
(like, surely, the differences between the version numbers of GPL and
LGPL to start let alone the other 300 "open" licenses).

Excluding IP, which is a big deal IMO, there are a few things.

The folks shunning digi modes that I talk to personally are in 2 camps:
1. Analog FM is universal, cheap, and easy.
2. Digital is too fragmented so see #1.
3. Digital is too complicated.

M17's elevator pitch to these is that with things like Module17 or Mobilinkd, M17 can be added to any radio with the proper interface. This makes it the most universal digital mode.

To users of other digital modes, M17 offers voice *and* data (yeah, so can D-Star), not just silly pictures from an overpriced webcam mic accessory and GPS positioning. Isn't vendor locked (again, it can

In other realms of the hobby, I'm inclined to just let some folks fall
behind. I think I (personally) may take that tack with DV. And
you're not giving me any ammo to do otherwise. :-)

For your list, #1 and #2 are *not* wrong. I've not seen a DV <->
analog "reflector" yet, but there isn't a good reason there couldn't
be one. There are bridges between the other DV methods. My problem
with reflectors, other than the silly name, is that they require
"on-shore" facilities. You can't, and likely won't ever be able to,
talk simplex between any of the 3 predominant DV methods plus analog.
Certainly both Yaesu and Icom (newer D-STAR modules) can switch
between analog and DV but I don't see that as helpful in any way. So
you need a box somewhere to transcode.

The #3 one is where I go back to "let them fall behind". I see this
in DV, I see it in APRS, I see this even with software packages like
DXLab - some folks don't get it and likely won't get it. At some
point ... rude as it seems ... you just need to let them go.

*I* get the whole IP and licensing thing but most people including
most hams do not. I was trying to come up with a way to pitch M17 to
them without falling back on "it's open source!". That's true, of
course, but means nothing to a LOT of people not on this list. I just
think we need a pitch for them that avoids that issue.


--
Peter Laws | VE[23]UWY / N5UWY | plaws0 gmail com | Travel by Train!

--

A couple questions:

For those of us that do keep up (mostly): Source code is considered a
published work and can be copyrighted. Who owns the copyright on
CODEC2 Has Dave Whose-VK-call-escapes me patented any of the methods
within it (ideas can be patented)? If so, what license are they
released under? Same question, really, for the copyright.

Here is the source for Codec2, including the license and copyright information:

I am not a lawyer, just followed lots of open-source stuff for the past 25 years. My understanding is that, at least in the US, copyright is automatically assigned to the author unless they specifically re-assign it. In the context of open source, that means that one project might have many copyright holders. The initial author decides on a license for the project, and all future contributions comply with and accept that license as part of their contribution.

The copyright holder(s) have the right to change the license, or simultaneously release the project under a different license if they wish. Where this gets interesting is there are many copyright holders and not all agree to the license change/add. If that happens, either the code contributed by the person(s) who don't agree to the license change must be removed/replaced, or the license cannot change. Big projects often require copyright reassignment--often to a foundation or other governing body--as part of contributing to the project to avoid this complication.

Looking through the Codec2 repo, I do not see any specific copyright (re)assignment required anywhere. The project is released under the GNU LGPL v2.1.

If the copyright holders collectively decided to close-source the project in the future, the version up until that decision is made will always be available under the LGPL, so open source work could continue on a fork form that point.

All the same questions apply to the M17 protocol.

The spec is GPLv2 licensed. See:

Other M17 projects use different licenses like the TAPR OHL. All M17 project repos are here: . See the "LICENSE" file in each repo for the specifics.

For D-STAR, it looks like JARL owns the copyright on the protocol,
DVSI owns all the IP related to AMBE, and Icom owns the trademark on
"D-STAR". Trying to figure out the equivalents for M17 in case
someone asks me.


On selling to the majority of amateurs that don't keep up what is
the elevator pitch? DV exists and people are either using it or
shunning it. Without talking about intellectual property what is
the big deal about M17?

Excluding IP, which is a big deal IMO, there are a few things.

The folks shunning digi modes that I talk to personally are in 2 camps:
1. Analog FM is universal, cheap, and easy.
2. Digital is too fragmented so see #1.
3. Digital is too complicated.

M17's elevator pitch to these is that with things like Module17 or Mobilinkd, M17 can be added to any radio with the proper interface. This makes it the most universal digital mode.

To users of other digital modes, M17 offers voice *and* data (yeah, so can D-Star), not just silly pictures from an overpriced webcam mic accessory and GPS positioning. Isn't vendor locked (again, it can be added to anything with a proper data port). It supports hotspots and all the other features digital users are used to. As far as ease of use is concerned, which is the selling point for the worst of the current crop of digi modes, that's an implementation detail that's up to the team adding M17 to a given radio's firmware. I think it's very important to get this right.

73,
Ben - KU0HN

On Wed, Aug 14, 2024 at 2:19?PM Jim - K6JM via groups.io
<jmm@...> wrote:

**Without talking about intellectual property** what is the big deal about M17?

Hams can change/improve/extend the protocol. The other protocols depend on DVSI to do that.

I should have said " **Without talking about intellectual property or
the fact that the source is open**". Remember, *most* amateurs don't
really understand "open source" and have no issue with critical parts
of amateur radio needing a license from a 3rd party to be used.

And DVSI, AFAIK but happy to be corrected, DVSI's CODEC has nothing to
do with the D-STAR protocol, the YSF protocol, or the DMR protocol.
It just encodes the voice and then the protocol wraps itself around
the resulting voice blobs and sends them on their way.

So hams, in theory, could modify any of the *protocols* without
needing any assistance from DVSI ... which would, of course, mean that
their traffic would be orphaned since it wouldn't work with anything
else. There is a paper at TAPR that proposes replacing the DVSI voice
packets with CODEC2 packets *within* D-STAR by using flags in an
unspecified/unused byte in the stream header, but as has been noted
here, M17 has made that proposal moot. And it would have the same
issue - a CODEC2/D-STAR radio could not talk to an AMBE/D-STAR radio
even if they were on the same network.



--
Peter Laws | VE[23]UWY / N5UWY | plaws0 gmail com | Travel by Train!

**Without talking about intellectual property** what is the big deal about M17?

Hams can change/improve/extend the protocol. The other protocols depend on DVSI to do that.

On Wed, Aug 14, 2024 at 12:19?AM Tony Langdon via groups.io
<vk3jed@...> wrote:

On 14/8/24 2:10 pm, Jim - K6JM via groups.io wrote:

I once took a course in Change Management, that is, selling improvement processes to people in an organization. The leader gave us all kinds of suggestions, but also pointed out that some people will never change, but they will die at some point. Change is inevitable.

Unless it's from a vending machine. ;)

Most of those are card-swipe/NFC these days. Which is the point, I suppose.

Open protocol works on me and I am a D-STAR fan over the other DV
methods in the hobby. *I* don't like that all three (D-STAR, YSF,
DMR) *all* use DVSI's IP to encode the voice. It's the one thing
about D-STAR I don't like. OK, there are some other things I don't
like about it but those are out of scope. :-)

But it's not 2010, it's 2024, so onward. We've largely ... well ...
maybe not *largely* ... solved the D-STAR<->YSF<->DMR interop issue
with reflectors that will transcode between all three (it *is* between
all three, right?).

Now we need a new scheme that doesn't depend on anyone's IP but our
own and M17 appears to be it.

A couple questions:

For those of us that do keep up (mostly): Source code is considered a
published work and can be copyrighted. Who owns the copyright on
CODEC2 Has Dave Whose-VK-call-escapes me patented any of the methods
within it (ideas can be patented)? If so, what license are they
released under? Same question, really, for the copyright.

All the same questions apply to the M17 protocol.

For D-STAR, it looks like JARL owns the copyright on the protocol,
DVSI owns all the IP related to AMBE, and Icom owns the trademark on
"D-STAR". Trying to figure out the equivalents for M17 in case
someone asks me.


On selling to the majority of amateurs that *don't* keep up what is
the elevator pitch? DV exists and people are either using it or
shunning it. **Without talking about intellectual property** what is
the big deal about M17?


--
Peter Laws | VE[23]UWY / N5UWY | plaws0 gmail com | Travel by Train!

On 14/8/24 2:10 pm, Jim - K6JM via groups.io wrote:

Steve,

I applaud you for working so hard to spread the word about M17 and open-source.

My suggestion is we mainly focus on what’s good about M17, open-source being a major such goodness. What we probably should avoid is communicating negative views about other DV systems. Though I have never had an explicit sales job, I have noticed over the years that really good sales people do not denigrate their competition or competitive products. They just talk up what they are offering.

Makes sense, and M17 has a lot to offer - well written specification,
fully developed data transfer capabilities (packet mode) and 100% open
source.? That's a lot for starters.? My own position is to integrate
what I can, which I've had a lot of success with.

And this goes for earlier modes, including analog FM. Many people enjoy that mode for its simplicity, and we may never convince them. That’s ok. As has been pointed out, newer generations include many who expect the advantages of digital, and some of those understand the importance of openness.

One of the things I like about ham radio is how older modes (CW being
the ultimate example) can live on and find a place alongside cutting
edge innovation.

I once took a course in Change Management, that is, selling improvement processes to people in an organization. The leader gave us all kinds of suggestions, but also pointed out that some people will never change, but they will die at some point. Change is inevitable.

Unless it's from a vending machine. ;)

--
73 de Tony VK3JED/VK3IRL