[MUSE HUB] Muse Hub is packaged as .deb which excludes non deb-based Linux distributions

[sberla365]

I am running Fedora 36 and having the Muse Hub packaged as a deb is a bit of mess. I tried to unpack the deb file and manually install the files in the correct locations. This brought to permission issues (which are solved through a native installer) and had to run MH through sudo. The experience was horrible anyway. After having downloaded some sounds, they appear as not downloaded (get) in MH after restarting the application. The fonts are loaded in MU4 though.

I have repackaged the deb to rpm using alien but installing the converted rpm reports a missing dependency liblttng-ust.so.0()(64bit) The dependency is part of lttng-ust which is installed in Fedora but in its version liblttng-ust.so.1()(64bit) and it is not recognised.

My suggestion, although I am not a developer and have no experience in programming, would be to package the Hub as a universal package, such as appimage (which is already done with musescore). This would allow compatibility across linux distros and ensure the shipment of the required libraries.

[sberla365]

I think it has to do with Muse Hub's interoperability with other software by the Muse company, some of which are closed source

[jeetee]

Perhaps, as mentioned before, it would make sense to write up these concerns, thoughts and requests for official statements in a place where those developing the Hub application might actually see them and respond to them? Their support site is over at https://musehub.zendesk.com/

The Hub and the Sounds are both closed source and are both not unique to MuseScore, but also cater to other products from the Muse Group, some of which (StaffPad for example) are closed source products (an Apple App Store requirement as well).

While I personally share some of the disappointment that the Hub seems to require permissions it probably shouldn't and turned out as a closed source thing; if official statements and feedback is what you're looking for, this is not the place to find them.

As for the topic title and base question; in one of the tickets on that site they have mentioned the intent to at least investigate distributing different package formats as well.

[aspiers]

I agree with a lot of the recent comments made here.

One can understand a decision to keep the Sounds closed source (even without necessarily agreeing with it) since the Sounds provide a notable advantage for MuseScore over its competitors. It's also worth bearing in mind that it doesn't really make sense to release large audio files under a software license, because they are audio data rather than code. If the Sounds were to be released under a more permissive license, most likely a Creative Commons license or similar would make more sense.

However MuseHub is simply a downloader/installer utility with no obvious significant competitive advantage (p2p torrent-like downloaders are nothing new). So if there's no appetite for releasing the Muse Sounds data under a more open license, it seems to me that there's still a very strong argument for making MuseHub open source while keeping the data it downloads under a closed license.

That way, each Linux distribution could maintain packages of MuseHub without impacting any competitive advantage, and anyone, even Mac/Windows users, could help make MuseHub better. Surely this would be a win for everyone involved.

If I see a few :+1: reactions to this comment then I'll happily post this suggestion on their support site.

Having said that, it's almost certainly naive to believe that the licensing hasn't already been carefully considered by smart and well-informed people, so maybe there's a stronger obstacle to making MuseHub open source whilst keeping the data it manages closed. Perhaps @Tantacrul can comment here.

[aspiers]

BTW if MuseHub was made open source, I would gladly submit a package for it to the openSUSE Build Service, which is an instance of the Open Build Service capable of building packages for not only openSUSE but also Fedora, Ubuntu, and several other distributions.

[EB2000]

We are talking about three products:

• Muse Hub
• the Muse Sounds
• the library /usr/lib/libMuseSamplerCoreLib.so which is loaded by musescore to access the Muse Sounds

Muse Hub is closed source and install the two others. Muse Sounds are not code, but mostly some data. I don't know what licence is needed for this to be packaged. I am more concerned about the library, which seems to be absent from the discussion here. Could the library be made open source?

If it turns out to be possible, then the distributions could package the library (from source) and the sounds (as binary blobs) and skip the hub.

If it doesn't turn out to be possible, then I guess we would have to live with some closed source program to enjoy the beautiful Muse Sounds. But I would much prefer it to be a simple library, running with user level privilege, and only when musescore is running, rather than a system service running as root all the time.

[cbjeukendrup]

Keep in mind that /usr/lib/libMuseSamplerCoreLib.so is only a simple dylib, loaded directly by MuseScore, and has no special privileges nor is a system service.

The thing that is a system service is the Muse Hub helper service; yes, that is yet another thing.

I don't expect /usr/lib/libMuseSamplerCoreLib.so will be made open source, as this library must contain the magic that makes Muse Sounds so good. I'd think this library is at least as valuable as the Muse Sounds data files.

[aspiers]

Thanks for highlighting the importance of the libMuseSamplerCoreLib.so sampler library. @cbjeukendrup is probably right that this contains some of the magic ingredients which produce such great results. Nevertheless, I would probably support open sourcing of that too, since:

• it would ensure it never becomes "dead-end" technology like Sibelius and SCORE became,
• it would allow the community to improve it, and
• if Muse Sounds was kept proprietary and not licensed for use by competitor products, then no competitor could use this library without making their own sounds.

In general, most Linux distributions will not accept packages of proprietary code or data. There are some exceptions, but I think in this case it would be impossible or at least a significant uphill struggle in most cases, accentuated by the enormous size of the Muse Sounds data. Due to this size, I think Muse Hub does provide value as a more efficient p2p mechanism for distributing the data. So my opinion about the optimal course of action remains more or less the same, although now taking the library into account:

• Release Muse Hub under an Open Source license, so that it can be packaged by any Linux distribution and supported by the whole community.
• It can then download the proprietary libMuseSamplerCoreLib.so sampler library and Sounds without violating any licenses or distribution policies.
• If possible, later release libMuseSamplerCoreLib.so under an Open Source license.

[aspiers]

It's also worth noting that when system-level services are packaged by distributions, their privileges can be restricted so tightly by technologies such as AppArmor and SELinux, that from a security perspective there's little difference to if they were running non-root.

And we have already seen that the service requires system-level privileges (e.g. for tweaking SSL certificates and/or the firewall) for the p2p functionality to operate, so it may not be possible for it run at user-level.

These kinds of tweaks very typically vary between Linux distros, which IMHO strengthens the argument for making Muse Hub Open Source and delegating the task of packaging it to the distro communities.

[jeetee]

Once again though; there is extremely little to be gained by further repeating and refining the details of Hub requests in the MuseScore issue tracker. Please move the discussion onto the correct platform.

[LGFae]

Once again though; there is extremely little to be gained by further repeating and refining the details of Hub requests in the MuseScore issue tracker. Please move the discussion onto the correct platform.

I've opened a thread over there: https://musehub.zendesk.com/hc/en-gb/community/posts/8536393474461-Muse-Hub-any-plans-of-making-the-source-code-available-.

[huantianad]

@Horus645 Sorry to continue this discussion, but it seems that your link is dead. Heading to it the website tells me that "The page you were looking for doesn't exist." Is there a different thread that's being used to track this issue, or is it an issue on my end?

After a quick look it seems that zendesk page, it seems that all the issues are gone, and only help articles remain? Is this a temporary change? Should we still be discussing the issue there?

[aspiers]

That link still works fine for me.

[LGFae]

It seems the service was simply temporarily unavailable . I tested very shortly after @huantianad made his comment and got a 404. But it has indeed come back now.

[osvein]

Because libMuseSamplerCoreLib.so is dynamically linked against Debian libraries, it can't be relied on to work on non-Debian systems due to ABI incompatibilities. For instance it currently won't run out-of-the-box with the MuseScore flatpak because of differences between Debian and the Flatpak runtime.

15706 is somewhat related.

[Tantacrul]

Muse Hub issues should be directed here: https://musehub.zendesk.com/hc/en-gb

Closing this conversation for now.