We should say “GitLab isn’t Open Source, it’s open-core”, just like we can say about price that something “isn’t free, it’s freemium”. Both acknowledge that there is something Open or free going on, but it’s not that the label itself just applies. This distinction basically applies to situations where the same name is used for the whole open-core thing overall (regardless of ways they try to distinguish it, such as the unreasonable “community” vs “enterprise” labels).
Musescore is Open Source as long as we know that we’re talking about the software and not the Musescore.com hosting service. And that confusion is BAD, but there’s at least no proprietary software version of Musescore the software that is actually the same software basically (although there’s a non-zero risk of it becoming open-core as they are working to rewrite the codebase and have a CLA which undermines the stability of GPL!)
In general, we should make this distinction clear in all of the ways we talk. A project is only FLO if 100% of what they publish under the project name is FLO.
And GitLab has gotten worse and worse, and open-core business models in general are not aligned with FLO and should be treated with suspicion. We probably should seriously consider moving to Codeberg. But for now, I’m suggesting we make the labels clear.
Open-core already did not fit the stated project requirements for Snowdrift.coop, and I’m just suggesting we use that term clearly and consistently. Some projects are FLO, some are open-core. We need to consider them and talk about them as distinct, even as we recognize that open-core is not the same as entirely proprietary.
On labels and distinctions, I recently discovered “Fair Code”, under which licenses are effectively identical to Open Source but prevent one narrow kind of commercial use. Since this wouldn’t officially meet the OSI or Free Software definitions (nor is it trying to), I assume we would block a given brand/group from using our platform to fund a fully FLO project, if they publish any pseudo-FLO stuff as well?
If they have even one separately published program with a GPL+Commons Clause license, for example? This seems to me to be something different from open-core, but maybe not…
We haven’t decided where to draw the line on entities who make both FLO and non-FLO. This topic is about drawing a line about whether a project can be considered FLO if the very name of the project applies to both FLO and proprietary versions made by the same entity, and really it’s not even just that, it’s whether the name that refers to something refers to both FLO and proprietary versions of that something.
So, Musescore demonstrates the ultimate edge-case to consider. Imagine for rhetoric that zero of Musescore the FLO software is used in anything proprietary (though perhaps it is in reality used for proprietary mobile-app versions of Musescore). Imagine the issue is only that a proprietary web hosting service Musescore.com has the same Musescore name. Even still, if we err toward avoiding anything confusing and deceptive, Musescore would be out.
The key is, the entity “MuseScore BVBA” could change the name of Musescore the FLO software to being NoteScore or something, and then if they stuck to the distinction where Notescore was never used to label anything proprietary, we would probably accept NoteScore as a project because regardless of what else MuseScore BVBA does, what matters is that a name “NoteScore” is a name for a 100% unambiguous and clear FLO project. We would still very much care about it being boldy front-and-center that Notescore software is used in proprietary Musescore softwares made by the same MuseScore BVBA entity.
Or we could decide that the legal entity behind a FLO project must themselves make no proprietary derivatives of the FLO project. I do think that in even that case, we would allow it even if that same entity made other truly unrelated and distinctly-named proprietary projects.