28 Feb
2014
28 Feb
'14
8:42 a.m.
Greetings, all--
A while back I asked some questions about licensing of the rtl-sdr
libraries, especially with regard to use with non-GPL software. At the
time, I was told that the ExtIO libraries were considered an acceptable
use-case.
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.
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 have placed the code here in case anyone wishes to look at the current
state (though please note that the text of the licensing is not yet
finished):
https://github.com/spcutler/SDRIO/blob/master
The SDRIO_RTLSDR module is quite thin and I hope does not give the
impression that SDRIO is just supposed to be a wrapper. If you look at the
other devices, you can see that they require more code and that the project
as a whole is quite a bit more than a wrapper.
Thank you for your time!
-Scott
28 Feb
28 Feb
9:05 a.m.
Sorry guys, the Github link I gave was invalid. I believe this should work:
https://github.com/spcutler/SDRIO
-Scott
On Thu, Feb 27, 2014 at 11:42 PM, Scott Cutler <scott(a)scottcutler.net>wrote;wrote:
Greetings, all--
A while back I asked some questions about licensing of the rtl-sdr
libraries, especially with regard to use with non-GPL software. At the
time, I was told that the ExtIO libraries were considered an acceptable
use-case.
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.
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 have placed the code here in case anyone wishes to look at the current
state (though please note that the text of the licensing is not yet
finished):
https://github.com/spcutler/SDRIO/blob/master
The SDRIO_RTLSDR module is quite thin and I hope does not give the
impression that SDRIO is just supposed to be a wrapper. If you look at the
other devices, you can see that they require more code and that the project
as a whole is quite a bit more than a wrapper.
Thank you for your time!
-Scott
9:59 p.m.
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
10:13 p.m.
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).
-Scott
On Fri, Feb 28, 2014 at 12:59 PM, Adam Nielsen <a.nielsen(a)shikadi.net>wrote;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
10:51 p.m.
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
11:15 p.m.
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(a)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
11:21 p.m.
Hi,
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)?
Yes, it's a problem.
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.
If the process was automatic, there would effectively be no difference
between shipping it with it directly and so this is clearly a
circumvention mechanism by which you try to "work around" the GPL to
achieve the same result as distributing both component as a whole.
The entire point of the GPL is to give "an edge" / "an advantage" to
software that are also GPL. Hence forcing the application to be less
practical, more of a burden to the user if it's not GPL is a
_design_goal_ ...
Cheers,
Sylvain
11:23 p.m.
Fair enough. I will keep the distributions totally independent. Thanks
again for the advice!
-Scott
On Fri, Feb 28, 2014 at 2:21 PM, Sylvain Munaut <246tnt(a)gmail.com> wrote:
Hi,
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)?
Yes, it's a problem.
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.
If the process was automatic, there would effectively be no difference
between shipping it with it directly and so this is clearly a
circumvention mechanism by which you try to "work around" the GPL to
achieve the same result as distributing both component as a whole.
The entire point of the GPL is to give "an edge" / "an advantage" to
software that are also GPL. Hence forcing the application to be less
practical, more of a burden to the user if it's not GPL is a
_design_goal_ ...
Cheers,
Sylvain
4131
days inactive
4131
days old
7 comments
3 participants
participants (3)
-
Adam Nielsen -
Scott Cutler -
Sylvain Munaut