AllStarLink, Inc. Obtains Copyright

There are a couple of warring camps in the Allstar (app_rpt) development world. One group, AllStarLink, Inc., has claimed to represent the vision and interests of Jim Dixon <WB6NIL>, the original developer of app_rpt. Another group, HamVoip, has made some significant changes in that code in an effort to improve it.

So why can’t we all get along?

Jim Dixon released his code under the terms of the Gnu Public License. The short explanation of GPL is that anyone is free to use the code but any enhancements must be shared back with the community. AllStarLink, Inc. has insisted that HamVoip share the source code to its enhancements. HamVoip has declined.

The acrimony in some online forums has been thick enough to cut with a knife. Some have branded HamVoip as pirates and some have said that AllStarLink ought to get over itself and has no authority to enforce anything.

The scale has shifted in favor of the AllStarLink, Inc. defense of “open source”. In a recent announcement, the Board of Directors reports that:

AllStarLink, Inc., the extension of Jim Dixon’s vision for AllStar, has obtained all rights including Copyright to app_rpt and associated material. In the spirit of Open Source, we encourage code contributions to the project. Thank you for your continued support in keeping the AllStar vision alive.

Hopefully this settles matters once and for all. May Jim Dixon’s vision of an open, community based solution for analog repeater linking live long and prosper.

You Say Protocol, I Say Reflector…

Is XLX a protocol? Is it a type of reflector? Why are we asking these questions?

There is a bit of a debate going on now in D-Star circles as to how the end user (you OM or YL) of a hotspot or repeater should connect to an XLX reflector. I’ve exchanged emails with some notable folks in amateur radio software development circles (Luc LX1IQ, Andy MW0MWZ, and Tom N7TAE) on the subject. The software developers are all in agreement. XLX is not a protocol, it is a type of reflector. On that point, they are quite correct.

To varying extents, each have indicated that the preferred way to access a reflector is via the protocol, node and module notation. Using this paradigm, to access XLX020A via DExtra protocol, you’d connect to XRF020A. But there could be an XRF020A that is not XLX020A. We’ll get to that in a couple of paragraphs.

On the other hand, Jonathan Naylor (G4KLX) has implemented the ability for ircDDBGateway to access XLX reflectors by name. Since all XLX reflectors support DCS protocol and DCS is the most modern of the three D-Star reflector protocols, ircddbgateway defaults to DCS connections. This make perfect sense to me. And it works!

Note: In case you did not know, ircDDBGateway is part of the software suite that comprises the exceedingly popular Pi-Star distribution. May of the tools provided as part of Pi-Star were developed by G4KLX.

As an end user of a hotspot or repeater, I just want to connect. There is also the problem of amgibuity. You can have an REF123, an XRF123, a DCS123, and an XLX123. They may or may not be the same destination. But XLX123 is a specific destination, as are the other three. So the best way to connect to an XLX reflector for the end user would be to allow the end user to specify that destination.

To continue to require that XLX connection requests specify a particular protocol, when there is no specific reason to do so, would be as confusing as requiring the end user of a mobile phone to specify what network the called party is connected to. Yes, the option is there, but let’s make this simple.

I’d like to see the various hotspot platforms adopt this aproach. What do you think?

73 de K2DLS