On Mon, Apr 14, 2014 at 03:41:49PM -0700, Vladimir Vukicevic wrote: > 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.
Should be opt-in, not opt-out. And I don't think temporarily checking in problematic source code is fine. See further below. > 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. You don't necessarily have to use XPCOM to make it an addon. > 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. Arguably, the feature doesn't need to be enabled for every local build, which implies not all developers need the SDK themselves. Only those working on the feature. That still leaves the issue with the builders, but we now can use tooltool almost everywhere (except non-desktop b2g aiui) to "deploy" files on builders. That being said, i'm not sure I'm comfortable with the implications of your proposal. Balancing with the fact that VR sounds to me like a hype that'll never see widespread use (it's not like there haven't been attempts in the past), I'm not convinced it's worth being more than a plugin/addon. Mike _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
