rtl-sdr licensing question

historical

Thank you for the detailed reply.  At the moment, I believe SDRIO fulfills
all of the requirements you detail.  You are correct that the SDRIO drivers
are individual DLLs that export the API defined in sdrio_ext.h, and that it
it is the job of the client application to look for these files and load
them dynamically.

I only have one small question, which is the exact treatment of
auto-install mechanisms.  I was hoping to use a auto-downloader to make the
installation process easier.  Do you consider it problematic if I use the
auto-downloader to grab the SDRIO installer and execute it (not individual
drivers, but rather the installer as a whole)?  It seems strange to me that
there should be a difference between a user manually clicking a download
link and running a program versus the program downloading automatically,
but I understand that this is a gray area.

At any rate, it is not a problem for me to keep the two distributions
completely separated; it is just a slight extra burden on the end users.
 We want to make things as easy as possible and this is an extra step, but
I am happy to go that route if it more clearly fits with the license.

Thanks again,

-Scott

On Fri, Feb 28, 2014 at 1:51 PM, Sylvain Munaut <246tnt at gmail.com> wrote:

> Hi,
>
>
> First off: IANAL. Also this email doesn't consistute legal advice and
> also doesn't consitute a grant of right or any kind of approbation,
> it's just my current opinion, at this moment and is subject to change.
>
> Being windows stuff, I can't build it but I assume that the "drivers"
> once compiled create .dll or shared object files, theses have a
> pre-define plugin API and are dynamically loaded by the host app (for
> example listing all DLL in a "drivers" dir).
>
> A few things are clear :
>
>  - The SDRIO_RTLSDR has to be distributed under GPL. (The source can
> be any license gpl compatible, but once built into a binary and linked
> to the lib, then it's _just_ GPL and must be distributed as such
> whatever other license was the source)
>  - You cannot distribute the SDRIO_RTLSDR DLL bundled with any app
> using the SDRIO interface that's not also GPL. And mechanism like
> auto-download / auto-install after the fact would easily be considered
> circumvention mechanisms and thus not allowed either. The app and the
> driver must be distributed separately and if the user wants it, it has
> to install it manually after the fact.
>  - The interface itself ( content of SDRIO directory, so essentially
> sdrio_ext.h ) doesn't really need a license. .h files that don't
> content inline functions are not considered copyrightable.
>  - The interface can't be a simple "wrapper" against a GPL lib. It has
> to be generic and completely detached from any rtl-sdr specific stuff.
> Seems to be the case here and since you provide drivers for other
> hardware, that shouldn't be an issue.
>  - Drivers must be loaded / detected dynamically, basically the host
> app (if not GPL) can't have any knowledge of rtl-sdr at all ...
>
> For the EXTIO case, you have all of the above _AND_ the interface was
> pre-existing which made it a no-brainer. Here's it's created after the
> fact but that shouldn't be an issue for this specific case.
>
> If the content of the SDRIO directory becomes filled with helpers to
> actually use SDRIO drivers, then it will need a license of its own and
> LGPL would probably be appropriate here or even BSD (and don't make
> that a library but more something to statically link in the target
> app). I find that dual-licensing makes things more tricky than needed
> so I would avoid that. (Because depending on build options or what had
> been effectively linked or not, or what it's bundled with, the
> effective license vary).
>
>
>
> Cheers,
>
>     Sylvain
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20140228/8cb61ff1/attachment.htm>