Hacker News new | comments | ask | show | jobs | submit login

> Google’s proprietary VP9 codec

That's an odd choice of phrase; it's unfortunate that a press release chooses to disparage alternatives without explanation.




Why is that odd? It is pretty much a textbook example of a proprietary standard.

Here are some definitions of "proprietary" as used by members of the FOSS community when talking about standards:

https://news.ycombinator.com/item?id=4634957 (BrendanEich)

>"Proprietary" as in "sole proprietor" is appropriate for a project with zero governance, launched by Google after some incubation closed-source, dominated by Googlers.

https://news.ycombinator.com/item?id=9395992 (pcwalton, Mozilla employee and Rust core developer)

>In a competitive multi-vendor ecosystem like the Web, public-facing protocols that are introduced and controlled by a single vendor are proprietary, regardless of whether you can look at the source code. NaCl and Pepper, for example, are proprietary, even though they have open-source implementations.


That is a really odd thing to claim, given that there are so many proponents of the MIT license. People claim that MIT is "more free than GPL" because MIT has less restrictions. GPL has more restrictions, and although those restrictions are there to ensure that the same rights are passed on other people, MIT proponents don't buy that argument: they argue that even if someone forks an open source project, slap a GUI on it and sell it as a proprietary product, no freedom is lost because the original is still available. It does not matter that you cannot contribute to the fork. The ability to make proprietary forks is seen as good.

Yet when applied to Google's products, this is suddenly viewed in a different manner? Even if the maintainer does not accept patches, you can still fork it, so no freedom is lost. And it's ok for other people to make a proprietary fork, but not ok for the author to make a proprietary fork? That sounds like hypocrisy to me.


Did you apply to the correct comment? Your post doesn't make much sense. We are talking about standards not code. Code is an implementation of the standard, and the license of the code is irrelevant to the status of the standard.

Forking standards is completely different to forking a codebase. It should be obvious why.


It's referring to the lack of standardization of the VP9 codec, and the terminology is pretty common in standards bodies - it does sound weird and misleading when intermingled with free software though.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: