Vector Sink/Source Type Support

[David Reuss]

Hello,

We have a few gnuradio blocks in an OOT module that require double
precision inputs and outputs. To help us test these blocks we created our
own vector sink/source blocks that are direct copies of the gnuradio vector
sink/source but with added support for doubles.

This works well, but I was wondering if there is a reason that vector
sink/source don't support double, std::int64_t and gr_complexd types, or
whether this is something that might be useful for me to create a pull
request for? These blocks are already templated (source:
https://github.com/gnuradio/gnuradio/blob/main/gr-blocks/lib/vector_sink_impl.cc),
so it should be easy enough to add support for more types.

Thank you,
David

Survey regarding Open Source Licensing of GR 4.0

[Josh Morman]

A quick follow up on one topic that was presented in the Q4 Project Update
video:

Tl;dr - the core of the code being merged as “GR 4.0” is LGPL.  We want
your opinion on how this will impact you and if further action is needed
for licensing considerations.  Please submit your feedback here:


https://forms.gle/u7PjYGhzfrshkngd9

Look forward to your responses.


Thanks,

Josh

—--

As has been widely discussed, the upcoming major version of GNU Radio, GR
4.0, is based on a new codebase developed by the team at GSI-FAIR and is
being migrated into the GNU Radio GitHub Repository.  Apart from the vast
and promising changes of this major revision, the code being migrated is
currently licensed as LGPL, which means that there are different
ramifications than the entirety of GNU Radio 3.x being GPLv3.  The plan is
that blocks ported over with IP from GR3 (apart from very trivial blocks)
will remain in modules that are licensed as GPLv3.  So for the vast
majority of GNU Radio use cases, the situation for derived works of
flowgraphs using signal processing blocks will not change.



But with the core (base classes and schedulers) being LGPL, this allows
derived works to link with GR, but have a different license.  Source
changes to the core GR codebase would still need to be provided to those
receiving any derived works.  This could enable the following situations:

   1.

   A GNU Radio user could create an OOT not bound by GPLv3 - so long as the
   OOT does not link against any of the GR GPL code (e.g. gr-filter or
   gr-digital)
   1.

  The OOT could not be distributed in binary form if it is built
  against GPLv3 modules without the artifact being licensed as GPLv3
  2.

  Realistically, this would limit non-GPL usage of GR4 OOTs in
  flowgraphs to custom blocks that have been licensed accordingly
  2.

   An application such as a graphical frontend linking to GR4 under the
   hood could be created under a non-GPL license


Note: The above is not legal guidance to any users of this codebase, but a
statement of a licensing change compared to previous GNU Radio revisions.
Each user should consult counsel where needed to understand their own usage

Links:

https://github.com/fair-acc/graph-prototype

https://events.gnuradio.org/event/21/contributions/390/

Re: Vector Sink/Source Type Support

[Jeff Long]

We don't seem to have any blocks in-tree that support either of these
types, so it wouldn't be of general use and would be hard to test with CI.
My opinion is that this is something to look into for GR4.0, unless there
is some demand for more precision in 3.X.

On Tue, Dec 19, 2023 at 2:57 PM David Reuss  wrote:

> Hello,
>
> We have a few gnuradio blocks in an OOT module that require double
> precision inputs and outputs. To help us test these blocks we created our
> own vector sink/source blocks that are direct copies of the gnuradio vector
> sink/source but with added support for doubles.
>
> This works well, but I was wondering if there is a reason that vector
> sink/source don't support double, std::int64_t and gr_complexd types, or
> whether this is something that might be useful for me to create a pull
> request for? These blocks are already templated (source:
> https://github.com/gnuradio/gnuradio/blob/main/gr-blocks/lib/vector_sink_impl.cc),
> so it should be easy enough to add support for more types.
>
> Thank you,
> David
>