wsjt-devel

[wsjt-devel] Licensing Issue of SuperFox Mode

[Kenji R. J. <jj...@gm...>]

I do appreciate all the efforts poured into the SuperFox Mode.

Writing that, I'd like to state one thing:

The current WSJT-X (2.7.0-RC5 and later) has a self-contradictory license
and that should be fixed ASAP.

GPLv3 requires ALL binary code must be able to be produced/built
from the distributed source code [1].
Currently, the SuperFox binaries, namely foxchk/sftx/sfrx are
unable to be built from the source code distributed as a part of WSJT-X.
This means the current state as of the 2.7.0-RC6 self-contradicts
with the license being claimed.
I would like this situation to be fixed ASAP.

There are a few possible ways to fix this situation:
by changing the license to allow the proprietary binaries,
or separating the proprietary part (namely SuperFox Mode binaries),
or making the source code of SuperFox Mode available with the package.
There might even be another way that doesn't come up to my mind.

I do not want to start a bikeshed discussion of licensing.
I simply would like the developers of WSJT-X to take this situation
seriously and propose a practical solution.

I hope WSJT-X would remain fully open-sources as it had been.

73
Kenji Rikitake, JJ1BDX

[1]: https://www.gnu.org/licenses/gpl-faq.html#DistributeExtendedBinary

Quote:

> I want to distribute an extended version of a GPL-covered program in
binary form. Is it enough to distribute the source for the original version?

> No, you must supply the source code that corresponds to the binary.
Corresponding source means the source from which users can rebuild the same
binary.

Part of the idea of free software is that users should have access to the
source code for *the programs they use*. Those using your version should
have access to the source code for your version.

A major goal of the GPL is to build up the Free World by making sure that
improvement to a free program are themselves free. If you release an
improved version of a GPL-covered program, you must release the improved
source code under the GPL.

Unquote.

Re: [wsjt-devel] Licensing Issue of SuperFox Mode

[Jeff S. <kb...@gm...>]

Partially verified this.

I checked the "manifests" for the rpms and debs.   Sure enough the 
binaries are
being distributed as part of the WSJT-X binary package.   They are not 
listed as
dependencies.

Working trough the source code, they are not there.   It would appear 
that those
of us building from source will be unable to participate in any of the 
RC testing,
as we do not have complete packages.

HOWEVER....

All three have a git hub repository, dated July 2024.   In other words, 
just opened.
So I doubt very much this is a license issue, as much as it is a 
catching up issue.
Perhaps the RC6 offering was done a little too quickly, before the git 
hub code was
made available.  NO BIG DEAL.   We are all volunteers and offer our 
SPARE time.
Sometimes, spare time isn't always in sync with each other.


PAULISPER EXSPECTA




On 7/19/24 09:22, Kenji Rikitake JJ1BDX via wsjt-devel wrote:
> I do appreciate all the efforts poured into the SuperFox Mode.
>
> Writing that, I'd like to state one thing:
>
> The current WSJT-X (2.7.0-RC5 and later) has a self-contradictory license
> and that should be fixed ASAP.
>
> GPLv3 requires ALL binary code must be able to be produced/built
> from the distributed source code [1].
> Currently, the SuperFox binaries, namely foxchk/sftx/sfrx are
> unable to be built from the source code distributed as a part of WSJT-X.
> This means the current state as of the 2.7.0-RC6 self-contradicts
> with the license being claimed.
> I would like this situation to be fixed ASAP.
>
> There are a few possible ways to fix this situation:
> by changing the license to allow the proprietary binaries,
> or separating the proprietary part (namely SuperFox Mode binaries),
> or making the source code of SuperFox Mode available with the package.
> There might even be another way that doesn't come up to my mind.
>
> I do not want to start a bikeshed discussion of licensing.
> I simply would like the developers of WSJT-X to take this situation
> seriously and propose a practical solution.
>
> I hope WSJT-X would remain fully open-sources as it had been.
>
> 73
> Kenji Rikitake, JJ1BDX
>
> [1]: https://www.gnu.org/licenses/gpl-faq.html#DistributeExtendedBinary
>
> Quote:
>
> > I want to distribute an extended version of a GPL-covered program in 
> binary form. Is it enough to distribute the source for the original 
> version?
>
> > No, you must supply the source code that corresponds to the binary. 
> Corresponding source means the source from which users can rebuild the 
> same binary.
>
> Part of the idea of free software is that users should have access to 
> the source code for *the programs they use*. Those using your version 
> should have access to the source code for your version.
>
> A major goal of the GPL is to build up the Free World by making sure 
> that improvement to a free program are themselves free. If you release 
> an improved version of a GPL-covered program, you must release the 
> improved source code under the GPL.
>
> Unquote.
>
>
>
> _______________________________________________
> wsjt-devel mailing list
> wsj...@li...
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel

-- 
Jeff Stillinger - KB6IBB
KB6IBB Laboratories, Wylie Tx
http://kb6ibb-15.ham-radio-op.net/
Reddit: r/KB6IBBSWLLogger

Re: [wsjt-devel] Licensing Issue of SuperFox Mode

[Joe T. <jo...@pr...>]

Dear Kenji-san,

Thank you for your interest in WSJT-X.  We do not believe the license 
terms for WSJT-X 2.7.0-RC5 and later are self-contradictory.

WSJT-X is a complete and independent program.  Its full source code is 
available to anyone.  One of its many operating modes makes use of 
short, uncomplicated exchanges with three independent programs that are 
licensed separately and made freely available for Amateur Radio use. 
These separate, stand-alone executable programs are not open source.

The following text is from "Frequently Asked Questions about the GNU 
Licenses", https://www.gnu.org/licenses/gpl-faq.html :

"[P]ipes, sockets and command-line arguments are communication 
mechanisms normally used between two separate programs... [W]hen they 
are used for communication, the modules normally are [considered] 
separate programs."

	-- 73, Joe, K1JT

On 7/19/2024 10:22 AM, Kenji Rikitake JJ1BDX via wsjt-devel wrote:
> I do appreciate all the efforts poured into the SuperFox Mode.
> 
> Writing that, I'd like to state one thing:
> 
> The current WSJT-X (2.7.0-RC5 and later) has a self-contradictory license
> and that should be fixed ASAP.
> 
> GPLv3 requires ALL binary code must be able to be produced/built
> from the distributed source code [1].
> Currently, the SuperFox binaries, namely foxchk/sftx/sfrx are
> unable to be built from the source code distributed as a part of WSJT-X.
> This means the current state as of the 2.7.0-RC6 self-contradicts
> with the license being claimed.
> I would like this situation to be fixed ASAP.
> 
> There are a few possible ways to fix this situation:
> by changing the license to allow the proprietary binaries,
> or separating the proprietary part (namely SuperFox Mode binaries),
> or making the source code of SuperFox Mode available with the package.
> There might even be another way that doesn't come up to my mind.
> 
> I do not want to start a bikeshed discussion of licensing.
> I simply would like the developers of WSJT-X to take this situation
> seriously and propose a practical solution.
> 
> I hope WSJT-X would remain fully open-sources as it had been.
> 
> 73
> Kenji Rikitake, JJ1BDX
> 
> [1]: https://www.gnu.org/licenses/gpl-faq.html#DistributeExtendedBinary 
> <https://www.gnu.org/licenses/gpl-faq.html#DistributeExtendedBinary>
> 
> Quote:
> 
>  > I want to distribute an extended version of a GPL-covered program in 
> binary form. Is it enough to distribute the source for the original version?
> 
>  > No, you must supply the source code that corresponds to the binary. 
> Corresponding source means the source from which users can rebuild the 
> same binary.
> 
> Part of the idea of free software is that users should have access to 
> the source code for *the programs they use*. Those using your version 
> should have access to the source code for your version.
> 
> A major goal of the GPL is to build up the Free World by making sure 
> that improvement to a free program are themselves free. If you release 
> an improved version of a GPL-covered program, you must release the 
> improved source code under the GPL.
> 
> Unquote.
> 
> 
> 
> _______________________________________________
> wsjt-devel mailing list
> wsj...@li...
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Licensing Issue of SuperFox Mode

[Christoph B. <my...@de...>]

Re: Joe Taylor via wsjt-devel
> WSJT-X is a complete and independent program.  Its full source code is
> available to anyone.  One of its many operating modes makes use of short,
> uncomplicated exchanges with three independent programs that are licensed
> separately and made freely available for Amateur Radio use. These separate,
> stand-alone executable programs are not open source.

What is the license of the extra superfox binaries? I'd assume they
are freely distributable, but is that written down somewhere?

If we wanted to include the superfox binaries in the non-free section
in Debian, we would at least need the statement that they are freely
distributable.

Joe, could you ack that?

Thanks,
Christoph DF7CB

Re: [wsjt-devel] Licensing Issue of SuperFox Mode

[Fons A. <fo...@li...>]

On Fri, Jul 19, 2024 at 03:07:34PM -0400, Joe Taylor via wsjt-devel wrote:
 
> The following text is from "Frequently Asked Questions about the GNU
> Licenses", https://www.gnu.org/licenses/gpl-faq.html :
> 
> "[P]ipes, sockets and command-line arguments are communication mechanisms
> normally used between two separate programs... [W]hen they are used for
> communication, the modules normally are [considered] separate programs."

That certainly makes sense if there is a clear separation of
functionality or if that functionality is entirely optional,
e.g. logging or visualisation.

The text you quoted continues:

  "But if the semantics of the communication are intimate enough,
  exchanging complex internal data structures, that too could be
  a basis to consider the two parts as combined into a larger
  program."

In this case the three closed source programs perform what 
could be considered 'core' functionality: encoding/modulation
and demodulation/decoding of the superfox waveform.

If that is acceptable, then the whole DSP part of WSJTX could be
delegated to some closed source binaries, leaving only the user
interface. Would you call such a WSJTX still 'open source' ?
If not, then where is the dividing line ?

IMHO at least the waveform should be fully documented, allowing
others to create their own implementation of the closed source
programs. And I wonder what are the legal aspects of using an
undocumented waveform on the HAM bands.

If the secrecy is there only to protect the fox callsign
authentication, then it will be just a matter of time before
we'll see another example of why 'security by obscurity' is
a bad idea. The amount of data that can be squeezed into a
fox message seems to be way too small for any really secure
cryptographic scheme. So this will be a very juicy target
for anyone who enjoys cracking such things. That includes
me :-) At least that would be an 'educational' side of
superfox...

Just my 2 Eurocents of course.

Ciao,

-- 
FA

Re: [wsjt-devel] Licensing Issue of SuperFox Mode

[OG55W <og...@oh...>]

Hello Mr. Ciao !
PSE use Your call sign with the sign of Your Messages!

73 Keijo OG5O


Fons Adriaensen via wsjt-devel kirjoitti 20.7.2024 klo 13.56:
> On Fri, Jul 19, 2024 at 03:07:34PM -0400, Joe Taylor via wsjt-devel wrote:
>   
>> The following text is from "Frequently Asked Questions about the GNU
>> Licenses", https://www.gnu.org/licenses/gpl-faq.html :
>>
>> "[P]ipes, sockets and command-line arguments are communication mechanisms
>> normally used between two separate programs... [W]hen they are used for
>> communication, the modules normally are [considered] separate programs."
> That certainly makes sense if there is a clear separation of
> functionality or if that functionality is entirely optional,
> e.g. logging or visualisation.
>
> The text you quoted continues:
>
>    "But if the semantics of the communication are intimate enough,
>    exchanging complex internal data structures, that too could be
>    a basis to consider the two parts as combined into a larger
>    program."
>
> In this case the three closed source programs perform what
> could be considered 'core' functionality: encoding/modulation
> and demodulation/decoding of the superfox waveform.
>
> If that is acceptable, then the whole DSP part of WSJTX could be
> delegated to some closed source binaries, leaving only the user
> interface. Would you call such a WSJTX still 'open source' ?
> If not, then where is the dividing line ?
>
> IMHO at least the waveform should be fully documented, allowing
> others to create their own implementation of the closed source
> programs. And I wonder what are the legal aspects of using an
> undocumented waveform on the HAM bands.
>
> If the secrecy is there only to protect the fox callsign
> authentication, then it will be just a matter of time before
> we'll see another example of why 'security by obscurity' is
> a bad idea. The amount of data that can be squeezed into a
> fox message seems to be way too small for any really secure
> cryptographic scheme. So this will be a very juicy target
> for anyone who enjoys cracking such things. That includes
> me :-) At least that would be an 'educational' side of
> superfox...
>
> Just my 2 Eurocents of course.
>
> Ciao,
>

Re: [wsjt-devel] Licensing Issue of SuperFox Mode

[Jakob K. D. <dd...@da...>]

Hello Joe,


> WSJT-X is a complete and independent program.  Its full source code is
> available to anyone.  One of its many operating modes makes use of
> short, uncomplicated exchanges with three independent programs that are
> licensed separately and made freely available for Amateur Radio use.
> These separate, stand-alone executable programs are not open source.


I am kind of confused by this statement. There has been a number of
requests on this mailing list to split the WSJT-X frontend and make the
actual decoders available as a library, but they have all been turned down.
But when it comes to licensing, all of a sudden, I'm supposed to see these
as separate parts. I would like to say that in the future, you should take
better care to distinguish which parts your software consists of. I'm
pretty sure that most users will see WSJT-X as a single package (it's a
single download, and they only get to see the one user interfaces).

I'd also like to point that your answer is not really taking all aspects
into account, the actual fallout of your decisions is bigger, and I'd say
you should definitely take action right now.

The problem is that on your website, you're currently offering binary
packages of WSJT-X (the overall package, not just the frontend), which
contain:
a) A copy of the superfox binaries
b) A copy of the GPL
c) A copyright declaration that states that "everything" is covered by the
GPL.

Just in case you're in doubt about the latter, this is the contents of the
copyright declaration included in the WSJT-X 2.7.0-rc6 Debian package,
downloaded 15 minutes ago:

Format: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
> Upstream-Name: wsjtx
> Upstream-Contact: Joe Taylor <k1...@ar...>
> Source: https://wsjt.sourceforge.io/wsjtx.html


> Files: *
> Copyright: Copyright (C) 2001-2024 by Joe Taylor, K1JT.
> License: GPL-3+
>  On Debian systems, the full text of the GNU General Public
>  License version 3 can be found in the file
>  `/usr/share/common-licenses/GPL-3'.


That is a the full extent of that file.

Since you do not intent to publish the source code of the superfox
binaries, I'd say that this is a clear violation of the GPL.

So as far as I can see, you should take the following actions as soon as
possible:

a) Find a license under which you can distribute the superfox binaries.
(Strictly speaking, this is optional, but if you don't copyright defaults
kick in, which may have further unwanted consequences)
b) Include that license with your binary distributions.
c) Make it clear which license applies to what files.

73s
Jakob DD5JFK

PS: In case you're wondering why I'm suggesting a certain urgency to take
action, consider this: I'm making these suggestions in an attempt resolve
these problems in your favor. If I were to take a different perspective, I
could also demand the release of the superfox sources given that you are
circulating binary distributions that claim those binaries are released
under GPL.



On Fri, Jul 19, 2024 at 9:07 PM Joe Taylor via wsjt-devel <
wsj...@li...> wrote:

> Dear Kenji-san,
>
> Thank you for your interest in WSJT-X.  We do not believe the license
> terms for WSJT-X 2.7.0-RC5 and later are self-contradictory.
>
> WSJT-X is a complete and independent program.  Its full source code is
> available to anyone.  One of its many operating modes makes use of
> short, uncomplicated exchanges with three independent programs that are
> licensed separately and made freely available for Amateur Radio use.
> These separate, stand-alone executable programs are not open source.
>
> The following text is from "Frequently Asked Questions about the GNU
> Licenses", https://www.gnu.org/licenses/gpl-faq.html :
>
> "[P]ipes, sockets and command-line arguments are communication
> mechanisms normally used between two separate programs... [W]hen they
> are used for communication, the modules normally are [considered]
> separate programs."
>
>         -- 73, Joe, K1JT
>
> On 7/19/2024 10:22 AM, Kenji Rikitake JJ1BDX via wsjt-devel wrote:
> > I do appreciate all the efforts poured into the SuperFox Mode.
> >
> > Writing that, I'd like to state one thing:
> >
> > The current WSJT-X (2.7.0-RC5 and later) has a self-contradictory license
> > and that should be fixed ASAP.
> >
> > GPLv3 requires ALL binary code must be able to be produced/built
> > from the distributed source code [1].
> > Currently, the SuperFox binaries, namely foxchk/sftx/sfrx are
> > unable to be built from the source code distributed as a part of WSJT-X.
> > This means the current state as of the 2.7.0-RC6 self-contradicts
> > with the license being claimed.
> > I would like this situation to be fixed ASAP.
> >
> > There are a few possible ways to fix this situation:
> > by changing the license to allow the proprietary binaries,
> > or separating the proprietary part (namely SuperFox Mode binaries),
> > or making the source code of SuperFox Mode available with the package.
> > There might even be another way that doesn't come up to my mind.
> >
> > I do not want to start a bikeshed discussion of licensing.
> > I simply would like the developers of WSJT-X to take this situation
> > seriously and propose a practical solution.
> >
> > I hope WSJT-X would remain fully open-sources as it had been.
> >
> > 73
> > Kenji Rikitake, JJ1BDX
> >
> > [1]: https://www.gnu.org/licenses/gpl-faq.html#DistributeExtendedBinary
> > <https://www.gnu.org/licenses/gpl-faq.html#DistributeExtendedBinary>
> >
> > Quote:
> >
> >  > I want to distribute an extended version of a GPL-covered program in
> > binary form. Is it enough to distribute the source for the original
> version?
> >
> >  > No, you must supply the source code that corresponds to the binary.
> > Corresponding source means the source from which users can rebuild the
> > same binary.
> >
> > Part of the idea of free software is that users should have access to
> > the source code for *the programs they use*. Those using your version
> > should have access to the source code for your version.
> >
> > A major goal of the GPL is to build up the Free World by making sure
> > that improvement to a free program are themselves free. If you release
> > an improved version of a GPL-covered program, you must release the
> > improved source code under the GPL.
> >
> > Unquote.
> >
> >
> >
> > _______________________________________________
> > wsjt-devel mailing list
> > wsj...@li...
> > https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
>
> _______________________________________________
> wsjt-devel mailing list
> wsj...@li...
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
>

Re: [wsjt-devel] Licensing Issue of SuperFox Mode

[Christoph B. <my...@de...>]

Re: Jakob Ketterl DD5JFK via wsjt-devel
> Just in case you're in doubt about the latter, this is the contents of the
> copyright declaration included in the WSJT-X 2.7.0-rc6 Debian package,
> downloaded 15 minutes ago:

The rc6 package I uploaded to Debian unstable some hours ago has the
sfrx/tx binaries stripped so it's pure GPL again. But of course, then
superfox operation doesn't work until you manually download the
helpers and copy them into /usr/bin.

Christoph

Re: [wsjt-devel] Licensing Issue of SuperFox Mode

[Jakob K. D. <dd...@da...>]

Christoph, I apologize for not being clear enough about this. I was
referring to the ".deb" files available from the WSJT-X pages on
sourceforge.

On Sat, Jul 20, 2024 at 4:40 PM Christoph Berg via wsjt-devel <
wsj...@li...> wrote:

> Re: Jakob Ketterl DD5JFK via wsjt-devel
> > Just in case you're in doubt about the latter, this is the contents of
> the
> > copyright declaration included in the WSJT-X 2.7.0-rc6 Debian package,
> > downloaded 15 minutes ago:
>
> The rc6 package I uploaded to Debian unstable some hours ago has the
> sfrx/tx binaries stripped so it's pure GPL again. But of course, then
> superfox operation doesn't work until you manually download the
> helpers and copy them into /usr/bin.
>
> Christoph
>
>
> _______________________________________________
> wsjt-devel mailing list
> wsj...@li...
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
>

Re: [wsjt-devel] Licensing Issue of SuperFox Mode

[Neil Z. <ne...@te...>]

May I refer you to the gnu.org FAQs on GPL programs using proprietary
libraries:

https://www.gnu.org/licenses/gpl-faq.html#SystemLibraryException


It says:


Can I link a GPL program with a proprietary system library?
(#SystemLibraryException
<https://www.gnu.org/licenses/gpl-faq.html#SystemLibraryException>)

    Both versions of the GPL have an exception to their copyleft,
    commonly called the system library exception. If the
    GPL-incompatible libraries you want to use meet the criteria for a
    system library, then you don't have to do anything special to use
    them; the requirement to distribute source code for the whole
    program does not include those libraries, even if you distribute a
    linked executable containing them.

    The criteria for what counts as a “system library” vary between
    different versions of the GPL. GPLv3 explicitly defines “System
    Libraries” in section 1, to exclude it from the definition of
    “Corresponding Source.” GPLv2 deals with this issue slightly
    differently, near the end of section 3.



Neil, KN3ILZ

On 7/20/2024 8:24 AM, Jakob Ketterl DD5JFK wrote:
> Hello Joe,
>
>     WSJT-X is a complete and independent program.  Its full source code is
>     available to anyone.  One of its many operating modes makes use of
>     short, uncomplicated exchanges with three independent programs
>     that are
>     licensed separately and made freely available for Amateur Radio use.
>     These separate, stand-alone executable programs are not open source.
>
>
> I am kind of confused by this statement. There has been a number of
> requests on this mailing list to split the WSJT-X frontend and make
> the actual decoders available as a library, but they have all been
> turned down. But when it comes to licensing, all of a sudden, I'm
> supposed to see these as separate parts. I would like to say that in
> the future, you should take better care to distinguish which parts
> your software consists of. I'm pretty sure that most users will see
> WSJT-X as a single package (it's a single download, and they only get
> to see the one user interfaces).
>
> I'd also like to point that your answer is not really taking all
> aspects into account, the actual fallout of your decisions is bigger,
> and I'd say you should definitely take action right now.
>
> The problem is that on your website, you're currently offering binary
> packages of WSJT-X (the overall package, not just the frontend), which
> contain:
> a) A copy of the superfox binaries
> b) A copy of the GPL
> c) A copyright declaration that states that "everything" is covered by
> the GPL.
>
> Just in case you're in doubt about the latter, this is the contents of
> the copyright declaration included in the WSJT-X 2.7.0-rc6 Debian
> package, downloaded 15 minutes ago:
>
>     Format:
>     https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
>     Upstream-Name: wsjtx
>     Upstream-Contact: Joe Taylor <k1...@ar...>
>     Source: https://wsjt.sourceforge.io/wsjtx.html
>
>
>     Files: *
>     Copyright: Copyright (C) 2001-2024 by Joe Taylor, K1JT.
>     License: GPL-3+
>      On Debian systems, the full text of the GNU General Public
>      License version 3 can be found in the file
>      `/usr/share/common-licenses/GPL-3'.
>
>
> That is a the full extent of that file.
>
> Since you do not intent to publish the source code of the superfox
> binaries, I'd say that this is a clear violation of the GPL.
>
> So as far as I can see, you should take the following actions as soon
> as possible:
>
> a) Find a license under which you can distribute the superfox
> binaries. (Strictly speaking, this is optional, but if you don't
> copyright defaults kick in, which may have further unwanted consequences)
> b) Include that license with your binary distributions.
> c) Make it clear which license applies to what files.
>
> 73s
> Jakob DD5JFK
>
> PS: In case you're wondering why I'm suggesting a certain urgency to
> take action, consider this: I'm making these suggestions in an attempt
> resolve these problems in your favor. If I were to take a different
> perspective, I could also demand the release of the superfox sources
> given that you are circulating binary distributions that claim those
> binaries are released under GPL.
>
>
>
> On Fri, Jul 19, 2024 at 9:07 PM Joe Taylor via wsjt-devel
> <wsj...@li...> wrote:
>
>     Dear Kenji-san,
>
>     Thank you for your interest in WSJT-X.  We do not believe the license
>     terms for WSJT-X 2.7.0-RC5 and later are self-contradictory.
>
>     WSJT-X is a complete and independent program.  Its full source
>     code is
>     available to anyone.  One of its many operating modes makes use of
>     short, uncomplicated exchanges with three independent programs
>     that are
>     licensed separately and made freely available for Amateur Radio use.
>     These separate, stand-alone executable programs are not open source.
>
>     The following text is from "Frequently Asked Questions about the GNU
>     Licenses", https://www.gnu.org/licenses/gpl-faq.html :
>
>     "[P]ipes, sockets and command-line arguments are communication
>     mechanisms normally used between two separate programs... [W]hen they
>     are used for communication, the modules normally are [considered]
>     separate programs."
>
>             -- 73, Joe, K1JT
>
>     On 7/19/2024 10:22 AM, Kenji Rikitake JJ1BDX via wsjt-devel wrote:
>     > I do appreciate all the efforts poured into the SuperFox Mode.
>     >
>     > Writing that, I'd like to state one thing:
>     >
>     > The current WSJT-X (2.7.0-RC5 and later) has a
>     self-contradictory license
>     > and that should be fixed ASAP.
>     >
>     > GPLv3 requires ALL binary code must be able to be produced/built
>     > from the distributed source code [1].
>     > Currently, the SuperFox binaries, namely foxchk/sftx/sfrx are
>     > unable to be built from the source code distributed as a part of
>     WSJT-X.
>     > This means the current state as of the 2.7.0-RC6 self-contradicts
>     > with the license being claimed.
>     > I would like this situation to be fixed ASAP.
>     >
>     > There are a few possible ways to fix this situation:
>     > by changing the license to allow the proprietary binaries,
>     > or separating the proprietary part (namely SuperFox Mode binaries),
>     > or making the source code of SuperFox Mode available with the
>     package.
>     > There might even be another way that doesn't come up to my mind.
>     >
>     > I do not want to start a bikeshed discussion of licensing.
>     > I simply would like the developers of WSJT-X to take this situation
>     > seriously and propose a practical solution.
>     >
>     > I hope WSJT-X would remain fully open-sources as it had been.
>     >
>     > 73
>     > Kenji Rikitake, JJ1BDX
>     >
>     > [1]:
>     https://www.gnu.org/licenses/gpl-faq.html#DistributeExtendedBinary
>     > <https://www.gnu.org/licenses/gpl-faq.html#DistributeExtendedBinary>
>     >
>     > Quote:
>     >
>     >  > I want to distribute an extended version of a GPL-covered
>     program in
>     > binary form. Is it enough to distribute the source for the
>     original version?
>     >
>     >  > No, you must supply the source code that corresponds to the
>     binary.
>     > Corresponding source means the source from which users can
>     rebuild the
>     > same binary.
>     >
>     > Part of the idea of free software is that users should have
>     access to
>     > the source code for *the programs they use*. Those using your
>     version
>     > should have access to the source code for your version.
>     >
>     > A major goal of the GPL is to build up the Free World by making
>     sure
>     > that improvement to a free program are themselves free. If you
>     release
>     > an improved version of a GPL-covered program, you must release the
>     > improved source code under the GPL.
>     >
>     > Unquote.
>     >
>     >
>     >
>     > _______________________________________________
>     > wsjt-devel mailing list
>     > wsj...@li...
>     > https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
>
>     _______________________________________________
>     wsjt-devel mailing list
>     wsj...@li...
>     https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>

Re: [wsjt-devel] Licensing Issue of SuperFox Mode

[Jakob K. D. <dd...@da...>]

You may refer me there, but that doesn't change a thing. I am not talking
about linking issues. I am talking about the binary packages and their
contents, and not about how the binaries interact with each other.

The fact that the binary packages contain closed-source binaries while at
the same time claiming that all contents of the package are licensed under
GPL is a problem, no matter how the individual components interact with
each other. In fact, it would still be a problem even if they did not
interact with each other at all.

On Sat, Jul 20, 2024 at 8:45 PM Neil Zampella via wsjt-devel <
wsj...@li...> wrote:

> May I refer you to the gnu.org FAQs on GPL programs using proprietary
> libraries:
>
> https://www.gnu.org/licenses/gpl-faq.html#SystemLibraryException
>
>
> It says:
>
>
> Can I link a GPL program with a proprietary system library? (
> #SystemLibraryException
> <https://www.gnu.org/licenses/gpl-faq.html#SystemLibraryException>)
>
> Both versions of the GPL have an exception to their copyleft, commonly
> called the system library exception. If the GPL-incompatible libraries you
> want to use meet the criteria for a system library, then you don't have to
> do anything special to use them; the requirement to distribute source code
> for the whole program does not include those libraries, even if you
> distribute a linked executable containing them.
>
> The criteria for what counts as a “system library” vary between different
> versions of the GPL. GPLv3 explicitly defines “System Libraries” in section
> 1, to exclude it from the definition of “Corresponding Source.” GPLv2 deals
> with this issue slightly differently, near the end of section 3.
>
>
> Neil, KN3ILZ
> On 7/20/2024 8:24 AM, Jakob Ketterl DD5JFK wrote:
>
> Hello Joe,
>
>
>> WSJT-X is a complete and independent program.  Its full source code is
>> available to anyone.  One of its many operating modes makes use of
>> short, uncomplicated exchanges with three independent programs that are
>> licensed separately and made freely available for Amateur Radio use.
>> These separate, stand-alone executable programs are not open source.
>
>
> I am kind of confused by this statement. There has been a number of
> requests on this mailing list to split the WSJT-X frontend and make the
> actual decoders available as a library, but they have all been turned down.
> But when it comes to licensing, all of a sudden, I'm supposed to see these
> as separate parts. I would like to say that in the future, you should take
> better care to distinguish which parts your software consists of. I'm
> pretty sure that most users will see WSJT-X as a single package (it's a
> single download, and they only get to see the one user interfaces).
>
> I'd also like to point that your answer is not really taking all aspects
> into account, the actual fallout of your decisions is bigger, and I'd say
> you should definitely take action right now.
>
> The problem is that on your website, you're currently offering binary
> packages of WSJT-X (the overall package, not just the frontend), which
> contain:
> a) A copy of the superfox binaries
> b) A copy of the GPL
> c) A copyright declaration that states that "everything" is covered by the
> GPL.
>
> Just in case you're in doubt about the latter, this is the contents of the
> copyright declaration included in the WSJT-X 2.7.0-rc6 Debian package,
> downloaded 15 minutes ago:
>
> Format: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
>> Upstream-Name: wsjtx
>> Upstream-Contact: Joe Taylor <k1...@ar...>
>> Source: https://wsjt.sourceforge.io/wsjtx.html
>
>
>> Files: *
>> Copyright: Copyright (C) 2001-2024 by Joe Taylor, K1JT.
>> License: GPL-3+
>>  On Debian systems, the full text of the GNU General Public
>>  License version 3 can be found in the file
>>  `/usr/share/common-licenses/GPL-3'.
>
>
> That is a the full extent of that file.
>
> Since you do not intent to publish the source code of the superfox
> binaries, I'd say that this is a clear violation of the GPL.
>
> So as far as I can see, you should take the following actions as soon as
> possible:
>
> a) Find a license under which you can distribute the superfox binaries.
> (Strictly speaking, this is optional, but if you don't copyright defaults
> kick in, which may have further unwanted consequences)
> b) Include that license with your binary distributions.
> c) Make it clear which license applies to what files.
>
> 73s
> Jakob DD5JFK
>
> PS: In case you're wondering why I'm suggesting a certain urgency to take
> action, consider this: I'm making these suggestions in an attempt resolve
> these problems in your favor. If I were to take a different perspective, I
> could also demand the release of the superfox sources given that you are
> circulating binary distributions that claim those binaries are released
> under GPL.
>
>
>
> On Fri, Jul 19, 2024 at 9:07 PM Joe Taylor via wsjt-devel <
> wsj...@li...> wrote:
>
>> Dear Kenji-san,
>>
>> Thank you for your interest in WSJT-X.  We do not believe the license
>> terms for WSJT-X 2.7.0-RC5 and later are self-contradictory.
>>
>> WSJT-X is a complete and independent program.  Its full source code is
>> available to anyone.  One of its many operating modes makes use of
>> short, uncomplicated exchanges with three independent programs that are
>> licensed separately and made freely available for Amateur Radio use.
>> These separate, stand-alone executable programs are not open source.
>>
>> The following text is from "Frequently Asked Questions about the GNU
>> Licenses", https://www.gnu.org/licenses/gpl-faq.html :
>>
>> "[P]ipes, sockets and command-line arguments are communication
>> mechanisms normally used between two separate programs... [W]hen they
>> are used for communication, the modules normally are [considered]
>> separate programs."
>>
>>         -- 73, Joe, K1JT
>>
>> On 7/19/2024 10:22 AM, Kenji Rikitake JJ1BDX via wsjt-devel wrote:
>> > I do appreciate all the efforts poured into the SuperFox Mode.
>> >
>> > Writing that, I'd like to state one thing:
>> >
>> > The current WSJT-X (2.7.0-RC5 and later) has a self-contradictory
>> license
>> > and that should be fixed ASAP.
>> >
>> > GPLv3 requires ALL binary code must be able to be produced/built
>> > from the distributed source code [1].
>> > Currently, the SuperFox binaries, namely foxchk/sftx/sfrx are
>> > unable to be built from the source code distributed as a part of WSJT-X.
>> > This means the current state as of the 2.7.0-RC6 self-contradicts
>> > with the license being claimed.
>> > I would like this situation to be fixed ASAP.
>> >
>> > There are a few possible ways to fix this situation:
>> > by changing the license to allow the proprietary binaries,
>> > or separating the proprietary part (namely SuperFox Mode binaries),
>> > or making the source code of SuperFox Mode available with the package.
>> > There might even be another way that doesn't come up to my mind.
>> >
>> > I do not want to start a bikeshed discussion of licensing.
>> > I simply would like the developers of WSJT-X to take this situation
>> > seriously and propose a practical solution.
>> >
>> > I hope WSJT-X would remain fully open-sources as it had been.
>> >
>> > 73
>> > Kenji Rikitake, JJ1BDX
>> >
>> > [1]: https://www.gnu.org/licenses/gpl-faq.html#DistributeExtendedBinary
>> > <https://www.gnu.org/licenses/gpl-faq.html#DistributeExtendedBinary>
>> >
>> > Quote:
>> >
>> >  > I want to distribute an extended version of a GPL-covered program in
>> > binary form. Is it enough to distribute the source for the original
>> version?
>> >
>> >  > No, you must supply the source code that corresponds to the binary.
>> > Corresponding source means the source from which users can rebuild the
>> > same binary.
>> >
>> > Part of the idea of free software is that users should have access to
>> > the source code for *the programs they use*. Those using your version
>> > should have access to the source code for your version.
>> >
>> > A major goal of the GPL is to build up the Free World by making sure
>> > that improvement to a free program are themselves free. If you release
>> > an improved version of a GPL-covered program, you must release the
>> > improved source code under the GPL.
>> >
>> > Unquote.
>> >
>> >
>> >
>> > _______________________________________________
>> > wsjt-devel mailing list
>> > wsj...@li...
>> > https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>>
>>
>> _______________________________________________
>> wsjt-devel mailing list
>> wsj...@li...
>> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>>
>> _______________________________________________
> wsjt-devel mailing list
> wsj...@li...
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>

Re: [wsjt-devel] Licensing Issue of SuperFox Mode

[Neil Z. <ne...@te...>]

Evidently WSJT-X 2.7 will be connecting to the Superfox binary using
either pipes, sockets, or command-line arguments.    In essence, its a
separate, proprietary program being called by WSJT-X.   This is
perfectly permissible, under the GPL.   In this case,  they just need to
adjust the license to add an exception for the SFTX.exe program.

As the program is still in Beta, I am guessing they will have that
exception added to the license when they go GA.

Neil, KN3ILZ


On 7/20/2024 1:23 PM, Jakob Ketterl DD5JFK wrote:
> You may refer me there, but that doesn't change a thing. I am not
> talking about linking issues. I am talking about the binary packages
> and their contents, and not about how the binaries interact with each
> other.
>
> The fact that the binary packages contain closed-source binaries while
> at the same time claiming that all contents of the package are
> licensed under GPL is a problem, no matter how the individual
> components interact with each other. In fact, it would still be a
> problem even if they did not interact with each other at all.
>
> On Sat, Jul 20, 2024 at 8:45 PM Neil Zampella via wsjt-devel
> <wsj...@li...> wrote:
>
>     May I refer you to the gnu.org <http://gnu.org> FAQs on GPL
>     programs using proprietary libraries:
>
>     https://www.gnu.org/licenses/gpl-faq.html#SystemLibraryException
>
>
>     It says:
>
>
>     Can I link a GPL program with a proprietary system library?
>     (#SystemLibraryException
>     <https://www.gnu.org/licenses/gpl-faq.html#SystemLibraryException>)
>
>         Both versions of the GPL have an exception to their copyleft,
>         commonly called the system library exception. If the
>         GPL-incompatible libraries you want to use meet the criteria
>         for a system library, then you don't have to do anything
>         special to use them; the requirement to distribute source code
>         for the whole program does not include those libraries, even
>         if you distribute a linked executable containing them.
>
>         The criteria for what counts as a “system library” vary
>         between different versions of the GPL. GPLv3 explicitly
>         defines “System Libraries” in section 1, to exclude it from
>         the definition of “Corresponding Source.” GPLv2 deals with
>         this issue slightly differently, near the end of section 3.
>
>
>
>     Neil, KN3ILZ
>
>     On 7/20/2024 8:24 AM, Jakob Ketterl DD5JFK wrote:
>>     Hello Joe,
>>
>>         WSJT-X is a complete and independent program.  Its full
>>         source code is
>>         available to anyone.  One of its many operating modes makes
>>         use of
>>         short, uncomplicated exchanges with three independent
>>         programs that are
>>         licensed separately and made freely available for Amateur
>>         Radio use.
>>         These separate, stand-alone executable programs are not open
>>         source.
>>
>>
>>     I am kind of confused by this statement. There has been a number
>>     of requests on this mailing list to split the WSJT-X frontend and
>>     make the actual decoders available as a library, but they have
>>     all been turned down. But when it comes to licensing, all of a
>>     sudden, I'm supposed to see these as separate parts. I would like
>>     to say that in the future, you should take better care to
>>     distinguish which parts your software consists of. I'm pretty
>>     sure that most users will see WSJT-X as a single package (it's a
>>     single download, and they only get to see the one user interfaces).
>>
>>     I'd also like to point that your answer is not really taking all
>>     aspects into account, the actual fallout of your decisions is
>>     bigger, and I'd say you should definitely take action right now.
>>
>>     The problem is that on your website, you're currently offering
>>     binary packages of WSJT-X (the overall package, not just the
>>     frontend), which contain:
>>     a) A copy of the superfox binaries
>>     b) A copy of the GPL
>>     c) A copyright declaration that states that "everything" is
>>     covered by the GPL.
>>
>>     Just in case you're in doubt about the latter, this is the
>>     contents of the copyright declaration included in the WSJT-X
>>     2.7.0-rc6 Debian package, downloaded 15 minutes ago:
>>
>>         Format:
>>         https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
>>         Upstream-Name: wsjtx
>>         Upstream-Contact: Joe Taylor <k1...@ar...>
>>         Source: https://wsjt.sourceforge.io/wsjtx.html
>>
>>
>>         Files: *
>>         Copyright: Copyright (C) 2001-2024 by Joe Taylor, K1JT.
>>         License: GPL-3+
>>          On Debian systems, the full text of the GNU General Public
>>          License version 3 can be found in the file
>>          `/usr/share/common-licenses/GPL-3'.
>>
>>
>>     That is a the full extent of that file.
>>
>>     Since you do not intent to publish the source code of the
>>     superfox binaries, I'd say that this is a clear violation of the GPL.
>>
>>     So as far as I can see, you should take the following actions as
>>     soon as possible:
>>
>>     a) Find a license under which you can distribute the superfox
>>     binaries. (Strictly speaking, this is optional, but if you don't
>>     copyright defaults kick in, which may have further unwanted
>>     consequences)
>>     b) Include that license with your binary distributions.
>>     c) Make it clear which license applies to what files.
>>
>>     73s
>>     Jakob DD5JFK
>>
>>     PS: In case you're wondering why I'm suggesting a certain urgency
>>     to take action, consider this: I'm making these suggestions in an
>>     attempt resolve these problems in your favor. If I were to take a
>>     different perspective, I could also demand the release of the
>>     superfox sources given that you are circulating binary
>>     distributions that claim those binaries are released under GPL.
>>
>>
>>
>>     On Fri, Jul 19, 2024 at 9:07 PM Joe Taylor via wsjt-devel
>>     <wsj...@li...> wrote:
>>
>>         Dear Kenji-san,
>>
>>         Thank you for your interest in WSJT-X.  We do not believe the
>>         license
>>         terms for WSJT-X 2.7.0-RC5 and later are self-contradictory.
>>
>>         WSJT-X is a complete and independent program.  Its full
>>         source code is
>>         available to anyone.  One of its many operating modes makes
>>         use of
>>         short, uncomplicated exchanges with three independent
>>         programs that are
>>         licensed separately and made freely available for Amateur
>>         Radio use.
>>         These separate, stand-alone executable programs are not open
>>         source.
>>
>>         The following text is from "Frequently Asked Questions about
>>         the GNU
>>         Licenses", https://www.gnu.org/licenses/gpl-faq.html :
>>
>>         "[P]ipes, sockets and command-line arguments are communication
>>         mechanisms normally used between two separate programs...
>>         [W]hen they
>>         are used for communication, the modules normally are
>>         [considered]
>>         separate programs."
>>
>>                 -- 73, Joe, K1JT
>>
>>         On 7/19/2024 10:22 AM, Kenji Rikitake JJ1BDX via wsjt-devel
>>         wrote:
>>         > I do appreciate all the efforts poured into the SuperFox Mode.
>>         >
>>         > Writing that, I'd like to state one thing:
>>         >
>>         > The current WSJT-X (2.7.0-RC5 and later) has a
>>         self-contradictory license
>>         > and that should be fixed ASAP.
>>         >
>>         > GPLv3 requires ALL binary code must be able to be
>>         produced/built
>>         > from the distributed source code [1].
>>         > Currently, the SuperFox binaries, namely foxchk/sftx/sfrx are
>>         > unable to be built from the source code distributed as a
>>         part of WSJT-X.
>>         > This means the current state as of the 2.7.0-RC6
>>         self-contradicts
>>         > with the license being claimed.
>>         > I would like this situation to be fixed ASAP.
>>         >
>>         > There are a few possible ways to fix this situation:
>>         > by changing the license to allow the proprietary binaries,
>>         > or separating the proprietary part (namely SuperFox Mode
>>         binaries),
>>         > or making the source code of SuperFox Mode available with
>>         the package.
>>         > There might even be another way that doesn't come up to my
>>         mind.
>>         >
>>         > I do not want to start a bikeshed discussion of licensing.
>>         > I simply would like the developers of WSJT-X to take this
>>         situation
>>         > seriously and propose a practical solution.
>>         >
>>         > I hope WSJT-X would remain fully open-sources as it had been.
>>         >
>>         > 73
>>         > Kenji Rikitake, JJ1BDX
>>         >
>>         > [1]:
>>         https://www.gnu.org/licenses/gpl-faq.html#DistributeExtendedBinary
>>
>>         >
>>         <https://www.gnu.org/licenses/gpl-faq.html#DistributeExtendedBinary>
>>         >
>>         > Quote:
>>         >
>>         >  > I want to distribute an extended version of a
>>         GPL-covered program in
>>         > binary form. Is it enough to distribute the source for the
>>         original version?
>>         >
>>         >  > No, you must supply the source code that corresponds to
>>         the binary.
>>         > Corresponding source means the source from which users can
>>         rebuild the
>>         > same binary.
>>         >
>>         > Part of the idea of free software is that users should have
>>         access to
>>         > the source code for *the programs they use*. Those using
>>         your version
>>         > should have access to the source code for your version.
>>         >
>>         > A major goal of the GPL is to build up the Free World by
>>         making sure
>>         > that improvement to a free program are themselves free. If
>>         you release
>>         > an improved version of a GPL-covered program, you must
>>         release the
>>         > improved source code under the GPL.
>>         >
>>         > Unquote.
>>         >
>>         >
>>         >
>>         > _______________________________________________
>>         > wsjt-devel mailing list
>>         > wsj...@li...
>>         > https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>>
>>
>>         _______________________________________________
>>         wsjt-devel mailing list
>>         wsj...@li...
>>         https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>>
>     _______________________________________________
>     wsjt-devel mailing list
>     wsj...@li...
>     https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>

Re: [wsjt-devel] Licensing Issue of SuperFox Mode

[Jakob K. D. <dd...@da...>]

I'd say that even that part is very much debatable. I haven't checked the
integration for the superfox mode, but for the older modes (FT8, FT4 etc.)
the integration uses command line arguments, together with shared memory
segments. Note that there is not mention of the latter in the FAQ. The data
structure used to exchange data aren't really documented anywhere (at least
not to my knowledge), and the headers that contain their declaration are
part of the private API of WSJT-X. That means they are not installed or
made available to other software. Of course you could get that information
from the source code, but I'd say the question is more that of what the
intentions were.

There's currently no documentation on how to use the "standalone" superfox
binaries. They don't have a "--help" usage text yet, nor do they have a
manpage. So I'd say at this point they don't serve any other purpose than
to decode within the context of WSJT-X, and I am having a hard time
considering them "standalone". Of course I could go into the source code
and start reverse engineering, but when we're discussing the licensing
that's not a path to consider.

I sure hope that the developers will start catching up here.

On Sun, Jul 21, 2024 at 1:33 AM Neil Zampella <ne...@te...> wrote:

> Evidently WSJT-X 2.7 will be connecting to the Superfox binary using
> either pipes, sockets, or command-line arguments.    In essence, its a
> separate, proprietary program being called by WSJT-X.   This is perfectly
> permissible, under the GPL.   In this case,  they just need to adjust the
> license to add an exception for the SFTX.exe program.
>
> As the program is still in Beta, I am guessing they will have that
> exception added to the license when they go GA.
>
> Neil, KN3ILZ
>
>
> On 7/20/2024 1:23 PM, Jakob Ketterl DD5JFK wrote:
>
> You may refer me there, but that doesn't change a thing. I am not talking
> about linking issues. I am talking about the binary packages and their
> contents, and not about how the binaries interact with each other.
>
> The fact that the binary packages contain closed-source binaries while at
> the same time claiming that all contents of the package are licensed under
> GPL is a problem, no matter how the individual components interact with
> each other. In fact, it would still be a problem even if they did not
> interact with each other at all.
>
> On Sat, Jul 20, 2024 at 8:45 PM Neil Zampella via wsjt-devel <
> wsj...@li...> wrote:
>
>> May I refer you to the gnu.org FAQs on GPL programs using proprietary
>> libraries:
>>
>> https://www.gnu.org/licenses/gpl-faq.html#SystemLibraryException
>>
>>
>> It says:
>>
>>
>> Can I link a GPL program with a proprietary system library? (
>> #SystemLibraryException
>> <https://www.gnu.org/licenses/gpl-faq.html#SystemLibraryException>)
>>
>> Both versions of the GPL have an exception to their copyleft, commonly
>> called the system library exception. If the GPL-incompatible libraries you
>> want to use meet the criteria for a system library, then you don't have to
>> do anything special to use them; the requirement to distribute source code
>> for the whole program does not include those libraries, even if you
>> distribute a linked executable containing them.
>>
>> The criteria for what counts as a “system library” vary between different
>> versions of the GPL. GPLv3 explicitly defines “System Libraries” in section
>> 1, to exclude it from the definition of “Corresponding Source.” GPLv2 deals
>> with this issue slightly differently, near the end of section 3.
>>
>>
>> Neil, KN3ILZ
>> On 7/20/2024 8:24 AM, Jakob Ketterl DD5JFK wrote:
>>
>> Hello Joe,
>>
>>
>>> WSJT-X is a complete and independent program.  Its full source code is
>>> available to anyone.  One of its many operating modes makes use of
>>> short, uncomplicated exchanges with three independent programs that are
>>> licensed separately and made freely available for Amateur Radio use.
>>> These separate, stand-alone executable programs are not open source.
>>
>>
>> I am kind of confused by this statement. There has been a number of
>> requests on this mailing list to split the WSJT-X frontend and make the
>> actual decoders available as a library, but they have all been turned down.
>> But when it comes to licensing, all of a sudden, I'm supposed to see these
>> as separate parts. I would like to say that in the future, you should take
>> better care to distinguish which parts your software consists of. I'm
>> pretty sure that most users will see WSJT-X as a single package (it's a
>> single download, and they only get to see the one user interfaces).
>>
>> I'd also like to point that your answer is not really taking all aspects
>> into account, the actual fallout of your decisions is bigger, and I'd say
>> you should definitely take action right now.
>>
>> The problem is that on your website, you're currently offering binary
>> packages of WSJT-X (the overall package, not just the frontend), which
>> contain:
>> a) A copy of the superfox binaries
>> b) A copy of the GPL
>> c) A copyright declaration that states that "everything" is covered by
>> the GPL.
>>
>> Just in case you're in doubt about the latter, this is the contents of
>> the copyright declaration included in the WSJT-X 2.7.0-rc6 Debian package,
>> downloaded 15 minutes ago:
>>
>> Format:
>>> https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
>>> Upstream-Name: wsjtx
>>> Upstream-Contact: Joe Taylor <k1...@ar...>
>>> Source: https://wsjt.sourceforge.io/wsjtx.html
>>
>>
>>> Files: *
>>> Copyright: Copyright (C) 2001-2024 by Joe Taylor, K1JT.
>>> License: GPL-3+
>>>  On Debian systems, the full text of the GNU General Public
>>>  License version 3 can be found in the file
>>>  `/usr/share/common-licenses/GPL-3'.
>>
>>
>> That is a the full extent of that file.
>>
>> Since you do not intent to publish the source code of the superfox
>> binaries, I'd say that this is a clear violation of the GPL.
>>
>> So as far as I can see, you should take the following actions as soon as
>> possible:
>>
>> a) Find a license under which you can distribute the superfox binaries.
>> (Strictly speaking, this is optional, but if you don't copyright defaults
>> kick in, which may have further unwanted consequences)
>> b) Include that license with your binary distributions.
>> c) Make it clear which license applies to what files.
>>
>> 73s
>> Jakob DD5JFK
>>
>> PS: In case you're wondering why I'm suggesting a certain urgency to take
>> action, consider this: I'm making these suggestions in an attempt resolve
>> these problems in your favor. If I were to take a different perspective, I
>> could also demand the release of the superfox sources given that you are
>> circulating binary distributions that claim those binaries are released
>> under GPL.
>>
>>
>>
>> On Fri, Jul 19, 2024 at 9:07 PM Joe Taylor via wsjt-devel <
>> wsj...@li...> wrote:
>>
>>> Dear Kenji-san,
>>>
>>> Thank you for your interest in WSJT-X.  We do not believe the license
>>> terms for WSJT-X 2.7.0-RC5 and later are self-contradictory.
>>>
>>> WSJT-X is a complete and independent program.  Its full source code is
>>> available to anyone.  One of its many operating modes makes use of
>>> short, uncomplicated exchanges with three independent programs that are
>>> licensed separately and made freely available for Amateur Radio use.
>>> These separate, stand-alone executable programs are not open source.
>>>
>>> The following text is from "Frequently Asked Questions about the GNU
>>> Licenses", https://www.gnu.org/licenses/gpl-faq.html :
>>>
>>> "[P]ipes, sockets and command-line arguments are communication
>>> mechanisms normally used between two separate programs... [W]hen they
>>> are used for communication, the modules normally are [considered]
>>> separate programs."
>>>
>>>         -- 73, Joe, K1JT
>>>
>>> On 7/19/2024 10:22 AM, Kenji Rikitake JJ1BDX via wsjt-devel wrote:
>>> > I do appreciate all the efforts poured into the SuperFox Mode.
>>> >
>>> > Writing that, I'd like to state one thing:
>>> >
>>> > The current WSJT-X (2.7.0-RC5 and later) has a self-contradictory
>>> license
>>> > and that should be fixed ASAP.
>>> >
>>> > GPLv3 requires ALL binary code must be able to be produced/built
>>> > from the distributed source code [1].
>>> > Currently, the SuperFox binaries, namely foxchk/sftx/sfrx are
>>> > unable to be built from the source code distributed as a part of
>>> WSJT-X.
>>> > This means the current state as of the 2.7.0-RC6 self-contradicts
>>> > with the license being claimed.
>>> > I would like this situation to be fixed ASAP.
>>> >
>>> > There are a few possible ways to fix this situation:
>>> > by changing the license to allow the proprietary binaries,
>>> > or separating the proprietary part (namely SuperFox Mode binaries),
>>> > or making the source code of SuperFox Mode available with the package.
>>> > There might even be another way that doesn't come up to my mind.
>>> >
>>> > I do not want to start a bikeshed discussion of licensing.
>>> > I simply would like the developers of WSJT-X to take this situation
>>> > seriously and propose a practical solution.
>>> >
>>> > I hope WSJT-X would remain fully open-sources as it had been.
>>> >
>>> > 73
>>> > Kenji Rikitake, JJ1BDX
>>> >
>>> > [1]:
>>> https://www.gnu.org/licenses/gpl-faq.html#DistributeExtendedBinary
>>> > <https://www.gnu.org/licenses/gpl-faq.html#DistributeExtendedBinary>
>>> >
>>> > Quote:
>>> >
>>> >  > I want to distribute an extended version of a GPL-covered program
>>> in
>>> > binary form. Is it enough to distribute the source for the original
>>> version?
>>> >
>>> >  > No, you must supply the source code that corresponds to the binary.
>>> > Corresponding source means the source from which users can rebuild the
>>> > same binary.
>>> >
>>> > Part of the idea of free software is that users should have access to
>>> > the source code for *the programs they use*. Those using your version
>>> > should have access to the source code for your version.
>>> >
>>> > A major goal of the GPL is to build up the Free World by making sure
>>> > that improvement to a free program are themselves free. If you release
>>> > an improved version of a GPL-covered program, you must release the
>>> > improved source code under the GPL.
>>> >
>>> > Unquote.
>>> >
>>> >
>>> >
>>> > _______________________________________________
>>> > wsjt-devel mailing list
>>> > wsj...@li...
>>> > https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>>>
>>>
>>> _______________________________________________
>>> wsjt-devel mailing list
>>> wsj...@li...
>>> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>>>
>>> _______________________________________________
>> wsjt-devel mailing list
>> wsj...@li...
>> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>>
>

Re: [wsjt-devel] Licensing Issue of SuperFox Mode

[Joe T. <jo...@pr...>]

Hi Jakob,

On 7/21/2024 9:13 AM, Jakob Ketterl DD5JFK via wsjt-devel wrote:
> There's currently no documentation on how to use the "standalone" 
> superfox binaries. They don't have a "--help" usage text yet, nor do 
> they have a manpage. So I'd say at this point they don't serve any other 
> purpose than to decode within the context of WSJT-X, and I am having a 
> hard time considering them "standalone". 
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.

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.

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.

	-- 73, Joe, K1JT

Re: [wsjt-devel] Licensing Issue of SuperFox Mode

[Jakob K. D. <dd...@da...>]

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

Re: [wsjt-devel] Licensing Issue of SuperFox Mode

[Hibby <hi...@de...>]

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
> wsj...@li...
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
> 

Re: [wsjt-devel] Licensing Issue of SuperFox Mode

[Neil Z. <ne...@te...>]

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
>> wsj...@li...
>> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>>
>

Re: [wsjt-devel] Licensing Issue of SuperFox Mode

[Hibby <hi...@de...>]

Hey Neil,

Don't worry - bubble not burst. I'm choosing to not pick a fight about the specific licensing of the binaries. Arguments about licensing are full of opinions and not very fun. They usually end up in flame wars and cold disagreement, as I think we can see from the previous discussion. I have expressed my opinions via other media as this is not the appropriate stage and people are welcome to disagree via those media.

Putting licensing aside and coming back to more solid facts and discussion of development - we can't include the binaries without the source in Debian (and secondly, we can't include them in debian-nonfree repo without explicit permission to redistribute them from Joe) - this has been said by another Debian maintainer on the list already. It is standard policy for Debian, part of our social contract and free software guidelines [1] that drive the OS.

This means that everyone who chooses to 'apt install wsjtx' or use an in built appstore from our package of rc5 onwards *doesn't* get superfox signing and doesn't get the protection from pirates the feature is meant to offer *unless* they are linux-capable enough to source the binaries for their platform and put them in the correct folder themselves. We can put in an interim solution of shipping something in the nonfree repo which myon asked earlier but didn't get a response to.

This flows down to users of Ubuntu, Mint, Raspberry Pi OS and other systems, which doesn't seem very fair. Also, as far as I'm aware the binaries don't support all of the architectures that we do, so it limits users from being able to play with weird and wonderful machines like risc-v!


[1] https://www.debian.org/social_contract

Cheers,
-- 
  Hibby
  Debian Developer
  Packet Radioist
  MM0RFN

On Wed, 24 Jul 2024, at 2:32 PM, Neil Zampella via wsjt-devel wrote:
> 
> 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
>>> wsj...@li...
>>> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>>> 
>> 
> 
> _______________________________________________
> wsjt-devel mailing list
> wsj...@li...
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
> 

Re: [wsjt-devel] Licensing Issue of SuperFox Mode

[Barry J. <zen...@ze...>]

On 24/07/2024 14:56, Hibby via wsjt-devel wrote:
> Hey Neil,
> 
> Don't worry - bubble not burst. I'm choosing to not pick a fight about 
> the specific licensing of the binaries. Arguments about licensing are 
> full of opinions and not very fun. They usually end up in flame wars and 
> cold disagreement, as I think we can see from the previous discussion. I 
> have expressed my opinions via other media as this is not the 
> appropriate stage and people are welcome to disagree via those media.
> 
> Putting licensing aside and coming back to more solid facts and 
> discussion of development - we can't include the binaries without the 
> source in Debian (and secondly, we can't include them in debian-nonfree 
> repo without explicit permission to redistribute them from Joe) - this 
> has been said by another Debian maintainer on the list already. It is 
> standard policy for Debian, part of our social contract and free 
> software guidelines [1] that drive the OS.
> 
> This means that everyone who chooses to 'apt install wsjtx' or use an in 
> built appstore from our package of rc5 onwards *doesn't* get superfox 
> signing and doesn't get the protection from pirates the feature is meant 
> to offer *unless* they are linux-capable enough to source the binaries 
> for their platform and put them in the correct folder themselves. We can 
> put in an interim solution of shipping something in the nonfree repo 
> which myon asked earlier but didn't get a response to.
> 
> This flows down to users of Ubuntu, Mint, Raspberry Pi OS and other 
> systems, which doesn't seem very fair. Also, as far as I'm aware the 
> binaries don't support all of the architectures that we do, so it limits 
> users from being able to play with weird and wonderful machines like risc-v!
> 
> 
> [1] https://www.debian.org/social_contract 
> <https://www.debian.org/social_contract>
> 
> Cheers,
> -- 
>    Hibby
>    Debian Developer
>    Packet Radioist
>    MM0RFN
> 

I agree with all the above.

This also applies to Mageia.

Barry
G4MKT
(WSJTX packager for Mageia Linux)