On 22/10/2014 16:36, Joe Taylor wrote: > Hi Greg and all, Hi Joe, > > KI7MT: >> I know you've been busy with WSJT-X updates, but was wondering if you >> came to any conclusions on KVASD v1.12 decoder (32/64) and if there will >> be a central location to pull the decoder from for the apps that use it? > I presently have versions of kvasd v1.12 compiled for Windows, linux32, > and linux64. Also kvasd v1.11 compiled for ARM, OSX_32, OSX_64, and > linux64. I could make others, if there's a good reason to do so. ARM comes in big and little endian forms so there might need to be another ARM requirement some time.
I'm not sure there is an OS X 32-bit architecture any more. > > The only difference between v1.11 and v1.12 is that 1.12 also does a > decode test (on internally stored data) when you ask for its version number. I thought there was a difference in the way the command line arguments were processed in 1.12, see comments in extract.F90. > > Where is the best place to put them, for easy access? Maybe not on > SourceForge, since they're not open source? Perhaps on the WSJT web > site, instead? I believe hosting kvasd binaries on SourceForge is permitted, here is a quite from their Ts&Cs: " By submitting Code to SourceForge.net, you certify that your Code is in compliance with the OSI-Approved or compliant license that you designate, and you hereby represent and warrant that you have all rights, licenses and consents necessary to grant Slashdot Media and other users the rights and licenses granted herein, and under the OSI-Approved or compliant license you designate, without infringement of any third party rights. In addition, the Code that you submit must also be made available in human-readable (i.e., “Source Code”) form. Whenever reasonably feasible, you agree that you will make Source Code available on or via SourceForge.net corresponding to Code that you post, submit, display or distribute. You must make Source Code available for all portions of Code that you have modified, enhanced or otherwise created derivative works from (with any such modification or derivative work being a “Change”). Slashdot Media acknowledges that there may be situations where posting Source Code is not reasonably feasible; examples of such situations are when you are posting Code that: (a) is ancillary to other Code that you have changed but such Code is only available to you in binary or executable form (such as closed-source device drivers or closed-source software frameworks); (b) is otherwise readily available in Source Code form online as part of an Open Source distribution, and where you notify users that the Source Code for such distribution is available elsewhere on the Internet (and you also provide a link to that location); or (c) Slashdot Media agrees in writing does not need to be posted in Source Code form. " Which comes from: http://slashdotmedia.com/terms-of-use/ > > Is static linking of these a bad idea, for any licensing reasons? (I'm > fairly clueless about these things...) Static linking GPL libraries into a closed source executable is not allowed. Static linking LGPL libraries into a closed source executable is allowed but I believe that the means to relink the executable must be provided somewhere. In practice that means making the object code of the closed source parts available. The above LGPL case should be the situation with kvasd, I can't answer for sure since I don't know which libraries are being statically linked. The complexity of making object code available might be not worth the trouble and dynamic linking may be easiest IMHO. AFAIK dynamic linking is the way that this is done in almost all proprietary products. > > -- Joe, K1JT ------------------------------------------------------------------------------ _______________________________________________ wsjt-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wsjt-devel
