In addition to what others said, Valgrind is GPL-licensed. That conflicts with the OpenBSD copyright policy (https://www.openbsd.org/policy.html), which says:
“The GNU Public License and licenses modeled on it impose the restriction that source code must be distributed or made available for all works that are derivatives of the GNU copyrighted code.
While this may superficially look like a noble strategy, it is a condition that is typically unacceptable for commercial use of software. So in practice, it usually ends up hindering free sharing and reuse of code and ideas rather than encouraging it. As a consequence, no additional software bound by the GPL terms will be considered for inclusion into the OpenBSD base system.”
“The original Apache license was similar to the Berkeley license, but source code published under version 2 of the Apache license is subject to additional restrictions and cannot be included into OpenBSD. In particular, if you use code under the Apache 2 license, some of your rights will terminate if you claim in court that the code violates a patent.”
OpenBSD begrudgingly made an exception for LLVM/Clang, after vocal opposition to the re-licencing. It currently uses LLVM/Clang 13 and has been making progress towards 15. Licensing is not the problem here. Most of the sanitizers are simply not enabled in the version shipped in base, and require runtime libraries that have not been ported to OpenBSD.
Valgrind exists in ports, but it is ancient and broken. It does not play well with various security mitigations.
> OpenBSD begrudgingly made an exception for LLVM/Clang […] Licensing is not the problem here
If it isn’t a problem, why do you say “begrudgingly”?
I think they are pragmatic but also do find it a problem. Why else would they say “source code published under version 2 of the Apache license is subject to additional restrictions and cannot be included into OpenBSD”?
I didn't say it wasn't a problem. I said it was not the problem here. Important distinction.
Licensing is not the reason for the sanitizers not being enabled in the default build, a lot of stuff isn't. If it were supported, it would probably be delegated to the ports version, along with the analyzer, additional llvm tools, cross-compiling, etc.
I think that’s what your parent is saying too. The last non-Apache-2-licensed version of the Apache HTTP server was version 1.3.x, and because the OpenBSD project did not accept the Apache 2 license, they forked the Apache HTTP server’s 1.3.x code base.
It's not coincidental. It was early in the Apache 2.0 lifecycle that the Apache License 2.0 came about (google says 2.0.49). OpenBSD's continued maintenance of a 1.x fork from 2004-2011 or so was mainly about licensing.
The point that Theo de Raadt is making is that this line of thinking is wrong*. Most of the FSF/GPL advocates never seem to look at the why's around people disliking their approach. See https://lkml.org/lkml/2007/9/1/102 as an example. OpenBSD helped the Linux project dual license the ath5k driver. They were thanked by GPL advocates illegally trying to strip the BSD license after the fact. Leaves a bad taste, and one that many of us won't forget. You can have your forced freedom.
* "GPL fans said the great problem we would face is that companies would take our BSD code, modify it, and not give back. Nope—the great problem we face is that people would wrap the GPL around our code, and lock us out in the same way that these supposed companies would lock us out. Just like the Linux community, we have many companies giving us code back, all the time.
But once the code is GPL'd, we cannot get it back."
EDIT: The pejoratives are why the FSF message gets lost on an awful lot of people. I admire what they are trying to achieve, the manner in which they go about it makes me not want to engage.
Theo de Raadt is the one who's wrong. When code goes closed source, you're locked out and can't have it at all anymore. When it goes GPL, you can still have it just by going GPL yourself.
“This is madness!
He has lost his mind!
This defies the first law of free trade.
Rule zero came before this rule one.
Freedom means you cannot dictate to anyone.” (emphasis mine)
I provided a reference for a portion of lyrics that fairly elegantly summarised the BSD position on freedom – that is it. Besides, it is a song and obviously it will take artistic liberties compared to an essay.
If you want to argue minutia related to things on that page other than the tiny lyric snippet, it is probably better that you send an e-mail to misc@.
They're describing libraries. By 'Linux', I'm assuming that you're referring to the OS distributions and not the kernel on it's own. And please drop the pejoratives.
There is seemingly a movement or line of thought that blames the success of “big tech” on permissive licenses. You do not see it as much on Hacker News, but it certainly has spread across IRC and many other forums. What is even odder is that a subset of it uses alt-right terminology to refer to both permissive licenses and their proponents. It is all very weird to experience as someone that entered the FLOSS community in the early 00s. Not to mention having had a personal conversation with rms bemoaning the license schisms and him explicitly expressing gratitude for the BSDs contributing to the larger FLOSS movement.
Both of those are very useful, but slow, especially valgrind.
I don't know OpenBSD, but presumably this is analogous to glibc's relatively faster memory sanity checking.
For GCC and clang you'd also want LSAN for this, not ASAN. ASAN is more accurate for edge cases, but much slower.
"Slow" here means that even for development the runtime can be prohibitively expensive.
E.g. I regularly run git's test suite, optimized/LSAN/ASAN/valgrind runtime is on the order of 3m/15m/30m/24 hours. The basic glibc sanity checking only adds a minute or two to the optimized run.
An advantage of any malloc based detection is also that you can run it on any existing binary. Whereas the likes of LSAN and ASAN require a custom debugging build (or to have that tracing overhead present in your production build).
This is available by default and integrates with existing tools (notably ktrace), making it easier to detect memory leaks on all platforms OpenBSD supports.
