License question

[amerkoleci]

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.

[kcat]

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.

[crazyhappygame]

Is there any chance to change licence to MIT? For game development static-linking is very important.

[iSLC]

@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

[crazyhappygame]

Is it possible to change licence to MIT for some parts? For example Android?

[kcat]

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]

@kcat Did you have a chance to work on "restructuring the library"

[kcat]

@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.

[halx99]

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.

[McSinyx]

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.

[halx99]

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?

[crazyhappygame]

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

[kcat]

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.

[okuoku]

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.

[halx99]

Great, MojoAL maybe better choice as game engine thirdparty.

[halx99]

Or build openal-soft as dynamic framwork bundle?

[kcat]

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.

[halx99]

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?

[mariusz102102]

@halx99

1. you can not use LGPL library in an iPhone app. User can not replace LGPL library (even dynamic linked library) for iPhone app
2. Using GPL, LGPL for game engines is tricky ...

[halx99]

ok, I will leave OpenAL.framework for iOS until finsih migrate audioengine backend to a non-(L)GPL licensed library.

[kcat]

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

[halx99]

@kcat thanks for your explain

[halx99]

And create a pr to support ios/osx dynamic framework with CMake option ALSOFT_OSX_FRAMEWORK: https://github.com/kcat/openal-soft/pull/466

[LumineBot]

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)

[McSinyx]

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.

[kcat]

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.

[LumineBot]

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.

[rotanov]

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.

1. 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.

2. 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!

[kcat]

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

[sam20908]

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.

[kcat]

Yes. SFML's license doesn't affect the license of other non-SFML code in the project.

[SeanTolstoyevski]

Mobile platforms restrict modifying apps. If iOS allowed modifying or editing apps, the user could replace OpenAL-Soft with another version etc. This is not possible even if the project is licensed under the MIT license. The context of the topic should not be licenses. iOS does not allow this.

[qwiff-dogg]

Sorry to bump this topic, but how does the situation with EAWebkit compare to OpenAL in terms of LGPL compliance in closed-source apps? The cases look very similar.

As far as I can tell, EAWebkit complies with the LGPL 2.1 by publishing their modified sources. There is, however, no reasonable way for an end-user to replace a dynamic library on closed platforms like consoles, outside of jailbreaking.

[kcat]

As far as I understand, actually replacing the files isn't that difficult. The issue lies more in the fact that the system will refuse to run with the modified file. With LGPL 2.1, this situation isn't prohibited even if it may be against the spirit of the license. It's (L)GPL 3 that plugs that loophole, which is why consoles and the like are fine with LGPL 2.1 libraries but not LGPL 3.

[qwiff-dogg]

Thanks for clarifying @kcat.

I did some homework this morning and despite claims to the contrary in this thread, using OpenAL Soft as a dynamic library shipped as part of a closed-source app is LGPL v2.1-compliant. While I'm not a lawyer, I'm 100% confident in making that statement.

Section 6.B of the LGPL v2.1 covers the use as a dynamic library. Further clarification can be found here: https://copyleft.org/guide/comprehensive-gpl-guidech11.html#x14-10700010.7

In practice, code signing may make it difficult/impossible for a user to replace the library, but that does not make a "work that uses the Library" non-compliant to the LGPL v2.1. In fact, LGPL v2.1 did not clarify the use of dynamic libraries sufficiently, hence Tivo-ization and the introduction of LGPL v3.0.

Nintendo, Sony and EA, for example, comply to OSS licenses by making the source available for download. None of their sources use LGPL 3.0.

[Vaani-del]

Hi, so sorry to be a bother, but is there any update to this? Curious how close this is to getting a more permissive license, as I'd like to use it

[nadrolinux]

It would be nice to see a new, more mobile friendly license than LGPL, because MojoAL or more precisely SDL2 building for an Android is really problematic. It looks like Android support is abandoned and whole existing build system is outdated, so MojoAL for Android isn't an alternative. I'm waiting for good news in this topic. Thanks for great work!

[CicTec]

Hi, I have read all the posts, for those who are not yet clear on the problem: 1) Apple's app store does not allow you to publish software that uses GPL or LGPL licensed parts, this makes it impossible to currently create free/commercial games with OpenAL Soft and distribute them in the Apple store. 2) iOS uses the DRM system and therefore signs the versions of the libraries used, therefore using the OpenAL Soft dynamic library would interrupt the execution of the app in the event of a library update.

For these two reasons, OpenAL Soft needs a license change in order to run on any system/platform without restrictions, the best license would be MIT.

I hope this license change happens soon.

[okuoku]

Apple's app store does not allow you to publish software that uses GPL or LGPL licensed parts, this makes it impossible to currently create free/commercial games with OpenAL Soft and distribute them in the Apple store.

Apple itself do not explicitly prohibit GPL/LGPL licensed software with their review guidelines. There's many apps that depends external LGPL2.1 software; e.g. VLC https://www.videolan.org/vlc/download-ios.html .

iOS uses the DRM system and therefore signs the versions of the libraries used, therefore using the OpenAL Soft dynamic library would interrupt the execution of the app in the event of a library update.

Unlike LGPL3, LGPL2.1 do not require any ability to replace the library(unless the library linked inside of the final product -- using dynamic-link library easily avoid this). OpenAL Soft is licensed under LGPL2.1. For example, VLC do not contain LGPL3 licensed library; they contain many "LGPL2.1 or later" library though.

[CicTec]

Apple itself do not explicitly prohibit GPL/LGPL licensed software with their review guidelines. There's many apps that depends external LGPL2.1 software; e.g. VLC https://www.videolan.org/vlc/download-ios.html .

We are talking about the Apple Store, not the fact that a Mac can use programs that use GPL/LGPL libraries, many projects that use these libraries have been rejected by the store. Unlike LGPL3, LGPL2.1 do not require any ability to replace the library(unless the library linked inside of the final product -- using dynamic-link library easily avoid this). OpenAL Soft is licensed under LGPL2.1. For example, VLC do not contain LGPL3 licensed library; they contain many "LGPL2.1 or later" library though.

This could also be solved with LGPL v3, but the problem of publishing apps in the store remains, without that, development on the iOS/Mac platform is impracticable, almost no one develops an app for iOS/Mac that is not intended for the store.

Furthermore, the LGPL somehow forces you to release source and/or object code, and several developers do not want this for their apps, which is why to eliminate all these restrictions, switching to an MIT license for example would be the best solution, today more and more projects are switching to this type of license.

[McSinyx]

I don't think compatibility with a policy that is intentionally hostile to software freedom (i.e. software that will always be libre) is a compelling motivation for people who contributed to OpenAL Soft under its copyleft license. If the problem is with Apply exerting its monopoly power to gatekeep even freely licensed software, the solution should not be kneeling down to it and getting other to do so as well.

Instead, push for the the ability to sideload so there could be application repositories what respect the users' freedom like F-Droid. The EU Digital Market Act is practically doing that, and hopefully it will have a worldwide effect like the USB type C port change.

Regardless, if the benefit of OpenAL Soft lies in its freedom-respecting and -preserving copyleft license, then it should continue to provide such benefit. There are already proprietary implementations of OpenAL in the wild, including Core Audio from Apple.

Once again, the LGPL only requires releasing modification to the licensed piece of software, which is the least developers should do considering fairness: as they were given the freedom to use, modify and redistribute the library, it's not nice for them to restrict such freedom from their users. This freedom-preserving aspect of the license also motivate developers to contribute back to upstream and improve the library we all enjoy and love.

If that's not enough to convince you, there is miniaudio under public domain. It doesn't have as many features as OpenAL Soft but it's unlikely to be a concern for mobile usages.

[okuoku]

many projects that use these libraries have been rejected by the store.

VLC is on the app store https://apps.apple.com/us/app/vlc-media-player/id650377962 for long time. It clearly states which libraries are used in its settings screen (because it's requirement of MIT or LGPL licenses.)

Although it's true that app store submission can be rejected various random/wrong reasons, apps like VLC or Jabber https://apps.apple.com/jp/app/cisco-jabber/id467192391 prove apps can pass the review even if it contained LGPL libraries.

[CicTec]

I don't think compatibility with a policy that is intentionally hostile to software freedom (i.e. software that will always be libre) is a compelling motivation for people who contributed to OpenAL Soft under its copyleft license. If the problem is with Apply exerting its monopoly power to gatekeep even freely licensed software, the solution should not be kneeling down to it and getting other to do so as well.

Instead, push for the the ability to sideload so there could be application repositories what respect the users' freedom like F-Droid. The EU Digital Market Act is practically doing that, and hopefully it will have a worldwide effect like the USB type C port change.

Regardless, if the benefit of OpenAL Soft lies in its freedom-respecting and -preserving copyleft license, then it should continue to provide such benefit. There are already proprietary implementations of OpenAL in the wild, including Core Audio from Apple.

Once again, the LGPL only requires releasing modification to the licensed piece of software, which is the least developers should do considering fairness: as they were given the freedom to use, modify and redistribute the library, it's not nice for them to restrict such freedom from their users. This freedom-preserving aspect of the license also motivate developers to contribute back to upstream and improve the library we all enjoy and love.

If that's not enough to convince you, there is miniaudio under public domain. It doesn't have as many features as OpenAL Soft but it's unlikely to be a concern for mobile usages.

The change to another open-source license like MIT but with fewer restrictions will not alter anyone's freedom, it simply eliminates the legal loopholes to which the library is subjected, increasing its popularity and use.

many projects that use these libraries have been rejected by the store.

VLC is on the app store https://apps.apple.com/us/app/vlc-media-player/id650377962 for long time. It clearly states which libraries are used in its settings screen (because it's requirement of MIT or LGPL licenses.)

Although it's true that app store submission can be rejected various random/wrong reasons, apps like VLC or Jabber https://apps.apple.com/jp/app/cisco-jabber/id467192391 prove apps can pass the review even if it contained LGPL libraries.

Some time ago VLC was eliminated from the store, then it was inserted again, most likely due to agreements reached between the authors and Apple, also given the popularity of the software, but not everyone can have this permission with their apps, and have them rejected by the store is not nice. Mine is just a suggestion, if you find an LGPL license capable of satisfying all the requirements of stores like Apple, very well, vice versa, it will only be a problem for the library, given that many users will not use it for their projects, for avoid problems like those noted above.

[McSinyx]

Furthermore, the LGPL somehow forces you to release source and/or object code, and several developers do not want this for their apps

they were given the freedom to use, modify and redistribute [OpenAL Soft], it's not nice for them to restrict such freedom from their users

The change to another open-source license like MIT but with fewer restrictions will not alter anyone's freedom

The LGPL only requires derivatives to be published under the same terms; if the library is not modified there will be no difference when redistributing it from one under the MIT Expat license. The goal of copyleft is end-to-end freedom, where in this case, OpenAL Soft being free software ensure after whatever modifications and redistribution process happening in between the end users should receive the same freedom. If the modifications were not released as free software, users would not be able to:

1. Remove malfeatures inserted in that proprietary derivative
2. Fix bugs introduced by the derivatives, or incompatibility with newer systems, if the developer of the program abandon it or simply refuse to fix
3. Improve the linked library for special needs, e.g. specific hardware or body
4. Incorporate new features from upstream back into the linked library when the program is abandoned or pin to a specific library version

Now, it's up to the developers of OpenAL Soft to decide these freedom are worth it. From what I can tell, the reasons it is released as free software does not necessarily correlate with its popularity among proprietary software.

I believe that OpenAL Soft is developed for the benefit of the public. For that reason, sacrificing end users' freedom, whether for application developers to release proprietary derivatives, or Apple to apply DRM and enforces its monopoly hold, is misguided. If the goal is for OpenAL Soft to reach the hands of iOS users, the right change would be to make it possible to distribute copyleft software to them, either via relaxing unreasonable Apple restrictions on its store or allowing sideloading a more friendly software repository.

[CicTec]

Furthermore, the LGPL somehow forces you to release source and/or object code, and several developers do not want this for their apps

they were given the freedom to use, modify and redistribute [OpenAL Soft], it's not nice for them to restrict such freedom from their users

The change to another open-source license like MIT but with fewer restrictions will not alter anyone's freedom

The LGPL only requires derivatives to be published under the same terms; if the library is not modified there will be no difference when redistributing it from one under the MIT Expat license. The goal of copyleft is end-to-end freedom, where in this case, OpenAL Soft being free software ensure after whatever modifications and redistribution process happening in between the end users should receive the same freedom. If the modifications were not released as free software, users would not be able to:

1. Remove malfeatures inserted in that proprietary derivative
2. Fix bugs introduced by the derivatives, or incompatibility with newer systems, if the developer of the program abandon it or simply refuse to fix
3. Improve the linked library for special needs, e.g. specific hardware or body
4. Incorporate new features from upstream back into the linked library when the program is abandoned or pin to a specific library version

Now, it's up to the developers of OpenAL Soft to decide these freedom are worth it. From what I can tell, the reasons it is released as free software does not necessarily correlate with its popularity among proprietary software.

I believe that OpenAL Soft is developed for the benefit of the public. For that reason, sacrificing end users' freedom, whether for application developers to release proprietary derivatives, or Apple to apply DRM and enforces its monopoly hold, is misguided. If the goal is for OpenAL Soft to reach the hands of iOS users, the right change would be to make it possible to distribute copyleft software to them, either via relaxing unreasonable Apple restrictions on its store or allowing sideloading a more friendly software repository.

If it were as you say, SDL (Simple Direct media Layer) would not have needed to switch from LGPL to ZLIB, it did so to solve all the problems indicated, and the library has benefited from its popularity and greater use. You can hardly expect giants like Apple to change their policies, so it's easier to do the opposite: "It is easier for a person to go to a mountain than for the mountain to go to a person."

If this doesn't want to be done, OpenAL Soft simply won't be a useful library for iOS/Mac developers and other similar platforms.

[kcat]

Mine is just a suggestion, if you find an LGPL license capable of satisfying all the requirements of stores like Apple, very well, vice versa, it will only be a problem for the library, given that many users will not use it for their projects, for avoid problems like those noted above.

Licensing and copyright is a really messy field to deal with, especially for a project with multiple contributors. I can't just change the license if I want to, because if someone contributes a significant piece of code under the current license, the license for that code can't be changed without permission. Not everyone will be okay with their code being changed to a more permissive license or adding license exceptions that weren't there previously, so we'd need to be able to identify what code belongs to who, and either ensure permission or find some way to remove it or rewrite it. That will then lead into the question of if a given piece of code has copyright protection (you copyright the idea of something, or when there's a limited number of ways to express the idea, or if it doesn't meet the creativity requirements), and would need permission. Questions of interoperability also come into play.

That said, I do have permission from some of the larger contributors, and I have a good idea of what I'd need to check up on. But the biggest remaining hurdle is the fact that OpenAL Soft started based on Creative's wrapper driver when it was under the LGPL license (prior to it going closed source). Unless by some miracle they grant permission to relicense whatever may remain of their code, I'd need to make sure none of their copyrighted code remains to be able to change the license. In the 15+ years of this project's existence, there isn't any part that hasn't been changed. Are those changes considered a new work that's not under their copyright? I have no idea, and I doubt anyone (even a lawyer) would be able to tell me "yeah, it's okay to modify the license now" or "it'll be okay if you remove/rewrite this and that".

It'll ultimately come down to whether there's anything that Creative could take issue with, as I can't afford to tangle with them even if I can prove I'm in the right.

[CicTec]

Mine is just a suggestion, if you find an LGPL license capable of satisfying all the requirements of stores like Apple, very well, vice versa, it will only be a problem for the library, given that many users will not use it for their projects, for avoid problems like those noted above.

Licensing and copyright is a really messy field to deal with, especially for a project with multiple contributors. I can't just change the license if I want to, because if someone contributes a significant piece of code under the current license, the license for that code can't be changed without permission. Not everyone will be okay with their code being changed to a more permissive license or adding license exceptions that weren't there previously, so we'd need to be able to identify what code belongs to who, and either ensure permission or find some way to remove it or rewrite it. That will then lead into the question of if a given piece of code has copyright protection (you copyright the idea of something, or when there's a limited number of ways to express the idea, or if it doesn't meet the creativity requirements), and would need permission. Questions of interoperability also come into play.

That said, I do have permission from some of the larger contributors, and I have a good idea of what I'd need to check up on. But the biggest remaining hurdle is the fact that OpenAL Soft started based on Creative's wrapper driver when it was under the LGPL license (prior to it going closed source). Unless by some miracle they grant permission to relicense whatever may remain of their code, I'd need to make sure none of their copyrighted code remains to be able to change the license. In the 15+ years of this project's existence, there isn't any part that hasn't been changed. Are those changes considered a new work that's not under their copyright? I have no idea, and I doubt anyone (even a lawyer) would be able to tell me "yeah, it's okay to modify the license now" or "it'll be okay if you remove/rewrite this and that".

It'll ultimately come down to whether there's anything that Creative could take issue with, as I can't afford to tangle with them even if I can prove I'm in the right.

Yes I understand what you are saying, what I can do is provide information. We have two types of licenses basically: 1 - Software Patent 2 - Copyleft/Copyright

The first protects the idea (created algorithm) and can only be exclusive (an example is the MP3 compression algorithm).

The second only protects the implementation of the code, however if it is possible to implement it in another form (if you do not get the author's permission to use it), just rewrite it even if it uses the same algorithm and the problem is solved.

Another example I can share is when I found myself in the situation of wanting to use the scale2x algorithm (https://github.com/amadvance/scale2x/) which has a GPL 2.0 license. When I contacted the author for permissions, he told me that the GPL only applied to the MMX code, the C code was public, so all I had to do was delete the MMX part or rewrite it to avoid licensing problems.

On the difference between patent and copyright, here is a useful guide: https://arapackelaw.com/patents/software-patents-vs-copyright/

So if you are rewriting the code, even if you use the same algorithm, that resolves the copyright, what you need to inquire about is whether there are any patented algorithms.

[teub]

This freedom-preserving aspect of the license also motivate developers to contribute

as a developer, this GPL-like "freedom-preserving license" is usually a guarantee I'll never use it at all

[ericoporto]

@kcat I have been watching this issue a long time, would you consider linking to mojoAL in your readme explaining that it has zlib license and is an alternative to this LGPL project?