>
Also, it seems very strange to complain about companies collecting data that they're required to collect by law.Thanks for clearly phrasing this, because I think this is exactly what I'm complaining about.
Audacity is, in fact, not required to collect anything by law, and for a very long time, it did not. It's a piece of software that runs on your computer. It doesn't even require you to have a network connection. It doesn't require the developers to even know that you exist.
No law (in any slightly free country, at least) prevents the existence of software that doesn't phone home. WordStar wasn't illegal. Emacs and Python and ffmpeg aren't illegal.
It is true that once you start collecting data, legal requirements start to apply, and you need to comply with requests for that data. That's a really good reason not to collect it in the first place.
If all you have is a stack trace, and you have nothing personally identifying (including filenames), then the data you have is useless for any other purpose besides fixing the bug. You're protected from legal requests, you're protected from illegal requests, you're less of a target of hacks, and so forth.
Fedora's ABRT, for instance, goes out of its way to ensure that any crash data they collect is suitable to make public: https://abrt.readthedocs.io/en/latest/ureport.html#ureport That's a pretty good way of squaring this circle. If the data is okay to make public, then by definition it's not a problem if anyone (law enforcement or otherwise) wants to see it, and you don't have to rely on their good intentions.
Ubuntu disables Apport by default in release versions, according to the page you link: https://wiki.ubuntu.com/Apport#Why_is_apport_disabled_by_def...
KDE doesn't claim to collect information about crash dumps; it just collects statistics about how it's used.
It is, of course, harder to debug things from just a list of symbols. And as you say, it's not feasible to teach everyone how to use gdb. So there's a tradeoff. You acknowledge that the software isn't going to be as good as possible in terms of bug-free-ness (or you find other ways to address that problem, like fuzzing or static analysis), but in exchange, you make the software better in terms of how it treats the user's privacy.