[dragonwriter]

There's two different distinctions in software for which "proprietary" is commonly used:

1. proprietary vs. Free / Open Source (code released under an F/OSS license), and

2. proprietary vs. Open Standards (an implementation of a standard governed by an independent standards body and freely implementable.)

QUIC is not proprietary by F/OSS on the first axis, and currently proprietary rather than based on an open standards on the second axis, with a stated intent of becoming the basis for open standards works in the future.

There is, I think, a pretty good case that this is a good way to get to new open standards that are actually useful for solving real world problems.

[DannyBee]

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 ....

[thrownaway2424]

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

[dragonwriter]

> 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.

[Zigurd]

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.

[wtallis]

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.

[DannyBee]

"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.

[wtallis]

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.

[DannyBee]

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 ).

[FooBarWidget]

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.

[sophacles]

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

[tatterdemalion]

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

(Some software implements a proprietary protocol.)

[hsivonen]

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.)