This relies on OpenOFDM for much of the "Physical" layer of WiFi, which has some INCREDIBLE documentation that is really worth checking out if you want to understand how modern radios go from a radio signal to packets:
Wow. I once wondered about building a wifi card with an SDR but quickly got discouraged when figuring out how much IEEE charges for the specifications.
Most of the IEEE 802 specs (including the base IEEE802.11 WiFi spec) are free [1]. But you do need to at least register to get access to them.
>New IEEE 802® standards are included in the program after they have been published in PDF for six months. All standards available in the IEEE GET 802™ program will remain in the program until they are replaced by a superseding document or are withdrawn. Drafts are not part of the program.
>
>To download these standards, you must sign in with an IEEE Account. If you do not already have an IEEE Account
I read about this program on several sites including the Linux wireless project page and the osdev wiki and the links seemed broken everywhere. Not sure why I didn't find this before.
Don't buy the spec unless you have a business reason to. 802.11 specs are available to most members of IEEE. Whether it be your personal membership or through your school, work, a friend. A membership is like 200 a year.
This project (and OpenOFDM) is massively impressive. The standard is complex, and almost nothing works until just about everything is working. They should write a blog about when the first ping worked.
Anyway, there is a lot of value as a testbench or as a standard implementation for others. I can only imagine how much a testbench would cost...
I like this sentence "nothing works until just about everything is working".
Actually the first ping worked in the end of 2018 to the beginning of 2019. But like you also realize, it is complicated, and actually well beyond my original imagination. So between the first ping and the release status (at the end of 2019), there was a lot of work. Finally it comes to today, and it runs "normally": stable ping, stable throughput, less crash. Huge effort is needed just to make things work as normal.
It seems one of the final missing links to fully open source hardware WiFi would be the RF transceiver chip. This is, to my understanding, something similar to a high-bandwidth DAC and ADC coupled with configurable frequency mixers to access radio frequencies.
Is anyone trying to create an open source version of that chip? I understand there's not a lot in the way of open source analog chip designs out there, but with Google/Skywater's free PDK, the time may be ripe to change that.
Also, there are many SDR LTE base stations, but can we make our own SDR LTE handset as well? Can it connect to an existing cell network?
If you're willing to take up a suitcase worth of room, you can use standard analog ICs and RF building blocks to take a quite normal DAC and upconvert it to RF, and downconvert the receive chain likewise to a very common ADC. The standard wifi channel width of 20MHz should place it within reach of quite a few off-the-shelf chips.
That approach should be able to do the whole thing with no NDAs or whatever; it would be a fine capstone project for someone chasing an EE/RF degree...
I think it would be cool if 100% of the digital logic was open source, and 100% of the analog was at least well-understood, and commoditized. Kind of like how you don't need an open source op-amp, they're well understood and commoditized (for most applications).
Does it really take up a suitcase worth of electronics to do what the transceiver IC's are doing?
The HackRF One can do 1MHz-6GHz, but also indicates "8-Bit I and 8-Bit Q".
On the one hand I'm like, it's basically just dumping wideband spectrum into the air, right?
On the other hand the OpenOFDM reference talks quite a bit about much larger I/Q values, so maybe "8-bit quadrature samples" is exactly why nobody uses it for Wi-Fi. :(
8bit I/Q definitely can be used for WiFi. I used HACKRF to send and capture Wifi packet without an issue (offline, use Matlab to process the captured I/Q samples).
Low resolution I/Q (8bit) will impact the RX sensitivity and TX EVM, but it won't be a factor that will totally fail the WiFi implementation.
The HackRF One uses a series of up/down converters, plus a MAX2837 for tuning, and a MAX5864 for the actual ADC/DAC. It goes 22 MSPS, so it can theoretically look at any ~20 mhz section of the 1 MHz - 6 GHz tuning range.
WiFi channels are generally 20, 40 or 80 MHz, so the latter two are not possible given the hardware, and the smallest (20 MHz) would be right at the limit of the hardware. Additionally, there may be other complications (tx/rx switching speed, tuning speed (I'm not sure if wifi would need to do frequency hopping, and if the bandwidth is sufficient to mitigate that need), etc...)
And then someone would have to actually implement it.
Sadly from my research of cheap and hobbyist SDRs, you generally aren't gonna get high bandwidth. I have a limesdr-usb sitting around which supports ~60mhz bandwidth iirc which wasn't good enough for a specific application I looked at which required a channel width up-to 192mhz. Although I'm also an absolute RF noob, do I may have misinterpreted something.
tx/rx switching speed is easy enough by just having two units. Use separate antennae so one doesn't fry the other.
Also just for safety's sake, twiddle your receive preamp gain down before transmitting. That can be done very quickly. Could probably tie a line between the two and have the CPLD do that, actually.
I'd say it is very unlikely and close to impossible unless it's sponsored by a government fund or a very big IC design company that's as big as Intel. But I'm glad if someone can proof me wrong :-)
Nowadays if you want an RF transceiver chip you either go with direct synthesis of ADC/DAC or homodyne architecture. The companies that have both of these design capabilities are ADI and TI, and both them are happy with their monopoly.
But if any R&D company that probably can pull it off it will be IMEC, and coincidentally it is the employer of some of Openwifi engineers. FYI, IMEC are both funded by Belgium government and a well established IC design company.
To achieve the same data rates as a usual LTE handset, but using SDR instead of an ASIC, would make it extremely power hungry. Power is not much of an issue for the base station, but for the handset it is essential.
If you're going down to the "fixed function chips must also be open" realm, you'd also need an open source FPGA (or to use PDK to try to tape out) for the OpenWifi design. My read is that currently OpenWifi is also tied to proprietary Xilinx IP cores like the Xilinx Viterbi Decoder.
The challenge of doing that, is that there are apparently a lot of proprietary IP blocks (both analog and digital) that are in the FPGA (like the Viterbi decoder as the parent comment suggests) that would need to be redesigned before you could tape it out into your own chip.
I am not sure what other IP blocks are being used in these FPGAs, but a viterbi decoder can be pretty area and power heavy (relatively speaking.) I'm not sure if you would be able to get enough performance [speed] with modern WiFi protocols by implementing it in normal FPGA fabric hence why those blocks are woven into the FPGA.
All that said, this is still a very good thing, because it marks a step forward towards a more open source hardware ecosystem.
Indeed, not only the viterbi but also many basic building blocks in the Xilinx and Analog Devices reference design which is the starting point of our openwifi project.
Viterbi won't be an issue, we know how to write our own viterbi decoder on FPGA. It just need some time.
A Thorough and comprehensive IP block analysis will be needed and we will also evaluate how big the effort will be to replace all (almost) the big company owned blocks. We have to do this analysis and invest effort in the future, because we really want to tape out a real opensource WiFi baseband chip! As the first step, RF won't be integrated.
Good and tough question. So far, we are not very successful to find enough funding to bring the design to the next mature level and tape out it. Working on it, but difficult.
No one can decide to pay 200~300k euro in a minute with very uncertain return (like charity), because no one can 100% answer the question of how many openwifi chips can be sold per year.
At least in the U.S., patents forbid making, using, selling, or importing a patent-encumbered device without the inventor or assignee's consent. So no, not just selling.
I did not claim that source code constitutes an "invention" for the purpose of patent law or that the act of copying source code constitutes "making" an invention--the law is unclear on that. I was only stating that "selling" an invention was not the only act forbidden by patent law.
(a) Except as otherwise provided in this title, whoever without authority makes, uses, offers to sell, or sells any patented invention, within the United States or imports into the United States any patented invention during the term of the patent therefor, infringes the patent.
(b) Whoever actively induces infringement of a patent shall be liable as an infringer.
Title 35 of the U.S. Code is the full text of U.S. Patent legislation. Then there are the volumes of case law interpreting it, if you'd care to read it.
Question: How does the AGPLv3 work when it's describing/programming hardware? I have a good idea how it works on software, but less than a good idea on hardware.
Please excuse my ignorance,I'm fairly new to this field. So with OpenWifi, will I have control as to what packets I would like to send over the air?
So for example, can I construct a specific packet using OpenWifi and then send them over the air over a specific channel (say channel 11, 2.4 Ghz)?
Not exactly, you can already do this using monitoring mode on your normal WiFi card. This is using SDR(software defined radio) to create a WiFi card from scratch. Technical speaking you can recreate any radio signal using SDR, with some limitations of course.
A bit longer answer:
Basically Linux gives packet to our driver, and then our driver gives the packet to our FPGA for further processing (queuing, modulation, CSMA, etc). So you can compose your packet in the driver or anywhere else that can communicate with the driver, then instruct the FPGA to send your packet at any frequency 70M~6GHz.
It will be very worth to read the README and project document word by word on the github: https://github.com/open-sdr/openwifi . I believe you can already find answers of more questions there.
How does licensing work with software defined Wi-Fi? As I understand it, Australia holds many Wi-Fi patents and most of the money from radios goes into their University system. Would SDR based implementations be in violation of those patents? What if someone made a hardware version?
Some of those patents have expired, so it would take a lot of research to be certain. A hardware implementation is likely to be patent-infringing.
The SDR implementation is unlikely to be patent-infringing, as Australia does not generally allow software patents. [0] Software implementations of existing hardware are generally not considered to be patent-infringing under the current interpretations of law.
However! The SDR implementation is still likely to be copyright-infringing, as Australia does have copyright laws that are rather vague and far reaching, and Australians are not granted the right to give up copyright.
[0] Software patents can be granted, but they require the idea "improve the computer" rather than "merely requires generic computer implementation". Which is a higher hurdle than people expect, and has led to IBM, Microsoft and others losing and failing to gain software patents in Australia.
So far as I'm aware, that question has yet to be tested in an Australian court.
As Australia operates under rules that translate to "reasonable interpretation", rather than strict definitions, the answer to your question is "Maybe".
Do you have some more details how it would be copyright infringing? I can't see what part of an implementation would be direct copied work, unless it's byte sequences etc.
To start of with, the belief that only plagiarised work can be copyright infringing is incorrect, at least when it comes to Australia.
A lot of reverse-engineering work is not done inside Australian borders, because the current interpretations of copyright law aren't favourable (as well as some other related laws).
For example, if there exists a proprietary protocol, then the protocol itself may fall under copyright, and simply making a tool that speaks to that protocol may be considered infringing. This is because our copyright laws, or rather the interpretations of them, speak to the 'substance' of the tool being copyrighted, rather than the work itself.
(And yes - copying a painting copies the 'substance' and can run afoul of our insane copyright regulations. Depending on how much the original artist cares.)
As I said before, vague and far-reaching. And the courts have never been consistent in the way they hand down their case-by-case judgements.
Australia is not well known for intelligent tech laws. Iterating public IDs can be considered hacking, forcing a secret backdoor isn't considered a systemic security weakness, etc.
I can’t speak to patent encumbrance on anything as recent as 802.11ac, but the Australian CSIRO patents began expiring in 2013 and have probably all aged out by now.
Depends how the patent claims are drafted. But there's no reason to think that the software implementation would be immune to an allegation of infringement.
Extremely surprised to see AGPLv3 used instead of GPLv3, given that this looks like binaries that you install on a device rather than a network service you connect to. Anyone know what's up with that?
The dual licensing is not used at all and getting shit open sourced out of my uni is a royal pain. Source: doing my masters with openwifi at this research group
Somebody shoot holes in my idea. I want to do wifi over coax with the baseband into the coax and the up/down converter on the antenna side. This is interesting for such a project, but of course I want full speed modulation (gigabit). I don’t want to just transmit data like MoCa. I want a direct interface to an antenna. The point is to make roaming over large distances completely transparent to the client.
- Limited client density (could be fine in a house)
- Beam-forming probably out of the question
It would probably work OK though. But why is it better than making 802.11r work? From my perspective as a user (not as a client node) it's completely transparent.
There are some works and even products on distributed antenna systems for WiFi. E.g. [1]. MU-MIMO can benefit from the distributed antennas due to the condition of the MIMO channel matrix.
If is should be standards-compliant, you will be limited in functionality. E.g. the timing-constraints of ACK and CSMA limit the length of the antenna cable, though that should not prevent your idea. I guess, it will be more problematic to realize compliant CSMA, as you would need to perform clear channel assessment on each individual antenna?
Anyways, distributed MU-MIMO seems to get traction. We are working on it ourselves.
When communicate with commercial device, tcp can achieve ~30M, UDP can achieve ~38M in 20MHz 11a/g non MIMO mode. We are still working hard to optimize the whole design, because we know it is not mature enough and there is still lots of work to be done. For example, the original PHY rx openofdm design is simplified a lot for a quite small fpga which means performance (like sensitive) is sacrificed. Now our FPGA is more advanced than the openofdm FPGA in USRP N210, so there is a chance to improve a lot on both performance and features (like MIMO and new standard). Recently nlnet.nl gives us a short term fund to complete the 802.11n feature: https://nlnet.nl/project/OpenWifi-80211n/index.html
There are lots of information (including throughout) in the readme and “project document” on GitHub (https://github.com/open-SDR/openwifi). Worth to read word by word.
AGPL is very controversial. I'm clearly on the "won't touch it with a 10 meter pole" side.
There are people with other opinions, but even they agree that this is not tested in court, and it's more expensive to be sued, even if you win, than to just buy (or write from scratch) ANY alternative to the AGPL software in question.
AGPL is a legal landmine. You can't plug it into anything else, even for your own purposes.
Let's say you use these to create a guest wifi network. According to AGPL it looks like you must now opensource any and all scripts that you use to manage this environment.
In other words that one-off script you used to loop over all your access points during setup must be opensourced. Oh, it has details about your internal asset tracking system? Well, they now have to be public. Oh, it relies on your internal database? I guess that's opensource now too.
Did you even keep that one-off script? AGPL demands that others must be able to run what you run, essentially. It says that everything you do operationally to your service must now be documented and published.
You want to connect your internal SSO to the AP? Sorry, you better instead change it so that your internal SSO takes whatever protocol the AGPL software already takes. Oh, that's not feasible? Ok, give up then.
1 year later… oh shit oh shit oh shit, someone added internal SSO to the AGPL software! Now we have to opensource that, but we can't because it includes code we licensed from a third party only for nondistribution!
AGPL only makes sense for organizations that fundamentally ONLY will EVER run open source software (like FSF and that's it), and usually not even then.
Also ideologically it's a huge violation of freedom. What I do in my own home is absolutely none of your business. What executes on my hardware is my business.
For those who disagree about my examples: Yeah… I'm personally not a lawyer (but HAVE consulted with lawyers about this). You may be right. In the end a court will decide. But do you want to take this poison pill in order to find out in court if you die?
So GPL doesn’t have this character? Like the GPLv2 taken by Linux kernel. I have an impression that AGPL only add “A” to GPL to adapt itself to the cloud era. Because a cloud/service deployment is not treated as redistribution in GPL, considering there wasn’t cloud at the time GPL was made. So some big cloud company can deploy GPL software on cloud without open source action because they are not actually “distribute” software, instead only distribute a service. AGPL fix only this hole created by cloud.
You say it "fixes" GPL, but as I described it makes AGPL completely unusable for basically any purpose, and it creates a HUGE risk that's in my opinion completely unacceptable, as described.
The only way it seems to work is:
1) it's extremely unpopular by number of projects
2) most private citizens who use it violate the license
3) most potential corporate users have it vetoed by their legal department, which means they plain don't use it
That's not a great situation. It only seems to work (in the rare cases that it's used) because so few people accept it, and the ones that do violate it.
AGPL removes freedom zero, in my opinion.
> The freedom to run the program as you wish, for any purpose (freedom 0).
I think my examples illustrate this, but I'm sure I could elaborate more.
The way I read it you cannot write an automation script for managing the MongoDB databases for your Etsy store without opensourcing those scripts.
In fact I disagree that "cloud didn't exist when GPL was created". This also applies to services like banks, and banks certainly existed before GPL, and provided a service.
So that was never a "hole" in GPL.
AGPL is poison because every time you touch it, even operationally, your work belongs to someone else. To call that "Freedom" is Orwellian.
But in the MongoDB case (when it was still using AGPLv3), those companies who violated AGPLv3 did have a solution: pay a fee for a commercial license of MongoDB instead of AGPLv3 which is free. In this way, those companies don't need to open source their code built based on MongoDB. MongoDB get money to go further, because I guess MongoDB people need to raise their family.
Sure. But if anyone who seriously uses some software (even on a hobby project) is either violating the license or buying a commercial license, in what sense is it free/libre software or even open source?
That's saying that AGPL is only useful to the extent that it doesn't exist.
But it's not just software "based on" MongoDB. It's your backup scripts. It's your cluster scheduling config for the jobs. It's your provisioning script, etc…
And it implies it being non-free software. It's only one (small) step removed from a licenes that disallows "commercial use".
A license disallowing commercial use is fine. But it's absolutely not "free software". Freedom zero was so obviously a freedom that it was initially just implied, and only added later to be explicit.
If you are saying AGPL's virus like behavior is much more severe than the GPL's virus like behavior, I am not professional on this aspect. Not sure.
If I understand correctly, the open source action is only required when you "re-distribute" it. So, if you play it only by yourself and never give your modified software to anyone else, it is OK for you to keep all code close. If you work on it together with other people in your organization, it is fair enough that you open the source code to those people for them to work together easily. But all the code are still kept inside your organization.
Only in a step that you want to re-distribute the software (or the service) to people (like external user or other company) who you don't want to show source code, you are facing violating the AGPLv3. But generally speaking, in this step you already have a plan to make money out of external people (like user or other company), so fair enough to pay a fee for commercial license.
"free software" or freedom zero is good, but how engineers/companies who develop free software make survival? Donations? If I am already a billionaire, I totally support your point.
> If you are saying AGPL's virus like behavior is much more severe than the GPL's virus like behavior
Well, it is, since it extends GPLs coverage to not just "linking" (a hard to define term) but also explicitly even to automation scripts.
But I'm also saying it's not just a difference in degree, but in kind.
> If I understand correctly, the open source action is only required when you "re-distribute" it. So, if you play it only by yourself and never give your modified software to anyone else, it is OK for you to keep all code close.
For GPL this is true. For AGPL it appears to apply to any artefacts or other public interactions too.
> Only in a step that you want to re-distribute the software (or the service) to people (like external user or other company) who you don't want to show source code, you are facing violating the AGPLv3.
Maybe. It's untested in courts. A very reasonable interpretation (that I subscribe to) if your BooksOnlineExample.com uses AGPL for backend storage, then that is covered by AGPL (but not GPL).
But even worse. If you use some AGPL software to compress some data as you transfer it to your backup tapes, then you are using this AGPL software in order to run BooksOnlineExample.com (after all, without backups you don't really have a service), and thus your backup script could very well be in scope for AGPL and may have to be published.
> But generally speaking, in this step you already have a plan to make money out of external people (like user or other company), so fair enough to pay a fee for commercial license.
Ah, but AGPL is not about covering the "making money hole". It's about the "cloud hole". I would argue that GPL never had any intention of preventing people from making money.
Do you think Linus is upset that maybe tens of thousands of companies have their own patches to Linux to run their service? Do you think he's upset that even the ones that don't patch the kernel don't publish their kernel config. (I don't know if you've ever built the kernel, like "make menuconfig", but this is definitely not just "settings", but actually a vital step in order to "reproduce the same binaries as run on your production servers")
GPL was extreme when it was created. Compare it to the BSD license. Then AGPL came along and just went absolutely off the wall by having your interactions with the software bind you to publish.
> "free software" or freedom zero is good, but how engineers/companies who develop free software make survival?
To be clear, are you saying that the main goal of AGPL is to have people NOT use it? Because people who do accept and abide by the terms of the AGPL license do NOT pay for it.
AGPL only prevents use. You're assuming all AGPL software is dual-licensed, which is very much not the case. Luckily very little software is AGPL.
If it's about money, then why use AGPL at all? Why not just have a commercial license? Because you're not giving anyone even the most basic freedom with AGPL.
If the goal of choosing AGPL is to get paid or not use it, then that's just commercial software. Which is fine, but don't call it free software, since it's anything but.
Ok. Actually I never (and don’t know who) call AGPL software a free software. Let’s just call it AGPL software! Problem solved.
Just curious, if AGPL is so evil, who made it for what kind of purpose from the beginning? You give me an impression that AGPL is totally wrong and shouldn’t be born.
I am not saying that AGPL is born to prevent people to use AGPL software. Instead, AGPL definitely encourages people to use for free under the license, or use it after purchase commercial license. Why you have impression that AGPL was born to let people not use the software?
Like MongoDB, it selected AGPL from the beginning, and many people were using it (so you can’t say AGPL stop people to use MongoDB), until some big commercial companies began to deploy it in cloud and violate AGPL (refuse to open source). This hurt the protocol and MongoDB, so MongoDB decided to change the license to a more explicit and strict license written by themselves to rule explicitly that if you deploy the MongoDB in cloud you should be open source. Otherwise you need to purchase a commercial license. From this point of view AGPL or the more strict MongoDB protocol find a good balance between open source and commercial usage. Please tell me if MongoDB uses more free software style license, like GPL, Apache, MIT, I guess many companies will use it in non open source style without violating the protocol, then how MongoDB can survive? If MongoDB can not live a good life, who will contribute to it, maintain it, help user continuously? MongoDB dies and the world gets nothing. Happy ending?
I am glad that google doesn’t like AGPL. To me this implies that the thing, that is not liked by big company, could be interesting. Google has become a gigantic monster. AGPL just prevents the big companies , like google, amazon, to use open source software for free.
> if AGPL is so evil, who made it for what kind of purpose from the beginning? You give me an impression that AGPL is totally wrong and shouldn’t be born.
Then I have succeeded in conveying my opinion. :-)
I think it was made with good intentions, but without thinking through the repercussions. It's made for a world where everything is opensource, and everyone has incentives to keep it that way.
But it's a fantasy world that doesn't exist. If all open source OSs were AGPL, then that would not force Google to start publishing their internal drivers. It would force Google to write their own Unix-like OS. It's a lot of work, yes, but especially if it's only for your own purposes it's not that hard. And they've done it before.
> Why you have impression that AGPL was born to let people not use the software?
Like I said any serious (I don't mean commercial) use of software requires automation and other surrounding stuff to make it work in a given environment. Yes, you can run MongoDB for fun at home, but considering that I've written scripts for my Ubiquity access points to collect some data, I'm glad that their software isn't AGPL. Even in my home use I would be forced to publish those scripts. Because it's not just me the legal entity that uses my access points. It's also my friends and family. So I'm in scope
So like I said and tried to give as much proof as possible for, there is only two ways to use AGPL software:
1) Violate the license. (by not publishing everything that touches the software)
2) Purchase another license.
(2) is usually not possible. Most software is not dual licensed.
(1) is not really using the license. If you don't agree to the license then you have no right to it. It's essentially software piracy.
So neither (1) nor (2) is actually using AGPL.
To the extent the software in question is used, it's not used under AGPL.
But I was mostly responding to "so everyone can just buy a commercial license" (but see (2)), which just means AGPL is only useful insofar as it doesn't exist.
> Like MongoDB, it selected AGPL from the beginning, and many people were using it (so you can’t say AGPL stop people to use MongoDB)
MongoDB is probably the most popular, yeah. Note that OpenBSD still uses POVRay 3.6, because 3.7 changed to AGPL.
I still maintain that most people who use MongoDB are violating the license, so they're not really "using" the AGPL.
> until some big commercial companies began to deploy it in cloud and violate AGPL (refuse to open source). This hurt the protocol and MongoDB, so MongoDB decided to change the license to a more explicit and strict license written by themselves to rule explicitly that if you deploy the MongoDB in cloud you should be open source
I was not aware of this. So you're saying AGPL failed at the one thing it attempted to do, which is to plug the so-called "hole" of cloud?
> From this point of view AGPL or the more strict MongoDB protocol find a good balance between open source and commercial usage.
"Open source" in the sense that the source is available for viewing? Yes. But most of the time that's not what that means.
From wikipedia:
> Open-source software is a type of computer software in which source code is released under a license in which the copyright holder grants users the rights to use, study, change, and distribute the software to anyone and for any purpose.
"For any purpose". That's freedom zero, which AGPL doesn't have.
Same with these recent licenses I've seen where the author has said "GPL but can not be used by the police", due to the author's political views. That's not what "open source" or "free software" means.
> Please tell me if MongoDB uses more free software style license, like GPL, Apache, MIT, I guess many companies will use it in non open source style without violating the protocol
Probably yes. I know at least one FAANG company that has purchased a non-AGPL license of MongoDB. But like I said that's not always possible. And my initial comment of "nope nope nope" is the legal stance frow actual tech lawyers I've discussed this with.
But curcially: This is intentional! Open source explicitly allows use for any purpose, even if that purpose is to interact with non-opensource. That's not a bug!
> If MongoDB can not live a good life, who will contribute to it, maintain it, help user continuously?
But this is two different questions. As I see it AGPL is about politics, not money. Most AGPL is not dual licensed.
As for maintaining. If you're a company (say Google) that runs GPL software (say the Linux kernel), then it's better to upstream your patches, when they are not specific to your proprietary internal systems, than to fork the code and have to manually apply upstream's patches.
Hell, the BSDs are still alive, and they even allow redistributing the binaries without providing source code!
The money question is a real one since free software began, but AGPL doesn't solve it, nor did it ever even attempt to solve it.
> I am glad that google doesn’t like AGPL. To me this implies that the thing, that is not liked by big company, could be interesting.
This is a terrible argument. I'm sure Trump also doesn't like it. The enemy of your enemy is not necessarily your friend. You should look at why they don't like it, and see if those reasons apply to you.
Google also doesn't like global warming or covid-19, but I don't see you out there releasing freon or licking ventilators.
Also note that this means none of the, what, 100'000 engineers working for Google are allowed to touch your software. No, not even contribute to it on their own time (with one exception: https://opensource.google/docs/iarc/).
Your community will shrink just because of that.
> AGPL just prevents the big companies , like google, amazon, to use open source software for free.
No, it prevents everyone from using it, as described.
Also: Using software for free (in both senses of the word) is literally what opensource is for.
"free software", "for any purpose", beautiful target. But maybe it can not be achieved in one step.
People select a license for purpose. No matter what is the purpose, the developer is free to choose, the user is free to accept or deny. If the license really brings some big hurt, people might change later.
Yup. There's nothing illegal about this private contract. I'm just saying it's a lose-lose license for both parties.
For authors:
AGPL is counterproductive to its stated purpose, and will only drive away users and contributors. AGPL is not "open source" or "free software". If dual-licensed then you are essentially releasing commercial software. And that's fine. But own up to that. If not dual-licensed then pretty much every user will violate your license. So what was the license good for?
For users:
There is no practical way to use AGPL software without violating the license. Everything you do with AGPL software incurs a huge legal liability. It is not open source or free software. If it's dual licensed, then pretend only the other license exists. If it's not, then pretend this software doesn't exist, and move along.
Actually, there is one way for authors to derive value from AGPL. It's not ethical, but it exists. Release your AGPL software, and wait for reports of a company using it. Then sue them. Because they are pretty much guaranteed to be in violation.
Not possible with an RTL SDR dongle. Not only are they not able to handle enough bandwidth (Wifi needs a minimum of 20MHz bandwidth), they can't transmit either. There's some other SDRs like the HackRF One that might be able to do it, but you're looking at needing two of them (one for RX one for TX) unless they can switch modes fast enough (not sure on that).
https://openofdm.readthedocs.io/en/latest/
(Modern) WiFi shares a lot of similarities to the physical layers of LTE/5G NR in their more basic modes, so this is useful well beyond WiFi.