How to deal with lgpl-license of openal-soft on android?

[thomas.trocha]

Hi there, this is my first post as I’m having a look on other capable multiplatform-engines especially looking what sound-system they use for android and stumbled over corona that is using openal (including android!?!). I’m also working on a 3d-engine that also uses openal soft for sound processing. OpenAL is ,concerning the LGPL license, fine on desktop-platform.
BUT just compiling openal-soft as shared-lib is not enough to fulfill the LGPL. Everyone have to be able to switch the lib with e.g. a newer or custom version.

I know this is silly but makes using LGPL-Licensed libs very problematic on mobile-devices and due to static linking even impossible for iOS. (Afaik openal is part(?) of iOS so that is no problem there) On android you can use shared-libs so this part is ok, but how to provide that mindblowing “swapping the shared-lib with a new/custom one”?

Some references ( http://en.wikipedia.org/wiki/GNU_Lesser_General_Public_License ):

... Essentially, if it is a "work that uses the library", then it must be possible for the software to be linked with a newer version of the LGPL-covered program. The most commonly used method for doing so is to use "a suitable shared library mechanism for linking". Alternatively, a statically linked library is allowed if either source code or linkable object files are provided. ....

Section 4d: http://www.gnu.org/copyleft/lesser.html

Since you, the corona-sdk-team are more professional and for sure have more clue about these license stuff, you many have a good advice about how to handle this? As I’m quite sure that everyone(!) not just the developer needs to be able to do relink (by replacing the lib). That is also the cause you need to tell what version you linked against or if changed the lib even publish the source-code you linked against…

I’m not sure if there is a straight way to go for this and I assume the only clean way would be to use opensl on android eventhough I hope you will give a good hint…

Thx, hope you can help me out there

[import]uid: 192351 topic_id: 32631 reply_id: 332631[/import]

[ewing]

There is no LGPL code on iOS. Apple includes their own implementation of OpenAL with iOS and Mac.

On Android, we just switched over to Apportable’s fork of OpenAL Soft where they did a terrific job getting the optional OpenSL ES working and fine tuning performance under load.
You can find their branch and our fork on GitHub:
https://github.com/apportableinc/openal-soft/network

It should be obvious that there are a lot of companies using OpenAL Soft on Android if you search for the number of Android forks of OpenAL Soft.

As for compliance, we dynamically link OpenAL on Android so no problem there. As far as you wanting to drop-in/replace our build, you should be able to do so like any other dynamic library. While we can’t offer free technical support to those who do this, we already have users who dissect the apk’s they build from us and repackage them up for various purposes. I believe this applies to end users as well since Android allows anybody to sign a package. (The license doesn’t say the process has to be convenient.)

[import]uid: 7563 topic_id: 32631 reply_id: 129777[/import]

[thomas.trocha]

Thx for the fast reply. Yeah, lots seem to use openal-soft. Indeed I also found a way to repackage, but for this you will need to have an apk which is afaik not possible to get from a not rooted android-phone. (only exception to let your apk install on external-device=sdcard)

And please don’t think I want to stick on your nerves, actually this license-stuff makes me a bit crazy Thx so long, I think I will also give it a try with openal-soft. Thx for the link, will look into that, I was using following one in my former tests(also using openSL). But you can’t have enough resources,right?
https://github.com/AerialX/openal-soft-android

Have fun ,ToM [import]uid: 192351 topic_id: 32631 reply_id: 129778[/import]

[ewing]

I agree the license stuff is crazy. And the signing stuff makes all this more complicated. But the license doesn’t say that users shouldn’t have to root their phones.

I know Android externalizes the .so files because it can’t actually read them from inside an apk. Is it possible to replace those copies without accessing the apk?

I have not tried the AerialX fork. Do you know how it compares?

We originally used the original Mozelko Audiotrack fork (with some tweaks for latency and suspend/resume). I had the opportunity to see the Apportable fork in action on some big games (e.g. Osmosis, EDGE). They did a really nice job on the heavy load mixing performance. (They haven’t done any NEON optimizations yet which could make it really cool.) And they also did the dynamic runtime detection of OpenSL ES availability which we currently need in Corona since we still support Android 2.2. But on the downsides of the Apportable fork, they didn’t do it through Git so there is no easy way to merge with the official Chris Robinson mainline. And both branches diverged quite a bit. I took an initial stab of trying to merge it, but it’s really complicated.
[import]uid: 7563 topic_id: 32631 reply_id: 129780[/import]

[ewing]

There is no LGPL code on iOS. Apple includes their own implementation of OpenAL with iOS and Mac.

On Android, we just switched over to Apportable’s fork of OpenAL Soft where they did a terrific job getting the optional OpenSL ES working and fine tuning performance under load.
You can find their branch and our fork on GitHub:
https://github.com/apportableinc/openal-soft/network

It should be obvious that there are a lot of companies using OpenAL Soft on Android if you search for the number of Android forks of OpenAL Soft.

As for compliance, we dynamically link OpenAL on Android so no problem there. As far as you wanting to drop-in/replace our build, you should be able to do so like any other dynamic library. While we can’t offer free technical support to those who do this, we already have users who dissect the apk’s they build from us and repackage them up for various purposes. I believe this applies to end users as well since Android allows anybody to sign a package. (The license doesn’t say the process has to be convenient.)

[import]uid: 7563 topic_id: 32631 reply_id: 129777[/import]

[thomas.trocha]

Thx for the fast reply. Yeah, lots seem to use openal-soft. Indeed I also found a way to repackage, but for this you will need to have an apk which is afaik not possible to get from a not rooted android-phone. (only exception to let your apk install on external-device=sdcard)

And please don’t think I want to stick on your nerves, actually this license-stuff makes me a bit crazy Thx so long, I think I will also give it a try with openal-soft. Thx for the link, will look into that, I was using following one in my former tests(also using openSL). But you can’t have enough resources,right?
https://github.com/AerialX/openal-soft-android

Have fun ,ToM [import]uid: 192351 topic_id: 32631 reply_id: 129778[/import]

[ewing]

I agree the license stuff is crazy. And the signing stuff makes all this more complicated. But the license doesn’t say that users shouldn’t have to root their phones.

I know Android externalizes the .so files because it can’t actually read them from inside an apk. Is it possible to replace those copies without accessing the apk?

I have not tried the AerialX fork. Do you know how it compares?

We originally used the original Mozelko Audiotrack fork (with some tweaks for latency and suspend/resume). I had the opportunity to see the Apportable fork in action on some big games (e.g. Osmosis, EDGE). They did a really nice job on the heavy load mixing performance. (They haven’t done any NEON optimizations yet which could make it really cool.) And they also did the dynamic runtime detection of OpenSL ES availability which we currently need in Corona since we still support Android 2.2. But on the downsides of the Apportable fork, they didn’t do it through Git so there is no easy way to merge with the official Chris Robinson mainline. And both branches diverged quite a bit. I took an initial stab of trying to merge it, but it’s really complicated.
[import]uid: 7563 topic_id: 32631 reply_id: 129780[/import]

[thomas.trocha]

Oh, sry didn’t see that you replied…

>I know Android externalizes the .so files because it can’t actually read them from inside an apk. Is it >possible to replace those copies without accessing the apk?
Good question,…might be worth checking. Not that much an android-developer or at least don’t know that internal stuff

>I have not tried the AerialX fork. Do you know how it compares?
I can’t tell how it is compared to the apportable-fork. All I know that it worked (more or less) out of the box as replacement for the desktop-openal-lib.(Well, as it should :p) This version also have the ability to check if opensl is available or not. If not the openal-lib passes the stuff via jni to the java audio-api. That was also one of my concerns when I tested it the first time and it worked (as you want) for 2.2+

There seems no further development of the areialX-fork(so no NEON soon…), but I was able to merge this one with official Chris Robinson one. At least the merge went without problems and I could compile for linux (not at my dev-computer right now)

I think I will stick to arielx for my project but for ogrekit (since we only use bsd/mit/zlib and such) I will have to write an opensl-version. (Shouldn’t(!) be that hard,…)

Thx and keep on rocking,ToM [import]uid: 192351 topic_id: 32631 reply_id: 130913[/import]

[thomas.trocha]

Oh, sry didn’t see that you replied…

>I know Android externalizes the .so files because it can’t actually read them from inside an apk. Is it >possible to replace those copies without accessing the apk?
Good question,…might be worth checking. Not that much an android-developer or at least don’t know that internal stuff

>I have not tried the AerialX fork. Do you know how it compares?
I can’t tell how it is compared to the apportable-fork. All I know that it worked (more or less) out of the box as replacement for the desktop-openal-lib.(Well, as it should :p) This version also have the ability to check if opensl is available or not. If not the openal-lib passes the stuff via jni to the java audio-api. That was also one of my concerns when I tested it the first time and it worked (as you want) for 2.2+

There seems no further development of the areialX-fork(so no NEON soon…), but I was able to merge this one with official Chris Robinson one. At least the merge went without problems and I could compile for linux (not at my dev-computer right now)

I think I will stick to arielx for my project but for ogrekit (since we only use bsd/mit/zlib and such) I will have to write an opensl-version. (Shouldn’t(!) be that hard,…)

Thx and keep on rocking,ToM [import]uid: 192351 topic_id: 32631 reply_id: 130913[/import]

[ewing]

The mainline (Chris’s) OpenAL Soft now has an OpenSL backend included. I haven’t tried it though.

But I think in all cases, the OpenSL backend originated from Glenn Kasten. He told me he read my book and was inspired to implement the backend. I’m flattered and think that is awesome. He worked at Google at the time and I think he did it as part of his 20% time. He cleared it with Google licensed it under Apache because Google prefers licenses like that one. Glenn is now part of the Android NDK team. But his implementation seems to be the basis of all the ones you will find in the OpenAL Soft forks.

So long story short, you can probably try OpenAL Soft mainline which still has the Apache license in the OpenSL implementation file. Or you can find Glenn’s original version.

We have been working out bugs in the Apportable branch these past few weeks. We think we finally fixed the last of the regression bugs today that got introduced when we switched. While it is unfortunate that it is forked so much from mainline, we have done some performance benchmarks and it is significantly better than the prior version we used. Apportable did a great job optimizing/performance tuning.

[import]uid: 7563 topic_id: 32631 reply_id: 131195[/import]

[ewing]

The mainline (Chris’s) OpenAL Soft now has an OpenSL backend included. I haven’t tried it though.

But I think in all cases, the OpenSL backend originated from Glenn Kasten. He told me he read my book and was inspired to implement the backend. I’m flattered and think that is awesome. He worked at Google at the time and I think he did it as part of his 20% time. He cleared it with Google licensed it under Apache because Google prefers licenses like that one. Glenn is now part of the Android NDK team. But his implementation seems to be the basis of all the ones you will find in the OpenAL Soft forks.

So long story short, you can probably try OpenAL Soft mainline which still has the Apache license in the OpenSL implementation file. Or you can find Glenn’s original version.

We have been working out bugs in the Apportable branch these past few weeks. We think we finally fixed the last of the regression bugs today that got introduced when we switched. While it is unfortunate that it is forked so much from mainline, we have done some performance benchmarks and it is significantly better than the prior version we used. Apportable did a great job optimizing/performance tuning.

[import]uid: 7563 topic_id: 32631 reply_id: 131195[/import]