So who actually needs to talk to Oculus? I can try to reach out some folks I used to work with who are there now and see if they're interested in making license modifications.

-e

On 4/16/14, 7:01 AM, Gervase Markham wrote:
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

Reply via email to