It's good to see an open source implementation of this, since the closed-source nature of most radio implementations (especially in cell phone basebands) is a serious problem. But I'm a little concerned to see that this is all written in C. While I can see some good reasons for that (easier porting to microcontrollers, for example), the C programming language has a well-deserved reputation for being extremely hard to write securely. Has anyone looked at this closely enough to comment on whether it's likely to hold up against people looking for vulnerabilities, as-is or after some careful auditing?
Speed matters. According to the authors of this software "Highly optimized Turbo Decoder available in Intel SSE4.1/AVX (+100 Mbps) and standard C (+25 Mbps)".
Also, a lot of alternatives are just not there. Rust is not mature; today it doesn't "fully" support SIMD. Go requires a runtime, does not support SIMD, and has a penalty for calling C code.
Awesome! Interesting that they're using the USRP, but have opted to use C directly rather than Gnuradio (python). I imagine the performance is pretty good because of this.
Looks awesome, wish I had the time to play with it.
A lot of GNU Radio is actually written in C++. Looking at some examples, it seems you don't need Python to create the flow graph either, that can be done in C++.
I think it is being used quite appropriately. If someone decides to create a service that uses this library to interface with an LTE network, they have to open source their software. If they went with GPL they wouldn't have to.
IIRC the extra clauses of the AGPL are triggered on modification of the work (which is restricted to copyright holders and licensees), not on public performance or communicating over the network. So if you are running the exact same version you downloaded, there are no extra provisions. If you patch the code to, say, fix a typo, then you have to distribute the code to network users.
This presupposes that modification of a copy of a copyrighted work that one lawfully owns is, in itself (even without subsequent distribution), an act restricted by copyright. I contest this assertion.
Even if it were the case, the permissions granted by the AGPL are not mutually exclusive with any other set of permissions. Dual licencing, for example, is a common practice. Thus, I'd argue one can take advantage of provisions of the AGPL permitting modification, but not rely on it, but instead on the provisions of copyright law itself, to actually execute the software. The AGPL is not a contract, it is a copyright licence; as such, the set of actions you can take for an AGPL-licenced piece of software is by definition a strict superset of the set of actions you can take for "all rights reserved" software.
Under US copyright law the "preparation of a derivative work" (in this context more or less making a change to the code base) is one of the six exclusive rights under the control of the copyright holder [1].
