Request for clarification on Muse Group's involvement and vision for the Audacity project

Both the Audacity website as well as Muse Group's website states that Muse Group has acquired Audacity. However, hardly any details have been given. The information given on the Wikipedia page on Muse Group is also vague and questionable at best. All we have to work with is this quote from Tantacrul's video:

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.

This raises several important questions. To name a few:

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?
Who exactly is behind Muse Group; what roles do these people have?
What are Muse Group's visions and goals for Audacity?
How does Muse Group plan on going about putting these goals and visions into practice?
How does Muse Group plan on handling situations where they want a new feature but the community rejects it (see PR 835)?
Are any of the core maintainers and team members of Audacity now on the pay roll of Muse Group?
What is the project father's and core maintainer's role and view of these events?

I'm specially interested in the questions about defining the relationship between Muse Group and external developers like contributors who have their own interest, will and schedule.

Because to speak about myself one of my main concern and interest for Audacity right now is to never see a split of efforts and other waste like I have seen so many time in other projects, either because one group has the name and the other group the workforce, either because of disagreements between parts, either because of lack of interest in being part of a whole.

Without much information I assume it's good and welcome if Muse Group can put paid people on making Audacity better and putting Audacity in places it's not there yet, but defining relationship with the community seems to be an important point to address to begin with. Hello people.

I'm also curious about this. "Acquiring" an open-source project that's licensed under the GPL2 -- or licensed under an open-source license at all -- seems really sketchy to me. (Is it even legal under the GPL to do something like that to begin with?) The lack of information about the acquisition, supposedly from a company who holds a stance that Audacity will remain "free and open-source", is also suspect. I think that we as the community have a right to know a lot more than what the company has provided us. If Muse Group -- whoever they are because I've never heard of them -- are trying to put on the face of transparency and trustworthiness, they're failing big time at it.

After answering these questions, I think it would be beneficial to work with the community towards written, specific policies on shared governance. I'll point to the Fedora Council Charter as a positive example of a for-profit company supporting a community project. RedHat employs a few select people to work on Fedora full time and pays for Fedora's infrastructure, but for the most part the project is run by and for its community. I've been using Fedora for 15 years and never felt concerned that RedHat's involvement with the project was harmful or in conflict with the community.

The only thing that I can think of is, that the name "Audacity" (which is a trademarked name, AFAIK) was sold. I cannot think of any legally possible way of really selling a GPLed source with more rights to/for the buyer than to anyone else would have/retain who aqcuired the source by other means (by e.g. just downloading the source).
So, the fork "FOSS-Audacity" most probably cannot keep this name but would be fine if named "Aefkaa" (Audio editor formally known as Audacity)...
Edit: Same as with Libre-/OpenOffice.

The "Audacity" logo trademark was filed in March 2021:
https://tmsearch.uspto.gov/bin/showfield?f=doc&state=4808:oh9d5r.2.12

In case that link throws a session error, also refer to:
https://www.trademarkelite.com/trademark/trademark-owner/MUSECY%20SM%20LTD.

@ethindp

I'm also curious about this. "Acquiring" an open-source project that's licensed under the GPL2 -- or licensed under an open-source license at all -- seems really sketchy to me. (Is it even legal under the GPL to do something like that to begin with?)

@ethindp Indeed it's possible to acquire an open-source project and it's fully legal (and is not necessarily harmful), GPL2 has nothing to do with this, GPL2 is mostly about making sure the copy you get once under GPL2 will still be GPL2 forever in your hands (even if yourself don't agree with this).

A company can acquire the name, hence the brand and trademark. It's not the project per se, but a project with its renowned brand is as fragile as a newborn again, so yes selling the brand makes huge part of acquiring a project. Selling only a brand already happened in the past with some other projects, though it appears that's not what is happening with Muse Group and Audacity there, there is multiple articles on the web clearly stating about taking care of the open source side of Audacity, the freeness of it, improving it (1, 2, 3) and even testimony from a developer who joined the team to work on Audacity (and one who know about open source), one who already worked for another open source software previously acquired by Muse Group: Muse Score. So time will tell, but for now we can't assume it's bad per se, and don't look harmful at first glance (though they may still have to learn a bit about some expectations of open source users given #835). That can be good if they behave well.

A company can also hire the key developers of a project, hence owning the workforce. A company can hire project heads, acquiring the decision. That can be good if they behave well.

In some case (if the sellers got copyright assignment) it may even be possible for a company to buy the copyright of the open source project with right to remove the GPL2 itself. That would not be good if that happened but I doubt it would happen with Audacity, and that's not what Muse Group does with MuseScore they acquired before anyway. So that part looks safe.

So, the fork "FOSS-Audacity" most probably cannot keep this name but would be fine if named "Aefkaa" (Audio editor formally known as Audacity)...

@Locutus74 A fork would be the worst thing for everyone (see my comment there), after a decade Xonotic never recovered the Nexuiz coverage after the Nexuiz trademark was sold, after a decade LibreOffice haven't recovered yet the other half of users using OpenOffice because they don't own the OpenOffice trademark… Such a fork would be bad for users, for audacity as a project, and for Muse Group. No one has something to gain from a fork. This only have to be done on last resort.

If MuseGroup seems to have to learn a bit about open source communities, for now all they did were mistakes they can fix and learn from, they didn't tried to harm the project intentionally yet.

@illwieckz

@illwieckz ... nope, a fork is not necessarilly the worst thing for everyone. LibreOffice is the very best example for this.

And BTW: What you described is exactly not acquiring a GPLed project. It's aqcuiring just the name, only.

Why? Just because the company which aqcuired the project does not have any more rights on it as anyone else who has the source-code. With the name it's a different thing, though.

And the name may be more important in the first place. But not on the long run...

I think that what is being lost in all this is the simple question:
Who are these people really, behind the organization known as Ultimate Guitar, or WSM Group, or Muse Group, or MuseCY Holding LTD.?
Who owns the for-proft company called MuseCY Holding LTD?
Personally, I would not trust their motives until this information is revealed.

At least at a first glance "MuseCY Holding LTD." seems to be a typical letterbox (money laundry?) company in Cyprus.
It therefor most probably is impossible to find out the real owner. And yes, this looks a little bit (more) shady, now...

At least at a first glance "MuseCY Holding LTD." seems to be a typical letterbox (money laundry?) company in Cyprus.
It therefor most probably is impossible to find out the real owner. And yes, this looks a little bit (more) shady, now...

Before we all loose our heads, there's plenty of legal and reasonable reasons to form a shell company.

Also wasn't it determined in 835 that MuZe Group is not affiliated with MuseCY?

Also wasn't it determined in 835 that MuZe Group is not affiliated with MuseCY?

Maybe. I must admit, that I did lost track after hundreds of posts in 835...

@illwieckz

@illwieckz ... nope, a fork is not necessarilly the worst thing for everyone. LibreOffice is the very best example for this.

@Locutus74 This is not contradictory. My opinion is that the Xonotic fork was the best thing that happened to Nexuiz, in term of direction. The LibreOffice fork is very successful and can be named among the most successful fork in history.

But the sad reality around this is even if the fork was the best thing that happened to Xonotic, Xonotic never recovered its recognition and reputation 10 years later, French Wikipedia even deleted three times the Xonotic page because of lack of recognition.

The sad reality is that even if LibreOffice is one of the more successful fork in history, half of the users still use OpenOffice, most of them probably don't know LibreOffice about at all, 10 years later, and I verified this around me.

Forking is engaging oneself for a full time job. This is just wasting time for every parts.

Xonotic didn't have the choice to lose the brand. LibreOffice didn't have the opportunity to keep the brand.

Note that LibreOffice is a special situation. LibreOffice was based on GO-Office which was an enhanced OpenOffice (basically all the Microsoft docx/xslx things were implemented in GO-Office first), at the time, and before LibreOffice existed, almost all Linux distributions shipped GO-Office under OpenOffice name. It was like, OpenOffice with GO-Office patches. But after all that Oracle buying and other details, the definitive split from OpenOffice was inevitable. LibreOffice suffered from the lose of the name, but they already had the workforce from before Oracle bought OpenOffice wen acquiring Sun.

So yes LibreOffice is a perfect example of successful fork, but also the perfect example that even after a decade such fork can't recover the same brand recognition and only gets something like half the users…

At this point nothing in MuseGroup acting makes a fork inevitable. They clearly made a mistake, but they can learn from it. No door is closed.

And the name may be more important in the first place. But not on the long run...

Both Xonotic and LibreOffice examples show that a long run of 10 years is not long enough.

Anyway this thread is about getting answers from MuseGroup. At this point we need answers from MuseGroup and they made many people angry, but they did not made any unrecoverable mistake that would make a fork inevitable yet… So better not be responsible for greater harm than they did by causing the fork oneself. At least, MuseGroup didn't forked, and they had right to, that's a notable thing to notice, that means they don't want to split the community.

what Muse Group does with MuseScore

Muse Group has imposed a CLA on MuseScore. That's another topic though. Let's discuss that in #844.

I'm not assuming you're the only one on earth reading that thread neither this thread is about you.

Fine. So, we can just discuss the main topic, again?

@orenwatson

I have begun editing the wikipedia page for muse group to insert the correct date of its formation, namely july 2020, not april 2021. (I have citations proving this, of course.)

@orenwatson Thank you for your efforts! As long as there is no statement from Muse Group or the people in charge of Audacity, we might as well collect as much information as we can. In this vein, would it be helpful to try and make a list of all people we know are involved with (employed by) Muse Group? For now, I am only aware of:

Tantacrul - UI/UX, "in charge"
crsib - Programmer
workedintheory - Head of Strategy

in some case (if the sellers got copyright assignment) it may even be possible for a company to buy the copyright of the open source project with right to remove the GPL2 itself.

No, this is not possible. The company may choose to develop a closed source version and release that under a different license, but they have no ability to revoke a license granted already. This is a key part of the GPL. Anyone who has used the software may use it, may distribute it, and may modify it and distribute the modifications, provided they comply with the requirements of the GPL.

If the company purchased the copyright from all original contributors (a practical impossibility at this point), they could themselves breach the GPL, as they would be using the code as the owners of it, rather than as licensees - but they could not revoke other people's valid licenses, and they could not prevent others from using and sharing their GPL'd versions.

@Blu3wolf

in some case (if the sellers got copyright assignment) it may even be possible for a company to buy the copyright of the open source project with right to remove the GPL2 itself.

No, this is not possible. The company may choose to develop a closed source version and release that under a different license, but they have no ability to revoke a license granted already.

@Blu3wolf Please don't extrapolate on other people words. I never said such company would be able to retroactively remove GPL2 on something delivered. It looks like you assumed words at the end of my sentence, words I never wrote. I never added “retroactively” at the end of the sentence.

I never wrote those words about retroactivity because I even made it clear some sentence before in the same post you quoted it is not possible to revoke a license granted already:

GPL2 is mostly about making sure the copy you get once under GPL2 will still be GPL2 forever in your hands (even if yourself don't agree with this)

“The copy you get once under GPL2 will still be GPL2 forever” → not possible to revoke a license granted already.
“even if yourself don't agree with this” → even if the company buying copyrights and/or getting CLA signed don't don't agree with this.

Clearly, what have been GPL2 is GPL2 forever, but the ones who may buy copyrights, obtain CLA etc. have rights to add new licenses to the existing code (that would be dual licensing, even with non-free licenses) and have rights to legally publish new version with code that was never GPL2 and will never be, meaning the users can't backport the change to the GPL2 version they got first.

If the company purchased the copyright […] they could not revoke other people's valid licenses, and they could not prevent others from using and sharing their GPL'd versions.

This is exactly what I said. We were just agreeing on that topic, so better not assume contradiction first.

This is exactly why CLAs can be problematic and people can be concerned about it.

A company can't buy the copy you already got in the past, but a company can buy almost everything about the future of the software: the name, the brand, the recognition, the workforce, the decision, and the right to change license for the future code.

Of course people can share their GPL'd version, but we can't assume those GPL'd versions will carry the brand, the recognition, the workforce and the decision. For example LibreOffice carried the workforce and the decision but did not carried the brand and had to build up recognition from scratch.

This is pretty problematic, and history shows that even among most successful forks may have hard time to fully recover. I'm not happy with this, but to properly deal with a problem we have to look at things the way they are and not the way we want them to be.

... but the ones who may buy copyrights, obtain CLA etc. have rights to add new licenses to the existing code (that would be dual licensing, even with non-free licenses)...

Erm, not quite... They cannot change the license of existing code. They however could republish the old code using a dual-license model (would not make too much sense for them) and they could try to add new code using a non-free license.

Why only "try"?

If there only remains one single line of code of which they do not have a CLA and which is originating as GPL before they added their shiny new stuff, then everything they add for new automatically becomes licensed under GPL, too (key word is "derivative work").

GPL is predatory in this regard: This is one of the main security features built into the GPL because RMS had foreseen situations like this. That twist is all but new...

... but to properly deal with a problem we have to look at things the way they are and not the way we want them to be...

I really would like stress and second this.

They cannot change the license of existing code.

I did not said change, I said add.

They however could republish the old code using a dual-license model

That's exactly what I said: “add new licenses to the existing code (that would be dual licensing […])”

Anyway, we are focusing on details about each other words, not about the specific questions related to Muse Group acquisition of Audacity. So we're loosing our time each other.

If something is not perfect in someone's word or may induce misinterpretation, this looks pretty minor compared to the topic, and those minor things can be handled later if they become non-minor at some point anyway.

I don't know where this poster got this information and if it is accurate...

It has not been widely publicized, but Muse group acquired rights to code contributions from many of the major contributors to the codebase. This doesn’t negate the GPL license, but would probably permit them greater control and maybe the ability to make a non-GPL version, but they haven’t suggested they are interested in that. If they did that, it would kill off the huge user support community and volunteer coder staff, and because the 3.0 codebase is still available, it could be forked from there or their latest GPL release. They may have plans to require license assignment from future third-party contributors, which might reduce the volunteer developer community, but it is not super-active anyway. I’m sure there are bug fix contributions that have not completely been acquired–from anonymous contributors, contributors who have died, and others who are just unfindable, but these would mostly have been reviewed, revised, and committed by identifiable team members who did license their contributions. There could be an issue with these contributions if Muse wanted to roll a pro version not under the GPL. It might require a substantial code audit if they wanted to do this which would be a huge obstacle, but If they tried that and somebody complained, it would mean the un-acquired code would then be clearly identified, and Muse could just pull it out or rewrite it or pay the contributor relicense it.

https://mu.se/newsroom/tpost/3dkxig59m1-muse-group-launches-to-support-music-tec

Executive roles and company leadership of Ultimate Guitar will transition into similar roles in Muse Group with no other major structural or operational changes within the individual portfolio companies.

@illwieckz

@illwieckz and @Locutus74

Just a quick reminder that this issue is about clearing up Muse Group's involvement and vision for the project. The details of copyright, while still to some degree very relevant here, are probably better discussed in detail over at 844.

Do we need a seperate issue for demanding that the people behind MuseCY Holdings Ltd and/or MuseCY SM Ltd. identify themselves and stop hiding behind Cypriot shell companies? This is not honest and open conduct.
Edit: An proprietary software developed under such circumstances would be considered highly suspect for being malware of some kind, of course here code can be audited, but if this program begins communicating with closed-source code at Muse...

Do we need a seperate issue for demanding that the people behind MuseCY Holdings Ltd and/or MuseCY SM Ltd. identify themselves and stop hiding behind Cypriot shell companies?

I don't think so. After all, one of the questions listed is: "Who exactly is behind Muse Group; what roles do these people have?"

I've got to say, I'm quite astonished that there is still no reply from any of those who do have at least some of the answers.

You're going to have to rely on public statements from https://mu.se/ and what you can work out for yourselves form publicly available information.

Beyond that, rely on actual behaviour of people actively working on Audacity. You can't tell that from immediate actions over the short term, only from longer term.

We use GitHub issues for issues with code. If someone closes this, it will be closed and locked pretty quickly. I'm converting this to a discussion so that it can stay open, at least for now.

Navigation Menu

Repository navigation

Request for clarification on Muse Group's involvement and vision for the Audacity project #855

12 remaining items

Metadata

Assignees

Labels

Type

Fields

Projects

Milestone

Relationships

Development

Request for clarification on Muse Group's involvement and vision for the Audacity project #855

Description

Activity

illwieckz commented on May 10, 2021

ethindp commented on May 10, 2021

Be-ing commented on May 10, 2021

Locutus74 commented on May 10, 2021

malberts commented on May 10, 2021

illwieckz commented on May 10, 2021

Locutus74 commented on May 10, 2021

orenwatson commented on May 10, 2021

Locutus74 commented on May 10, 2021

IGBC commented on May 10, 2021

Locutus74 commented on May 10, 2021

illwieckz commented on May 10, 2021

Be-ing commented on May 10, 2021

12 remaining items

Locutus74 commented on May 10, 2021

domsson commented on May 10, 2021

Blu3wolf commented on May 11, 2021

illwieckz commented on May 11, 2021

Locutus74 commented on May 11, 2021

illwieckz commented on May 11, 2021

Be-ing commented on May 11, 2021

Be-ing commented on May 11, 2021

domsson commented on May 11, 2021

orenwatson commented on May 11, 2021

domsson commented on May 11, 2021

JamesCrook commented on May 11, 2021

Metadata

Metadata

Assignees

Labels

Type

Fields

Projects

Milestone

Relationships

Development

Issue actions