OpenAL Windows Drivers link broke

Monkey Forums/Monkey Bug Reports/OpenAL Windows Drivers link broke

blueFire(Posted 2014) [#1]
In the monkey documentation the link for the OpenAL Windows Drivers (HOME/TARGET SDKS/THE GLFW TARGET) which opens "http://connect.creativelabs.com/openal/Downloads/oalinst.zip" in a web browser opens a "server not found" error message.

Jason


Nobuyuki(Posted 2014) [#2]
OpenAL.org's registrar status is in AUTORENEWPERIOD and has been since August. All that's left is a placeholder. It may be worth looking into replacing the references to OpenAL with OpenAL Soft, which can be statically-linked into the runtime (unlike OpenAL). This should be a drop-in replacement pretty much, and would make it a lot easier on developers of the desktop version since we wouldn't have to include the redistribution installer anymore (furthermore, it seems like finding it online's gonna be difficult from here on out anyway). http://www.openal-soft.org/


Soap(Posted 2014) [#3]
oalinst is included with Monkey.

targets\glfw\oalinst.exe

Its license allows you to redistribute it freely. It also has silent install option so you can easily bundle with installer and user will not see a thing.

Agreed with Nobuyuki.


dawlane(Posted 2014) [#4]
OpenAL Soft, which can be statically-linked into the runtime (unlike OpenAL).
A warning here. The license is LGPL. This basically means that if you statically link to this library it becomes a derived work so then you will also have to make at least your compiled object file available on request to anyone who wants to compile against any other version of that library. Which is a bugger if you want to sell you creation as free loader Joe Bloggs can demand a copy under the terms of the LGPL license. The best solution here is to either dynamically link to the library or get in touch with the copyright holder and get written permission if you wish to statically link to a LGPL code for commercial purposes.

You should have a look at http://answers.google.com/answers/threadview/id/439136.html


marksibly(Posted 2014) [#5]
Just to clarify: The glfw target does NOT statically link to OpenAL so there's no problem.


Paul - Taiphoz(Posted 2014) [#6]
Mark the issue is that OpenAL the version were using at the moment is on the way out the door and I think is no longer getting any form of support, no website, no downloads etc.

The version which seems to taking over is OpenAL Soft, and as dawlane pointing out is under the LGPL.

The question now I think is whats your plans with this Mark ?, are you going to plod along with a now dead and un-supported OpenAL, or are you going to move to OpenAL Soft or find something else?


dawlane(Posted 2014) [#7]
OK I did a bit of digging in the Creativelabs forum and found this and this

@marksibly: It has been mentioned a couple of times in various posts here and in the other BRL forum about statically linking, and in the case of GPL licensed code dynamically-linking libraries or code without also explaining the legalities. Someone who is completely new to programming may get the wrong impression and think that it is OK to statically link a library and then fall foul of the law. It would be worth it for people to look into some of the lawsuit cases that the Free Software Foundation have brought against companies/individuals the biggest being against Cisco Systems.

And one more thing for anyone reading this. If you sign up to any developer program you must read the License Agreement very, very carefully. It should be also noted that if you release a application under the GPL or port over a GPL application to a Apple device, it will be rejected/removed as iTunes Store Terms of Service, which is incompatible with the GPL.


Gerry Quinn(Posted 2014) [#8]
Presumably the new version could be dynamically linked if necessary. I agree it is a pain.


dawlane(Posted 2014) [#9]
Presumably the new version could be dynamically linked if necessary
That how it is done in Monkey. Only GLFW gets built into an application as it's licensed under the zlib/libpng license http://www.glfw.org/license.html. When using any library you should read the license and what it allows.If I read the licenses correctly, any thing that's linked statically or dynamically to GPL libraries/code becomes GPL so your source code must also be released as GPL. Any thing that's statically linked to LGPL libraries/code, either has to be released as LGPL or at leased the compiled object has to be made available without cost or restrictions. You don't have to release source code when statically-linking to LGPL. Dynamically linking to LGPL means you can distribute you application as you see fit. The only down side is that the end-user has to have that library available on their system. Any LGPL library that you distribute along with your application has to have it's license notice supplied and it's source code made readily available or a place where the source code can be acquired. If you have modified any LGPL library to work with your program then you are required to release that modified source code.


Nobuyuki(Posted 2014) [#10]
Well, that's easy enough. OpenAL Soft distributes the source, and we can still dynamically link to the dll, but also be able to include it with the installation now instead of having to rely on the OpenAL installer, since LGPL is less restrictive than the previous licensing agreement. Still a win in my book, even if static linking is not possible for closed-source applications.


SLotman(Posted 2014) [#11]
I would be really glad if it was possible to use DX9 and anything other than OpenAL on Windows - for example, at my university, I can't install OpenAL (no admin rights), and I can't run GLFW (some OpenGL apps works, but slow as hell) due to crappy Intel drivers.

So, although I'm perfectly capable of compiling with MINGW, I can't run or debug anything on those machines =(


AdamRedwoods(Posted 2014) [#12]
I can't install OpenAL (no admin rights)

you just need the openal.dll to be next to the .exe. it doesn't have to be in the system folder.


Paul - Taiphoz(Posted 2014) [#13]
Yeah I'v started to copy it into the project folder as a habbit as a few of my testers had no clue what openAL was and didnt like the idea of having to download something they seemed unable to find on the internet, so since then I have been sending out zips with my exe and the openAL.dll file just in case.


Nobuyuki(Posted 2014) [#14]
@Taiphoz

I hate to be pedantic, but since license pedantry seems to be a recurring theme in this thread, I should just point out that the official version of openAL doesn't allow distribution of the dll file in that way. Probably no big deal if it's just going out to a few testers, but definitely not OK for the final published project. OpenAL Soft, however.....


Paul - Taiphoz(Posted 2014) [#15]
Yeah I know, and yeah just a few testers.. but your right I should be sending out the installer.