Hi All, This is an update on work in progress related to KVASD. Sorry it's yet another long message but the KVASD situation is potentially toxic and is long overdue for a good solution.
Firstly some background as I see it. KVASD is closed source and must be dissociated from deployments of GPL licensed applications like WSJT-X. This dissociation doesn't prevent cooperation between WSJT-X and KVASD at run time so long as the interface between them is itself open. It also doesn't preclude WSJT-X from deploying a tool or tools to optionally install KVASD post installation. I view this as similar to an open source GPL licensed web browser being used to download closed source proprietary content, for example a plugin of some sort. To this end the current arrangement of the WSJT-X build system bundling KVASD in deployment packages and installers is not compatible with our GPL license. Having a step in the build to inject KVASD for development and testing purposes is, I believe, acceptable so long as it is optional. This last capability is currently in place, but as it stands the creation of installer packages for both Windows and Mac bundles a KVASD executable and this is not compliant. To move to proper compliance with the GPL licence there is currently work in progress as follows: Greg KI7MT is working on a non-free (as in not Free Open Source) Debian package to install KVASD as a stand alone executable. I believe Richard KF5OIM is looking at a similar package for RPM based systems. This is a good solution for Linux systems because they already have all the support libraries needed for KVASD, i.e. the LGPL licensed libgcc libraries to support dynamically linked C and Fortran based executables built using gcc/gfortran. Note that dynamic linking of LGPL libraries is required by their license terms for closed source applications. For Windows and Mac the provision of a standalone KVASD package is not such a good solution because in both cases the above mentioned libgcc support libraries are not available as standard system components and thus would have to be bundled with the KVASD installer. Although such bundling is possible, it does create a number of secondary issues including: * On Windows use of a separately installed package would require the system PATH to be modified to make the KVASD executable available to WSJT-X, alternatively the WSJT-X installation would have to be made aware of the location of the KVASD executable as some sort of post installation step. * On Mac there is no real mechanism for a command line executable to include its own support libraries, that is more normally done as an application bundle which is by definition not a command line application. To address these and other issues I propose to develop and enhanced installer for WSJT-X on Windows that optionally fetches the KVASD EULA and executable and injects it into the WSJT-X install. This fetch is done over the Internet at install time therefore not requiring any closed source content to be bundled in the WSJT-X installer. By using this process the KVASD executable ends up in the WSJT-X installation binary folder and therefore shares the libgcc DLLs with WSJT-X itself. On Mac life is a bit more complex as the installer we use has no scripting or programmatic content, it simply uses standard OS X facilities to present the user with a graphical Drag'N'Drop install step to place the fully self contained WSJT-X application bundle into the system /Applications folder, or elsewhere. This is a fairly normal and very common Mac installation mechanism which is made possible by the fully self contained Mac application bundle structure itself. This means that on Mac a post installation step becomes necessary to "inject" KVASD into the system. The best place by far for this "injection" is into the WSJT-X bundle itself, this is because the KVASD application can then, with a few adjustment commands on the executable, reference the libgcc dylibs that are already bundled with WSJT-X. These references are relative paths therefore including the KVASD executable inside the WSJT-X application bundle allows the bundle to be moved around or copied without issue just like any other application bundle. There is one gotcha associated with this approach on Windows and Mac and that is that we must ensure that the libgcc libraries KVASD is linked against are either the same or at least very close to the ones that are used to build WSJT-X and bundled with it. This is essential as KVASD would be sharing the WSJT-X support dylibs. This should not be beyond our capabilities given that we are largely in control of the building of KVASD. Another issue is the acceptance of the KVASD EULA by individual users, on Linux this is built into the package install system so long as the appropriate license text is included in the package itself. On Windows I propose to add a custom page to the NSIS installer that fetches the KVASD EULA and binary from the Internet and requests acceptance of the EULA before KVASD installation can be completed. On Mac I propose to write a small application that fetches the KVASD EULA and binary from the Internet and requests agreement of the EULA before injecting KVASD into a WSJT-X application bundle. This Mac only application would be included on the WSJT-X installation disk image and would be invoked by dragging the post installed WSJT-X application bundle back onto it. I already have a proof of concept implementation for Windows and am part way through developing a Mac application to install KVASD. Here is a sample of the enhanced Windows installer: https://dl.dropboxusercontent.com/u/4192709/wsjtx-1.4.0-rc3-win32-KVASD-installer.exe The remaining issue is what we do if the user chooses not to install KVASD, currently no KVASD executable will cause one missing KVASD program message box per session and many "KV decoder missing" errors in the "Rx Activity" window. In the past this has been limited to one error per session (the code is still there but commented out) but was changed to make it clear that running without KVASD is not optimal. I did consider a dummy KVASD program to include in install packages but this leads to more problems than it solves so I think I would prefer a modification to make the missing KVASD executable message more explicit perhaps with a link to a page that explains how to install it and no error messages in the "Rx Activity" window at all. Thoughts, comments and updates from the Linux packagers welcome. 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
