Every sane GL library needs a software fallback for the case that the driver does not implement hardware acceleration for particular functionality. In that case, the CPU is used to perform such operations. It will be considerably slower, but at least it will render correctly, which is what the library is supposed to do.
Eh, software fallbacks are an OpenGL developer's worst nightmare. The API should report an error when you try to use an unsupported feature, so you can fallback to a simpler implementation or bail out completely.
Software fallbacks are nasty because you don't know when they are going to trigger and there's little you can do when they do trigger. You can rest assured that no user will appreciate a 2fps rendering, they'll just say e.g. Google Earth sucks and delete it from their system.
Fortunately, the situation is much better nowadays where we have more capable hardware and an OpenGL that is better-aligned with hardware capabilities. This used to suck much more back around the R200/R300 era when you could hit shader limits trivially (and sometimes randomly).
BlackStar, just shut the fuck up. I'm not even going to make any effort defending software fallback. If a user doesn't like 2fps Vs. a blank screen the problem is simply between keyboard and chair. Nobody who is able to influence the Gallium3D code will think otherwise. Noobs be noobs.
V!ncent, the issue here is that many applications include code paths for different levels of GL support, so in most cases exposing a lower level of GL support that is fully HW accelerated will give a better user experience than exposing the higher level of GL support but with a few software fallbacks.