3 ms·

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 whe

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.

woodruffw 4y ago
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.
mustache_kimono 4y ago
> 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.
- torstenvl 4y ago
  > 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.
  - mustache_kimono 4y ago
    > 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.

woodruffw 4y ago

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.

mustache_kimono 4y ago

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

torstenvl 4y ago
> 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.
- mustache_kimono 4y ago
  > 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.