As I said later, all things that get submitted to IETF for standardization are going to fall into "proprietary on the second axis", because they want running code, not design-by-committee.

So this definition of proprietary does not seem particularly useful ....

Almost all software fails 2 because hardly any software is an implementation of an open standard. That doesn't seem like a useful definition.

> Almost all software fails 2 because hardly any software is an implementation of an open standard.

Very few applications are only an implementation of an open standard, but things like the QUIC implementation or other communications protocol implementations aren't applications, but lower level components.

Moreover, I think it abuses the meaning of "proprietary" to claim QUIC is proprietary. There is no exclusivity, nor secrecy, nor any other element of control by one party here.

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.

"Who other than Google currently has a vote on what constitutes the definition of QUIC? "

Anyone who wants to discuss it on the mailing list and submit code.

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.

In usage 2, QUIC is proprietary, following conventions older than me.

Protocols would be judged proprietary on the second axis, not software.

(Some software implements a proprietary protocol.)

When it comes to protocols and formats, using the word "proprietary" adds more confusion than clarity.

Consider:

H.264 has a spec that's written down by a standards-setting organization and not a trade secret (though behind a paywall) and has multiple independent interoperable implementations. Yet, it's "proprietary" in the sense that it's patent-encumbered. I.e. the patent holder are the proprietors.

VP8, OTOH, is Royalty Free with a Free Software canonical implementation and has other implementations, too, though their independence is debatable. Yet, VP8 is called "proprietary" by some, because the design of VP8 was under a single vendor's (Google's) control and not blessed by a standards-setting organization.

I think using the word "proprietary" as the opposite of "free as in Free Software" is fine when talking about a particular implementation, but it's better to avoid the word when talking about protocols and formats.

For protocols and formats, it's more productive to talk about:

* Royalty-free vs. encumbered

* Multiple independent interoperable implementations vs. single implementation.

* A Free Software implementation exists vs. doesn't.

* Fully specified vs. defined by a reference implementation.

* (If fully specified) Non-secret spec vs. secret spec.

* (If non-secret spec) Spec available at a freely GETtable URL vs. spec behind paywall or similar.

(A number of Googly things that are royalty-free and have a Free Software implementation go to worse end of these axes on the points of having a single implementation and being defined by the quirks of that implementation.)