Recently, I had a bug in my application concerning sf::Sound. I stored sf::Sounds in a container. When playing, they didn't show the right 3D-sound attributes. After debugging quite a while, I found out the sf::Sound copy constructor wouldn't copy the properties Attenuation and MinDistance.
In my opinion, this leads to unexpected copy semantics. I guess one would reckon those properties to be copied with the sf::Sound, too. At least I did so. Isn't this behaviour confusing and not coherent with other SFML classes like Sprite (in some way, sf::Sound is the audio equivalent of a sprite) which copy the whole object's state?
I think fixing this issue wouldn't be a big effort. You could expand the sf::Sound copy constructor with the following lines:
SetAttenuation(Copy.GetAttenuation());
SetMinDistance(Copy.GetMinDistance());
By the way, is there a reason why you duplicate code and write
ALCheck(alSourcei (mySource, AL_BUFFER, myBuffer ? myBuffer->myBuffer : 0));
ALCheck(alSourcei (mySource, AL_LOOPING, Copy.GetLoop()));
ALCheck(alSourcef (mySource, AL_PITCH, Copy.GetPitch()));
ALCheck(alSourcef (mySource, AL_GAIN, Copy.GetVolume() * 0.01f));
ALCheck(alSource3f(mySource, AL_POSITION, Copy.GetPosition().x, Copy.GetPosition().y, Copy.GetPosition().z));
instead of
SetBuffer(Copy.GetBuffer());
SetLoop(Copy.GetLoop());
SetPitch(Copy.GetPitch());
SetVolume(Copy.GetVolume());
SetPosition(Copy.GetPosition());
? This would be easier to maintain, too. The same applies to the other constructors which could call the set functions as well.