Request for license exception

[caturria]

To whom it may concern: As these challenging times continue around the world, I hope this message finds you in good health. My name is Jordan and I am a blind programmer. I am in the early stages of developing a game engine, and subsequently a game, for the blind (more commonly known as an audio game). As this is a public forum and I have not publicly announced my project to the blind community, I do not wish to disclose the details, to avoid rumours and speculations. Audio games are Indi projects (usually developed by a single blind developer), exclusively for fellow blind gamers. As such, they rarely generate a meaningful profit, and are generally considered goodwill/ passion projects. It is my humble request that you consider a special exception to OpenAL Soft's LGPL license, specifically with respect to static linking. Piracy, including sound effects/ music piracy, is a major problem in the audio games scene. Were I to dynamic link OpenAL Soft and distribute my game and/or game engine, dumping isolated music tracks and sound effects to a file becomes a trivial matter of recompiling the library with a small I/O routine included. Would it be possible for us to negotiate an agreement which would allow my game engine, and the audio games it creates, to statically link OpenAl Soft in exchange for a license fee or some other form of special attribution? Best wishes to all of you this Holliday season, and I look forward to hearing from you.

Kind regards,

Jordan.

[SeanTolstoyevski]

Linking OpenAL-soft with statically may cause people who want to play your game to be unable to change their configurations.

For example, if we want to replace a problem DLL with a working DLL, this will not be possible.

I think security of your audio datas is beyond the scope of OpenAL-soft. This is a DRM issue.

For a simple protection shield, you can examine the paket module in my repo. This Golang and can be easily ported to any other language.

[caturria]

Hi, With all due respect, assuming I understand the potential pros and cons from a purely technical standpoint, would you be willing to discuss this with me from a licensing perspective? Technically, at the end of the day, I have to pass buffers of isolated audio samples from individual sound sources to OpenAL Soft. If I can’t trust that the version of OpenAL Soft I’m passing audio to hasn’t been modified by a malicious user to include fopen() and fwrite() calls, then I can’t produce a product that either myself or others who would use my engine to develop games will trust to at least make stealing individual sounds nontrivial. Would it be possible for us to negotiate some sort of terms for a static linking exception, be it a royalty fee and/or some sort of attribution? I thank you for your consideration and look forward to hearing from you.

Kind regards,

Jordan.

On Jan 30, 2021, at 1:35 PM, SeanTolstoyevski notifications@github.com wrote:

Linking OpenAL-soft with statically may cause people who want to play your game to be unable to change their configurations.

For example, if we want to replace a problem DLL with a working DLL, this will not be possible.

I think security of your audio datas is beyond the scope of OpenAL-soft. This is a DRM issue.

For a simple protection shield, you can examine the paket module https://github.com/SeanTolstoyevski/paket in my repo. This Golang and can be easily ported to any other language.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/kcat/openal-soft/issues/510#issuecomment-770260843, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEAWXZBWJBBNIFNUTJGX6ALS4RGOVANCNFSM4VIQMXEQ.

[SeanTolstoyevski]

@caturria

I don't think OpenAL-soft is configured for static linking.

I tried this on my Go projects. It didn't happen.

If you suspect user hacking the DLL, you can calculate a hash of your original DLL before DLL calls. like sha256.

And hey, I'm not the main developer. Owner of this repo @kcat :) .

[kcat]

If I can’t trust that the version of OpenAL Soft I’m passing audio to hasn’t been modified by a malicious user to include fopen() and fwrite() calls, then I can’t produce a product that either myself or others who would use my engine to develop games will trust to at least make stealing individual sounds nontrivial.

You can check that the OpenAL Soft library being loaded is the one you expect. A size and/or md5sum hash check. Being LGPL2 instead of 3, the anti-TiVo-ization provisions aren't there, so you can do verification to ensure the code being loaded is what you expect it to be.

At some point, I would like to have more flexible licensing options, but as the codebase started with someone else's LGPL code, I need to either get permission or rewrite anything that may be left of their code, to be able to relicense or add (optional) exceptions.

[caturria]

Hi, Thank you. I had thought of the hash check as well but figured it would also violate the license. Thank you for the clarification.

On Feb 3, 2021, at 5:30 PM, kcat notifications@github.com wrote:

If I can’t trust that the version of OpenAL Soft I’m passing audio to hasn’t been modified by a malicious user to include fopen() and fwrite() calls, then I can’t produce a product that either myself or others who would use my engine to develop games will trust to at least make stealing individual sounds nontrivial.

You can check that the OpenAL Soft library being loaded is the one you expect. A size and/or md5sum hash check. Being LGPL2 instead of 3, the anti-TiVo-ization provisions aren't there, so you can do verification to ensure the code being loaded is what you expect it to be.

At some point, I would like to have more flexible licensing options, but as the codebase started with someone else's LGPL code, I need to either get permission or rewrite anything that may be left of their code, to be able to relicense or add (optional) exceptions.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/kcat/openal-soft/issues/510#issuecomment-772871234, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEAWXZGKYDJGRX7MD3Z7LATS5HFB3ANCNFSM4VIQMXEQ.

[ethindp]

If I can’t trust that the version of OpenAL Soft I’m passing audio to hasn’t been modified by a malicious user to include fopen() and fwrite() calls, then I can’t produce a product that either myself or others who would use my engine to develop games will trust to at least make stealing individual sounds nontrivial.

With respect, I believe your being overly paranoid here. By that very same logic, the OS you run your game on shouldn't be trusted and you should need to validate every DLL loaded in the dynamic linking table because it just might not be the one you really want. Concealing assets into the binary (or however your doing it) isn't a very effective strategy, especially if cryptography is involved because someone will get at them anyway. I strongly do not recommend you attempt to "hide" assets this way.

Key takeaways:

• Don't be paranoid. Don't take the attitude of "distrust everything" because that's not going to get you anywhere and your code will be mostly a bunch of hash function calls or a bunch of unnecessary security safeguards that will just result in major performance hits. Furthermore, any DLL in your dynlinking table can be hijacked. You won't know, and something like this is extremely nontrivial to verify. Doing it would require using functions from those loaded DLLs, and if someone knows how to hijack those loaded DLLs, your screwed and they can make you see whatever they'd like you to see -- even a phantom DLL table. There is no way around this, which is why only the super ultra high-end DRM solutions actually attempt to do this, and said solutions require people to install custom drivers/kernel modules/dynamic linkers/etc. to actually work properly. On Linux you could check the LD_PRELOAD environment variable but, again, if a hacker decides to hijack or outright replace one of the loaded libraries, they can modify getenv() to return nothing when you call getenv("LD_PRELOAD").
• Don't try to go nuclear on asset security because it will only make people try harder to get at your assets.
• Piracy usually happens as a result of devs adding distrustful people onto their dev teams. Its unlikely the majority of blind individuals who would be interested in steeling your assets (or any of them, really) would have the knowledge of how to hijack the OpenAL32 binary to begin with, let alone how to hook it during execution. Both tasks are not trivial; the first requires knowledge of C/C++, which very few blind people possess, and the second requires advanced assembly language and debugging knowledge, which, again, very few blind people possess. Those who would want access to your assets most likely do not possess any of this knowledge, so hooking the binary or recompiling it to add trace/dumping routines would require them to get someone else to do it -- and those who would know how to do so probably would ask why and reject to do it outright since it would be illegal.

Mind, someone will get access to your assets. Hiding them is impossible. But I think your fears are unfounded.

[SeanTolstoyevski]

@ethindp

You don't need to be a C++ master to steal data from openal. Or to know assembly.

Just source code, cmake, and a few modified lines.

Protection of assets is important. All game companies do this. Also, modern computers are fast in this topic. If you are not writing GTA, the hash calculations you make will not keep you busy.

[caturria]

@Ethindp I generally like to static link libraries especially if they deal with sensitive assets. Of course I can’t 100 percent protect anything, but at least this gets you as close as is reasonably possible without extraordinary effort and/or performance cost. There are actually a good number of blind programmers — both hobbyist and professional — who specialize in backend code. There are a few with the level of skill required to steal assets no matter what measures are in place, but those aren’t the ones I’m worried about as I think most of them have enough maturity and self respect to not do something like this. The ones I’m worried about are the teenagers. Unfortunately a lot of blind kids live very sheltered lives (myself included), have limited opportunity to participate in social activities which their peers enjoy (myself included), and by necessity develop above average technical skills at a young age (myself included). Those are the ones who will think to themselves: “Hey, if I just add a fopen hear and a fwrite there and recompile Openal, I can go ahead and put songs and sound effects from this game in my Dropbox and share it on Discord where all my friends hang out”. I was one of those blind kids who lived such an unusual and isolated life to where social norms had to be learned through trial and error during early adulthood, so I don’t wish to speak ill of anyone else in that situation (it isn’t their fault), but that’s the kind of problem I’m seeking to mitigate here.

On Feb 5, 2021, at 10:12 PM, SeanTolstoyevski notifications@github.com wrote:

@ethindp https://github.com/ethindp You don't need to be a C++ master to steal data from openal. Or to know assembly.

Just source code, cmake, and a few modified lines.

Protection of assets is important. All game companies do this. Also, modern computers are fast in this topic. If you are not writing GTA, the hash calculations you make will not keep you busy.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/kcat/openal-soft/issues/510#issuecomment-774387991, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEAWXZB74IGD6ND5AV4HIFDS5SXSVANCNFSM4VIQMXEQ.