This is merely a historical archive of years 2008-2021, before the migration to mailman3.
A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/osmocom-sdr@lists.osmocom.org/.
Sylvain Munaut 246tnt at gmail.comHi, 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