Sure, but the OpenAL API, although small, is still a pain in the ass. I think it would be just easier to implement some simple IO functions for the platform, but you are right
I'm not talking about the OpenAL API. It's implemented in OpenAL-Soft, fine. I'm talking about the internals of OpenAL-Soft itself: it already has a smaller subset of platform specific functions for low-level input/output. You would just have to port these functions to make it work on a new platform. No need to reinvent the wheel.
Sure, but then the library would still be under LGPL.
would have YSE ready for using any of its other functions
Not through SFML, then?
Yes, or at least until SFML implements them.
Why dont you stop arguing already Tex Killer? You painted yourself into a corner and by endlessly repeating the same disproven arguments you will make yourself only look worse without ever being able to convince people of doing unnecessary free work. Just change your own code to use YSE or whatever.
I am not trying to convince anyone to do anything anymore. I will be the one trying to strip JUCE from YSE and wrapping it with the OpenAL API.
Btw., isn't YSE using JUCE and with JUCE beeing GPL your own code would be linking indirectly with GPL code instead of LGPL OpenAL soft? This would mean you would be "worse off" and need to open source your code, as GPL doesn't even have that dynamic linking exception. 
JUCE is being used mainly for low level audio input/output. That can be replaced by a compatible library with a more permissive license, and I think it would be rather easy. I am still yet to analyse the code to have a better notion of that.
YSE is not an audio back-end, it's merely a highlevel API over JUCE and JUCE does the hard work. Just replacing OpenAL with YSE or writing a OpenAL API wrapper for YSE won't solve anything regarding licesing issue, in fact it would get even worse due to JUCE being GPL. Thus one first needs to replace JUCE, which will not be an easy thing, especially for all platforms.
From what the developer of YSE has told me, JUCE is being used for the low level audio input/output only, so I believe that it would be easy to replace it with another library with a more permissive license. It used to have PortAudio for that (when it was on google code), so that could be an option.
If you really think about replacing JUCE with the OS APIs for YSE, then you'll very soon realize that this work is not something we want to do and maintain in SFML itself, thus 1) won't happen.
As for 2) what's the point? There's no comparable library out there, as such you'd have to write your own (say you adapt YSE) and thus you'd essentially implement all the OS API calls (like OpenAL already did), just to end up with a different high-level API. Wouldn't it be waaaay smarter to use the standardized and well-known/used API (i.e. OpenAL specification) and simply write a new implementation for it, which you then can release under whatever license you'd want?
That last suggestion is what I am trying to do here (except maybe the OS API calls). Did you read my last posts? I will try to first replace JUCE with a library with a more permissive license, then wrap YSE with an OpenAL API. SFML wouldn't have to change anything if I manage to do that, I would just replace the OpenAL implementation it uses.
If there's really a platform which doesn't support OpenAL, it would still be a lot better to modify OpenAL itself, instead of investing days of work to get a library that supports all the platforms OpenAL supports + the one you want to support. Then the whole OpenAL user base could benefit from it as well. Analogically if you notice that you missed a feature in your library code, you don't go and throw the code away and start from scratch, but you simply add it to the existing code base. 
As for LGPL and linking. The way I understood the license is, that you can link it however you want. The only thing you have to guarantee is, that a newer/different version of the LGPL licensed library can be linked. Thus you could also just provide the object files of your application, so someone can link in a newer version of OpenAL. Of course this would still allow for linking modified versions of OpenAL.
I don't know if that is allowed. It would certainly stop the casual players from replacing the DLL, but I think the object files have symbols from the code, so that would be even worse. I'm not sure, I would have to research more about that, and if it is allowed by LGPL.
If you're concerned about asset leaks through library replacements/injections, then you'd probably would have to talk to the drivers directly or even write your own driver, because as shown above, e.g. OpenAL on Windows uses DirectSound, which again is a library that can be replaced and DirectSound uses WinMM, which again is a library that can be replaced and depending on your driver, the driver might also be built as library and would thus be replaceable, etc...
As binary1248 indicated, playing around with the RAM is rather easy with the right tools, so you're largely misjudging the difficulty of one vs the other task.
And when it comes to GPU memory, things get even easier. Not to mention the numerous DirectX or OpenGL injectors out there.
I have talked enough about that. Replacing DirectSound would get you the mixed output sound only, not the individual assets. Taking assets from RAM would be possible, but one would have to take it buffer by buffer and join them together. Anyway, lets stop discussing this.
To sum it up for anyone arriving here now: I am not asking for anyone to do anything anymore. I am going to at least try to get YSE to work with its Eclipse license and wrap it on an OpenAL API myself, so that I can replace the current OpenAL implementation with it. No point arguing about the same points again, so please read all previous messages before posting, and lets just stop talking about asset leaking and focus on useful discussion about the work I am trying to do. All this arguing is not geting us anywhere.
