Hey all, I have a prototype of VR display and sensor integration with the web, along with an implementation for the Oculus VR. Despite there really being only one vendor right now, there is a lot of interest in VR. I'd like to add the web and Firefox to that flurry of activity... especially given our successes and leadership position on games and asm.js.
I'd like to get this checked in so that we can either have it enabled by default in nightlies (and nightlies only), or at least allow it enabled via a pref. However, there's one issue -- the LibOVR library has a not-fully-free-software license [1]. It's compatible with our licenses, but it is not fully "free". There are a couple of paths forward, many of which can take place simultaneously. I'd like to suggest that we do all of the following: 1. Check in the LibOVR sources as-is, in other-licenses/oculus. Add a configure flag, maybe --disable-non-free, that disables building it. Build and ship it as normal in our builds. 2. Contact Oculus with our concerns about the license, and see if they would be willing to relicense to something more standard. The MPL might actually fit their needs pretty well, though we are effectively asking them to relicense their SDK code. There is no specific driver for the OVR; it shows up as a USB HID device, and LibOVR knows how to interpret the data stream coming from it. This gets them easy compat with all operating systems, and the support I'd add would be for Windows, Mac, and Linux. 3. Start investigating "Open VR", with the intent being to replace the Oculus-specific library with a more standard one before we standardize and ship the API more broadly than to nightly users. The goal would be to remove LibOVR before we ship (or keep it in assuming it gets relicensed, if appropriate), and replace it with a standard "Open VR" library. There are a few other options that are worse: 1. We could ship the VR glue in nightly, but the Oculus support packaged as an addon. This is doable, but it requires significant rework in changing the interfaces to use XPCOM, to do category-based registration of the Oculus provider, in building and packaging the addon, etc. It also requires a separate install step for developers/users. 2. We could ship the VR integration as a plugin. vr.js does this already. But we are trying to move away from plugins, and there's no reason why the Oculus can't function in places where plugins are nonexistent, such as mobile. Delivering this to developers via a plugin would be admitting that we can't actually deliver innovative features without the plugin API, which is untrue and pretty silly. 3. Require developers to install the SDK themselves, and deploy it to all of the build machines so that we can build it. This is IMO a very non-pargmatic option; it requires a ton more fragile work (everyone needs to get and keep the SDK updated; releng needs to do the same on build machines) and sacrifices developer engagement (additional SDKs suck -- see the DirectX SDK that we're working on eliminating the need for) in order to try to preserve some form of purity. 3. We do nothing. This option won't happen: I'm tired of not having Gecko and Firefox at the forefront of web technology in all aspects. Any objections to the above, or alternative suggestions? This is a departure in our current license policy, but not a huge one. There were some concerns expressed about that, but I'm hoping that we can take a pragmatic path here. - Vlad [1] https://developer.oculusvr.com/license _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
