On Wed, May 25, 2011 at 23:21, Jeff Brower <jbro...@signalogic.com> 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. _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio