Rift SDK and GPL

Yep.
When Ogre3D changed it's license from LGPL (which is already much more relaxed than the GPL) to MIT, Sinbad (the creator) had to get permission from every contributor to the codebase, and rewrite the code from anybody he couldn't reach or didn't agree.



Since Oculus aren't trying to hide anything and have given out all the code already, there shouldn't be any harm in changing to a GPL compatible license (but not to GPL itself, I'd cancel my order right now if they crippled it like that). Except then they couldn't have the license clause that we can't use the sdk code with any other brand of vr headset. (That goes against one of the GPL's clauses on imposing extra restrictions)
(There's other incompatible bits, that's just one of the more obvious ones)

MSat is right. For example, obviously John Carmack and Palmer Luckey intended their code to be usable together. And Cybereality and Cybereality intended their code to be used together. There's no reason to obey the letter of the law in those cases, when the spirit of it is so obvious.

Also, games like Doom 3 BFG are linking to lots of other proprietry libraries and code in order to be compiled and to run on Windows, as there's a specific exception in the GPL for that purpose.

"Eli2" wrote:

I hope you understand that not everyone is satisfied to operate without legal security.
I do not think it is unreasonable to ask for clarifications.

Secure from whom? Who are you worried will sue or punish you?

"kojack" wrote:

Saying that it's ok to break a copyright license because other people are doing it already isn't exactly the smartest legal strategy.

It is a smart legal strategy. It works well, and not just for copyright. True rule of law doesn't actually exist anywhere, everywhere really has "rule of what most other people do and think is acceptable". If everybody does it, then nobody will question it, no matter how explicitly the law disallows it.

"kojack" wrote:
The official GPL faq disagrees with you:
If you want your program to link against a library not covered by the system library exception,

What makes you think it's not covered by the system library exception? It is basically a system library for the Rift platform. Specifically, I'd say it's a "Window System", since that's one that's explicitly mentioned in the GPL, and it is basically fulfilling the role of a very simple window system.

But if people really want, I can try and write my own open-source version of their SDK. It's not really that complicated, mostly just enumerating a specific HID device, reading reports from it, and doing some sensor fusion. Nothing I haven't done before. I haven't checked how they get the display parameters, but that shouldn't be too hard either. The main problem is that I don't have a dev kit yet.

Also I don't particularly like doing a lot of work that's probably going to be used for killing or oppressing real people, unless I'm very confident they need killing or oppressing, and this has rather obvious military applications. But since they can already do that anyway with the Oculus SDK, I guess I wouldn't really be doing much to enable that by making a GPL version. So I might as well.

"2EyeGuy" wrote:

"kojack" wrote:
The official GPL faq disagrees with you:
If you want your program to link against a library not covered by the system library exception,

What makes you think it's not covered by the system library exception? It is basically a system library for the Rift platform. Specifically, I'd say it's a "Window System", since that's one that's explicitly mentioned in the GPL, and it is basically fulfilling the role of a very simple window system.

GPL license:

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.

The libovr is not a compiler, not a code interpreter, and not an essential component of a specific operating system. No, it's obviously not a windowing system. It's not even a driver.

Rather than writing your own library (at least talk to the anti-c++ people first, they want a new library as well and you might as well team up to save effort) it would be easier for Oculus to change their license to a simplier one like MIT. I'm sure since Doom3 and the rift are apparently so destined to be together that wouldn't be a problem. Very simple change, the code is still copyrighted and there's no longer any ambiguity or arguments. We can add rift support to any gpl compatible open source game without fear of running into someone who takes the license they chose seriously. Win for us, win for oculus, win for game devs.

Instead of telling people it's fine to break license agreements if we think two guys like each other's products, we should be asking one of those guys to change it so we don't have to. I've seen other open source libraries change their license after people pointed out how they were limiting themselves.

It's not like any other current vr headset will benefit from this sdk. They don't require the same distortion. There's no secret techniques in the sensor reading. There's nothing in there that couldn't be recreated fairly easily with a specs of the sensor board output. It's not like natural point, the makers of trackir, who require a copyrighted and trademarked haiku poem to communicate with their cameras, which gives them more legal ammunition against competitors.

It's not surprising that the various number of interpretations of the GPL license is almost equal to the amount of people that know anything about it. I've even seen what appears to be contradictory statements in the GNU FAQ itself regarding using proprietary libraries in a GPLd application. So the question remains, how does the Oculus license restrict a GPL application using the ovrlib? The restriction of the Oculus license is on the use of unofficial hardware which the GPL does not cover or even mention at all. GPL is strictly concerned with modification and distribution of software and code. Otherwise, the Oculus license appears to be quite similar to GPL in regards to distribution of code. With no explicit mention of hardware rights in the GPL, can you argue that it's truly incompatible with the Oculus license based on that one point?


I understand why Oculus doesn't want to release their code under a more permissive license. Besides for protecting their interest in terms of hardware, a lot of time and money is going to be invested in software. It may not seem like much right now, but the SDK is going to become a hell of a lot more complex in the near future as they start implementing a lot of new features and capabilities. Actually, I wouldn't be surprised if they eventually closed their source.

"msat" wrote:
What's pretty annoying is when people fixate on the letter of the law rather than the spirit (of course, the letter isn't perfectly defined anyway). The Rift SDK source is open with only minor restrictions on it's use and distribution, and I have a hard time seeing how using it with GPL'd software would really restrict the latter's software.

Well, the Oculus SDK is not free software (or open source) by any stretch of the imagination (sure, it's more permissive than most proprietary licenses out there, but still). Which is a shame, especially since it was first advertised as an “open-source HMD”...

IANAL, but it is definitely incompatible with the GPL, and many free software licenses (and some build of a free software linking to the libOVR library can't really be called free software anymore anyway).

"msat" wrote:
Is it really any worse than the closed-source "blob modules" such as nVidia and and ATI GPU drivers under linux?

Worse or not, I don't know, but it's a different issue... nVidia and ATI blobs provide an implementation of an API (OpenGL) that is available without them, and they do not require any modification, even at build time, of software using it. Running them is exclusively the end user's matter (and they are definitely are “system libs” anyway).

It would be really nice if the SDK could be free software, at least the “driver” parts of it... it would be even better for inclusion in different engines if it were released in a really permissive licence such as the BSD or MIT licence.

Quoting "Hooray" on the FlightGear Forum:

The legal concerns voiced by some OR developers are not really justified, because these folks don't understand that linking apache/bsd code into GPL'ed code is no issue, vs. doing the same vice versa would be "viral" due to the GPL: http://www.apache.org/licenses/GPL-compatibility.html

I'm not a developer, and I know nothing about these legal matters, so I probably won't be able to answer any questions, but you could join a discussion about Oculus Rift support for FlightGear at http://www.flightgear.org/forums/viewtopic.php?f=24&t=20159 and speak to Hooray.

I'm just someone who very much wants to see Oculus Rift support for FlightGear, so please hurry and get this legal stuff sorted out, ok? :) Thanks...

"gtrdrt" wrote:
Quoting "Hooray" on the FlightGear Forum:

The legal concerns voiced by some OR developers are not really justified, because these folks don't understand that linking apache/bsd code into GPL'ed code is no issue, vs. doing the same vice versa would be "viral" due to the GPL: http://www.apache.org/licenses/GPL-compatibility.html

The oculus sdk isn't apache/bsd so what is the point of him saying that we don't understand linking apache/bsd with gpl?

Only the oculus samples are apache licensed. The libovr library (that actual thing that would be integrated with flightgear in some way) is NOT apache.

kojack - someone has just posted to the FlightGear Forum discussion pretty much the same thing you're saying. Anyone can check for responses there by following the link I posted. I can't respond to your question myself, because I'm ignorant. :lol:

Looks like what I posted originally should have been posted to a different thread. Hooray's response on the FlightGear Forum:

I was specifically referring to this thread: viewtopic.php?f=42&t=362#p6497

We have people working with flight gear here and might look into rift support in the future. However, FlightGear is a GPL program and I'm pretty sure the Apache license that the SDK uses isn't compatible with GPL, so it might be "illegal" to use it...

and like I mentioned earlier, we do have a bunch of proprietary protocols and projects supported by FG, just by interfacing through a standalone application that no longer needs to be GPL then.

The SDK seems so bloated to me anyway. To add headtracking only takes about 15 lines of code but you have to stare at the examples forever to figure out which ones...

I wonder how much code is behind those 15 lines.