MuseScore
MuseScore copied to clipboard
musescore
[MU4 Issue] Possible GPL violation when linking to Muse Sampler
Describe the bug I am not a lawyer and this is not legal advice. I'm worried that distributing MuseScore 4 violates the GPLv3 licenses of the VST SDK and MuseScore itself, because it contains code which links to the MuseSamplerCoreLib library. There doesn't seem to be a way to obtain the source code of that library as required by the GPLv3.
To Reproduce See src/framework/musesampler/internal/libhandler.h, the code which links to MuseSamplerCoreLib. The file's header states that it is covered by GPLv3.
Expected behavior MuseScore shouldn't contain closed source components in a way that violates the GPLv3. Me and others who are looking to include MuseScore 4 in Linux distributions expect that we should be able to distribute MuseScore 4 without violating its license and licenses of third parties.
Additional context §6 of MuseScore 4's GPLv3 license:
You may convey a covered work in object code form under the terms of sections 4 and 5, provided that you also convey the machine-readable Corresponding Source under the terms of this License, in one of these ways: (...)
"Corresponding Source" is defined in §1:
The "Corresponding Source" for a work in object code form means all the source code needed to generate, install, and (for an executable work) run the object code and to modify the work, including scripts to control those activities. However, it does not include the work's System Libraries, or general-purpose tools or generally available free programs which are used unmodified in performing those activities but which are not part of the work. For example, Corresponding Source includes interface definition files associated with source files for the work, and the source code for shared libraries and dynamically linked subprograms that the work is specifically designed to require, such as by intimate data communication or control flow between those subprograms and other parts of the work.
I'm not an expert either but I don't think there is a violation, because MuseSamplerCoreLib is not distributed together with MuseScore itself, and it is also not really linked to MuseScore's source code. It is not part of MuseScore itself.
MuseScore can indeed load this library at runtime, but MuseScore can also open mscz files created by users and it can also load QML plugins (from any source with any license). About those things, nobody is complaining, and I don't see how the situation with MuseSamplerCoreLib is very different.
In my view, the file https://github.com/musescore/MuseScore/blob/master/src/framework/musesampler/internal/libhandler.h (which is part of MuseScore, and therefore also open source and under the GPL license), plays a role that is similar to, for example, https://github.com/musescore/MuseScore/blob/master/src/plugins/api/qmlpluginapi.h and https://github.com/musescore/MuseScore/blob/master/src/engraving/rw/scorereader.cpp.
IANAL, but the interface definition as mentioned under Corresponding Sources is indeed part of the GPL3 code and available. As for dynamically linked subprograms, the sampler itself is not linked in, but loaded and is also not required to be able to build, operate, run or distribute MS4.
The idea here is that MuseScore is not tied to any specific implementation of the Muse Sampler API. Anybody can write a library that implements the Muse Sampler API and MuseScore will load it just fine, just like anybody can write VST plugins and MuseScore will load the plugins just fine.
I had a look at the GPL FAQ
mscz files would probably be considered data, not code, and therefore not be covered by GPL:
If a programming language interpreter is released under the GPL, does that mean programs written to be interpreted by it must be under GPL-compatible licenses? (#IfInterpreterIsGPL) When the interpreter just interprets a language, the answer is no. The interpreted program, to the interpreter, is just data; a free software license like the GPL, based on copyright law, cannot limit what data you use the interpreter on. You can run it on any data (interpreted program), any way you like, and there are no requirements about licensing that data to anyone.
The FAQ has this to say about plug-ins:
When is a program and its plug-ins considered a single combined program? (#GPLPlugins) It depends on how the main program invokes its plug-ins. If the main program uses fork and exec to invoke plug-ins, and they establish intimate communication by sharing complex data structures, or shipping complex data structures back and forth, that can make them one single combined program. A main program that uses simple fork and exec to invoke plug-ins and does not establish intimate communication between them results in the plug-ins being a separate program. If the main program dynamically links plug-ins, and they make function calls to each other and share data structures, we believe they form a single combined program, which must be treated as an extension of both the main program and the plug-ins. If the main program dynamically links plug-ins, but the communication between them is limited to invoking the ‘main’ function of the plug-in with some options and waiting for it to return, that is a borderline case. Using shared memory to communicate with complex data structures is pretty much equivalent to dynamic linking.
If I write a plug-in to use with a GPL-covered program, what requirements does that impose on the licenses I can use for distributing my plug-in? (#GPLAndPlugins) Please see this question for determining when plug-ins and a main program are considered a single combined program and when they are considered separate works. If the main program and the plugins are a single combined program then this means you must license the plug-in under the GPL or a GPL-compatible free software license and distribute it with source code in a GPL-compliant way. A main program that is separate from its plug-ins makes no requirements for the plug-ins.
This seems to describe both Muse Sampler and QML plugins.
The idea here is that MuseScore is not tied to any specific implementation of the Muse Sampler API. Anybody can write a library that implements the Muse Sampler API and MuseScore will load it just fine, just like anybody can write VST plugins and MuseScore will load the plugins just fine.
Is the Muse Sampler API documented?
Better than documentation, you have the actual source code. The API is simply the header files that the program and library have in common. Those header files are fully open source under the GPL.
The header files are GPL, but the closed source library can use them because of the CLA. So effectively the shared header files are dual licensed GPL + commercial. When MuseScore includes those header files it does so under the GPL. When the library includes them it does so under the commercial license granted by the CLA. The program and library are distributed separately and the combination happens on the user's machine. This is the same situation that arises when you use a closed source VST plugin with MuseScore (or with any other GPL application that supports VST).
The library is not required to compile or use MuseScore (not even for playback purposes). MuseScore would work with any library that implements the same API.
I think @shoogle is correct that this is ok for Muse Sounds because of the CLA. And I personally have no problem with Muse Sounds being proprietary. I do, however worry that the Muse group is the only entity able to create proprietary samplers under this system. If MuseScore allows proprietary samplers then it should allow anyone to create them, so I would ask that the appropriate headers be MIT licensed (or similar).
It is OK because MuseScore does not link against the proprietary sampler library, regardless of the CLA.
As it stands, others can create either GPL'ed samplers against the GPL version of the interface (as available via the MuseScore source code) or contact Muse Group to attain a different license; which it can provide thanks to the CLA. It is up to the Muse Group whether they would like to allow others to create these proprietary samplers and under which conditions they'd want that. MIT could be an option if they want no license fees on it.
The main problem is that the musecore website tells loud and clear that the "plugin" is considered a part of the programs main standards and functionality. You can use the program without, but are encouraged to download and install it. And that is clearly against the spirit of the gpl. license.
The default download link also goes to the closed source Muse Hub. It might feel against the GPL spirit, but it is not a violation AFAIK, which is the topic of this thread.
Better than documentation, you have the actual source code. The API is simply the header files that the program and library have in common. Those header files are fully open source under the GPL.
I would be careful to consider the header files alone to be sufficient documentation for others to use the API. I hope that if the API is really intented to be usable by others, some proper documentation will be added like we have for QML plugins. Would be great to see Muse Sampler included in other software as well because its performance seems to be unmatched at the moment.
Until then I agree with @larshenrikoern that it seems like Muse Sounds is intended to be an essential part of MuseScore, especially with the many regressions in playback from MuseScore 3 without it, like no MIDI program change, no bends, no SFZ on Linux.
Better than documentation, you have the actual source code. The API is simply the header files that the program and library have in common. Those header files are fully open source under the GPL.
I would be careful to consider the header files alone to be sufficient documentation for others to use the API. I hope that if the API is really intented to be usable by others, some proper documentation will be added like we have for QML plugins.
I would go further: the header file linked at the beginning of this thread is essentially useless for someone who would want to implement MuseSamplerCoreLib themselves. There is no description of what each function is supposed to do, if there are or aren't side-effects, which version of the C++ language to use, how to link it against Musescore, etc. Normally, for things where the original software developers encourage "rolling your own implementation", these are all thoroughly explained, with multiple toy examples to help users along the way.
It might feel against the GPL spirit, but it is not a violation AFAIK, which is the topic of this thread.
I would like to point out that the GPL, and specifically GPL3, was created with a very specific purpose, with a clear historical reasoning behind it. Broadly speaking, I believe it is very difficult to make the argument that something can be against its spirit but not violate it. Fundamentally, due to what it is trying to achieve, if it is against its spirit, it may very well violate it, since its spirit is very much the whole point of the thing. At the very least, most people who put the GPL3 license in their open source project tend to give it the most encompassing interpretation possible, precisely because that is the whole point of its existence.
As things currently stand, I agree with @larshenrikoern and @osvein: it does not appear (as the time I am writing this; it could change in the future) that MuseSamplerCoreLib is something that musescore expects people to implement themselves and musescore is objectively less useful without it.
Until then I agree with @larshenrikoern that it seems like Muse Sounds is intended to be an essential part of MuseScore, especially with the many regressions in playback from MuseScore 3 without it, like no MIDI program change, no bends, no SFZ on Linux.
All of the regressions you mentioned are separate issues to be addressed regardless of the optional Muse Sounds library (I for one use MS4 perfectly fine without it currently).
I would like to point out that the GPL, and specifically GPL3, was created with a very specific purpose, with a clear historical reasoning behind it. Broadly speaking, I believe it is very difficult to make the argument that something can be against its spirit but not violate it.
The thing that feels against the GPL spirit are the Hub and the Sounds, both projects not encompassed by it. The API itself to communicate with the Sounds library however is GPL and part of MuseScore. Fundamentally, that is what this issue is about imho. I don't see the same concerns or rejections being raised against the VST support now built in? Or is that just because the Muse Group themselves did not also release or promote a VST?
Plans to release more documentation around the playback system and Sounds interface have been announced via Discord from before the beta. Whether or not that documentation will include examples remains to be seen.
it does not appear (as the time I am writing this; it could change in the future) that MuseSamplerCoreLib is something that musescore expects people to implement themselves
I would indeed assume that. Having the interface public and allowing other to develop plugins against it is something different from supporting others in reimplementing your own closed source library implementation of it. Nor would I expect any closed license program that was written against a public interface expect to do so.
I would be careful to consider the header files alone to be sufficient documentation for others to use the API. I hope that if the API is really intented to be usable by others, some proper documentation will be added like we have for QML plugins.
I love how you point to the QML plugins as an example; an API notoriously under and un-documented for many years, with only a handful of source code samples to work from. The doxygen generated API docs are so well written that fairly often one has to dive into the MuseScore sources to see what is actually happening.
That header file is the most correct form of documentation that there is (or will be), even after additional documentation might be released. It is guaranteed to be not out of date.
As for the comment that "There is no description of what each function is supposed to do" for the header file: Isn't that exactly what an interface is about? Give connection points without making assumptions of the implementation behind it? If someone wants to use the interface to drive a mechanical playback orchestra, then that's fine too.
The question that was raised is whether or not MuseScore is in violation of the GPL by including the (equally GPL'ed) interface files of a plugin system that may be used for playback and of which "Muse Sounds" is a proprietary example of a plugin using said interface. The answer to that question is "no, there is no GPL violation in MuseScore because of that interface inclusion".
There is a reason why companies like Redhat is not giving links or helper programs for download of copyrighted non-free licensed codecs. Because that would be a violation of the gpl.
The frontpage of musescore.org is showing of the sounds from Muse hub as one of their main reasons to use Musescore. But Musehub is not a part of Musescore. So I could say the company behind the current development is trying to make Musescore partly nonfree. That is most likely an violation of the gpl.
I have for years been able to use nonfree software for my entire workflow. But what the musegroup is doing right now might make that impossible. I am currently using FreeBSD for my workflow. And I can compile almost any free software. Muse hubs sound is not and might very well never be released for that. Free to download for certain os'es but it is not free software according to the gpl or compatible licenses.
I do hope they release it under an open license soon. Then I will have no objections against the Muse Group and what they are doing.
The Muse Group is indeed pushing for all of its products (you might have noticed the "search for sheet music" in the header of .org over the last 10 years?) and many of those are not open source.
If you yourself choose to draw the line at Muse Sounds and Muse Hub (again, both totally optional for MS4) then that is of course fine. But Muse Group pushing non-free things has been a constant for years with the commercial score sharing platform as well.
The Muse Group is indeed pushing for all of its products (you might have noticed the "search for sheet music" in the header of .org over the last 10 years?) and many of those are not open source.
If you yourself choose to draw the line at Muse Sounds and Muse Hub (again, both totally optional for MS4) then that is of course fine. But Muse Group pushing non-free things has been a constant for years with the commercial score sharing platform as well.
The Muse Group do not own Musescore. So it is not their product. But they are free to distribute, contribute and even sell it. Everything that is allowed according to the GNU license 3
I'm not sure what definition of "own" you have in mind when you state "The Muse Group do not own Musescore". But for the record, by any conventional definition I can think of, yes, certainly they do. Similarly, I'm struggling to understand what you mean in saying "it is not their product". Again, by any conventional definition of "their", of course it is their product..
I'm not sure what definition of "own" you have in mind when you state "The Muse Group do not own Musescore". But for the record, by any conventional definition I can think of, yes, certainly they do. Similarly, I'm struggling to understand what you mean in saying "it is not their product". Again, by any conventional definition of "their", of course it is their product..
They may have the rights for the name. But as it is gpl 3 Anyone is allowed to fork the code ,change and redistribute it as long it is done under the same license. So they do not own the code. But anyone (and especially you) should be recognized for contributing :-)
Muse Group owns the copyright of MuseScore thanks to the CLA. But MuseScore also contains code owned by third parties like the VST SDK, which means that a GPL linking exception for Muse Sampler wouldn't be possible.
The GPL doesn't mind the proprietary web services, and neither do I because I can use them on Linux just fine. But Muse Sampler being closed source is directly hurting the usability of MuseScore on Linux, both because it's only built for Debian, and because it brings into question the legality of including MuseScore itself in Linux distributions, with or without Muse Sampler.
Sure, of course anyone is allowed to redistribute. But ownership of a project - open source or otherwise - goes far beyond rights to a name. And in any possible legal sense I can imagine one trying to define, the Muse Group owns MuseScore. Not that I understand the point you were trying to make in claiming otherwise. I just found it a curious statement - factually incorrect, but also not obviously relevant to the discussion whether true or not.
Muse Group owns the copyright of MuseScore thanks to the CLA. But MuseScore also contains code owned by third parties like the VST SDK, which means that a GPL linking exception for Muse Sampler wouldn't be possible.
The GPL doesn't mind the proprietary web services, and neither do I because I can use them on Linux just fine. But Muse Sampler being closed source is directly hurting the usability of MuseScore on Linux, both because it's only built for Debian, and because it brings into question the legality of including MuseScore itself in Linux distributions, with or without Muse Sampler.
Thats my point as well. I am a former debian user. And right now using FreeBSD. And I am, as you might have guessed, a strong supporter of opensource software.
And yet again I fail to see how (or why) you try to make the distinction between Muse Sounds and the interface for it or any random proprietary VST that you can't run and it's interface.
The question is and remains "Is MuseScore violating the GPL" and the answer remains plainly "No". I don't see why you'd consider the optional Muse Sounds playback plugin any more or less "hurting the usability of MuseScore" compared to any other equally (third party) VST playback plugins which themselves may or may not be open source and/or (un)available for your platform.
And yet again I fail to see how (or why) you try to make the distinction between Muse Sounds and the interface for it or any random proprietary VST that you can't run and it's interface.
With VSTs, there are usually three separate licensors: Steinberg, the plugin host developer and the plugin developer. It wouldn't make sense to blame either party for making it possible to use a GPL-incompatible plugin with a GPL host or vice versa. And the user doing the linking can't be blamed because "You may make, run and propagate covered works that you do not convey, without conditions so long as your license otherwise remains in force."
I think it makes a difference that MuseScore, Muse Sampler and the Muse Score API are all owned by Muse Group. I'm not saying that I'm convinced it's a violation, but I'm surprised that Muse Group seems to think that this is entirely unproblematic and has such a different interpretation of the GPL compared to the FSF.
I don't see why you'd consider the optional Muse Sounds playback plugin any more or less "hurting the usability of MuseScore" compared to any other equally (third party) VST playback plugins which themselves may or may not be open source and/or (un)available for your platform.
I'm worried that Muse Group is moving features which were previously open source and supported on all platforms into a proprietary component which only works on select platforms. I would've been equally disappointed if these features were removed from MuseScore because they could be provided by a third-party VST unsupported on Linux, which seems to be the case with SFZ and MIDI program change btw (correct me if I'm wrong). But in that case I wouldn't be concerned about the legal aspect when distributing MuseScore.
I'm worried that Muse Group is moving features which were previously open source and supported on all platforms into a proprietary component
Except this most certainly has not happened. Not a single line of code has moved into a proprietary component. It's a complete red herring.
I didn't suspect any physical code from MuseScore has been copied to Muse Sampler, as it seems to contain mostly StaffPad code (though I'm not sure that would've been a GPL violation due to the CLA). I'm just saying it feels like the quality of out-of-the-box playback has received lower priority due to Muse Sounds. Otherwise I don't see why there would be such regressions in a major stable release which is being strongly advertised as having improved playback.
But I didn't intend for this to be a discussion about development decisions. This issue won't be resolved until someone states clearly on behalf of the copyright owner that they don't believe this to be a violation.
Muse Group owns the copyright of MuseScore thanks to the CLA. But MuseScore also contains code owned by third parties like the VST SDK, which means that a GPL linking exception for Muse Sampler wouldn't be possible.
The GPL doesn't mind the proprietary web services, and neither do I because I can use them on Linux just fine. But Muse Sampler being closed source is directly hurting the usability of MuseScore on Linux, both because it's only built for Debian, and because it brings into question the legality of including MuseScore itself in Linux distributions, with or without Muse Sampler.
Think of our support for VST, which allows people to use proprietary 3rd party VST samplers. Our support for Muse Sounds is no different. We created a new system for sending playback events (an alternative to MIDI, called MuseScore Playback Events), which others can make use of to create their own samplers - and which is packed in MuseScore and licensed under GPL3. The Muse Sounds sampler is simply patient zero. Others will be able to make their own plugins using MNFPE and can license it however they please. We have not (yet) had time to document the whole thing, incidentally but we will.
Regarding Linux support, one problem the Muse Sounds team had was the vast amount of work involved in supporting every Linux distro. This is an ongoing thing. We had to start somewhere, so supported some of the most popular distros, with the intention to expand over time. Linux always costs much more to support than Mac or PC for this reason (this is also true for my other team, Audacity). There is no rule in GPL that says you have to support every distro on Linux immediately. We're getting there but it's not an easy thing, so takes time.
@osvein
I'm just saying it feels like the quality of out-of-the-box playback has received lower priority due to Muse Sounds.
Did you somehow miss the fact that we implemented VST fx and VSTi support? That was an enormous amount of work - and something we'll be building upon as a matter of priority.
Regarding Linux support, one problem the Muse Sounds team had was the vast amount of work involved in supporting every Linux distro. This is an ongoing thing. We had to start somewhere, so supported some of the most popular distros, with the intention to expand over time. Linux always costs much more to support than Mac or PC for this reason (this is also true for my other team, Audacity). There is no rule in GPL that says you have to support every distro on Linux immediately. We're getting there but it's not an easy thing, so takes time.
I am not expecting anyone to support my system (FreeBSD). I am expecting that I can debug, patch and compile it myself. But I expect that GPL program makes their complete source code available so I can do so (or together with others). And that Gpl software.
Here is what is saying about what you are doing. Corect me if I am wrong :-)
"I'd like to incorporate GPL-covered software in my proprietary system. I have no permission to use that software except what the GPL gives me. Can I do this? (#GPLInProprietarySystem)
You cannot incorporate GPL-covered software in a proprietary system. The goal of the GPL is to grant everyone the freedom to copy, redistribute, understand, and modify a program. If you could incorporate GPL-covered software into a nonfree system, it would have the effect of making the GPL-covered software nonfree too.
A system incorporating a GPL-covered program is an extended version of that program. The GPL says that any extended version of the program must be released under the GPL if it is released at all. This is for two reasons: to make sure that users who get the software get the freedom they should have, and to encourage people to give back improvements that they make.
However, in many cases you can distribute the GPL-covered software alongside your proprietary system. To do this validly, you must make sure that the free and nonfree programs communicate at arms length, that they are not combined in a way that would make them effectively a single program.
The difference between this and “incorporating” the GPL-covered software is partly a matter of substance and partly form. The substantive part is this: if the two programs are combined so that they become effectively two parts of one program, then you can't treat them as two separate programs. So the GPL has to cover the whole thing.
If the two programs remain well separated, like the compiler and the kernel, or like an editor and a shell, then you can treat them as two separate programs—but you have to do it properly. The issue is simply one of form: how you describe what you are doing. Why do we care about this? Because we want to make sure the users clearly understand the free status of the GPL-covered software in the collection.
If people were to distribute GPL-covered software calling it “part of” a system that users know is partly proprietary, users might be uncertain of their rights regarding the GPL-covered software. But if they know that what they have received is a free program plus another program, side by side, their rights will be clear."
The full MuseScore source code is available here under the GPLv3 terms, so I'm not sure what you're alluding to?
The closed source programs from MuseScore do not include GPL-covered source code. It does include the same source code under a different license, as made possible via the MuseScore CLA.
Muse Hub on the other hand is a different program altogether and as mentioned many times, the MuseScore github is not the place to be discussing details of that software package just because it happens to be owned/published by the same parent group company.
The full MuseScore source code is available here under the GPLv3 terms, so I'm not sure what you're alluding to?
The closed source programs from MuseScore do not include GPL-covered source code. It does include the same source code under a different license, as made possible via the MuseScore CLA.
Muse Hub on the other hand is a different program altogether and as mentioned many times, the MuseScore github is not the place to be discussing details of that software package just because it happens to be owned/published by the same parent group company.
I did not mention MuseHub. You did. I am talking about Musescore itself and its freedom.