Oculus Rift

Feedback on past, current, and future development.
User avatar
AnyOldName3
Posts: 2668
Joined: 26 Nov 2015, 03:25

Re: Oculus Rift

Post by AnyOldName3 »

So you can link to WMR because it comes with Windows, but not to OpenVR o OculusSDK because the user isntalled it.

It's no sense for me, the importante thing for me is that every user that will try to run OpenMW in VR will have one of those libraries installed, so it's part of their OS.
I'm not 100% sure if WMR counts as a system library, but I suspect not. The exact definition is as follows:
The “System Libraries” of an executable work include anything, other than the work as a whole, that (a) is included in the normal form of packaging a Major Component, but which is not part of that Major Component, and (b) serves only to enable use of the work with that Major Component, or to implement a Standard Interface for which an implementation is available to the public in source code form. A “Major Component”, in this context, means a major essential component (kernel, window system, and so on) of the specific operating system (if any) on which the executable work runs, or a compiler used to produce the work, or an object code interpreter used to run it.
I don't think WMR is a major essential component of Windows.

Installing software onto a computer doesn't make it part of the OS, either. Once you've installed OpenMW, it's not part of your OS, it's just on your computer. It could maybe be argued for device drivers, but either way, it's irrelevant, as the GPL allows linking against system libraries as defined above, not parts of the users OS as defined by you.
It does have to link with at least one of the libraries, and none of them are GPL friendly ... so the dependency is still there until there is something GPL friendly underneath.
That doesn't have to be how it works. For example, the OpenVR or Occulus SDK or WMR OpenXR implementations could link against a GPL-compatible OpenXR library instead of the OpenXR library linking against them. This is a fairly common way of getting GPL and non-GPL software to interact with each other.

Another example of software that does exactly that is Mod Organizer 2. It's GPL software, and users can create plugins for it. It's designed such that plugins can use more or less whatever licence they want. This is achieved by having an LGPL library, UIBase, that defines the plugin interfaces, some important Mod Organizer 2 components, and some glue, but doesn't actually implement anything other than the glue. The main Mod Organizer 2 executable links against UIBase and implements the Mod Organizer 2 components as specified in UIBase. Plugins link against UIBase and implement the plugin interfaces as specified in UIBase. When MO2 starts, it loads any DLLs in its plugins directory (using a system library), and the UIBase glue lets it do that without actually linking against those DLLs. If it wants to do something using a plugin, it calls functions it's imported from UIBase, and when a plugin wants to get MO2 to do something, it calls functions it's imported from UIBase.

In practice, it doesn't work because someone forgot to label a couple of the UIBase files as being LGPL, so they've accidentally become GPL, and so the whole convoluted mechanism still blocks proprietary plugins until someone emails two people who've disappeared off the internet and asks their permission to relicense their UIBase contributions under a licence they may or may not have assumed they were under in the first place.
Post Reply