[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] To implement WiMAX with GnuRadio or not?

From: Michael Dickens
Subject: Re: [Discuss-gnuradio] To implement WiMAX with GnuRadio or not?
Date: Wed, 25 May 2011 14:29:49 -0400

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 Chemeris wrote:
> 3) Right now all our code is open-source, but we must leave an option
> for proprietary plugins. How can we make this possible?
> 4) 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 restrictive 

(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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]