undefined | Better HN

0 pointsdragonwriter10y ago0 comments

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.

0 comments

DannyBee10y ago

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

thrownaway242410y ago

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

dragonwriterOP10y ago

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

Zigurd10y ago

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.

wtallis10y ago

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.

1 more reply

sophacles10y ago

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

tatterdemalion10y ago

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

(Some software implements a proprietary protocol.)

hsivonen10y ago

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

j / k navigate · click thread line to collapse