In fact, with the software I mentioned above, you generally don't even get it directly from the developer you get it from a redistributor like a Linux distro, who may have modified it. The general cultural assumption is that if you want the software to get better, you have to participate, and if you don't participate, the developers don't owe it to you to fix your crashes.
Some software like the Rust compiler will print out a crash report and ask you to copy/paste it into a GitHub issue on your own you can decide not to. Open source software generally does no automated crash reporting. I think this is a culture-clash question. My current temporary (and building) fork is available at GitHub, too and I would love to see this project being governed by a community of developers rather than a single owner that can potentially dictate integration of tracking mechanisms on others. Of course, a dialog where end-users could opt-in to everything would've been nicer than enabling/disabling it via build environment flags - but that could've been a simple rational discussion. Personally I think this is a classical miscommunication error, and it seems as the intent of Muse Group was to be as legally compliant as possible. I've detailed this more in my comment in the GitHub repository's issue to make sure others will read about it, too.
While I have been cautious and was trying to make sure that not any code could run by mistake (or false environment variable / ifdef checks down the line), I have to say that The Muse Group's intent seem to have been clearly that the code can be built without any of the tracking.Īll networking related features seem to have been optional, and could be disabled via environment variables like `HAS_NETWORKING` or `HAS_SENTRY_REPORTING` etc.
I've forked the codebase and removed most of the code related to networking, crash reports or sentry telemetry.