I see your points. In the end it boils down to the fact that there is no clear split between free and paid features in the codebase itself due to the chosen commercialization model. The paywall that is in place right now is mostly artificial because the code is the same for all systems. So even if I wanted to, I could not implement the classic open core model with a fully open source base version. I could have used a different approach to start out, e.g. only locking certain features behind a license and not certain remote systems like it is currently done. That would have probably allowed me to implement the more classic open core model. But the current model also has its advantages in other areas.
You can just ship your own version of the repo if you want due to the apache license. To properly run this the user would however still need the regular xpipe installation which contains some parts that you would still need to properly make use of it. I think the term basic core functionality can be interpreted differently here. So if you are talking about being able to use all the nice features that make xpipe stand out, then yes these non-open-source components are necessary for core functionality. If you are just talking about being able to run the application and do limited things with it, then they are not.
Yeah maybe the term open core is not the best way to describe it as it doesn’t entirely fit the pattern. I’m open for better suggestions where I can still somehow highlight that most of the application is open source (in terms of LOC, it is around 90% in that repo)