Forum Discussion
Oculus SDK: to bundle or not bundle with project?...
well, here is the issue:
the license for the Oculus SDK basically says that, if included in source-form, the whole SDK needs to be included...
except... the assets for the Tuscany sample are pretty large (they add considerably to the project size, *1).
it would be admittedly more preferable to simply include LibOVR and similar, or maybe the other parts of the SDK and just omit OculusWorldDemo.
as-is, means that the Tuscany assets alone nearly doubles the project's ZIP size...
other options, like a binary-only LibOVR, or requiring people to supply it themselves if they want Rift support, would be a bit limiting.
side note: I also had to make some (very minor) tweaks to the LibOVR code in a few places to get it to compile from source (there were a few places where "char *" and "wchar_t *" were being mixed up, and the compiler wasn't happy...).
the project in question is not FOSS, but the source is available for people to mess with, but with restrictions (currently no commercial use or forking).
*1: though my project also includes a lot of textures, most are currently compressed with a somewhat customized image codec, which results in considerably smaller files (for example, the main texture pack is 22MB).
I call it BTJ, and it is sort of like "JPEG++" (baseline format is JPEG-base, with lots more features and format tweaks glued on), probably not topical here... (only to say that it is, IMO, "reasonably competitive for my uses"...).
likewise, audio uses a custom codec, and it is currently 8MB for the sound-files, ...
(the audio-codec is a random-access CBR codec, with similar bit-rates but worse audio quality than MP3, may consider alternatives, ...).
note: the development directories are *considerably* larger.
such is the power of lossy compression...
are there any good options here?...
or is it just that, if I don't want the DDS files around, I have to leave the SDK out of the distributed source code (burdening those who want to build from source and have Rift support)?...
the license for the Oculus SDK basically says that, if included in source-form, the whole SDK needs to be included...
except... the assets for the Tuscany sample are pretty large (they add considerably to the project size, *1).
it would be admittedly more preferable to simply include LibOVR and similar, or maybe the other parts of the SDK and just omit OculusWorldDemo.
as-is, means that the Tuscany assets alone nearly doubles the project's ZIP size...
other options, like a binary-only LibOVR, or requiring people to supply it themselves if they want Rift support, would be a bit limiting.
side note: I also had to make some (very minor) tweaks to the LibOVR code in a few places to get it to compile from source (there were a few places where "char *" and "wchar_t *" were being mixed up, and the compiler wasn't happy...).
the project in question is not FOSS, but the source is available for people to mess with, but with restrictions (currently no commercial use or forking).
*1: though my project also includes a lot of textures, most are currently compressed with a somewhat customized image codec, which results in considerably smaller files (for example, the main texture pack is 22MB).
I call it BTJ, and it is sort of like "JPEG++" (baseline format is JPEG-base, with lots more features and format tweaks glued on), probably not topical here... (only to say that it is, IMO, "reasonably competitive for my uses"...).
likewise, audio uses a custom codec, and it is currently 8MB for the sound-files, ...
(the audio-codec is a random-access CBR codec, with similar bit-rates but worse audio quality than MP3, may consider alternatives, ...).
note: the development directories are *considerably* larger.
such is the power of lossy compression...
are there any good options here?...
or is it just that, if I don't want the DDS files around, I have to leave the SDK out of the distributed source code (burdening those who want to build from source and have Rift support)?...
7 Replies
- I am not a lawyer, but I'm pretty sure the 'SDK' only covers what isn't explicitly licensed under some other terms. If you look closely, you'll see that all the sample code is under the Apache 2.0 License. The resources are binary files that don't have license headers, but since they're in the sample code, a strong argument could be made that they're also under the Apache 2.0 license.
That's my take. "jherico" wrote:
I am not a lawyer, but I'm pretty sure the 'SDK' only covers what isn't explicitly licensed under some other terms. If you look closely, you'll see that all the sample code is under the Apache 2.0 License. The resources are binary files that don't have license headers, but since they're in the sample code, a strong argument could be made that they're also under the Apache 2.0 license.
That's my take.
yeah, if I can leave off the samples, that is probably good.
kind of lame to have a lot of data compression, only to have it all being eaten by a few SDK samples.
admittedly, I am not much of a fan of DDS anyways.
IMHO: DDS is not currently in a good spot WRT size/quality/performance tradeoffs...
file-sizes=large, size/quality=poor, performance=typically strongly I/O bound.
more compression can actually make the loading faster (if the codec is well designed for good decoding speeds), if for no other reason than compensating for the typically comparably slow (70-150MB/s) reading speeds of conventional HDDs.- You just have to include the LibOVR folder. Thanks.
"cybereality" wrote:
You just have to include the LibOVR folder. Thanks.
yep, that is good.- I just statically compile LibOVR and link it directly inside my executable. Hopefully this is OK :)
"idimkovic" wrote:
I just statically compile LibOVR and link it directly inside my executable. Hopefully this is OK :)
The license explicitly excludes applications built with the SDK from being considered derived works, so regardless of the legal opinions on whether derived works are created by static linking as opposed to dynamic linking, you should be in the clear."jherico" wrote:
"idimkovic" wrote:
I just statically compile LibOVR and link it directly inside my executable. Hopefully this is OK :)
The license explicitly excludes applications built with the SDK from being considered derived works, so regardless of the legal opinions on whether derived works are created by static linking as opposed to dynamic linking, you should be in the clear.
yes, this is my understanding as well.
I guess in my case, it more mattered more because I was including the source-code of LibOVR.
nevermind the general wackiness in my case of doing an open-source but otherwise proprietary project.
(don't know of any particularly good term for this...).
I figure there just isn't a whole lot in the codebase that is particularly worthy of keeping secret, and if people are going to steal code, they could just as easily steal it from some other projects, and ultimately it doesn't matter that much where people get their code.
then again, some people get weird about things...
like code needs to either all be FOSS, or be closed-source and secretive, like there is no middle-ground, and somehow seeing the code for a commercial/proprietary project will corrupt their mind or something.
FWIW, I see it all more like the text in a book.
a codebase then is basically just sort of like a large book filled with code...
and, you don't go after people who read books, more those who copy/paste big chunks of it and/or use it commercially and refuse to pay royalties or similar...
(basically, as far as I understand things, this is basically how it works, and the "mind corrupting" aspects would only apply if NDAs or similar were involved...).
or, at least the parts I haven't already put under the MIT license, which are already free to use...
