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

[Alexander Chemeris]

On Wed, May 25, 2011 at 23:21, Jeff Brower <address@hidden> wrote:
> 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, thanks. Yes, I'm trying to solve a bigger problem then just my
personal case. And you're right - if we want to see serious projects
to use GnuRadio, then there must be how-to's and examples.


-- 
Regards,
Alexander Chemeris.