Hi Alexander - I think Martin & Tom covered that GNU Radio is quite
capable of being programmed for the basic receiver processing. You
might need to play around a bit with your DSP blocks, but otherwise I
think GNU Radio’s data processing is up to the task.
On May 23, 2011, at 3:50 PM, Alexander C. wrote:
Right now all our code is open-source, but we must leave an option
for proprietary plugins. How can we make this possible?
Related to (3) - how can we make sure our protocol stack can be
embedded into a closed-source application/system?
IANAL and TINAL. I think, as has been said, you’ll really want to
consult a lawyer to figure out how to best meet your needs.
GNU Radio is licensed solely under the GPLv3, which is written with the
intent that -anything directly- using source or binary becomes part of a
“greater work” and hence would also fall under this or an equivalent
license (e.g., if used in a sold product). In the case of GNU Radio,
that means any C++ code that links with GNU Radio’s libraries, or Python
script that makes use of GNU Radio’s Python / SWIG files / libraries.
To the best of my knowledge, because GNU Radio is not dual-licensed,
neither can “greater works” derived from it. Ettus’ UHD code is (will
be?) an example of a dual license (GPL for the primary source, or some
other license allowing you to do closed source for your needs when you
pay to license the code from Ettus); Qt tries to do this dual-license
as well – I don’t know how well they succeed, but they do try.
IMHO, you have 3 primary choices for keeping your code closed source:
(0) Do not use GNU Radio; use some other project that has a less
(1) Do not distribute a product or service that uses the code: Nobody
will care how you license your code so long as you / your company does
not sell or distribute your product – e.g., if you use it just in house
for testing and evaluation, then you can license it however you want.
However, I doubt that this is what you’re looking for: why develop such
a product, but not sell or distribute it? That brings us to:
(2) Make sure your code does not -directly- rely on GNU Radio’s headers,
Python scripts, or compiled libraries: Use currently available GNU Radio
blocks as much as you can (or, those written and released by others),
and then create a pipe or socket connection to your specific code.
Because your code does not rely -directly- on GNU Radio’s codebase /
libraries, it forms an independent work & thus you can license it as you
choose. That said, this method is certainly a nuisance and, depending
what blocks are available versus what you need, it might also be
impractical (never impossible :).
I don’t know of another way to look at this issue – maybe someone on
this list is more enlightened?
That said: Unless you feel strongly that your work truly needs to be
proprietary, then why not just create a project on the CGRAN or your
preferred area (e.g., github) & make your work public – it will benefit
many others in the SDR / DSP world (and, likely, beyond).
Good luck, and please do keep the list informed on your project – it
sounds quite interesting! - MLD