rtl-sdr licensing question

Scott Cutler scott at scottcutler.net
Fri Feb 28 21:13:46 UTC 2014

Thank you for the reply.  The GPL-LGPL dual solution is one I had in mind
and with your feedback sounds even more inviting.

My program is in fact functional without the SDRIO drivers, reading
recorded files instead of streaming from an SDR device.  All of the core
functionality is still there.  And I do have the capability of distributing
SDRIO separate from my program, so that should not be a problem either.

Unfortunately, I cannot release the program as-is due to the use of a
proprietary library (used with permission to incorporate, but not to
distribute source).  It may be that I can make a version without that
library and I will strongly consider GPLing it in the future.  In the
meantime, I would like if others could use SDRIO with maximum flexibility
(i.e., use it in programs that are not pure GPL).


On Fri, Feb 28, 2014 at 12:59 PM, Adam Nielsen <a.nielsen at shikadi.net>wrote:

> > My code has been in development, and for various reasons--the largest
> > being the desire for transmit support--I have developed my own HW
> > abstraction layer called SDRIO.  At the moment, I support rtl-sdr,
> > bladeRF, and Funcube Dongle devices via the abstraction layer.  The
> > layer will, of course, be GNU licensed and thus free for anyone to
> > modify or extend.
> There are many GNU licences with differing terms, so this will depend
> on which GNU licence you select.  If you choose LGPL for example, then
> what you propose isn't a problem.  But if you choose GPL, I believe that
> what you want to achieve may not be permitted.
> > My intent is thus for SDRIO to live in the same niche as ExtIO and
> > thus have the blessings of the developers.  I'm aware that you cannot
> > give legal advice; my hope is only that, if someone comes to me
> > saying I violated the rtl-sdr license, that at least I can tell them
> > that I've talked with the lead developers and that they've given me
> > the same permissions as the ExtIO developers.
> I'm not a developer on this project (nor a lawyer), but I will point out
> an entry from the GPL FAQ[1]:
>   If a library is released under the GPL (not the LGPL), does that mean
>   that any software which uses it has to be under the GPL or a
>   GPL-compatible license?
>     Yes, because the software as it is actually run includes the
>     library.
> This means that if you release your library under the GPL, then your
> entire program must also be released under the GPL.  If you wanted to
> use your SDRIO system with a closed source program, you would need to
> release it under the LGPL.
> However since librtlsdr is released under the GPL, you don't have a
> choice here and must release any code using librtlsdr as GPL also.
> There is one possible way out, however.  Since you are the developer,
> you are able to dual-licence your own code.  This means you can dual
> licence SDRIO as both GPL (to keep librtlsdr happy) and some other more
> permissive licence, and use the other licence yourself to link it with
> your closed-source program.
> This means however that you would not be able to distribute your program
> with librtlsdr (because then the GPL licence would take precedence),
> just like ExtIO programs do not include open-source ExtIO modules and
> require users to install them separately.
> In other words, your program must be functional and usable without any
> of the GPL'd SDRIO modules present.  Users can add these themselves to
> provide more functionality, but if you require any GPL'd SDRIO modules
> to be present in order for your program to be usable, then it is clear
> that the SDRIO system only exists to circumvent the requirements of the
> various licences and would be legally questionable.
> Perhaps you would consider releasing all your code under the GPL
> instead, for the benefit of everyone?
> Cheers,
> Adam.
> [1] http://www.gnu.org/licenses/gpl-faq.html#IfLibraryIsGPL
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20140228/edd3bf53/attachment.html>

More information about the osmocom-sdr mailing list