@vk6flab Now that you say that, I think you're absolutely right!

#FT2 #pirates

@vk6flab #FT2 OK, Martino IU8LMC came back to me. He basically says:
1. The FT2 encoder-decoder is his own work, and he reserves the right to publish the sources.
2. He's aware of the copyright breach will *soon* distribute the sources of the modified version of WSJT that accommodates the encoder-decoder.

(1/5)

@vk6flab So here's the deal:

#FT2 leverages WSJT-X as a platform by modifying it so that it works with their proprietary encoder-decoder.

When #FT2 publishes the modified WSJT-X "host" and the proprietary FT2 encoder/decoder "client" separately, have they solved the copyright breach?

Apparently, perhaps, yes. (2/5)

@vk6flab #FT2

However, one could contend that, if the modified WSJT-X shares complex data structures or intimate memory spaces with the FT2 encoder-decoder, it is a derivative work. In this case, the proprietary #FT2 "plugin" must be open-sourced, or the developer is in breach.

What would be "acceptable"?

(3/5)

@vk6flab #FT2

* If the modified WSJT-X software communicates with the proprietary FT2 encoder/decoder via a formal, documented interface (like a pipe, a socket, or a command-line argument), they are often considered separate programs.

* If Martino and colleagues added a generic plugin architecture to WSJT-X that could be used by anyone writing "plugins" similar to the one they wrote FT2, and then happens to use it for their proprietary tool, it would be harder to prove a breach.

(4/5)

@vk6flab #FT2

It remains to be seen in which case we are. That would not be possible until the developers publish the sources for the modified WSJT-X host under the GPL v.3 licence. Then we could analyse what's going on.

(5/5)