On 13/11/2014 00:59, Greg Troxel wrote: Hi Greg,
I'll try and answer your questions since I kicked off this thread. > I'm a packager for pkgsrc, used on NetBSD and SmartOS (Illumos), and > which runs on about 20 other systems. I haven't yet packaged WSJT-X, > but it's on my eventually list. This is 99% about not having spare > time, but I am also unenthused about the non-Free aspects, both from a > philosophical viewpoint and because of the huge portability problems > caused by programs wihtout available source code. OK, hopefully the WSJT-X superbuild project mentioned previously will help you with that as it aims to provide a "proper" upstream source tarball that will build on any *nix system. There are some restrictions in that it requires Qt 5 at least, other than that it aims to make your life as a *nix package maintainer as easy as possible. > > > I have a strong preference for KVASD being handled as an entirely > separate package, so that someone could use it without WSJT-X to do the > computations it is useful for. Then, WSJT-X could optionally use it if > present, and also function without it. That would allow WJST-X builds > to be included in binary package collections. If KVASD were required, > that would block anything that depended on it. That's assuming KVASD > can't be distributed in binary form; searching for KVASD license didn't > turn up specific license text. pkgsrc does distribute non-Free packages > as long as the upstream's license permits distribution. That's exactly where we are heading for away from Windows and Mac, I hope. The KVASD EULA is here: https://sourceforge.net/p/wsjt/wsjt/HEAD/tree/trunk/kvasd-binary/kvasd_eula.txt > > Having a free software program ask to download non-free code isn't > against the license terms, but to me it feels against the spirit. > > (As an aside: Presumably KVASD can't be hosted on sourceforge; my > understanding is that the free hosting is only for code with a Free or > Open Source license. I did find binaries in svn, but, they didn't seem > to have a license and clearly aren't covered by the top-level GPL2. But > I'm a bit confused by the svn layout.) KVASD binaries CAN be hosted on SourceForge, the terms of use have explicit exceptions for closed source binaries like proprietary drivers. The SVN layout is somewhat confusing. Most of Joe's projects are branches rather than being under a trunk. WSJT is the trunk, WSJT-X , WSPR, WSPR-X, MAP65 exist as branches and some have "real" branches such as WSJT-X v1.3 and WSJT-X v1.4 as well. > > There's another issue, which is that it's unlikely KVASD will be > available for more than a small fraction of the OS/version/cpu > combinations that pkgsrc supports. I don't really have a good > suggestion for addressing that. The only way to address that is to provide a suitable environment to Joe K1JT to compile and link KVASD either directly or via a cross tool chain. > It's normal in pkgsrc to have any libgcc runtime (beyond what's provided > by the base system) available as a package. So if there were control > files for a kvasd package that could build binaries from the (not > distributed) source tarball, the resulting binary packages should work. > Or a package can package a dynamically linked executable that assumes > particular support libraries in standard places. Presumably you are > avoiding a full static link because of the LPGL requirement to permit > relinking (which makes sense). AFAIK KVASD is currently built either by individual compile and link commands or by a Makefile. I am pretty sure no package exists over and above that. > > Longer term, it would be good to have a roadmap for removing the > need/desire to use non-Free code, as it seems to be causing signficant > practical problems (with the resulting lack of portability arguably > being the largest issue). I've seen some comments on the list, but am > unclear on the status/prognosis. As far as I understand the main issue is not just with the source code as such but the patents that protect the algorithm contained therein. This may make it impossible to even reverse engineer the algorithm without violation. That probably means that the whole JT65 community would have to move to a new protocol to escape. I don't know how the other JT65-HF etc. implementations deal with this. AFAIK KVASD is only used for JT65 modes so users could choose JT9 operations with degraded JT65, at least in WSJT-X. AFAIK one member of the community has an open source implementation that gets within 0.5 dB of the KVASD algorithm which was independently developed but I've not heard much of that since it was mentioned many months ago. I suspect that would require them to make the source available without reference to Joe K1JT given he is privy to the patented implementation. These deep level dB figures may not be of great significance on HF with adverse band conditions and congestion, but for EME operators they are right in the operating zone most of the time and highly relevant I expect. > > How bad is it for someone to choose not to use KVASD? Does it cost them > decode performance, or CPU time, or both? Or is it really not a > feasible choice? The documentation I've found doesn't address this; it > just says "go get this non-free code, with an implicit "assuming it's > available for the os/version/cpu that you want to run it on"". Decode performance in JT65 to the extent of 2dB extra decoding depth. > > > 73 de n1dam 73 Bill G4WJS. ------------------------------------------------------------------------------ Comprehensive Server Monitoring with Site24x7. Monitor 10 servers for $9/Month. Get alerted through email, SMS, voice calls or mobile push notifications. Take corrective actions from your mobile device. http://pubads.g.doubleclick.net/gampad/clk?id=154624111&iu=/4140/ostg.clktrk _______________________________________________ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
