Hi there, I’m thinking of making an Open source OpenXR / CloudXR client for Quest, is this allowed?
I know there are a couple clients already out there on Github, one by Pico and one by someone else, but just because they may or may not have permission, doesn’t mean it is actually permitted.
PS: An open source CloudXR client app, or even just an APK, is totally useless without the SteamVR plugin to go along with it, i.e. the CloudXR-Setup.exe file. I guess my next question would be: how can we share that? Is there any chance Nvidia might consider asking Valve to integrate it directly into SteamVR proper? Because without that installer, the only alternative is to use the server plugin / direct engine integration method in CloudXR 4.0, which isn’t out yet. But then I need to check if it’s ok to redistribute the libs as well. Without both client and server side libs or installer, it’s totally useless to make a client open source.
The short answer is a conditional “Yes”. What I received as information it roughly means that as long as you stay within permissive licenses (not GPL and the likes) follow all the rules of the EULA and do NOT brand anything as NVIDIA, you should be fine. But this is not legal advice!
Because the long answer is that you MUST read and follow the EULA, which is part of the CloudXR SDK, before any redistribution of NVIDIA binaries or reference code.
With respect to the SteamVR plugin I am still trying to find some answer for you.
I will definitely read it carefully and even ask some reps directly, but that’s exciting!
I want to use CloudXR as a kicking off point to help people escape the rigid constraints of Oculus Runtime, SteamVR, and Virtual Desktop, which are all closed source. CloudXR libraries and plugin are of course closed source, but they’re just the middleware layer, with ways to forward extra data like Hand/Eye/Body/Face tracking over the standard input methods rather than having to use external solutions like ODS that I consider to be hacks and I don’t want to build my tech/games on a shaky foundation.
I will make sure to get an OK. If I release an open source OpenXR client, I have no intention of using GPL (which I consider poison, or a legal virus, as a developer)
I need to be able to post the CloudXR-installer.exe and both client and server-side .libs and headers to github. I of course won’t do anything to jeopardize my relationship and good standing with Nvidia (legally or otherwise).
I could potentially just release a closed source APK / binary for the OpenXR VR client (I’d rather an A-to-Z fully open source solution), but the server side has to be fully open source in the sense that I don’t have time (or even skills) to write my own OpenXR compositor from scratch, so I have to piggy-back off other solutions.
Either Monado or this one here which isn’t officially compliant but has ASW / smoothing which matters far more:
This is of course using the closed source but mature and popular Virtual Desktop, but I’d like to also be able to connect to it using CloudXR clients as well. I will also be integrating CXR 4.0 directly in my game engine, bypassing an OpenXR runtime entirely (on the PC side), but it remains to be seen how well that works, or how it handles frame drops, or if your engine is supposed to do framerate insurance yourself (ex FPS = Hz at all times). This is my goal, possibly relying on DLSS-G and / or dynamic resolution scaling, or dynamic foveation, to guarantee max FPS = Hz at all times. But I just want to be clear about my goals here before I waste my time doing something that may run afoul of any restrictions NV may have.
It’s pointless for me to do most of this if I can’t share the client or server libs + installer for CXR. I may still use a closed source CXR 4.0 client and direct engine integration, but that’s a big ask / unknown number of users would be willing to not use SteamVR or Virtual Desktop. There are human issues (brand loyalty, familiarity, inertia) that often trump technical ones (better image quality, latency, features). I’d like to cover all my bases here and use an OpenXR runtime that supports both Virtual Desktop and CloudXR connectivity.
That is something I cannot comment on, you have to decided that. But did you mean BSD?
One clarification I received though which is that “The entirety of the CloudXR distribution is redistributable, but the distribution does not include an OpenXR runtime (or OpenVR runtime, like SteamVR).” according to the EULA.
Thanks for the replies, looks like I’m good to go, I’ll use MIT and I’ve forked the runtime in the link above to add CloudXR backend to it. I will be rewriting a new CloudXR client from scratch and publishing that too.
Monado, the other alternative OpenXR runtime I could have picked, is using BSL, or Boost Software License:
But I believe mbucchia’s one works better in frame drop scenarios (still testing this aspect) and supports reprojection.
Is CloudXR 4.0 final version going to be launched any time soon? I know you are still at RC2 for early access folks.