Hi all, Turns out you can't tell furries that a superfox is proprietary!
https://sprocketfox.io/xssfox/2024/07/24/superflawed/ After I mentioned my disappointment and concern about the implications of closed binaries in this week's zero retries [1], including making users in debian, ubuntu, raspi, etc second class, superfoxless citizens in the wsjt-x universe [2], some friends of mine took it upon themselves to see if a free implementation was possible. The above post is the outcome of a couple of days of research. [1] https://www.zeroretries.org/p/zero-retries-0161 [2] https://salsa.debian.org/debian-hamradio-team/wsjtx/-/blob/debian/latest/debian/changelog?ref_type=heads Cheers, -- Hibby Debian Developer Packet Radioist MM0RFN On Sun, 21 Jul 2024, at 5:46 PM, Jakob Ketterl DD5JFK via wsjt-devel wrote: > Hello Joe, > >> I have to say I don't remember your ever having contributed usefully to >> the open-source WSJT project, so I consider your >> complaints-to-contributions ratio to be rather high. Perhaps I am being >> unfair to your ultimately friendly purposes for the benefit of Amateur >> Radio. > > I'm not surprised you don't remember. After all, it's just been a minor patch > so far. I don't think that should matter though, I'm not trying to complain, > I'm trying to participate in this debate. I'm trying to back up my arguments > with facts, and I'm expressing my opinions as based on my understanding of > software licensing. I'm not the guy that's intending to cause trouble here, > I'm here to tell you that your current situation is inviting trouble. > >> We're working hard to meet deadlines related to the Jarvis expedition's >> schedule. Please be patient for us to catch up with clear and complete >> licensing statements. > > I don't share the particular interest in DXpeditioning, and as such I don't > have a great personal interest in the fox/hound or superfox mode in general. > >> In the meantime, try saving a few *.wav files when monitoring K8R, or >> ask for some example files recorded by someone else. Then execute the >> standalone SuperFox decoder sfrx, using something like the following >> simple command at your bash shell prompt, and see the subsequent output. >> >> $ sfrx 240720_132400.wav >> 132400 -7 0.3 750 ~ JH6KOQ K8R RR73 >> 132400 -7 0.3 750 ~ N0AN K8R RR73 >> 132400 -7 0.3 750 ~ YO3ICT K8R RR73 >> 132400 -7 0.3 750 ~ IK0NKA K8R +01 >> 132400 -7 0.3 750 ~ DF2RQ K8R +10 >> 132400 -7 0.3 750 ~ OH3FVP K8R +04 >> 132400 -7 0.3 750 ~ W2ZQ K8R +03 >> K8R verified >> >> If need be, I will send you a few files. > > Thanks, it's nice you're taking the time to show me how it works, but it's > not necessarily what I intended to happen. It's not important for me to > understand how these decoders works, it's important that such information is > made available to the general audience, maybe packaged together with the > binaries. This information may eventually become relevant for my work on > OpenWebRX, but given that I've worked with the other decoders I'm pretty sure > I would have been able to figure this out myself. At this time I'm trying to > make a different point: the lack of such information makes it very easy to > argue that the superfox binaries are not, as claimed, standalone, thus > forcing you to release their code. You may disagree on that, which is fine > for me, but it's also kind of a great risk to take for some missing > documentation. > > The same goes for the binary packages. It's quite risky to shove these > binaries out the door just because they're needed for a DXpedition while at > the same time not taking care of the licensing. > > 73s > Jakob DD5JFK > > _______________________________________________ > wsjt-devel mailing list > wsjt-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wsjt-devel >
_______________________________________________ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
