On Monday, VMware's Jose Fonseca didn't outright reject the floating point work (email), but as far as the implementation impacting LLVMpipe are implemented, he doesn't want that driver to have the support in its current form. The reason for this is not due to legal concerns with VMware developing the LLVMpipe driver, but because of performance reasons for how it's implemented right now with the most common textures being slower. In fact, Jose is fine with the branch being merged and the OpenGL floating point extensions being enabled by default for LLVMpipe, Softpipe, and the classic Mesa software rasterizer. These are all of the Mesa / Gallium3D drivers that don't work in tandem with a GPU but rather are software/CPU-based.
How can they get away with enabling it by default for software drivers without worrying about legal backlash? Because there is prior art of sampling/rendering floating point textures purely in software, which is admitted by the patent holder. For the hardware drivers is where it becomes a different story.
David Airlie commented on the proposal to merge the libtxc_dxtn (S3TC) library into Mesa to basically counter this idea. With the S3TC library, it's built as a separate library that can plug-in to Mesa. This isn't possible with the floating point work, which is why it needs to be integrated with core Mesa. By integrating the S3TC library into core Mesa, it then means users must always rebuild Mesa rather than just dropping in a shared library. Users right now need to build the S3TC library anyways since the library can't be redistributed in binary form.
But that's basically been about it as far as the S3TC / floating point Mesa discussion has gone in recent days; the discussion has basically died yet again.