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

[Jeff Brower]

Michael-

> 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 license.
>
> (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 :).

This is where I think licensing discussions tend to go off track.  Legal 
precedents have clearly established
requirements for interoperability.  In that context, the key point is not what 
code "links to", but where it resides
and what shape it takes.  "Linking based" arguments are fuzzy and argued ad 
infinitum until at least one such case
reaches the Supreme Court -- not likely any time soon.  If code resides across 
a network, across a bus (i.e. on a PCIe
card inside the GNU radio host server), or some other clearly non-GNU radio 
location then interoperability becomes the
metric.  It doesn't matter what header files or libraries (or whether the 
libraries are static or shared object, etc)
were used to create an interface to the code that is physically separate  -- in 
that case, the code is clearly out of
the scope of the license.

I've mentioned on the forum before the need for ways to insert proprietary code 
within the GNU radio framework, as
have others.  For example, is it possible for GNU radio users to insert code 
blocks into the FPGA data flow, for
instance if FPGA Verilog code contained "user defined" stubs or simple 
reference examples to serve as a starting
point?  Could an Nvidia accelerator be used?  To me, it's a matter of 
imagination, creativity, and persistence -- if
GNU radio developers believe in the need for proprietary IP within their 
framework, then it can be done.  So far,
evidently, they don't believe.

Alexander is asking excellent questions and I'm surprised at the tepid response 
-- he's got like 4 replies so far? 
He's the prototype GNU radio user who needs to maintain his group's IP, he 
should be receiving "how to's", not
"INALs".

-Jeff

> 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