Any reason you keep calling Wireguard by the name Netguard? Is there some background story?
On another of your points, so far as I know, OpenBSD worked closely with the Wireguard developers before Wireguard "landed" in OpenBSD.
I made a mistake. I must have mixed up WireGuard and Netgate.
The problem is around Macy's commits: whether that was honest human error, carelessness, intentional or problems that were difficult to be foreseen. Not the original code of WireGuard. Netgate simply wanted WireGuard in Pf Sense, and used FreeBSD as a litmus test.
It's saying it was too close for comfort for going into a FreeBSD release. It was in development, where it's well known that, that's not for production systems. FreeBSD current is known for being for testing grounds. Stable is kind of like this way too. The tone of the article is: everyone involved screwed up badly and has a stain on them from this.
Damage was done for Pf Sense and Netgate. It looks like their intention wasn't for bad code to get in. They asked someone who had a reputation for being a good developer and had commit privileges, alternatively the article says he had problems unrelated to software development. Maybe they'll update their release to be without WireGuard. Wireguard's reputation was also hurt from this.
I also question the author's level of expertise for making conclusions, and the associations made. IE, implications of GPL2 code making into the kernel of a development branch, as some GPL2 code is accepted in base. FreeBSD had GPL2 code in its base before, such as GCC, Binutils and modules/drivers. If that's a big deal, that's easily an honest mistake, because a lot of modules in FreeBSD are GPL2, and someone simply moved something from modules to the kernel.
Often, program code isn't portable. Maybe the committer tried to get it in before a release, and ended up adding code to get it in, then made a mistake by moving a FreeBSD module (where GPL2 is allowed) to kernel (where it doesn't belong). Maybe other code was added, as FreeBSD's base is rather slim, and a lot of ports and Linux program builds aren't slim, to simply get it to work. As a separate example, a lot builds with GNU make, but more compatibility work is needed to get BSD make to work. The case isn't about which make was used (as this was a common example), but other software (BSD make was obviously used). However, FreeBSD did replace GNU's binutils for FreeBSD 13 with Elf utils. Adding a bunch of software can make programs work, but the core issue is compatibility issues to make it work with what's in base.
Update:
WireGuard: fast, modern, secure VPN tunnel
www.wireguard.com
License
The kernel components are released under the GPLv2, as is the Linux kernel itself.
Other projects are licensed under MIT, BSD, Apache 2.0, or GPL, depending on context.
GPLv2 getting into the development kernel was an honest mistake, where they didn't keep track of everything. All the WireGuard author has to do if they choose, is dual license kernel components which they are the full author of that are needed to go into Pf Sense and FreeBSD.
The harsh criticism that Macy criticized someone else for using GPL code, then did it himself goes overboard. I was likely an honest mistake.
About Macy: What are squatter rights and basic tenant protections in California? Tenants deserve rights, and I say leniency. Squatters are arguably another topic. This is why I wondered heavily how much relevance of what someone did outside of software, had to do with committing code. Sometimes it matters.
This problem has a lot to do with trying to get code in before a release. The insinuation is that Macy intentionally put bad code in. Maybe he did, as the author implies, but that we don't know right now. It's more than likely, Macy's insertion of GPL code into the FreeBSD development kernel wasn't intentional.
This is why it's good not to rush things in to a newly coming release.
When more information comes about, the article itself may be a minor stain on Ars Technica more than on FreeBSD. Not for saying more standards need to be implemented, but for the approach it took.