Rift SDK and GPL

"jwilkins" wrote:
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.

Or just read pages 16-19 of the sdk manual which tell you exactly how to do it, no staring at examples needed.

There's still an appalling amount of abstraction behind those lines, made all the worse that the abstraction hasn't allowed them to produce a Linux version of the SDK yet.

"jherico" wrote:
There's still an appalling amount of abstraction behind those lines, made all the worse that the abstraction hasn't allowed them to produce a Linux version of the SDK yet.

Isn't the whole point of abstractions to make hardware differences not matter, rather than to cast such hardware differences in stone? Still, I like programming on the bare metal, where nothing stands between you and raw power.

"geekmaster" wrote:

"jherico" wrote:
There's still an appalling amount of abstraction behind those lines, made all the worse that the abstraction hasn't allowed them to produce a Linux version of the SDK yet.

Isn't the whole point of abstractions to make hardware differences not matter, rather than to cast such hardware differences in stone? Still, I like programming on the bare metal, where nothing stands between you and raw power.

Yes, but abstractions applied liberally just makes everything bigger and harder to... abstract! The abstractions chosen were to turn everything into OO patterns (http://c2.com/cgi/wiki?AreDesignPatternsMissingLanguageFeatures), moreso than abstract the hardware. This pattern is why I refuse to work at a C++ shop anymore -- programmers have leapt off the cliff of sanity.

"geekmaster" wrote:

Isn't the whole point of abstractions to make hardware differences not matter, rather than to cast such hardware differences in stone? Still, I like programming on the bare metal, where nothing stands between you and raw power.

Abstraction for its own sake or that impedes actual functionality (like say, a Linux version of the SDK) just makes the world a worse place. There's also a lot of 'not-invented-here' syndrome going on in the SDK. By my reckoning most everything in the Src/Kernel directory is stuff that would better be left to the Standard Template Library, or Boost. Boost has a very permissive license, along the lines of BSD, that basically says 'Here, use it however you like', so there's no reason for Oculus to be re-inventing the wheel for thread management, reference counting, file management, etc. Time spent developing and testing that stuff is time they're not working on features their customer's care about.

"msat" wrote:
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?

Yes, I can - GPL explicitly forbids extra restrictions added to the entire GPL'd application unless permission's granted from all of the copyright holders to do so.

Since libovr added a restriction that essentially forbids the use of it on unofficial hardware, that makes it incompatible with GPL.

"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).

Except the common interpretation about libovr being incompatible with GPL, and thus, shouldn't be used alongside it, is to the spirit - the Free Software Federation, the one who wrote GPL, are really that fanatic.

If they had their way, they'd have all software under GPL or similar licenses.

They are known to bash certain software because they either allow one to use them in closed-source applications which they detest (to the point where it's said that all of their PCs only use "free software" {ie, under GPL or similar license}), they're closed source applications or even because they "attempted to destroy the user's freedom" even if the source code's readily available in some way or form (their reasoning for disabling Javascript in their own web browsers, believe it or not: https://www.gnu.org/philosophy/javascript-trap.html ).

They even admitted that a FSF member would most likely say “Your program is very attractive, but I value my freedom more. So I reject your program. Instead I will support a project to develop a free replacement.” instead of “I am surprised you were able to make the program work so well without using our development model, but you did. How can I get a copy?” like a "pure open source enthusiast".

https://www.gnu.org/philosophy/open-source-misses-the-point.html

So there you have it: The only way to legally use libovr with GPL'd apps is either if you're the sole copyright owner of your source code, you obtained official permission from all the current copyright holders or you use loopholes like a standalone app that networks with the GPL'd program in order to provide Oculus Rift support.

"KarjamP" wrote:
obtained official permission from all the current copyright holders

Just add a linking exception to the app's license, and see if anyone complains. :lol: