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@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