The company has now three times in a row clearly shown a disregard for both users' and developers' interests. I'd conclude from that behavior that the stewards of audacity have no other interests than monetization and appropriation. A fork will probably be the only way out of this mess.

> developers' interests

As I understand it, it was the developers who sold it, whatever that even means with GPL licensed software. A fork that doesn't attract the main contributors is bound to fail.

So The Muse Group saw what happened to the user base of Freenode and thought to themselves “yes, we want some of that, and we want it quick”.

The only thing that would deter users and devs more than this license violations and blatant data slurpage and tracking would be to physically smear a dog’s turd on said people screen upon downloading any guise of the application.

Have an happy fork everyone.

$ cat "Salt-N-Pepa - Push It Lyrics.txt" | sed -e 's#push#fork#gI'

Nothing wrong with telemetry or legally tight privacy policies. People moaning should concentrate on helping to improve it. Its still, you know... open source.

If Audacity gets half as good as musescore all these faux outrage will be well worth it. Musecore is amazing!

Audacity has needed an update for years. Glad to see it happening and I will happily submit my telemetry data to get there!

Yep, it is open-source and it is going to be improved. As a fork where the first improvement was to remove the telemetry.

"...all these faux outrage..."

Do you honestly believe that both the users of Audacity and open-source developers just happened to all independently pretend to be upset about something that often leads to people getting upset (due to historical precedence), or do you thinik they collaborated on pretending to be upset?

They're both absurd options, I'm just curious. A lot of people on these boards seem to think that "fake" and "unwarranted" are synonyms, so I suspect this might be your problem. [It's not unwarranted either, though...]

> People moaning should concentrate on helping to improve it. Its still, you know... open source.

It's a guise to obtain free labour. You know we have laws here against that - company has to pay at least a minimum wage and you cannot volunteer for a for-profit organisation.

It’s really really depressing that software has become synonymous with spying on your users. What’s wrong with just releasing software that does what the user expects?

How’s the fuck did we get to this point? Why do software companies think it’s acceptable? Etc etc etc… moan, complain, sob….

It really pisses me off

As a developer myself, I've found telemetry and particularly crash reporting to be hugely beneficial to the development process. Some people call it "spyware" others call it reporting, the most important thing is simply that you can turn it off by choice if you are in the "spyware" brigade.

I can understand that but can't a crash report be a one-off that you choose to send in the event of a crash.

Not a continuous telemetry just in case that you have to turn off to escape.

“…a one-off that you choose to send in the event of a crash…”

…which is how things USED to work. And everyone was happy

One-off manual activities are a good model for end-user/consumer software that's used interactively by an individual human. That probably describes Audacity very well for nearly all users. So yes, the practice of optionally being able to attach a crash dump to a bug report is probably a good way to do it.

However, that's not a good model for larger systems that run continuously, are non-interactive, or span dozens to thousands of machines. While filing individual support tickets for specific problems is still useful and necessary in that case, it's not sufficient. At data centre scale, even reliable software crashes every day on some machine somewhere. If you have a huge team of administrators, perhaps they can manually examine all of those dumps, deduplicate and root cause them, and open tickets with their software vendors. But it's also quite reasonable to *prefer* that those crash dumps -- possibly sanitised in some well-specified manner -- be automatically sent to the vendor. Let them do the deduplication and root cause analysis; it is their software after all.

Should it be opt-in? Probaby in most cases, and CERTAINLY for interactive end-user software like Audacity. Is it a useful feature that can benefit both vendor and customer? Yes, it is.

So again, please be careful not to paint with too broad a brush here. What you're saying is true for applications like Audacity; it's not true for all software. Having to file individual tickets and manually attach crash dumps at scale most certainly does not make "everyone happy".

"I've found telemetry and particularly crash reporting to be hugely beneficial to the development process."

When my job included crash dump analysis, the full dump included the entire image in RAM (A standard Windows thing for full dumps), which happened to contain an unencrypted version of the users current data. We used to have to get GDPR consent for each and every dump that we took for analysis.

Why I can imagine it being useful in development, it's not necessary , as such it really should require informed consent with the default being opt-out.

You downvoters need to rethink things (with one caveat). Looking from the support and sysadmin side telemetry can be extremely useful, especially when the customer provides such gems as 'this is producing an error' without narrowing it down to which of the 100,000 possible items of that type on the system might be producing the error.

However, the large caveat is that telemetry needs to be OPT IN, and carefully explained exactly what is being recorded. I don't care how useful it is, you have no idea how private the data on the user's PC is, it shouldn't be on by default.

> particularly crash reporting to be hugely beneficial to the development process

That's already invasive, because companies were too generous with helping themselves to your data.

If you can't do proper testing, then crash reporting should only ever be opt-in and you should be paying the user for use of his or her time as a beta tester.

This.

No actual reply just wanted to emphasise the point more than just an upvote.

Have an upvote, then I don't have to reply to your reply saying I upvoted but didn't reply.

It's only because the overall user base was too small, that software hasn't been targeted like this at scale beforehand.

We've hit the L'oreal moment. Because you're worth it.

Turning the cynicism up to 11, you might find that someone has done the 'what if they fork?' calculation.

Just to depress you a little bit more.

Audacity could easily go the same way as OpenOffice or XFree86.

it's wrong that there are people, who have this (...) trait that they see EVERYTHING as a source of EXTRA money, and they don't stop, nosir, they just keep looking for NEW source, all their fucking, miserable cunty lives.

" It’s really really depressing that software has become synonymous with spying on your users. What’s wrong with just releasing software that does what the user expects?

How’s the fuck did we get to this point? Why do software companies think it’s acceptable? Etc etc etc… moan, complain, sob….

It really pisses me off "

On any non-trivial software project that is being developed by a team of developers, it is the telemetry and crash reporting features that helps to deliver the software that does "what the user expects".

The telemetry in particular can be used to see which features of the software are popular (and therefore should be optimised, and have a priority for bug fixes etc.) and which features can be dropped.

I have written complex distributed systems that run 24/365 for (literally) years at a time and have never needed to implement so much as a crash dump dialogue, never mind continuous telemetry. Basically, my released software doesn’t crash. Ever.

I have also written a lot of stuff for very high volume consumer electronics and (as far as I know) my stuff hasn’t crashed.

If software crashes it’s because it’s not been written well enough and not been tested well enough - don’t put the burden onto your users to debug your software.

As for the “all software has bugs” argument, that’s just bloody lazy thinking and I refer you to the previous paragraph. If you release software that crashes and you feel you can’t do any better then find another line of work.

This was my first thought, they can only do what the user expects if they're told what the user expects. The alternative is trawling through user feedback when people can actually be bothered to send it.

If there are no logins or collection of personal info or open documents, then anonymised usage patterns and crash data can't be all that bad. What features are people using most? Develop more in those areas. What hardware did it crash on? Let's see if there's a similarity with other devices that also crashed. Causes can be identified more easily and fixes can be quicker. I don't care if they know about my hardware as long as it's not data that can be used to identify the actual devices, and as long as they aren't collecting names and addresses. And the data collection should be transparent and honest because open source.

Having said that, any talk of telemetry still freaks me out because I couldn't personally trawl through all the code to see what's being collected. But given that it's open source, there'll be changelogs detailing any changes to the scope of telemetry, they will be honest because it can be independently verified, and you know there will be people doing exactly that, reviewing the code to ensure it's doing what they say it does and writing articles about it that we can easily refer to.

The whole thing more worrying in a closed source world, and I suspect a lot of people are seeing the word telemetry and remembering Windows 10 and the way MS ignore all the bad feedback they get about telemetry.

It is quite important that the open-source Audacity fork doesn't get too fragmented or it will be hard to overtake MuseCo's version. As it stands, it seems like the following is the most promising:

https://github.com/cookiengineer/audacity

I found this from a comment in: https://fosspost.org/audacity-is-now-a-spyware/

Looking at the issues / commits, it seems like they are serious. They are looking into a new name for it too.

Well I suppose if they give it a new name, the fork can stick with Audacity?

Might I suggest a choice for the new name: Fauxdacity?

Heh, not a bad name. The aux is pretty relevant too. Though is it really faux? Hopefully it will end up being the de-facto implementation.

There is a second fork here: https://github.com/SartoxOnlyGNU/audacium

"Audacium". Quite a cool name. Close enough to upstream to still say "fsck you!" ;)

They are in talks with the other fork to merge together as a single org. This is a very good thing.

I don't know if any El reg guys spot this but perhaps they could put a list of these forks in the article? It is a really cool demonstration that people care about free-software and could also predict this mess happening as soon as a commercial interest got involved.

Fraudacity?

Not sure it fits but it sounds good.

audio manipulation program (AMP for short) ?

Although you could never get a trademark on a generic description of function, which also means that anyone could abuse it.

Presumably there is a cunning plan, the likes of which Team Baldrick could only fantasize, lurking in here somewhere?

Either that or....

It is time to set up a new hosting platform called "Fork Me!" or "You're Forked!"?

I wonder if IBM have already patented: making software T&C so bad that people setup an alternative ?

Boss, since we shutdown centos people are getting mad at us and are making an alternative. Lawyers eye's light up

"Get Forked".

> A ban on the use of the app by the under-13s (more to do with consent to data collection than audio pr0n, we'd wager) is also in the terms

It is not permitted under the terms of the GPL to put any additional restrictions on the use, redistribution, etc. of the software. Disallowing use by a particular demographic, in this case under-13s, is a clear violation.

However, they *could* work around that if they had full copyright ownership of all the code, and released a non-GPL version with those limitations. That said, since there was a big stink about a CLA recently, I would assume Audacity didn't require copyright assignment before the takeover, so it may not be possible for the corporation to validly claim full copyright ownership of the codebase.

It really does sound like the new "owners" are either actively malicious, or really don't know what they're doing.

Is this even enforceable?

Seems like the worst that could happen would be that they will have to become compliant and make a donation to FSF.

Between this and that, there is plenty of data to collect and profit from.

Kids seem to be getting introduced to IT creative applications at an early age at school. Scratch is used by neighbour's pre-teens. When I get my 3D printer I suspect that SketchUp will become popular. I thought the US/UK education aim was to produce a skilled creative future workforce to be globally competitive?

This is privacy "not news" as the law enforcement and data sharing provisions are absolutely standard and reasonable. . The 13 year old bar is almost certainly about consent, as parental or guardian consent for personal data processing is required on behalf of minors below that age.

The big thing is that Audacity has taken the trouble to inform users properly, which is [1]remarkably rare . It's amazing to me that when a company takes the trouble to comply with the law by informing its data subjects it attracts flack, but the gazillions of businesses that don't arouse no ire at all.

[1] http://businessinforisk.co.uk/library/Awful_not_Lawful-final-BiR.pdf