Comment by woodruffw | Hacker News Reader

Comment by woodruffw | Hacker News Reader

Parent Full thread

This is incorrect on multiple levels: there is no organization that has "exclusive" control over Go, much less Rust. There's a company (Google) that made Go, but they have no control over the source code itself beyond the terms of the non-proprietary license they provide it under[1]. Even the things that Google does w/r/t Go are not even remotely controversial in the context of the definition of proprietary software, like CLAs. Linux has a CLA!

Comparing this to Borland or Microsoft is bizarre: Microsoft and Borland actually do have proprietary C compilers that they do not make publicly available in source code form. Those compilers in turn have all kinds of non-standard, proprietary extensions.

The one thing that sets C apart from Rust and Go is the presence of an official ISO standard. But this isn't material to the definition of "proprietary" in the open source world. And, well, that ISO standard is itself copyrighted.

[1]: https://github.com/golang/go/blob/master/LICENSE

Edit: You shouldn't delete and re-write your comments. Here's the original comment I responded to:

> That's a dubious claim, and irrelevant besides. They are proprietary, in the standard meaning of the word, because a single private organization has exclusive control over each, but whatever word you choose to describe that is up to you.

> Google owns Go in a way that has never been true of Microsoft (or Borland or GNU or Apple...) when it comes to C.

Edit 2: For the edited comment: you're setting up a distinction that does not matter for programming languages that do not have formal specifications. There is no "interface" to distinguish against, and the claim that Rust (or Go, or Python, or any other language without an ISO spec) is tacitly reserving all rights to the design of the language itself is completely unsubstantiated.

Your position that not having a standard is irrelevant for languages that don't have a standard is circular and bizarre.

The fact that you keep focusing on whether compilers are proprietary instead of whether Rust and Go are proprietary is starting to seem deliberately evasive. You're free to extol the virtues of open source software, and I agree with you, but it's utterly beside the point.

.rs is analogous to .doc. The "right" way to handle it is defined solely with respect to the reference implementation. I view that as a problem. You may disagree, and that's fine, but don't pretend this is a conversation about something else.

Where's the circularity? This is the claim: you can't claim that a nonexistent thing is proprietary. Rust and Go do not (to my knowledge) have any sort of standard other than the living standard of the reference implementation, which is itself not proprietary. Anybody is welcome to copy or modify that living standard, per the terms of the permissive license.

This is the overwhelmingly common state of affairs for programming languages: Python, PHP, Go, Rust, etc. do not have formal standards in the sense of C, but instead of a living standard in the form of their reference implementation. The reference implementation is permissively licensed, so the "standard," insofar as it can be said to exist, is also permissively licensed.

Edit: Again: this is just not what the definition of "proprietary" is, in the context of open source. There is a legitimate grievance that you're expressing about software standards and implementation diversity, but it has absolutely no bearing on whether the reference implementation is proprietary or not.

By analogy: I, an open source developer, create a new file format $FOO and release my reference implementation of a $FOO parser under a permissive software license. Am I somehow compelled to spend time writing a formal specification of $FOO to make it non-proprietary? It might be nice for me to do, and nothing stops anybody else from converting my living standard into a formal one, but I am absolutely not compelled to do it.

> The fact that you keep focusing on whether compilers are proprietary instead of whether Rust and Go are proprietary is starting to seem deliberately evasive.

"You keep using that word. It don't think you know what it means." -- Inigo Montoya

This is just bizarre. If MIT/Apache-licensed Rust is proprietary, then anything could be? AFAIK there is no POSIX definition for epoll/io_uring. I suppose epoll is proprietary too?

proprietary: "2: something that is used, produced, or marketed under exclusive legal right of the inventor or maker"

Can Rust be forked, modified, used/sold and distributed with your changes? If yes that hardly seems like an exclusive legal right. Your problem seems to be that people trust the Rust project, and don't trust you or a central committee (yet). But that doesn't make a project proprietary. It makes it implementation defined, which has its own problems, but those are not the same problems of as those of proprietary software.

> MIT/Apache-licensed Rust

Rust is not MIT/Apache-licensed, rustc is.

Rust is licensed under terms that require explicit permission for use outside of a few very narrowly-defined circumstances.

> Rust is licensed under terms that require explicit permission for use outside of a few very narrowly-defined circumstances.

I think you mean the Rust trademark, and sorry, but you don't get to use IBM or Google's mark willy-nilly either? I'm not sure it's a realistic expectation on your part to be able to market your changes under the other guy's mark.

All commits to the Go repository must be approved by two Google employees: https://groups.google.com/g/golang-dev/c/K7oGURi0wTM/m/3mg1O...

Yes. Again, Google can do whatever it likes with its repositories. This is entirely unrelated to whether or not the software is proprietary.

Compare Google's practices here to Qt's[1], CMake's[2], or any other large open source project that is primarily maintained by a single company.

To be abundantly clear: I don't think this is a good way to run an open source project, but it is a legitimate way to run one. So long as the source code and standards (insofar as they exist) are themselves permissive, then the community details are just that.

[1]: https://wiki.qt.io/Qt_Contribution_Guidelines

[2]: https://github.com/Kitware/CMake/blob/master/CONTRIBUTING.rs...

Reply on news.ycombinator.com