> If the Broadcom driver gets into the kernel now based on merit, it doesn't necessarily mean the vendor will be able to do whatever it wants in the future. Broadcom is not the Linux kernel gatekeeper. If things don't clean up between the main actors in this, I trust Linus will make the correct compromise.
Right. It seems to me that the main problem raised in the article (that kernel people will want to be able to make changes without consulting Broadcom first) is something Broadcom will have to deal with, not something that should be much of a problem for other kernel developers. Broadcom have made their code GPL, and there is always the - pretty easy - option of forking maintenance of it if they don't play the way other kernel developers would like, so it seems reasonable to give them a chance. If their multi-platform driver maintenance works out it the experience could benefit everyone.