There's no way a program like Audacity has a legitimate reason to spy on users

Summary: Audacity's new management is making a huge mistake; but forking should be the last resort and there's probably still room for constructive negotiation

OVER the past 3 days many people spoke about the resurgence of an agenda we covered here before [1, 2]. We don't want to reproduce all the dramatic if not sensationalist headlines here, as we mentioned it in passing in some videos over the weekend (many new links about it can be found here; there are few more scattered around, but those dozen or so links from the past weekend ought to suffice). The short story is, clueless new owners of Audacity mused about pushing on with controversial changes during a long (holiday) weekend and many Audacity users are rightly upset. I'm among those Audacity users.

We've seen arguments about distro makers making 'soft' forks or removing the offending code (less likely to happen for proprietary operating systems)... or pressuring the owners of the software (they now want a CLA for Audacity) to muse a reversal in policy, seeing that the spying now extends to governments and would likely be oppressive -- not how it was initially sold to us ("improving user experience" and whatnot).

We've seen not a single fork that has sufficient momentum behind it (the ones we saw involve violating privacy with Microsoft at GitHub... to supposedly 'solve' privacy concerns); Audacity's new owner should muse moving away from that grave error to alleviate a need for such a fork. That's still doable. A fork should be the last resort or the most extreme course of action (otherwise it can be pointless and perish like Glimpse did).

An associate of ours has meanwhile prepared an AppArmor prototype (usr.bin.audacity) for blocking this behaviour, namely totally worthless Internet connections for a program that needs none (just in case opting out cannot be trusted in the binaries):

# vim:syntax=apparmor # initial prototype AppArmor policy for audacity # See : https://manpages.ubuntu.com/manpages/hirsute/en/man5/apparmor.d.5.html

#include <tunables/global>

# No template variables specified

/usr/bin/audacity { #include <abstractions/dbus> #include <abstractions/base> #include <abstractions/user-tmp>

# No policy groups specified

/usr/bin/audacity rmPx,

owner /.Trash-*/ w,

owner @{HOME}/ r, owner @{HOME}/.Xauthority r, owner @{HOME}/.config/pulse/** rk, owner @{HOME}/.local/share/mime/** r, owner @{HOME}/.local/share/icons/ r, owner @{HOME}/.local/share/icons/** r, owner @{HOME}/.local/share/ r, owner @{HOME}/.local/share/recently-used.xbel* rw, owner @{HOME}/.audacity-data/ rw, owner @{HOME}/.audacity-data/** rw, owner @{HOME}/Desktop/ rw, owner @{HOME}/Desktop/** rw, owner @{HOME}/Music/ rw, owner @{HOME}/Music/** rw, owner @{XDG_DESKTOP_DIR}/ rw, owner @{XDG_DESKTOP_DIR}/** rw, owner @{XDG_DOWNLOAD_DIR}/ rw, owner @{XDG_TEMPLATES_DIR}/ rw, owner @{XDG_PUBLICSHARE_DIR}/ rw, owner @{XDG_DOCUMENTS_DIR}/ rw, owner @{XDG_MUSIC_DIR}/ rw, owner @{XDG_PICTURES_DIR}/ rw, owner @{XDG_VIDEOS_DIR}/ rw,

/etc/gtk-3.0/settings.ini r, /etc/fonts/** r, /etc/fstab r, /etc/alsa/conf.d/ r, /etc/alsa/conf.d/** r, /etc/pulse/** r, /usr/share/** r, /usr/local/share/** r,

/dev/shm/ r, /dev/snd/ r, /dev/snd/** rw, /proc/[0-9]*/mounts r, /proc/[0-9]*/mountinfo r, /var/cache/fontconfig/** r, /sys/devices/system/node/ r, /sys/devices/system/node/** r,

@{run}/** rw,

unix peer=(addr=@/tmp/.X11-unix/* label=unconfined), }

Let's try to resolve the conflict without a fork; conveying an intent to fork is sometimes enough of a motivating factor -- enough to discourage integration of antifeatures (or a removal later). That's just the GPL at work! This is Free software giving users more collective power/control over the development of a program. This is fine. But being too combative would likely not accomplish the best outcome. ⬆