[amsat-bb] Possible Outernet GPL violation

Wed Oct 12 20:09:28 UTC 2016

El 12/10/16 a las 20:18, Joseph Armbruster escribió:
> Dani,
> 
> I'm not familiar with this code base or software specifically, but I
> am curious, how did you determine it was linked?  Did you use a
> platform tool, such as ldd or dumpbin or did you just grep the
> baseline for 'librtlsdr" and it popped up?  There's a difference
> between finding text in a baseline vs a lib being statically or
> dynamically linked into it, which is why I ask.  I will assume you are
> correct and it is being used, one way or another.

Hi Joseph,

I used ldd:

/outernet-linux-lband/bin $ LD_LIBRARY_PATH=../sdr.d/starsdr-rtlsdr/ ldd
sdr100-1.0.4
./sdr100-1.0.4: /lib64/libtinfo.so.5: no version information available
(required by ./sdr100-1.0.4)
./sdr100-1.0.4: /lib64/libncurses.so.5: no version information available
(required by ./sdr100-1.0.4)
	linux-vdso.so.1 (0x00007fff14d70000)
	libncurses.so.5 => /lib64/libncurses.so.5 (0x00007f65e9c4c000)
	libtinfo.so.5 => /lib64/libtinfo.so.5 (0x00007f65e9a16000)
	libstarsdr.so => ../sdr.d/starsdr-rtlsdr/libstarsdr.so (0x00007f65e9812000)
	libm.so.6 => /lib64/libm.so.6 (0x00007f65e951b000)
	libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f65e92ff000)
	libc.so.6 => /lib64/libc.so.6 (0x00007f65e8f63000)
	libdl.so.2 => /lib64/libdl.so.2 (0x00007f65e8d5f000)
	librtlsdr.so => ../sdr.d/starsdr-rtlsdr/librtlsdr.so (0x00007f65e8b4d000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f65e9e71000)
	libusb-1.0.so.0 => /lib64/libusb-1.0.so.0 (0x00007f65e8935000)
	libudev.so.1 => /lib64/libudev.so.1 (0x00007f65e870f000)

As you can see, a binary .so file is for librtlsdr is included with
their linux L-band receiver software. A binary .so file for libmirisdr
is also included. Essentially, you select which one gets loaded by
setting your LD_LIBRARY_PATH. However, one of these two libraries (you
choose which depending on your SDR hardware) is needed to make the
software run. Without these two libraries, the software will refuse to
start with the usual "error while loading shared libraries".

> Because you received a copy of a derivative work containing software
> that has GPL applied to it, then you are entitled to the source code
> of the derivative work.  It should have also come with a copy of the
> GPL, but if not, bygons.

Outernet clearly states that sdr100 is covered under a closed-source
licence only:

https://github.com/Outernet-Project/outernet-linux-lband/blob/master/SDR100_LICENSE.txt

They provide no source for sdr100. I believe this to be a violation of
the GPL, as sdr100 should be released under a GPL-compatible licence, as
it is a derivative work of librtlsdr and/or libmirisdr.

A fine detail is that the closed-source sdr100 binary doesn't link
librtlsdr "directly". It links it through some wrapper called libstarsdr
that Outernet have written to support both RTL-SDR and MIRI-SDR in their
software. libstarsdr is LGPLv3.

I managed to contact user "foxbunny" on Github. He is the main committer
in the Outernet repositories. He doesn't work at Outernet any longer,
but he told me that their lawyer said that what they're doing is legal
because sdr100 doesn't link to librtlsdr or libmirisdr directly, but
only through libstarsdr, which is LGPL.

I don't believe this sort of trick can work legally, because it's
trivial to write an LGPL wrapper for any GPL library you want to link.
If these sort of tricks worked, anyone could link a GPL from
closed-source software just by writing an LGPL wrapper.

He also told me that since the same sdr100 binary can work with
libstarsdr compiled against libmirisdr or librtlsdr, then it satisfies
the clause "can work without". I think this is another trick that
doesn't work, because clearly sdr100 needs at least one of libmirisdr or
librtlsdr just to load and start running.

In any case, I think that only the copyright holders of libmirisdr and
librtlsdr would be able to bring this matter to court. It's a case of
Outernet breaking the terms of the GPL in libmirisdr and librtlsdr by
not distributing sdr100 as GPL software. It's not a case of Outernet
distributing sdr100 as GPL to me and then not following the terms and
refusing to give me a copy of the code. In this latter case I (or anyone
that gets a copy of sdr100) could bring the matter to court.

> Developers Are human and make mistakes, it would be interesting to
> hear from the authors to determine what the story is.  If the
> libraries that you referred to are not being used and could be
> stripped out, that could eliminate the issue down the road or they
> could just release the whole thing under GPL moving forward and be
> done with it.

Almost a year ago I contacted Thane Richard when he made some publicity
of the Outernet project in amsat-bb. I told him that I didn't understand
why the key pieces of their decoder where closed source, and that I
thought that making the project fully open source would better serve
their goal of easing worldwide accessibility to internet content. Thane
told me that for strategic reasons they feel it's better to release
those parts as freeware rather than open source.

At that time, the only closed source part was the ONDD daemon, since
Outernet used Ku-band instead of L-band and the demodulation was
performed on a DVB-S2 hardware receiver. The modulation was standard
DVB-S2, and so the details where known. Only the format of the data
stream in the DVB-S2 multiplex was "secret".

Since Outernet has moved to L-band, their demodulator is now SDR
software (the sdr100 binary I'm talking about above). This demodulator
has being released only under closed-source. The modulation format is
kept "secret".

>From reverse engineering, I know the following:

* 4200baud BPSK
* r=1/2, k=7 convolutional code with CCSDS polynomials
* IESS-308 scrambler
* HDLC framing is used somehow

Still, I haven't figure out how to produce anything useful from these
parts yet. In particular, I don't know which kind of differential
encoding is used and where exactly in the chain (some differential
encoding or other kind of polarity determination must be used, since the
IESS-308 scrambler works completely different for one bitstream and the
bit-inverted bitstream). Also, I don't know precisely how is HDLC
framing used.

Perhaps the sdr100 binary includes some copyrighted code which they
can't release, or is bound by some NDAs or whatever. In particular, they
don't seem to use Phil Karn KA9Q's Viterbi implementation, so perhaps
they use some copyrighted library for that which they can't release.

Still, I believe it's easy to produce a completely working decoder using
only open source software. KA9Q's Viterbi library can be used for the
convolutional code, the scrambler is simple and I have already
implemented a working GPL descrambler, and there's plenty of open source
code for HDLC around. So I have the impression that if Outernet doesn't
release an open source demodulator is just because they don't want to,
not because of using copyrighted code or NDAs for something very secret.

It seems that for some reason Outernet wants to keep the key pieces of
their receiver closed-source. Just enough to keep someone from writing
an alternative receiver software.

> I'm interested in following this :-)

I'll keep you updated off-list. So far I've written to the copyright
holders for libmirisdr and librtlsdr, the Free Software Fundation and a
few people at Outernet.

73,

Dani.