Who other than Google currently has a vote on what constitutes the definition of QUIC? Merely being open to suggestions for changes isn't a relinquishment of control, and protocols can't be forked the way software can.
Wouldn't that be offering a suggestion to Google that they could accept or reject at their sole discretion? QUIC isn't defined by any organization or process that isn't completely governed by Google. Nobody outside Google can cast any actual vote with any kind of binding power, just persuasive influence.
Believe it or not, Chromium/etc (the ones we are referring to here) are open source project with a lot of Google committers, not a Google project that accepts things or not depending on whims.
In fact, the project has a ton of non-google non-drive-by committers (250+ IIRC, it's been a while since i looked ).
Is that even the relevant authority to be considering? Since QUIC is not formally specified yet and only exists as a de facto standard with little historical stability so far, isn't it primarily defined by the most prevalent implementations—Google's official client and servers—not the current state of the project's version control repository?
I do admit that things aren't as cut-and-dry for protocols and specifications than for actual implementations where rights and ownership are pretty clearly defined, but surely you can see that there is a distinction that can be drawn here? QUIC is expected to become an open standard (or die), but it's not there yet. Though it may be further along on the "open" than "standard" aspect.
By that reasoning, most open source software is "proprietary". If you submit code to sqlite then the author can accept or reject the code at his sole discretion.
Software and protocols aren't the same thing. An open vs proprietary distinction can be drawn for either, but that doesn't erase the important distinctions between the two.
