Not for children: Audacity fans drop the f-bomb after privacy agreement changes A few more litres of accelerant were poured onto Audacity critics' fire late last week as an update to the sound editor's privacy agreement seeped out to the consternation of users. Eyebrows began rising on 2 July, and continued skywards with an update on 3 July as the implications of the refeshed privacy policy became clear …
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.
as GPL software, a fork will _ALWAYS_ be possible.
However, if Audacity switched licenses [and the owners can do this if contributors have given up any ownership claims or GPL claims to their contributions] then future features [say that 10 times fast - that that that ... oh nevermind] future features for the new non-GPLd version wouldn't be GPLd and would therefore have to be re-written from scratch, probably, to be included under the GPL'd fork.
Personally I'm quite happy with the version of Audacity I'm using right now, a 2 year old FreeBSD port. Why do I need an update? The only thing *I* can think of that would force a need to update would be a change to a required library [which is probably why things like vlc sometimes include their OWN forks for dependency libs to prevent their code from BREAKING when you try to build it].
and it makes another point, "bleeding edge" is OVERRATED.
So maybe just a "maintained" version of "what's there under the GPL right now" (minus any anti-privacy or irritating 'features') is a GOOD thing anyway? That is, along with a snapshot of major dependency libs [that might change on a whim at any moment], of course, so we can build it 5 years from now without any problems (just in case).
Besides libraries, the main problem of forks is the name. The old name is often trademarked and cannot be used. Said differently, it is the weight and traction the old name carries which needs to be transferred to the fork.
Examples include LibreOffice and MariaDB. The success of these was in large part due to major developer support and adoption by most if not all distributions. That caused the new name to carry weight and put the original (old) name in the shadows.
For a successful audacity fork you will need both a new name and the traction to carry the new name overshadowing the old name.
Why wouldn't there be confusion with Libre Office, Open Office and Star Office. As I recall, Star Office was purchased by Sun way back when and made it available under the GPL as Open Office. When Oracle bought Sun and had control of Open Office, users got nervous and the Libre Office fork was born. After Oracle decided it couldn't rip-off unsuspecting computer users, it abandoned Open Office and Apache Open Office resulted.
So yes, there may be confusion, because they are indeed related.
...and as of this posting time, it's the lead story in the BBC News Tech section. That's probably about as mainstream as it's likely to get.
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.
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!
Just, an aside... An aside mind you... Whatever happended to all that outrage when that other Company tried to pull this crap about six years ago now? As far as I know they are still very much to it, to this day. and will probably contine to do so come version XI.
Yet everyone seems to just love Windows X for some strangly unexplored reason. WHY?!
"...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...]
"Nothing wrong with telemetry or legally tight privacy policies."
Just that telemetry in general is pretty useless to improve a product, because it can't capture user intentions. And without the user context it's impossible to determine if the behavior of the software is correct or not.
Where telemetry can be of some use is in the form of crash reports which are sent to the developer, but again without user context the information is often not sufficient to pinpoint it to a problem.
Telemetry however is very good for building user profiles and use them for marketing purposes.
And you're right, there's nothing wrong with some business buying up a FOSS project to monetize it's users, at least as this happens within the laws such as GDPR. But there's equally nothing wrong with users voting their dislike for a business snapping up and monetizing their favorite FOSS project, and there's also nothing wrong with someone forking it (and thereby de-valuing the business's asset they just bought). Such is live.
"People moaning should concentrate on helping to improve it."
They do, by forking it. You can't really expect people to help improving a program which monetizes its users' data.
TIL the literally thousands of times I've relied on telemetry to resolve production issues never happened. Your simplistic theory misses a few things, including that most of the time high level intent isn't important to resolving a bug and that high level intent is often known from user study anyway. But mostly it just flies in the face of the real world where telemetry is used pretty much daily to make real improvements.
While is can(and is) used for beneficial and legitimate purposes, it is also constantly used in ways that are invasive, abusive, and occasionally illegal.
People like Mark "F them for trusting me" Suckerburg pretty much crapped in the pool for everyone that was trying to be a legitimate actor with data collection. So it's on the developers to be clear about what is collected and why, what policies govern the use of the data, and to make a clear and easy opt choice.
The should also ASK the community first. Instead the industry, and the new management just dropped the stuff in without consulting the community. Remember, as an open source project, you as the sponsoring company are not the only opinion that matters. Your out-of-house developer community matters just as much, and don't forget the user communities as well, as devs sometimes do.
They are the main reason "why" an open source project exists. The devs are the "how" not the "why", though they forget that from time to time when they are feeling salty and underappreciated. A major change impacting the users should be planned, transparent, and justified.
If the new Audacity management had announced they wanted to implement telemetry tracking, been open to discussion and feedback on the scope, terms and privacy, they'd have what they needed with no trauma and less drama.
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.
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".
"However, that's not a good model for larger systems that run continuously, are non-interactive, or span dozens to thousands of machines."
... Which in most is either under the ownership of the provider, or data can be assembled at a local node, that can in turn notify and request an admin if it is okay to send the report to the provider.
There is never a valid reason to just automatically track what is happening on other peoples devices.
"data can be assembled at a local node, that can in turn notify and request an admin if it is okay to send the report to the provider"
I hate to have to ask, but have you ever operated a service that scales to hundreds of thousands or millions of servers? Yes, that data gets aggregated into a control plane and data archival service (which itself is almost always some kind of scale-out service running on hundreds or thousands of servers). No, it is not realistic to ask a human to sit there and tick the thousands of boxes every day indicating whether it's ok to send off crash dumps ranging from a few MB to tens of GB each, never mind expecting that human to manually review the contents before doing so. Once you scale beyond a couple dozen servers, there are only two options: an automated process or no process. That is what "possibly sanitised in some well-specified way" means: it's possible to limit what is collected in some manner satisfactory to the customer.
"There is never a valid reason to just automatically track what is happening on other peoples devices."
I agree, and you need to go back and read what I wrote instead of knee-jerk assuming I'm saying it's fine for software providers to spy on you.
First: We aren't talking about people's devices; the cases I'm making for automated collection of crash dumps apply only when the operator is a corporation. The "devices" in question are not your phone or laptop; they are corporate-owned servers sitting in data centres.
Second: I already agreed that this kind of service should be opt-in with informed consent. That is not "just automatically track[ing]" anything. If you don't want it, don't turn it on. The customers who buy and operate the kind of software I'm referring to definitely do want it.
Third: I already agreed that this method is neither necessary nor appropriate to Audacity and other interactive applications used by individual humans. Did you even read?
Fourth: The case I was making was not for "tracking what is happening" in general. You're imagining that for example every keypress and mouse click are being recorded, which is a thing that some evil corporations do with interactive software -- and in fact what I fully expect Muse want to do with Audacity -- but that is not what I'm talking about. The software for which this kind of automated collection makes sense is NON-INTERACTIVE which means there are no keys or mice, and the kind of data I'm suggesting should be collected is limited to errors and crashes. At this scale, collecting every individual normal event is extremely expensive and while the operator may choose to do that (and aggregate it) for its own purposes, it would never make any sense to want that sent to the software supplier. That's not what customers want; even if they were comfortable having their own or their customers' data sent out at that level of detail (they aren't), it would be prohibitively expensive.
Fifth: To the extent that this data can contain personally identifiable information or information that is confidential to individuals, GDPR and other data protection laws apply and must be followed. The SCC dodge is nonsense in this case as anyone knows perfectly well that data sent to Russia cannot be protected adequately by any private contract. At no time did I suggest ignoring the law to collect crash dumps *without informed consent*, *without an opt-in*, nor *without appropriate processes in place to protect and manage that data*.
Get a grip. I am advocating for *opt-in* automated collection of *error reporting data* for *non-interactive software* run only by *corporations* and then only *at scale*, performed *in a manner compliant with the law*. If your position is seriously that no software vendor should ever be allowed to have its software send data about its own erroneous behaviour back to itself, we'll simply have to agree to disagree, because you are wrong and that position does the customer no favours.
> please be careful not to paint with too broad a brush here
Heed your own words: Your example has absolutely nothing to do with Audacity, which by no stretch of imagination is a "larger system that run continuously, is non-interactive, or span dozens to thousands of machines". We're talking here about a small personal, single-user program wanting to collect marketing data to resell. This has absolutely nothing to do with data center management.
Take your own advice, nobody here that's trashing telemetry has said a single word about Audacity or their actual planned changes.
The post he was replying to, like every other severely upvoted post on this article, was some variant of "telemetry evil, devs evil" with no mention of Audacity anywhere. And yes, this nonsense needs to be called out as much as any other form of FUD. It's not just big companies that can FUD, it's an equally effective tool for grassroots, and it's in heavy play here.
As to your actual point: The reality is that there are many reasons which have nothing to do with DC management or $$$ that you'd want direct telemetry at scale from your endpoints. User experience being one of the largest. UX with telemetry stomps UX without telemetry for two (primary) reasons: 1) real world workflows are understood and 2) real world crashes/problems/bad updates/performance issues are solved "telepathically" by the company before the user gets to reporting them. Both of these are positives for the end user with no inherent privacy risk.
I don't use Audacity and these guys specifically may well be scumbags, but the reactions in this forum from a supposedly technical audience are some real head scratchers.
> 1) real world workflows are understood and 2) real world crashes/problems/bad updates/performance issues are solved
Real world workflows can't be understood by compiling statistics. Quantity has nothing to do with quality. Besides, as somebody already said here in this page of comments, what makes a software special and worthwhile is often the less-used features, the stuff most users don't even know are there. Take them away and your software isn't special anymore. As for crashes, I'm no developer but I'm pretty sure you don't manage reliability feedback the same way on a data center headless service as on a small end-user program.
.
> the reactions in this forum from a supposedly technical audience are some real head scratchers
Could it be you haven't yet realized what the word "telemetry" means in 2021?...
"Real world workflows can't be understood by compiling statistics" of course they can, whatever you want to theorize it's done every day and verified by user studies at many companies around the globe.
"Quantity has nothing to do with quality." and this has nothing to do with the conversation as far as I can tell. Or do you seriously think telemetry is desirable to developers because we want more quantity (or even "quality" whatever that means) on our plates?
"what makes a software special and worthwhile is often the less-used features" this depends heavily on what sort of software you're trying to write and you can't generalize about it at all. There are niche pieces of software that rely on the rarity of their features, and there are very general pieces of software that rely on doing the common stuff really well. Neither is less useful or less valid than the other, and telemetry is useful in both cases.
"As for crashes, I'm no developer but I'm pretty sure you don't manage reliability feedback the same way on a data center headless service as on a small end-user program" what do you think the difference is exactly? They're just defect tickets at the end of the day. Further, just because a web service doesn't run a Windows UI locally doesn't mean it doesn't have a UI, most do and most track what happens in that UI a hell of a lot more closely than any desktop app does. Try making a heatmap from desktop telemetry, something web apps have been doing for a decade.
"Could it be you haven't yet realized what the word "telemetry" means in 2021?..." considering my experience working with it on a daily basis I'm gonna guess I have a pretty good idea.
> "Real world workflows can't be understood by compiling statistics" of course they can
I'd quote Churchill, but you probably know the quote already. Statistics is a field where the way you formulate your question will heavily influence the answer you get. If you expect to find insight on was to make users happy, telemetry is definitely not the best tool, because it doesn't tell you what they want to do, just what they manage to do. It's like that shop which doesn't sell a given item because it doesn't sell. Obviously, since it's not on sale...
.
> Or do you seriously think telemetry is desirable to developers because we want more quantity (or even "quality" whatever that means)
Yet that's all you get: Masses of information on what (and how) is used most, with the only real information being raw quantity. Unless you resell your users' PI, in which case telemetry brings you cash...
.
> what do you think the difference is exactly? They're just defect tickets at the end of the day
Sorry, but that's a pencil pushers point of view. For me the difference is that one is a program running in a more or less controlled environment by (vaguely) trained users, while the other is used by more or less totally computer-illiterate people on crappy and wildly varying environments. Problems are neither triggered nor handled the same way.
.
> considering my experience working with it on a daily basis
I wasn't asking about your experience working with telemetry, but if you were aware about the connotation it has in the minds of people, people you'd probably like to persuade to buy your ware or service. Apparently not.
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.
When it is set up like that, you still require the language in the user agreement that caused the gnashing and wailing. You can't in this day and age collect data, even optionally, and not have these things listed out.
As I understand it, telemetry is disabled, you can opt in to it if you are having problems and want them to investigate.
"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.
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.
> from the support and sysadmin side telemetry can be extremely useful
Can, yes, but this is more often than not but an excuse. If some people break in your house, what would you assume? That they came to do some voluntary cleaning or that they came to steal stuff?
The time where people could assume beneficial motives are definitely gone, and we're living in a time where everyone including the corner baker shop tries desperately to collect some marketable personal information, so arguing about crash reports sound either terminally naive or totally disingenuous.
(Didn't downvote you though.)
I think it depends how open they are, if the source code or protocol sending data can be examined, just how strongly the telemetry is pushed, and their history.
When Audacity initially put in some basic telemetry this was not necessarily an issue. However, coupled with a code license change and in particular the EULA that explicitly includes providing data to a potential purchaser I'd suggest trust should be in short supply.
As open source grows in popularity the willingness of the average user to do technical investigation reduces, they're less likely to be willing to set logging options, and the thought of re-compiling with debug options set is minimal. Telemetry by itself is not necessarily evil.
> Telemetry by itself is not necessarily evil.
That's true. But today, right now, there is a huge push from about everywhere to collect juicy personal information to resell to all and sundry. When the shop which cuts your hair starts requesting your birth date, job title, all your phone numbers and an email address, you know something has gone terribly wrong. My hair is on my head, that's all they need to know.
So yes, it's not necessarily evil, but in reality it usually most definitely is, and the very rare baby thrown out with the bath water will have to accept this. Users don't like being spied upon under the false pretext of technical necessity, and grow increasingly angry about it. The smart developer in 2021 would put forward the fact his product doesn't do any telemetry, it has become a selling point nowadays.
> 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.
It's really easy to see the difference in these threads between people who work with software professionally and hobbyists. If you think the only reason a bug can escape is "you didn't do proper testing and are using me as a beta tester" and the only reason to get error telemetry is "to steal muh stuffs" then you're an extremely unproductive part of this conversation to be honest.
Is what Audacity plans to do ok? No idea, didn't look into details. Is, in general, telemetry a bad thing? No. Is, in general, telemetry in any way necessarily privacy impacting? No. People's knee jerk reactions to telemetry are nuts.
telemetry should only be of the 'anonymized' variety, and OPT IN, and ONLY directly relevant to the software you are running (i.e. does not report about my OS other than the version, does not scan for other running software nor keep any kind of history about my behavior, etc.). Sometimes I opt in to telemetry for debug-only purposes. But lately I seem to always say NO. My trust level is very low.
I might agree with you for test/beta releases, but not for general distribution. And doesn't GDPR and similar things require you to make that info visible and delete-able to the user, if it's not truly anonymized? A user who navi-guesses through the web-ocracy to find the actual data may not be too happy about what he finds, i.e. the things that were actually collected.
Other running software is directly relevant to the software with the issue, especially when it's anti virus, spyware prevention, game cheat prevention software, or drivers (especially for graphics cards) all of which can sometimes be highly invasive and involve injecting DLLs into processes without asking.
How do you expect to detect an error that occurs in module C only after visiting modules A and B if a history is not kept?
Nevertheless yes, it has to be opt-in, and transparent as to what is collected.
"...telemetry and particularly crash reporting to be hugely beneficial to the development process"
@doowles: don't you end up with loads of very similar crash reports? Lots of duplication? Just wondering how this works for programmers, not challenging or doubting what you say.
Telemetry can broadly be categorized as either product or engineering telemetry and basically breaks down like this:
1) Product telemetry informs product development and is mostly aggregate data, answers questions like "how many people click these three things in this order and should we have a simplified flow for this task?"
2) Engineering telemetry is the performance/crash stuff and answers questions like "which are the hot paths where we should do performance optimization?" or "what code is crashing in the wild in a way we didn't expect?"
In general engineering reports are consumed two ways:
1) A triage team/automation/something will give it a once over on intake and try to put the issue in the right bucket, number of reports and severity will be used to prioritize tickets by dev and a few exemplars of the crash will get pulled by the dev.
2) An issue is found by another means and the reports are checked to see if it's an in-the-wild issue and how prevalent it is, then a dev again is likely to pull a few during reproduction, and maybe again to aid in verifying a fix.
Depending on the nature of the software and the type of deployment these things may also have monitoring and alarms attached to the aggregates so that if there's, say, a spike in crash reports (ex after a bad update) a big ol' klaxon goes off in mission control and it's all hands on deck to patch it.
"Don't you end up with loads of very similar crash reports? Lots of duplication?"
The problem is that it can be the exact nature of the user data that causes the crash. The data is the scenario. I used to use a tool that could obfuscate such data while still allowing it to cause the same scenario crash in replication. With a bit of further development the tool could have been put into an automation sequence to ensure that only GDPR-compliant data left either the users server or a GDPR-compliant vault.
-----
What brain damage, in today's IT youths.
Your IT elders knew a world before scumbags got their mitts on everything.
That one would ever compromise decency...says it all.
-----
Among other crimes:
- Google having the gaul to read and mine e-mails.
- Fecesbook pissing on privacy and inciting the masses.
- Microsoft's monopoly O/S forcing updates and ads.
-----
Old versions excepted, Audacity is dead to me.
-----
Let the fork and renaming begin!
"- Google having the gaul to read and mine e-mails."
A Gaul? Do you mean Asterix?
The word you are looking for is "gall"
Rudeness and the quality of being unable to understand that your behaviour or what you say is not acceptable to other people:
Cambridge Dictionary
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."
I'd argue that it should go that way. Companies buying up open source tools with a large community in order to monetize it for their own purposes are certainly allowed to do that. It's legal and there's nothing wrong with it philosophically, imo.
However, it's often also in the best interests of the community to fork off that development and make the purchase a loss for that company. It's not very often that the capitalistic interference of a tech business has improved open source projects after buying them. If the free market is, in fact, free, then the users should cease using the projects that've been bought and fork them into projects they want to use, which also acts as a disincentive for purchases like that in the future.
well, when the bean counters at the "umbrella" companies FINALLY get the clue-bat properly applied to the alignment point by a qualified technician, they might try to monetize the thing in a way that makes the end-users happy [I gave some examples in an earlier post], and makes themselves profitable.
But treating us like CATTLE to be USED for MONEY is NOT the way SUCCESSFUL business is done... unless it is a monopoly. In that case, if it's what they're trying to accomplish, a FORK becomes a LART.
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.
Fair points in theory, but in the real world they collide with human nature, which is this: (many) people instinctively don’t like to be tracked. Which in the IT world tends to mean the most tech-savvy people, who will then go out of their way to disable/block any attempts at telemetry.
End result? You only get telemetry from the users who are too oblivious/naïve/uncaring to disable it.
So your telemetry tells you “huh, our users are generally ok with telemetry, and don’t use the advanced features of our software”… and you ramp up the former, and dial back the latter… and the end result is Windows 11.
"... trawl through all the code to see what's being collected ... 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 boolean check ( telemetry == false ) is far simpler to verify than your suggestion of tracking the changelogs then verifying the installed telemetry does no more than what was claimed. Anyway after reviewing the EULA there is little point in reviewing the code.
"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."
Dropping the least used features is often what turns a great piece of software into a plain vanilla clone of all the others out there. I've lost count of the number of times over the years that I've dumped software for something different because the original one "lost" the one or more features I needed.
Yes, if features aren't used by many, then they are less important to the majority so if dev time is limited, dropping support might be the only option. But ONLY if that option requires time to keep it working after other changes have been made. After all, it's "free" to the end user, so if a dev has no time to make function X work in the latest version, who am I to complain? On the other hand, I also have the choice to move on to something that DOES support function X that I want to use.
> telemetry in particular can be used to see which features of the software are popular
And cutting someone open can save his life. What do you think police will say if you tell them you're carrying that knife in case you happen on somebody with acute appendicitis?
There are way better ways to know what your customers want, rather than spying on them. Especially since, admit it, you aren't spying on them just to make them happy... Sorry, I've ceased believing in Santa since the 1970ies.
(Didn't downvote you though.)
well you *do* need a way to monetize it. Just not one that's *EVIL*.
In My Bombastic Opinion, there are some traditional ways to do this without violating user privacy.
* sell add-ons
* shareware model (people DO license things) even if it takes the form of a 'donate' button on the web site.
* 'support' model. This works for database and CAD and Linux distros and similar things.
* 'freemium' model. Free for the Open Source version, but you pay license to get latest features or some other premium content or feature (and it may be shipped as closed source). Qt (as I recall) has done something like this. in some ways, VirtualBox does this (or used to) with the extension pack.
* other things that people already do that make it worth forking over a small amount of money to get something worth the price.
What you do NOT want to do is the Google/Micros~1/FaeceB*/Tw*tter/etc. model and MARKET PEOPLE'S PRIVATE INFO and TRACK US. But it appears they're doing JUST THAT...
"well you *do* need a way to monetize it. Just not one that's *EVIL*."
We may not all agree on what "evil" means, though. I consider Freemium to be evil, and I'm no fan of the support model if purchasing support is a condition of using the software. Basically if your monetisation strategy involves an EULA of any kind, which includes "fake open source" type licenses (AGPL, SSPL, RSAL, etc.), I'm not going to be supportive.
One only needs to monetise something if one has spent money to purchase it. If there's no obvious way to generate a good ROI on the purchase of an open source project's copyright without infuriating the user base and engineering community, perhaps the solution is not to find "less evil" monetisation strategies but to invest one's capital in something else. No one forced Muse to buy Audacity.
I dumped Windows for Linux when Windows made my gorge rise. I have now dumped Audacity too. Sorry, .ru. Software that is "synonymous with spying on its users" is 1. more profitable to own and 2. so common that people have become used to it. Sheep are for wool, mutton and lamb chops. Are we?
"How’s the fuck did we get to this point?"
Users care about free and don't care about privacy, so the one was sold to allow the other to happen by the companies serving them. No real mysteries here.
Even today with the privacy issue being mainstream I've done straw polls to see if people would pay for email or other online services and the answer is always still a hard no because it's "free from Google".
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.
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.
This post has been deleted by its author
This post has been deleted by its author
Obligatory Dr. Who reference in naming: "Sonic Shades" [and it's not being used at the moment as far as I can tell]
I had to look up a LOT of Aud- Sonic- Sound- Mus- and similar obvious names to find something that was not already in use for audio software, as far as I can tell anyway. ('Sonic Sunglasses' is even being used by a store, so I went with 'shades')
> be hard to overtake
Why do we need to overtake anything? This isnt a popularity contest. We need alternatives, tahts all and thats what the forks will provide.
Those users who learn of Audacity's issues and wish to escape can do so and the fork they find the best will be what they use.
We dont need to win a race, just have different racetracks.
> 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.
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?
Certainly, it would seem to be in violation of the spirit of the license.
What is God's name are they doing specifying that children can't use the software?
That stood out to me as the most bizarre stipulation.
Don't we want to introduce free software to children at the earliest possible age?
Muse Co seems to have completely lost their minds.
> What is God's name are they doing specifying that children can't use the software?
Data collection laws require parental consent, thus if you dont get consent or the developer cant be arsed to implement a method for getting it you have one choice: ban the kiddies.
Of curse, the kids will use it, but you banned them. Just like facebook does, you thus cover your ass and if anyone asks why a kid is using audacity or facebook you can look all surprised.
This post has been deleted by its author
0) If you leave user data alone, you don’t need to ask permission for slurping it. It’s as simple as that.
1) Audacity is released under GPL, which means that you can access the code and verify by yourself that, up to the last pre-Muse commit, they didn’t need to ask permission because of 0)
2) Because Muse have their balls tied up in the GPL, 1) dictates that if they did not disclose people would have called them out and it would have been even worse.
3) Business that slurp data do attract attention (and not of the loving kind, since a long time): the news of the GDPR should have permeated also under the heaviest rocks by now.
Really? All the "data" that the app has access to is mine on my local machine. Why should installing it give any agency the "right" to access that data, especially if I am in a different legal jurisdiction?
Similarly for the "13 year" limit - there is no need for any data about a user to be transmitted from the app.
Also, what is the GDPR "reason" for collecting, storing and processing this data? I doubt that "we might find it useful" is adequate.
It makes me wonder if future plans might include looking at what files you are working on, just in case there might be some copyright infringement. Maybe the RIAA and their ilk are behind this? </tinfoil hat mode>
The GPL is specifically constructed such that consent to use the software is not required.
As someone above commented, I'm not entirely sure that such a provision is even compatible with the GPL since the whole point of the license is to grant permission to *everyone* and prevent anyone from denying others those same permissions
This morning I read that other article. It seemed rather reasonable to me. I went and checked the website, they were talking about opt-in telemetry.
I made a post where I stated that opt-in telemetry was better than most, because if you don't opt-in, it doesn't exist.
And now this.
I said this morning that if ever Muse got out of hand, I'd be the first to light the fire for the stake.
Well, I've got my lighter now. Point me in the right direction and we're going to have a bonfire.
This made me wake up and get an application firewall, Blocks all outgoing connections from any app I choose.
https://radiosilenceapp.com is what I chose for Mac. There are other options for Linux and Windows.
You still control your computer today. Don't put up with crap like this.
Anyone thought about those folks with huge collections of digitized music they've recovered from LP's, cassettes, CDs, DVDs that they've bought?
Anyone thought that those folks when using Audacity to do things to their collected music might be leaking lists of music?
RIAA execs on that corporate board perhaps?
Am I a paranoid nutcase? probably. Am I wrong? perhaps at this moment. Is this something I see coming? hellz yeah.
I agree with your concerns. My version (2. something) of Audacity seems OK, but when I saw the Litigation part of "Data necessary for law enforcement, litigation and authorities' requests (if any)" I realised that they probably do intend to do something to help the likes of RIAA.
Could you even trust them not to slip some form of ID or watermarking into mp3s that it generates?
Title short version.
Used audacity for years as its an adequet stop gap to cool edit Pro which won't run reliably on modern systems. But Ffs seriously what fucking data even app telemetry could be of use to them. Either you have the right codec or you don't. That's about all that can go wrong with it. The only thing I can think of they could be planning to use it for is selling ips and wave form hashes to dcma vultures.
Grateful to El Reg for highlighting the telemetry changes in advance. I downloaded the last clean version because I hadn't upgraded in years. I just don't use it that much now.
I confess I still use Paint Shop Pro 7 as my image editor, which arrived on the front of a PC magazine disc. I know there is far better FOSS imaging available, and I had the full Adobe suite at the time, but I just like it and it does what I need it for. It's uncomplicated, pleasant and low maintenance, like the best of girlfriends.
I'll stick with that telemetry-free version of Audacity until enough of you dedicated young people extol the benefits of the fork. I am open to persuasion, hence LibreOffice rather than OpenOffice. And I may play with darktable for a day or two thanks to the original article because that's news to me.
Anyone remember what Wireshark used to be called before someone trademarked the old name? Yeah, some of us greybeards do but even I have trouble remembering it.
I think the same will be true after we all start using the forked version, we'll all remember the new name (whatever it is) and forget audacity ever existed.
I always thought Audacity was too good to be true. It was fun while it lasted.
Still there is really nothing much new under the sun in the world of audio editors and I doubt there will be much more in the next 10 years, so I will just stick with my current version.
Besides, its only a matter of time before the 'next' free version is gelded and full features are only available in a paid/subscription model.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
