On 14/04/14 23:41, Vladimir Vukicevic wrote: > 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".
As others in this thread have guessed, this discussion is the follow-up to the bug Vlad opened to ask about this issue. It's here: https://bugzilla.mozilla.org/show_bug.cgi?id=989903 although because it's a legal bug, sadly few of you will be able to see it. I don't think there's anything secret in it, but it's not within my power to open. So people may be interested in what I said. My apologies that I am late to this thread. tl;dr: Henri is right that checking it in would reduce Oculus' desire to work with us. We should talk to them first, and quickly. > 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. The license concerned is here: https://developer.oculusvr.com/license Here are the issues I found with it after a quick read: * You can only distribute or re-distribute LibOVR in whole, not in part. An Open Source license "must allow modifications and derived works" (OSD). * If your applications cause health and safety issues, or if you upset them in other ways, you may lose your right to use the Oculus VR SDK, including LibOVR. Open Source licenses need to be irrevocable, and they need to not restrict what you can use the software for. * Modifications to the Oculus VR SDK in source or binary form must be shared with Oculus VR. The most that an Open Source license can require is that they be shared with anyone to whom you give a copy of the binary. This requirement goes beyond that. * Certain sorts of changes have to be copyright-assigned to Oculus VR, and you do not get a permissive license back to use them how you choose. * You can't use the code to interface with other headsets. An Open Source license cannot restrict what you can use the code for. * They can change the license on you at any time. Open Source licenses must not be revocable. This license is a fairly long way from open source. So Mozilla policy <http://www.mozilla.org/MPL/license-policy.html> would say that we don't check this code into our repos (either in source or binary form) and also, whether it's in our repos or not, we don't ship it with Firefox. Making Firefox not-open-source would have a number of fairly serious ramifications. Calling this "licensing dogma" is like calling the right to trial-by-jury "freedom dogma". As others have said, there are a large number of people in the project to whom this is important. > 2. Contact Oculus with our concerns about the license, and see if > they would be willing to relicense to something more standard. I think we should definitely do this. > 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. This strategy of using the Oculus code temporarily was not in view in the original bug filed on this issue. It is perhaps an improvement, but (without attributing bad motives to anyone) I suspect that once code is in, integrated and working, the pressure to ship it would become so great that the "and replace it with some open source stuff later" part would get dropped and lost. I can certainly name one Mozilla project where a non-open-source library was used, and the bug to replace it with something open source never got any attention after the code was shipped and working. > 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. This is my proposal. Given that the hardware here costs $1500 and is available in limited quantities, I am not too worried about the burden on developers and users of installing an add-on. Add-ons are where non-free code lives in the Firefox ecosystem. (Well, and plugins, but we don't like them any more.) > Any objections to the above, or alternative suggestions? This is a > departure in our current license policy, but not a huge one. I think making Firefox non-free in the name of the new shiny is a pretty huge departure, myself. Particularly as there are other options available, and people already working on free drivers. > There > were some concerns expressed about that, but I'm hoping that we can > take a pragmatic path here. In the bug, I wrote: "I still feel I'm missing the big picture here. Why do we want to throw away 15 years of shipping open source software and annoy a large chunk of our developer base and core supporters (now, of all times!) in order to provide built-in support for a single device from a single vendor which isn't even officially released yet and, if you can get your hands on one, costs $1500 a pop? What organizational goal is this in service of?" I still feel those are reasonable questions, particularly if Andreas' assessment of it as "a few hundreds lines of signal processing + USB HID glue" is accurate. It feels like selling our birthright for a bowl of pottage. (Genesis 25:34) Gerv _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
