FOSS in Amateur Radio

Why free and open tools matter for hams, and where to find them

Amateur radio has always run on open standards. Anyone with a license can build a station and talk to anyone else, because the modes, band plans, and protocols that make that possible are published, not owned by any one company or person. That's been true since spark-gap days, and it's still true of FT8, APRS, and Winlink. Software should follow the same rule, but it hasn't always: a growing amount of the code that runs a modern station (digital mode decoders, logging, rig control, SDR receivers) ships closed, tied to one vendor, one platform, one subscription, or person, in a hobby that was never supposed to work that way.

Why open source matters

• You can see what it's doing. Software that keys your transmitter or decodes your signal should be auditable, especially on a shared, licensed band.
• Protocols only work if implementations can interoperate. FT8, APRS, and Winlink work because more than one program can speak them correctly.
• Radios outlast companies. Hardware stays in service for decades. Code tied to one vendor's servers or license dies when the company does.
• It grows the next generation of builders. A ham who can read the code can fix it, extend it, and teach the next license class.
• You control your own equipment. Free software means you can run it, study it, change it, and share those changes, instead of being bound by a license that dictates how you're allowed to use your own station.
• Bugs get fixed faster. With the source available, any operator can report an issue with real detail, and any developer can submit a fix.
• It supports new and experimental modes. Open code makes it easier for hams to try new digital modes and protocols instead of waiting on one vendor.
• Your data stays yours. Logs, configurations, and QSO records stay in open formats you can read, back up, and move between programs.

None of this is about being anti-commercial or anti-manufacturer. Plenty of open source ham software is written by the same people who design and sell radios, and plenty of it runs happily alongside proprietary firmware. The point is that amateur radio is a service built on operators helping each other learn, experiment, and stay on the air, and open source is simply the version of that spirit applied to code. A club member fixing a bug in their spare time, a student reading real transceiver code to understand a protocol, an old rig kept useful because someone rewrote its driver: these are ordinary things in this hobby, and they only happen because the software allows them to.

You'll often see this referred to as FOSS, short for Free and Open Source Software. The "free" here means freedom, not price: the freedom to run a program for any purpose, study how it works, change it to suit your needs, and share those changes with other hams. Some FOSS licenses require that anything built on the code stays open too, which is what keeps a protocol or a tool from being absorbed into a closed product and taken away from the community that built it. It's the same philosophy that runs most of the internet's infrastructure, and it maps naturally onto a hobby that already runs on shared, published standards.

Not every open source project is FOSS in that fuller sense, and it's worth knowing the difference. OSS just means the source code is published and viewable. FOSS specifically guarantees those four freedoms: to run, study, modify, and redistribute the software, including your changes. A project can release its source under a license that lets you look but bans derivative works or forbids redistribution, and that's source-available without being FOSS or, by most casual use of the term, OSS. A license that restricts commercial use is a common enough case worth calling out on its own: people often still call it OSS, but the Open Source Initiative's own definition explicitly excludes field-of-use restrictions like that, so by their definition it isn't OSS either. Licenses like GPL, MIT, and Apache 2.0 are FOSS licenses. Reading a project's license file, not just seeing a public repository, is the only way to know which one you're actually getting.

Open source tools to try

Check each project's own site for current downloads and build instructions.

Browse more projects: github.com/topics/amateur-radio  |  awesome-hamradio

How to help

• Test a nightly build on your own rig and file a clear bug report.
• Write the setup doc you wish had existed when you started.
• Answer a beginner's question on a project's mailing list or forum.
• Donate to a maintainer keeping a protocol library alive on their own time.

Why you should make your own software open source

If you've written something useful for your own station, releasing it as open source is worth doing even if you never expected anyone else to use it. Other operators are often solving the exact problem you already solved, and a project sitting on your hard drive helps no one. Putting it out in the open means someone with a different radio or a different use case can extend it in ways you hadn't planned for, and it means the tool doesn't disappear the day you lose interest, change callsigns, or move on to another project. It also puts your code in front of people who will catch bugs and edge cases you'd never find testing alone. And practically: it's a real, visible piece of work you can point to, which matters whether you're looking for feedback, collaborators, or just credit for something you built.

Keeping it proprietary, meanwhile, costs more than it looks like it does. A closed license means you're the only person who can ever fix a bug once you've moved on, so the software has an expiration date tied to your own interest. It also means no one can verify what the program is actually doing with their station or their data, which is a harder sell in a hobby built on operators trusting each other. If you ever want someone else to help maintain it, review it, or port it to new hardware, a proprietary license makes that legally impossible, not just inconvenient. And licensing terms, activation, or paywalling something that took you a weekend to write tends to work against the reason most hams built the tool in the first place: to solve a problem for the community, not to manage one.

There's also a selfish, practical case for it. Open sourcing a tool tends to make the tool itself better, faster, than working on it alone ever would: other operators test it on hardware you don't own, in conditions you can't easily reproduce, and file the issue before you'd have noticed it yourself. It's a way to build a reputation in the hobby that outlasts any one contact or contest, since a widely used tool with your callsign attached says more than a logbook does. And it plugs your project into a much larger support network for free: instead of maintaining your own build system, documentation, and issue tracker in isolation, you inherit the platforms, packaging, and conventions the wider FOSS ham community has already built. If you ever want to move on to a different project, a clean handoff to a new maintainer is only possible if the license already lets someone else pick it up.

Making your own software open source

Written a logging tool, a rig control script, or a mode decoder for your own station? Here's what it takes to release it as open source:

• Pick a license. This is the step people skip and shouldn't. A license tells others what they're allowed to do with your code. If you want it to actually be FOSS, not just source-available, pick a license that guarantees the four freedoms: to run, study, modify, and redistribute the software, including changes. GPLv3 requires anything built on your code to stay open too. MIT or Apache 2.0 are more permissive FOSS licenses and allow use in closed-source projects. A "look but don't touch" or non-commercial license doesn't count as FOSS, even if the code is public. And skipping a license file entirely means all rights reserved by default, so legally no one else can use, modify, or redistribute your code no matter how visible the repository is. choosealicense.com is a good place to compare options, though it only covers FOSS licenses.
• Put it somewhere people can find it. GitHub, GitLab, or Codeberg all work. Public source control also gives you version history and a place for others to file issues or submit fixes.
• Write a real README. What the program does, what hardware or modes it supports, how to build or install it, and how to report a bug. Assume the reader has never seen your code before. opensource.guide has a good walkthrough of starting a project this way.
• Document your protocol choices. If your software talks to a radio, a server, or another program, write down the format it uses. That's what lets someone else write a compatible client, or maintain yours after you've moved on.
• Accept that others will use it differently than you intended. Someone will run it on hardware you never tested, or want a feature you don't need. That's normal, and it's a large part of why open projects improve over time.
• You don't owe anyone free support. Open source doesn't mean you're on call. Answer what you can, accept help from others who pick up issues, and set your own pace.