You'll need to abolish not only software patents, but also DCMA, copyright on software, and outlaw the activities of organisation like those handing the keys for HDCP encryption.
I'm all for it, but its a much more difficult task than what even you suggested before.
I think the current generation of Radeon is the first whose entire design dates after the beginning of AMD's opensource policy right after their acquisition of ATI. Now factor in that they have to get used to the process, fix the problems, iron-out the bump... it's getting to take quite a lot of time before they are a fully open-source supporting house like Intel. (As an indication, look at all the time it took google to transition to an FOSS model of development with Android and integrate their mods into main-line kernel, *even* if they've been pro open-source from the begining, and *even* if it's software only with way much more shorter cycles than hardware).
Nvidia indeed *does not* document their desktop hardware. But regarding to Tegra and their mobile hardware, they are warming up to the idea of opening and documenting their stuff (probably because Linux *is* a very strong player in the embed world). But then again (specially taking into account the transition of AMD mentioned above) it's going to take quite some time until their opensource offering rivals what AMD (or even Intel) are doing.
Current OpenGL ES 3.x = subset of the current OpenGL 4.x
(That's why Mesa can claim Open GL ES 3.x support sooner than OpenGL 4.x. : less things to support).
Now you have to look closely:
- what OpenGL ES and OpenGL have in common is all basic graphic functionality needed to draw things on a screen. (Triangles, shaders, etc.)
- what OpenGL has in addition is a lot of complex arcane stuff which currently is only used on high end workstation running CAD software. Things that don't actually make sense for any everyday use of graphic hardware (desktop compositing, gaming, etc) but only make sense for this specific hardware.
- also OpenGL ES keeps a lot of old almost 'deprecated' functionality because of backward compatibility to please the CAD-on-workstation crowd. For example you'll find a lot of API for fixed pippeline handling, even if most of the modern hardware use programmable shaders. OpenGL ES tries to throw away some of this (almost unused) legacy cruft.
- Open GL = every single API call dating all the way back from when it was a library running on expensive SGI workstations.
- Open GL ES = only what modern hardware does and what modern applications needs.
Believe it or not, under the hood, there's a lot more in common between what latest generation embed hardware is doing and your desktop, than there is between an old dusty Silicon Graphics machine and your desktop.
So the hype is that it is a thiner and lighter layer that does exactly what Open GL is currently used for on desktops, making it easier to develop for and making it easier to add support into FOSS drivers.
The functionnality we're throwing away between OpenGL ES 3.x and OpenGL 4.x mostly isn't that much relevant to us.
*BUT* this functionnality is relevant to a very specific crowd, which happens to be the most profitable market segment for hardware makres (the CAD-on-workstation crowd) so you can expect that vendors will continue to cater to them and produce OpenGL in addition to OpenGL ES support.
Just don't expect regular dekstop application to use much of OpenGL beyond what's available in OpenGL ES. Maybe expect for a few specific stuff. Which never the less can be incorporated into OpenGL ES as specific official extension. (Which aren't supported on some mobile devices).