Hi > 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.
'--with-non-free' But actually I'd support the option of keeping the SDK separated and dlopen'ing the lib when needed. That is better from a legal perspective and keeps the tree free from non-free software. The latter is especially important as VR support is currently just a toy and not something we have to provide to be competitive. How many public interfaces does libovr contain? Maybe there could be a compatible, but free, library in the tree that provides a hardware-independent interface. And internally, it would use the SDK if that's available. Best regards Thomas > > 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 > _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
