This project was sitting on my hard drive for several years until now. Last time I made an attempt to clean it up and prepare for publishing to GitHub in 2017.

Making sure it compiles agains all required targets and contains all the required notes - is easy for such a small project. But there was something I just didn’t know how to deal with… More on this below.

Back in time, I was playing with RTL-SDR dongles, and the device I was connecting them to was a Microsoft Surface 2 Pro - “laptop-but-more-like-a-tablet”. I love Microsoft Surface devices, especially that old one, for it’s compact size. It is really cool to be able to move around freely, listening what’s coming from a dongle, no awkward balancing acts with a classic laptop…

Portable use has some UX specifics. Namely, having to use keyboard and mouse is really limiting, and touch screen operation on a tablet device is much more preferred.

While SDR# had quite clean UI, it was clearly made without such considerations. The core functionality - frequency navigation - was nearly impossible to perform on the go. It is really hard to hit top or bottom of the right digit on the frequency display.

At the same time, I had some examples of test and measurement equipment in access. These are historically made with very good tactile operation in mind. So I figured I can bring some of that experience to a SDR# plugin.

The plugin

First thing I wanted to address - I want to be able to perform with a thumb what was only possible to perform with a mouse. I implemented my own frequency display with the big buttons to select/increment/decrement a digit. This alone was pretty enabling experience already.

Second thing - I quickly realize there are cases when I need to jump by predefined steps. Think of channels in some communication standard. So there it is - an additional set of controls - step size entry field and navigation buttons to move around.

I have a feeling these two sets could’ve been boiled down to something better. Currently there are two pairs of similar buttons doing very different things and that gives to me not so great UX smell… I just had no bright idea to solve this. So far it is straightforward implementation and does the job (not too dissimilar from early test and measurement devices, whose interfaces were reflecting the inner mechanics).

Third thing - I quickly noticed that I often use the navigation just to pan around. Tapping buttons continuously is not really comfortable. Autorepeat feature solved this nicely, I think. Although the way the touch handling in Windows distinguishes between “RMB clicks” and “LMB long presses” is something to get used to. Maybe I could’ve handled right click events in the way to make them behave like long presses…

Fourth thing - jumping to a precise frequency from anywhere. Panning is not fun when you know exactly where you have to jump. I recreated the classic frequency input interface from T&M equipment in form of a popup window with digits and units entry.

And there you have it. Thumb-friendly frequency navigation plugin.

I thought about providing binaries for official version and open-source forks. But for now I decided to just publish the source and see whether there will be any interest. (I didn’t even check if it is still compatible with up-to-date official version.)

The license

I wrote the plugin in 2015 initially (I think). I was returning to it in 2016 and 2017 briefly to clean it up and prepare for publish. But the one thing always stopped me until this point.

I couldn’t just slap MIT license on it. I thought it doesn’t go well with what looks like a disrespectful practice of the SDR# developer. If they limit their contribution to the community unilaterally and only care to sell their products - why should I contribute and increase the capabilities of their own software for nothing?

I never was close to the scene. Maybe that’s just an another attempt to figure out a way for authors to sustain themselves and simplify the maintenance of a software available for free, before Patreon or anything like that… Maybe that was just the first time I run across something like this…

From top of my head, PaintNET is another free closed-source software written in C#. But I have a better impression of it - while it is possible to support the developer, it was never about trying to commercialize it.

I was looking at other open source licenses and another concern was growing in me. There are very basic permissive licenses like MIT and BSD - I can comprehend them and put under my code I don’t care much about. But the rest are multipage documents written by lawyers for lawyers, focusing on someone else’s concerns. Trying to match them against my own concerns feels like interpreting centuries old religious texts. That’s not something I consider acceptable.

I keep wondering about why there is no license similar to Creative Commons, but applicable to code, so I could include parts I care about from a predefined set. The reason might be that code licensing is more complicated and can’t be decomposed to loose parts, maybe?

For this project I decided to write down all I have in mind and organize it in a way I find clear. I’m not a lawyer and not even a native English speaker, so the result is not great. But it might be a good starting point for a discussion on how to make better licenses for independent developers…

My text is currently under 2K characters long and I find this size comfortable, considering it is also as plain language as reasonably possible. Even MIT has very long liability rejection section and I wonder if it actually has to be that way. Look at tl;drLegal for example. For most of our practical purposes we only need a gist of what license says. Can we organize a license text in a way that does not need a TL;DR or an Abstract?

While writing my text, I started to think about it as a decision tree. Any reader will refer to a license text with sertain questions in mind. In order to be readable, license text must reflect real world cases. “Can I <do something> with this project in <certain conditions>?” The better license follows real usage scenarios and breaks them down from more generic to more specific - the clearer the answers will be and less interpretation needed.

Wrapping back to Creative Commons-like modular license. I think the modular software license framework is possible. It will require to identify common concerns and provide a constructor that will allow to combine them into a decision tree, resulting in a well formed license. Like with Creative commons, license might be present in a compact form (easy to grasp) and a full form (with added section of precise term definitions, not affecting readability of the meaningful section).

Feel free to grab this idea and form a community working group. Or point out to me if something like this was done already or can’t be done…