openal-soft
openal-soft copied to clipboard
kcat
License question
Hi, And sorry if this is bump question, I would like to know how would openal-soft integrate onto other projects. I'm working on game engine, would love to add openal-soft under ThirdParty and will also mention the usage into README.md, is that legal?
The engine is MIT and usually build as static library.
Thanks in advance.
Hi.
Generally speaking, as long as OpenAL Soft is unmodified and distributed as a shared library, you can use it in any project you wish. Unless your code is also (L)GPL, that's typically the easiest way to deal with LGPL libraries. Otherwise, if OpenAL Soft itself is static-linked into a binary, then any distribution must also offer the source or object files of the binary so a user can relink with another version of OpenAL Soft.
Is there any chance to change licence to MIT? For game development static-linking is very important.
@crazyhappygame I doubt he can. The original licensee would be Creative Technology. He simply maintains the project. Which is allowed because it satisfies LGPL.
You wouldn't be the first to be a bit disappointed by the licensing chains around this library. Awesomeness comes at a cost tho :D
Is it possible to change licence to MIT for some parts? For example Android?
I do plan on restructuring the library so that I can relicense parts of it that I know are mine, and rewrite what's left over. It will probably take a fair amount of time, though. Saying that, it's still strongly recommended for OpenAL Soft to be dynamically linked if the platform allows it (I know not all do), so that the user has the option of replacing the dll/so/dylib with a better version released in the future.
@crazyhappygame A bit, though this upcoming release will be more focused on the conversion to C++ and making sure it's not causing problems. The restructuring that has been done, along with the switch to C++, should help make the remaining work quicker, though.
What about MIT license, recently, I integrate to the game engine fork of cocos2d-x: https://github.com/c4games/engine-x And I receive message from user of cocos2dx forum: https://discuss.cocos2d-x.org discuss with me about engine audio backend library, I think this lib openal-soft is the best choice for unify audio engine of engine-x for all paltforms, but the LGPL license may limit commercal use for game developer.
the LGPL license may limit commercial use for game developer.
Please elaborate. LGPL only requires source publication of modification of, in this case, openal-soft. Static linking to proprietary software is permitted.
Also nitpicking a little, even if openal-soft was released under AGPLv3+ (the most copyleft license to date), there would be nothing forbidding games statically linking (there's no restriction on dynamic linking) it from being commercial. It's perfect fine for a *GPL-licensed game to be sold (whilst admittedly it doesn't seem to be a very bright business idea). In addition, speaking of separation, it's also possible to create a copyleft game with non-free assets, e.g. like how Quake 3 is licensed nowadays.
That means if the game developer modify source code of openal-soft and static link to them commercal game, they only need publish the modification of openal-soft, otherwise, no any limitions? correct?
@halx99 it is complicated and risky ... https://www.gnu.org/licenses/gpl-faq.en.html#LGPLStaticVsDynamic
"If you statically link against an LGPL'd library, you must also provide your application in an object (not necessarily source) format, so that a user has the opportunity to modify the library and relink the application."
Ultimately, the purpose of the LGPL is to allow users to replace the library with their own version if they want. You in no way have to support such a replacement, but letting users do it for themselves is the intention. In practice, this essentially means if you static link it to an app, the user needs to be able to relink the app with a replaced version. Dynamic linking makes this less problematic since it's easy to replace OpenAL Soft's dll/so/dylib without the app having to care.
For platforms that depend on code signing, this is actually a loophole in the (L)GPL prior to v3 ("TiVo-ization"). You can technically replace the code, but a runtime check fails validation and the system refuses to run the modified version. OpenAL Soft, being LGPL 2 with the option of upgrading to a newer license version, can be used in such a scenario as long as you don't exercise that option to update to v3.
Standard disclaimer: I'm not a lawyer, and this isn't legal advice. But it's notable that LGPL2(.1) code is openly used by the likes of Nintendo and Sony in their consoles.
But it's notable that LGPL2(.1) code is openly used by the likes of Nintendo and Sony in their consoles.
Since these are for system software (ie. not for game apps,) perhaps EAWebKit is better example for LGPLv2 inside game titles on proprietary platforms.
Larger issue here is their SDKs are distributed under NDA; this means in case openal-soft needed to be modified, we cannot comply LGPL because distributing modified openal-soft sources would likely violate NDA. EAWebKit avoids this issue by adding additional portability layer that does not depend on their NDAed SDKs.
If you don't need effects and surround output, MojoAL (OpenAL on SDL2 with Zlib license) would be an alternative.
Larger issue here is their SDKs are distributed under NDA; this means in case openal-soft needed to be modified, we cannot comply LGPL because distributing modified openal-soft sources would likely violate NDA.
When it comes to the core system, they tend to be a BSD- (Sony, Nintendo) or Windows-based (Microsoft) OS on an ARM- or x86-based CPU, so the majority of OpenAL Soft's code should build with little issue as OpenAL Soft sticks to standard APIs for its core workings. Any changes here could be implemented as optional library behavior (e.g. not reading external files) or using general wrappers (e.g. SDL), that don't expose the SDK. Where it comes to interacting with the proprietary audio API, if the backends for SDL, PortAudio, etc, don't work, OpenAL Soft provides the loopback extension to create your own hook without having to modify the library.
That said, if OpenAL Soft for some reason can't work on a given system, there's the option of using an alternative implementation, like MojoAL (basic, free) or Rapture3D (more featured, commercial), for those specific systems.
So, what's the best AL library should as thirdparty of MIT licensed game engine on ios platform, build openal-soft as dynamic framework bundle or use MojoAL?
@halx99
- you can not use LGPL library in an iPhone app. User can not replace LGPL library (even dynamic linked library) for iPhone app
- Using GPL, LGPL for game engines is tricky ...
ok, I will leave OpenAL.framework for iOS until finsih migrate audioengine backend to a non-(L)GPL licensed library.
So, what's the best AL library should as thirdparty of MIT licensed game engine on ios platform, build openal-soft as dynamic framework bundle or use MojoAL?
OpenAL Soft as a dynamic library in your app bundle should be fine.
you can not use LGPL library in an iPhone app.
I don't believe that's true. People have used OpenAL Soft in iPhone apps, as mentioned above it looks fine to use LGPL2(.1) code on systems that do code signing checks as multiple big name companies allow it, and LGPL3 made it a point to explicitly fix that loophole (similarly those companies don't use LGPL3 code).
And create a pr to support ios/osx dynamic framework with CMake option ALSOFT_OSX_FRAMEWORK: https://github.com/kcat/openal-soft/pull/466
Hi, is there any updates? I've been static linking this library effortlessly and everything run smoothly in few machines i had until I realized this is LGPL library.
I'm remaking an old game where I'd like to keep the content pipeline same like the original ones and i want the client files look exactly the same as the original. The original doesn't have openal32.dll so it's unacceptable in my case, including object files is also unacceptable in my case since the original didn't include them either in their distribution client files.
You may think trivial case but under NO circumstances I able to compromise this situation and I want to hear the possibility to do this with OpenAL (the current and the future of OpenAL)
I've been static linking this library effortlessly and everything run smoothly in few machines i had until I realized this is LGPL library.
As said earlier, @LumineBot, LGPL was made explicitly to allow static linking to proprietary software.
Hi, is there any updates? I've been static linking this library effortlessly and everything run smoothly in few machines i had until I realized this is LGPL library.
It's progressing. Much of the code seems to be good for relicensing, and I've been separating the code into a core component as I've been verifying it and untying it from the AL API. There's just RTKit in there that's MIT licensed and the SSE2/4 linear resampler that's LGPL2+, neither of which are necessary if push comes to shove, but I know who exactly to ask to get it relicensed. The rest in core I'm free to relicense as I want, so the more that moves into there, the closer the library as a whole is to being able to be relicensed.
That said, while I don't know what your project is, if it's open source then it's not a problem to static link LGPL code. As long as the user has the option to relink the app with a replacement lib, it's fine (the source or object files don't need to be with the binaries, they just need to be available somewhere that a user can reasonably get to). If your app is not open source, then one option would be to install the openal soft dll globally during installation, then your app can still dynamically link to the dll and it doesn't need to be with the rest of the installed client files. Alternatively, maybe there's a way to store the dll as a resource in the exe, and load it from there somehow. I'm not too familiar with using exe resources, so I don't know if it's possible to have LoadLibrary load it directly from in the exe, or if you need to copy it out to a temp folder (%TEMP% or %TMP% or whatever) at runtime and load that with LoadLibrary.
Hi thanks for answering
As said earlier, @LumineBot, LGPL was made explicitly to allow static linking to proprietary software.
Yes, but read the next sentences, providing dll or object files isn't in my option. Unless I misunderstand something where I can static linking the lib without providing object files and source code, then I have no problem.
It's progressing.
Thank you for your hard work! I wish OpenAL become more flexible in terms of licensing in the future.
That said, while I don't know what your project is, if it's open source then it's not a problem to static link LGPL code.
I forgot to mention that I'm not making this project open source. While it's technically planned to be released into "public" and free, there's some sort of "barrier" which may cause the project only belong for small numbers of audience. But I think this won't affect how it treat LGPL license anyway.
If your app is not open source, then one option would be to install the openal soft dll globally during installation, then your app can still dynamically link to the dll and it doesn't need to be with the rest of the installed client files.
This could be a potential solution to my case, but I'd like to stay true to the original client where the client is small and portable. I could simply run the original client from the usb stick, using global dependencies will break this portability.
Alternatively, maybe there's a way to store the dll as a resource in the exe, and load it from there somehow
This actually interesting solution, I probably could work with this if LGPL allow such method. Just one more thing, will it considered violation if I decide to obfuscate my client where the obfuscator may (or may not, idk) obfuscate the application resources as well? I guess it will involve a bit of work, especially if I wanted to support three major desktop OS, not to mention it has chance it won't work.
That said, my project is probably still light years ahead from completion (hopefully not lol). By the time of development, I wish OpenAL could be relicensed, even if only small portion of it. I mostly use it as simple playback only.
Hi! @kcat I'm asking for clarification about using openal-soft under iOS. I'm sorry but some things are still not clear for me after all the discussion above.
-
Where is it explicitly stated that openal soft is LGPLv2? I only see "OpenAL Soft is an LGPL-licensed" in the readme and BSD-3 Clause.
-
You mentioned some big names permit openal-soft on iOS and LGPLv3 was made specifically to address some issues (I read the whole story about Tivoization) but there are multiple claims that warn about it. Even dynamically because end-user won't be able to replace dynamic library on an iOS device. Example claims are:
https://roadfiresoftware.com/2013/08/the-problem-with-using-lgpl-v2-1-code-in-an-ios-app/
https://stackoverflow.com/questions/459833/which-open-source-licenses-are-compatible-with-the-apples-iphone-and-its-offici
https://softwareengineering.stackexchange.com/questions/269653/how-to-comply-with-lgpl-2-1-source-code-request
Backstory: we have a MIT licensed C# game engine used in commercial games. After researching a certain audio bug on Windows I found out that replacing openal32.dll with openal-soft dll (and renaming it to "openal32.dll" so OpenTK will use it) fixes the bug. At that point I thought it's a good idea to start using openal-soft on all platforms and "unify" our audio system backend. But license questions arose.
And thank you for all your hard work!
Where is it explicitly stated that openal soft is LGPLv2? I only see "OpenAL Soft is an LGPL-licensed" in the readme and BSD-3 Clause.
The various sources have an LGPLv2+ header comment, along with the COPYING file in the source root for the LGPLv2.
You mentioned some big names permit openal-soft on iOS and LGPLv3 was made specifically to address some issues (I read the whole story about Tivoization) but there are multiple claims that warn about it. Even dynamically because end-user won't be able to replace dynamic library on an iOS device. Example claims are:
It should be mentioned that I'm not a lawyer, so I can't speak to the validity of the claims. However, my thoughts are as follows.
https://roadfiresoftware.com/2013/08/the-problem-with-using-lgpl-v2-1-code-in-an-ios-app/
This seems to suggest it's fully possible ("You can certainly do that on your website like Sparrow did, but that means you have to package your app so it supports linking to another version of that framework, and you have to host that package on your site."), they just didn't feel it was worth the hassle.
That said, I don't know how true it is that "you have to provide a way for people to download your app so they can link against another version of that third-party framework. And that has to happen outside of the App Store since there’s no way to do it through the App Store." I presume when you install an app through the App Store, it's downloaded to your device, and there would be ways a user could extract the app package to replace its files. Either way though, it's definitely possible to distribute the files outside of the App Store if it comes down to it.
https://stackoverflow.com/questions/459833/which-open-source-licenses-are-compatible-with-the-apples-iphone-and-its-offici
This isn't very clear on which LGPL version it's referring to. The top response also seems to be assuming the LGPL code is static linked, or I'm not quite understanding what they're saying.
https://softwareengineering.stackexchange.com/questions/269653/how-to-comply-with-lgpl-2-1-source-code-request
This doesn't seem to be saying there's any problem. The app developer is just confused about why a library author is asking for their own source to the library used (with the answer given that they're most likely just compliance testing to make sure of source availability for the LGPL portions).
Found this thread and wanting to ask here: I have been developing a closed-source app that uses SFML, which also uses this library. Does the same restriction of having to deliver the DLL apply even though SFML uses a different license?
Thanks.
Yes. SFML's license doesn't affect the license of other non-SFML code in the project.