Hate to burst your bubble, the binaries do NOT have to be stripped, as they can be included as an exception to the GPL license.
Neil, KN3ILZ On 7/24/2024 4:05 AM, Hibby wrote:
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
