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

[Alexander Chemeris]

On Wed, May 25, 2011 at 22:29, Michael Dickens <address@hidden> wrote:
> 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.

Yes, with an exception that we our receiver is not basic (e.g. see
comment about DL-MAP) and we also need transmitter, and integration
with MAC level, ugh.

> 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.

Yes, this is an option.

> (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:

Right.

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

Let me clarify.
We will publish our main source code as open-source (we already do for
our Matlab models). But we want (1) to allow other parties to replace
some parts of our open-source code with their proprietary blocks and
(2) more importantly - allow creation of proprietary solutions to be
based on this code. So far, (2) would require you to create a
socket/IPC based API and use it to embed into a larger system - though
this implies that you add latency in your processing path. Requirement
(1) may go the same way, as long as it's only for some blocks, but
again - this may add latency. I'm not yet sure how bad is this added
latency, but in general, latency is an important characteristic for
4G.

Interesting thing is how Linux kernel allows proprietary modules. If I
understand this correctly (IANAL), it's because kernel's API is
clearly defined and kernel it's considered, that it's a kernel native
feature - to be able load and run modules, just like it's for
applications. With this logic, it's possible to allow modules with
GnuRadio if there are a clearly defined external API. But note, that
the kernel is licensed under GPLv2, and GnuRadio is under GPLv3 - I'm
not sure whether this trick works for the latter.

> 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).

We're more concerned about others to use our work. That's what is
missing for many GnuRadio projects - we build software for ourselves.
We want to create a software which will be used by many.

> Good luck, and please do keep the list informed on your project -- it sounds 
> quite interesting! - MLD

Thanks! I'll do my best keeping the community informed.


-- 
Regards,
Alexander Chemeris.