Hello Richard,
There's only one thing about U-Boot that doesn't seem so good:
U-Boot is GPLv2 (sometimes "or later").To have some parts which are GPLv2 only is unfortunate.
This is due to us many times (re-)using Linux drivers inside U-Boot.
Also this is one of the objections worded on the mailing list, namely that such a cooperation will be impossible in the future if U-Boot moves to GPLv3.
As a base for reasonable discussion, I think we need to evaluate those claims and back them up by actual figures. Only then the real effort needed to move and the potential loss of "code immigration" can be estimated.
Is there any chance of convincing those authors to change that?
Apart from the the above reasons, currently most people who voiced their opinion (not too many right now) oppose the move. The reasoning seems to be that companies using U-Boot inside a commercial product consider it to be "a neccessary precondition to only accept blessed firmware upgrades" (my wording). What motivates this argument is not completely clear to me. Maybe it is fear of being liable as a product vendor to faulty sw upgrades.
A common theme in the embedded community is the fear of "getting copied by cheap labor countries" - which should not be the case here, but I cannot say for sure.
I believe that without discussing this question seriously with all its implications we will not get enough momentum to even start defining the work for a switch.
We should also start to actively inform the regularly appearing people on this mailing list complaining that they cannot get the source code to U-Boot of "device xyz" that with a GPLv2 U-Boot this may become a theoretical question in the future when they cannot install the changed binary anymore.
Cheers Detlev