Muse Group Continues Tone Deaf Handling of Audacity | Hacker News Reader

Muse Group Continues Tone Deaf Handling of Audacity

hackaday.com

117 pointsnickthegreek67 comments

The subject is telemetry, but the article calls it "tracking code". I would be curious to know if the writer actually knows that the telemetry data is enough to track users, or whether they're just exploiting the recent FUD about telemetry.

Edit: To clarify, "tracking" means that you're following a particular user around. "Some user pressed the Audacity record button at 13:04:42 Sunday" is not tracking data (although with sufficiently granular data you could do fingerprinting (which is tracking), the countermeasures for which should be obvious) - "User #1934602 pressed the Audacity record button at 13:04:42 Sunday" is tracking, even if it's anonymized.

There are different levels of privacy that people care about (e.g. some people are ok with anonymized tracking, while others don't want tracking at all). Conflating them is an underhanded tactic used by people to emotionally manipulate others. Furthermore, "non-tracking statistics" is a category of things that few people care about, versus "anonymous tracking", so conflating these two is particularly egregious.

They swear they are implementing telemetry, but their privacy policy implies tracking. You don’t need to worry about minors or handing personal information over unless you’re storing it.

Non-personalized telemetry and crash reports would have been fine to me, but none of their discussions have convinced me that it’s where they would stop (or even really, where they’d start).

I’ve since moved to a paid option, and feel good about the move so far.

> They swear they are implementing telemetry, but their privacy policy implies tracking. You don’t need to worry about minors or handing personal information over unless you’re storing it.

Good point - reminds me of a principle I recently heard someone espouse, "Disregard whatever promises a corporation/individual in power makes, and only pay attention to their legal constraints."

I don't agree with the last statement.

Just because you have the legal right to be an asshole doesn't mean you are an asshole. And conversely, the law can be broken, and clever loopholes can be exploited. There may be consequences, but it doesn't you will get repaid personally.

For me, privacy policies are just indicative. I try to approach the problem considering incentives, risks and benefits. What are the consequences for breaking the promise, for me, and for the company. For the company, imagine yourself as a shareholder, you want to maximize your profit, you know that by breaking your promise customers will be unhappy, will they go to the competition? is your image a valuable asset? is the short term profit worth it? For you, what is leaked? How will it affect your productivity and security? Can you easily switch to a competitor? At what point too much is too much?

If I only cared about legal constraints, I would get into every scam. I mean, advance fee fraud is illegal, so that Nigerian prince cannot take my money, right?

>> Just because you have the legal right to be an asshole doesn't mean you are an asshole

If they're explicitly carving out the legal rights to be an asshole, I think it's fair to assume, regardless of what they say, they are going to quickly become a giant asshole.

I've literally never seen a contract that contained a prohibition on being an asshole. If you are presented with a contract that doesn't contain such a condition it doesn't tell you anything about the intentions of your counter-party

Corporations are obliged to their shareholders, not their consumers. Furthermore, if the service is marketed as free to downstream consumers, those same consumers are more likely in some way the product. Therefore, any action that increases shareholder confidence in the company is liable to be taken. Harming downstream consumers can sometimes be damaging to shareholder confidence, but isn't necessarily.

In essence, companies are incentivized to be "assholes" when it furthers their valuation. Unfortunately, being an "asshole" is very often a lucrative move as long as it's done carefully.

I don't believe everyone who works at a large corporation (example being Amazon) is evil and immoral. However, collective action taken by the company on large scales has shown in many cases to have "asshole" effects. Also, fuck Jeff Bezos.

There's a pretty good write up on the topic [1] over on arstechnica. Author of the above is clearly overreacting or trying to ride some kind of rage-train to more clicks.

Especially the quote from one of the authors of audacity which states "telemetry collection is optional and configurable at any time"

Wether it's opt-in or opt-out is a smaller issue IMO. Like the article on Ars also states, even Firefox telemetry is opt-out, and you don't often see people raging about FF not being privacy sensitive enough....

[1]https://arstechnica.com/gadgets/2021/07/no-open-source-audac...

For once, I disagree with Ars Technica.

Sure, what they're doing right now appears not to be nefarious. But they're putting language into their user agreements that opens the door for them to be nefarious in the future with no warning or recourse.

Without recourse? Audacity is still Foss right? If they screw up bad enough you can just fork em! And I'm sure it will be big news when they actually do mess up, given how big news it became when they didn't even, so you'll probably know about it.

> you don't often see people raging about FF not being privacy sensitive enough....

There are actually a bunch of HN threads about just that.

The article calls it telemetry, and says the fork was created that "removed any current or future tracking code that was implemented upstream." Which is true, even if you don't want to call their telemetry "tracking."

Further, the subject of the article is the CLA, and the entire telemetry part is just to recap recent events.

The subject is their ridiculous new EULA, which includes telemetry. It also bars anyone under 13 from using the software, which is a violation of the actual software license.

People hate the telemetry the most, I think, but it's just one example of a pile of bad ideas baked into their privacy policy.

The IP address is what typically turns "not tracking" into "tracking".

The source IP address is delivered with any IP packet. If there's a dividing line related to the IP address it has to be storing it, not having it available.

The point is that as long as telemetry is delivered over the internet, it is also tracking. There is absolutely no difference whatsoever unless your telemetry is delivered via Tor or some other mathematically proven means of nearly-anonymous transport.

There is no way for a user to tell the difference, and it's very difficult for experts. So for all intents and purposes telemetry and tracking are the same thing.

That the Muse Group is asking for a CLA that permits them to use the code in future non-Free software is cause enough to fork the project and walk away from Audacity. Just because the Muse Group, in its current incarnation, isn't doing anything particularly odious at the present time doesn't mean that a successor entity won't.

Audacity was, is, and will always be GPL. The CLA does not change this. The CLA simply provides a dual license option for distribution through channels that may not be GPL friendly (ex: app stores).

Look at the VLC/Apple issue. This is an insurance policy against something similar in future.

CLA is not to be able to create a paid version of Audacity, that is fundamentally against our core beliefs. Creators should have free access to software; the money is in content.

In addition, the CLA allows for the ability to share code between the MuseScore and Audacity projects, greatly accelerating development. MuseScore has had a CLA in place from the beginning so it is only possible to share code between projects if similar CLA is in place.

The next version of MuseScore will introduce a completely redesigned/rebuilt UX, VST3 support, realtime effects, a redesigned mixer, expanded MIDI support, and a proper sequencer is soon to follow.

All of these features have been popular requests of Audacity users and will greatly (and quickly) extend the capabilities of Audacity.

Not applying a CLA actually limits the potential of the project (availability on popular devices and using code from MuseScore) more than applying the CLA.

That all sounds great. The CLA says:

You hereby grant to Company , a perpetual, non-exclusive, worldwide, fully paid-up, royalty free, irrevocable copyright license to reproduce, prepare derivative works of, publicly display, publicly perform, sublicense, and distribute your Contribution and such derivative works.

Someday "MUSECY SM LTD, an affiliate of MuseScore and Ultimate Guitar" could be acquired or come under the control of an entity that does not share the "core beliefs" the CLA was drafted under. I wouldn't be comfortable relying on beliefs in lieu of a legal document spelling out exactly what contributed can be used for. The language in the CLA is what matters, not beliefs.

I haven't contributed to Audacity so it's not a practical matter for me. I wouldn't contribute to a project with a CLA that grants such a broad license. I'm a minority, to be sure, but there are probably others who feel the same way.

I've been burned, in business relationships, by verbally-articulated intentions that weren't codified in contracts and weren't honored. The whole "I thought you said..." and "I meant..." game has made me very wary of accepting terms that aren't articulated as part of a legal agreement. If something is important enough to agree upon it's important enough to put in writing.

We do understand that the CLA will discourage some from contributing.

Audacity is transitioning from an entirely voluntary development team to a team of many engineers, designers, testers, project managers, and a product manager all working full-time on the project.

While we welcome and encourage community contributors to the project we anticipate that most of the contributions will be from the dedicated team.

MuseScore underwent a similar transition to where more than 85% of commits are now from the dedicated team, while the number and frequency of commits has also significantly increased.

We expect Audacity to be similar.

I'm looking forward to replacing Audacity with Tenacity. I don't know what's wrong with Muse Group, but virtually all the interactions with the communities of the applications they buy have been negative. The company clearly has some sort of culture issue.

The actual issue is a bit different than what is perceived.

This comes down to the actual definition of community.

Our priority is the contributor community and the user community as a WHOLE.

Of those complaining on Github and online, not a single one of them have contributed a single line of code to the project. Not even one.

Their complaints and concerns are also not very representative of the actual user community (1.2% of users are running Linux, while the overwhelming majority of complaints were from Linux users).

So, in addition to the contributor community and the user community as a whole, I do not see any other community.

There is this nebulous broader FOSS community that is often referred to. A group demanding to impose their version of idealogical purity on the project, yet not contributing a line of code.

But if they are not contributors and not representative of the actual user community... why should the project be forced to cater to the demands of 1.2% of the user base at the cost of convenience to the other 98.8% of users?

How absolutely insane would it be for any other software project to be beholden to 1.2% of their actual users?

Don't get me wrong, we are extremely committed to FOSS, and our motivations are actually quite ideological - we believe every creator deserves equal/free access to professional quality software.

The difference is our ideology is not the same as this very vocal minority that is primarily anti-corporate and whose demands limit capabilities for the overwhelming majority of users.

Thanks for replying, Daniel, but your team seems to have a major culture issue regardless and I think the defensive and somewhat random/rambling tone of your comment clearly reflects that.

I run OSX/Tenacity, not a Linux user looking for idealogical purity - just a long-time user that sees a lot of red flags on the wall with your acquisitions. Your comments in the musescore-downloader project after the legal threat were simultaneously the first red flag I was made aware of and the first time I had heard of the "Muse Group".

For a director of strategy, your strategy and how you deal with the users and fans of the software/good will you've purchased seems less than ideal to this outside observer. Good will was generated by a long-term interaction between the community and the open-source project and you've managed to squander it and apparently continue to do so.

Again, which community are you talking about, exactly?

I only know of two - the contributor community and the actual user community.

I hope you aren't suggesting that I'm not part of your user community because I don't fit in your box and dislike the things your company has been doing. Honestly, I'm surprised that someone with your position in your organization has no idea how to communicate with people that use your software.

Regardless, this has cemented my transition to Tenacity and I'll be recommending to everyone in my circle to move on from Audacity. I hope one day you'll see how you and your company are poisoning the well, but I don't hold out a ton of hope that your company isn't suffering from a seriously rotten culture and inability to admit mistakes.

Anyways, in the unlikely event that anyone is actually reading this thread, marcan's comment [1] and the legal thread [2] was my first intro to the terrible way that Muse handles acquisitions and I haven't seen anything that suggests the company is handling things any better.

[1] https://news.ycombinator.com/item?id=27005385 [2] https://archive.is/w8O3L

This is probably controversial but I think they've handled it pretty well and offered reasonable options. It seems the people doing the forks think telemetry == adware, no matter what and will never be pursued otherwise.

I think this is a classic example of "Once trust is lost is next to impossible to regain"

They completely screwed the launch of their "telemetry" collection, so bad that no mount of "reasonableness" is even being considered by many in the community.

Agreed. They should have communicated better initially.

A good reputation arrives on foot and leaves by horse, as the Dutch say.

How can they move the source code from open to closed source? They don’t own the contributions. I guess they hope the small contributors won’t mount a legal challenge or they will pay them off to transfer the rights?

Seems like a lot of effort for this. What is their ultimate end game? I’m not sure that this is worth all the money they have invested is it?

> How can they move the source code from open to closed source? They don’t own the contributions.

It's in the article. They are having the contributors sign CLAs, which would allow them to do this.

The ones who don't sign the CLA, they will re-write that code themselves to get around it.

I'm not sure whether you can actually do that. The law works on provenance, not on bits.

There are techniques for reproducing copyrighted code in a legal way. The simplest one would be to simply remove all the copyrighted content (assuming it came from minor contributors) and clean-room a replacement.

Didn't racket do much the same with their switch over to mit?

The clean room method breaks the provenance.

This is not just writing stuff from scratch like all of us have done at one time or another with our own code.

Maybe they can use GitHub's Copilot to "rewrite" the code :)

The CLA provides for a dual license option, but does not impact the GPL nature of Audacity.

Audacity was/is/always will be GPL.

It’s hard to find but contributors are required to sign a CLA which allows the project owner to do what they want with the code.

https://www.audacityteam.org/cla/

Holding out some hope for viable forks! I have a machine specifically reserved for attempting builds but I still remain pretty baffled over this wxwidgets business. My previous investigation resulted in failure because the project made reference to a resource that has since made unavailable.

I still have a 2.2.x version that I use for day to day recording, flakey, unstable but works if I fiddle enough with it.

Sounds like any recording equipment of sufficient age. I get a buzz unless I wedge this piece of cardboard into the jack kind of fiddling?

lol yeah! I seem to have to fiddle with the input source, but it could be any number of things, including my linux installation.

Here are the commits I could find that remove the "telemetry:"

commit 2a37cd19a022fd6bc63d1c0a403840eb300dfd1c Author: Cookie Engineer <cookiengineer@protonmail.com> Date: Sun Jul 4 10:22:57 2021 +0200

    :shit: Remove Breakpad Crash Reports

commit 5728dd542fac39c0673dbb1c9d716838a25d69bd Author: Cookie Engineer <cookiengineer@protonmail.com> Date: Sun Jul 4 10:20:24 2021 +0200

    :shit: Remove Update Check

commit bbf352d36d725335962718f91fc3591a1037f39b Author: Cookie Engineer <cookiengineer@protonmail.com> Date: Sun Jul 4 10:19:04 2021 +0200

    :shit: Remove Sentry Reporting

Audacity/Tenacity is a really good application, I hope the fork gets some dedicated maintainers to keep it alive.

For those who didn’t see the news, the maintainer of the first major fork was allegedly attacked with a knife by someone from 4chan and stepped down https://news.ycombinator.com/item?id=27765210

GitHub thread with links to some 4chan posts: https://github.com/tenacityteam/tenacity/issues/99

I've been following this all very closely and I have not seen any evidence to show that any physical attack has ever happened, including the alleged police report in Germany, by cookie, which others can not seem to find.

So I would not take what cookie says as fact at face value.

Seconding this. I perused a few of the threads in question and while there was significant grumbling there wasn't the level of fury usually associated with actual harassments, let alone a physical attack. The harassment-happy lunatics at Kiwi Farms also failed to significantly care about this issue. I will remain highly skeptical until I find non-anecdotal evidence.

Sneedacity is a better name anyway.

The guy made it all up.

I've seen screenshots of his GitHub Page, and I'm not sure why he put the n-word in his GitHub status so many times. As a thinly-veiled joke?

Seems like Muse could handle it better but has Audacity kept up? I used it at first but moved on to Reaper quite some time ago.

Audacity is pretty good if your focus is editing/tweaking/cutting/splicing individual/small numbers of samples. Haven't at all felt the need for something more featureful still. Ripper seems to have some other niche.

( FWIW, Audacity is a million miles better than it was 10 years ago (aka it's more stable) )

I've used both recently, here's my thoughts.

Reaper's non-destructive editing is bloody priceless when compared to Audacity's.

Plugins for reaper are... less well integrated into the application as a whole. Audacity makes for a great ACX mastering tool because of the open source, purpose made, plugins they have available.

Reaper's ability to add SFX chains to tracks without modifying the track directly is pretty incredible. You can both live preview SFX changes, and change settings without having to undo between changes.

I miss spectrograph editing when in Reaper. Word is there's an external plugin, but... see point 2.

Maybe stability depends on your use case. For me, Audacity has been much less stable in the last three years than it was 10 years ago. For the past three years, I've had multiple cases where features broke with an update. I (sometimes) record a podcast with a friend, and our flow involves "not updating Audacity anymore, just so we don't have to deal with bs regressions."

Reaper is a full-fledged DAW. Audacity is just a barebones audio editor.

Think of it this way: Audacity is nano. Reaper is fully-kitted-out Emacs with everything in ELPA.

Audacity is free to use. (I am a Reaper user.)

I can't tell if "Tone Deaf" was an intended pun or not.

I can!

You must have perfect pitch

I might be missing something, but what's the problem with just having distros patch out the misfeatures?

There's a hundred billion distros, so that would be a hundred billion forks.

You've got like 4-5 major upstream distros though

Given the seeming poor faith in some of Muse's explanations for some of the changes, I rechristen Audacity as Mendacity.

More seriously, I propose a general disintermediated solution to the general problem of bug verification via automatic reports:

1) All crash reports are opt-in.

Reports are created locally after a crash or other event. They are added to a log folder. Users are given tools to examine the report data.

Then either:

A user can choose to upload any reports they want. A user can have already chosen to upload all reports automatically.

Either way, transmissions include nothing but the reports logged for review by users. A condition that can be verified by examination of the programs source.

The transparency of what is sent, and requirement of consent, both strongly incentivize reports constructed to be anonymous and limited in terms of any possible nefarious use.

2) The transmission goes to a third party bug identification agent of the users choosing. Users can make their choice based on a public list of such agents and their sites with their public reports.

3) The bug identification party is a third party, separate from the developer group, that works to identify and characterize the bug in the source code.

Bug characterization reports are then created that include a list hash values for each of the crash reports that contributed to the report.

The bug identification report is then made available publicly so users can be aware of it and developers can use it to identify and implement solutions.

The public disclosure of the bug characterization incentivizes a report that reveals little or nothing that could be interpreted as privacy violations.

An exception is made if the bug reveals serious security concerns, in which case the bug identification report can be made to developers earlier than public release, with assurances in writing that developers have a certain amount of time to act before the bug identification is made public.

Instead of immediately making the bug identification public, only its hash is made public so users can be aware of an anonymous bug fix in progress.

Developers in that window of time have the opportunity to fix the bug, determine that a bug fix is not practical or important enough, or they will continue working on the bug, etc., but must be transparent about either within the time frame or be seen to have violated trust.

At the end of the window, the bug report agent will publish the bug report, and the developers actions (fix, decision not to fix, decision to take more time, etc).

Note that the bug report agent can operate unimpeded without any cooperation from developers if there is none. But developers certainly have some incentive to take the bug reports seriously.

The thing to do is use rust to build something much better than audacity that is owned by a not for profit foundation like Ghost.

The thing to do is not be an asshat and fuck up something that was doing just fine before your asshattery.

Maybe you guys can find a middle ground here, and not be an asshat with rust? We definitely need rust in this equation.

Reply on news.ycombinator.com