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_...

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.