The Audacity multi-track audio editor and recorder got its start in the previous century; it is a popular application that is available for multiple platforms, and it is licensed under the GPLv2 or later. But Audacity has been acquired by a newly formed organization called Muse Group; that event has caused something of an uproar in its community. The problem, at least in part, is the new Contributor License Agreement (CLA) required to contribute to Audacity.
The acquisition of the project was announced in an early-May YouTube video posted by Martin Keary (“Tantacrul”); that news was subsequently confirmed on the Audacity web site. In the video, Keary talks about what is planned for Audacity:
Audacity has just joined Muse Group, a collection of brands that includes another popular open source music app called MuseScore, which I’m currently in charge of. And since things are going rather well at MuseScore, I was asked to step up and also manage Audacity in partnership with its open source community. And just like we’re doing at MuseScore, we’re now planning on significantly improving the feature set and ease of use of Audacity – providing dedicated designers and developers to give it the attention it deserves – while keeping it free and open source.
In general, the reaction to the announcement (e.g. at Hacker News and again the next day) was fairly positive; there is a belief that Audacity could use some work on its user interface and that Keary has done good work on the MuseScore interface and elsewhere. But it did not take all that long for a clash between the community and the project to arise. A pull request by Dmitry Vedenko to add a telemetry feature was met with a large amount of dissent.
The feature, which was meant to be opt-in at install time, would report anonymous information to Google and Yandex; telemetry could be also be configured out at build time, though it would be present in the builds made by the project. Hundreds of comments on the pull request were made—nearly all unhappy with it due to privacy concerns—which led to the feature, as originally proposed, being dropped. In that message, Keary said that there is a need for opt-in crash and error reporting in Audacity, but that any data sent will be hosted by the project (or Muse Group), not Google and Yandex. Meanwhile, though, there is still interest in more-intrusive application-usage data if an acceptable mechanism is found for it:
Telemetry is a practical tool that tells us a lot about how an app is performing or underperforming (is this new feature being used a lot? Is this button being discovered? etc.) We assumed that making it opt-in would allay privacy concerns but since this isn’t the case, we are dropping it. In the future, we may want to determine if there are any acceptable alternative solutions that could achieve the same goal. Feedback would be appreciated on this point. In the meantime, I will continue user testing, interviewing, reading feedback and conducting surveys to learn more about what our users want.
Something that became clear from various discussions on GitHub and other forums is that people in the community were confused by what was actually acquired when Audacity “joined Muse Group”. While the rest of the software industry is notoriously acquisition-happy, the free-software world has generally avoided those kinds of changes, in part because the code is often “owned” by the contributors—and the community. A request for clarification that was linked in various places raised a number of questions about the acquisition, such as:
- Is it even possible for a company to acquire a free and open source project licensed under the GPL?
- How exactly did Muse Group acquire Audacity?
- What rights and power does Muse Group legally have over the Audacity project?
- Can Muse Group even legally claim ownership over the project or do they simply own the trademarks to the name and logo?
It took a bit, but Daniel Ray (“workedintheory”), Muse Group’s head of strategy, answered on May 25. In a nutshell: “Muse Group acquired the Audacity trademark and project infrastructure in addition to a license to the source code from contributors to the Audacity project in the form [of a] CLA.” In a follow-up message, he confirmed that Muse Group had gotten signed CLAs from all of the relevant Audacity developers; that means that the company has control of the licensing of the code moving forward as well. Ray also pointed to a press release about the acquisition from April 30 that seemingly flew under the radar; for one thing, it filled in the strongly positive reaction from the project’s founders, which was something that had been asked about.
But, in an unsurprising development, that same day Ray posted information about the CLA that would be required for contributions going forward. In it, he said that Muse Group intended to update the Audacity license to GPLv3 in order to make Audacity compatible with Virtual Studio Technology 3 (VST3) plugins, and with MuseScore, which recently switched to GPLv3. It is not entirely clear why the GPLv2+ license that Audacity has would be a problem for sharing code with either VST3 or MuseScore, however. He did try to reassure the community, though: “Naturally, Audacity will remain free and open source with no artificial limitations or paid tiers.”
But there are platforms like iOS where the GPL can be an impediment, he said, so Muse Group wants the flexibility to be able to further relicense if need be. In addition, it may offer additional services:
We will likely offer separate cloud services that Audacity users can take advantage of if they choose. These services will fund the future development of Audacity, in much the same way that MuseScore.com funds the development of MuseScore composition software.
As might be guessed, that set off another lengthy thread. Numerous commenters pointed out that, in their opinion, the reasons specified by Ray were not sufficient to overcome the problems that stem from a CLA of that nature. The crux of the matter is that the CLA puts Muse Group in a position to use contributions from the community in other products, even if Audacity itself remains free. As Ray put it: “The CLA also allows us to use the code in other products that may not be open source, which we intend to do at some point to support the continued development of Audacity.” It is worth noting that while Ray and Keary have both committed to keeping Audacity available as free and open-source software, nothing in the CLA binds the company to doing so.
There has been talk about forking the project or starting over from scratch, but it is not at all clear how serious any of that is. The Audacity team was obviously involved in the transaction, at least to the point of agreeing to sign the CLA for their contributions, though financial terms have not been disclosed. The team has been largely silent throughout the uproar, perhaps because much of the unhappiness is being expressed by Audacity users or unconnected FOSS community members, not project contributors. In his follow-up linked above, Ray suggested that may explain the lack of engagement:
Mostly, I don’t think they really have too much to say much because nearly all of these people who are commenting are not people they know or that have had anything to do with the project in the past. This sudden influx is not from the Audacity contributor community, not really sure if even from the user community, but seem to place demands on a project they were never a part of.
I can see why they would prefer not to say too much.
A lengthy message from Shane Mueller gives his reasons for signing the CLA for his 15-year-old contributions to Audacity. He is impressed with what the team of “3-4 volunteer programmers and handful of regular non-programmer contributors” has done with the application over the years, but worries about the future:
The volunteer team is small and not growing, not young and getting older, mostly not really pro-audio or usability experts, and probably won’t be contributing at all in another 10-15 years. Audacity will literally end if a couple key contributors took a step back from the project or retire. It will have no chance of even doing a new release, let alone putting substantial effort into things that will make more than incremental improvements. When people call for a fork, I wonder where they have been for the last 20 years or so–if they were really passionate enough to contribute to a mature project (ugh) for amateur users (ugh) using c++ (ugh), wx (ugh), having an ugly UI (ugh) and relying on large mishmash of audio libraries to figure out (ugh), all to enable cross-platform capability (ugh), I think they would be doing it already.
Mueller said that he would have been happy to sign a CLA for a hypothetical Audacity non-profit foundation—and still would be. But it takes a lot of time and effort to set up that kind of organization, which still does not solve the lack-of-contributors problem. Effectively, he does not see a good future for Audacity without a new approach; he is not interested in working on that himself, but is “willing to support those who are involved and let them try this new model for how the project will be sustained into the future”.
It would seem that Muse Group has the current Audacity team on-board with its plans, and has added some additional developer-power to the project. That would seem to bode well for improvements, probably at a much more rapid pace. But the CLA may deter community contributions to the project going forward. Muse Group would seem to have taken that into account in its planning—in the near term, it may be no real change from the status quo.
If there truly is a groundswell of interest in an independent Audacity, obviously a fork is possible at any point while the code is available under the GPL. Or an interested group could start over; Mueller’s message and other comments seem to indicate that Audacity might not have the most pleasant code base to work with. But it seems fair to say that if all of the developers with any substantial copyright in Audacity are happy with the Muse Group and its plans, that is clearly the right path for the project, even if it does not mesh entirely cleanly with what the FOSS world has come to expect. It may well be the only plausible way forward for the project.