5 ms·

> There is no meaningful sense in which either Rust or Go’s reference compilers is “proprietary.” Nobody is talking about the compilers. This, right here — the

> There is no meaningful sense in which either Rust or Go’s reference compilers is “proprietary.” Nobody is talking about the compilers. This, right here — the fact that you are conflating a language and one implementation — is the whole point and is indicative of the tight control the respective organizations keep over their languages. The direction of the languages is entirely up to their private owners, and that exclusivity is enforced via intellectual property law. They are exactly as proprietary as RHEL or Unix.

woodruffw 4y ago
This is not a definition of "proprietary" used anywhere in the open source community. Private direction (which Rust notably does not have) does not somehow erase the fact that both are permissively licensed and have open codebases that you can use and contribute to to your heart's content. I don't even know what you're referring to with IP law. The projects' names and logos?
- torstenvl 4y ago
  > both are permissively licensed No, the code of the implementation is permissively licensed. Do I really have to explain, on HN of all places, the importance of distinguishing between implementation and interface?
  - woodruffw 4y ago
    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 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.
    - torstenvl 4y ago
      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.
- lelanthran 4y ago
  > I don't even know what you're referring to with IP law. The projects' names and logos? I think it's the fact that if you took the Rust codebase and forked[1] it to accept new keywords, the resulting language that it accepts is most definitely not Rust. If you did the same to a C compiler[2], the resulting compiler would still be called a C compiler by everyone. [1] Assuming that the license allows it. [2] One who's licence allowed this.
  - woodruffw 4y ago
    Yes, the license allows it. Rust's compiler is more permissively licensed than GCC, and is roughly as permissively licensed as LLVM. This argument does not make sense: if you fork GCC or LLVM and change the language frontend for C, the thing you are parsing is no longer standard C. This is exactly the same as is true for Rust, except that the reference is the the living standard rather than an ISO standard. By the original commenter's logic, the modified C compiler would effectively be proprietary: it no longer has a public, liberally licensed specification that it conforms to. But this isn't the way anybody in the open source community uses the word "proprietary," because it precludes any open-source work that doesn't have a corresponding formal specification.
    - lelanthran 4y ago
      > This argument does not make sense: if you fork GCC or LLVM and change the language frontend for C, the thing you are parsing is no longer standard C. It doesn't make sense to you, certainly. To the type of person who've used a dozen different C compilers, all of them containing extensions to the language, and all of them still advertised as "C compilers", the argument makes perfect sense. I mean, the input to the GCC C compiler is, by default, C with extensions, and yet even you still called it a C frontend, not a "SomeOtherLanguage" frontend. You may not agree that the argument is valid or sound, but you can't with a straight face say that it is an unreasonable position to take.
      - woodruffw 4y ago
        > You may not agree that the argument is valid or sound, but you can't with a straight face say that it is an unreasonable position to take. That's not the argument I'm advancing: I'm saying it does not make sense to call that modified C compiler "proprietary." I don't care if you call it "C" or not, because everybody who writes C understands that compiler-specific extensions are commonplace. But the existence of non-formally-specified extensions doesn't somehow override the permissively licensed nature of the compiler. Similarly, going back to the original argument: it does not make sense to call Rust "proprietary" because it only has a living specification, rather than a formal one. It's permissively licensed, and you can modify it to your heart's content. The only reason people wouldn't call your changes "Rust" is because the community doesn't share the same expectations re: vendor extensions that C's community does.
mustache_kimono 4y ago
> The direction of the languages is entirely up to their private owners, and that exclusivity is enforced via intellectual property law. Can't you just fork the language, or, just re Rust, participate in the RFC process? Do we need more bureaucracy?

woodruffw 4y ago

This is not a definition of "proprietary" used anywhere in the open source community. Private direction (which Rust notably does not have) does not somehow erase the fact that both are permissively licensed and have open codebases that you can use and contribute to to your heart's content. I don't even know what you're referring to with IP law. The projects' names and logos?

torstenvl 4y ago
> both are permissively licensed No, the code of the implementation is permissively licensed. Do I really have to explain, on HN of all places, the importance of distinguishing between implementation and interface?
- woodruffw 4y ago
  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 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.
  - torstenvl 4y ago
    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.
lelanthran 4y ago
> I don't even know what you're referring to with IP law. The projects' names and logos? I think it's the fact that if you took the Rust codebase and forked[1] it to accept new keywords, the resulting language that it accepts is most definitely not Rust. If you did the same to a C compiler[2], the resulting compiler would still be called a C compiler by everyone. [1] Assuming that the license allows it. [2] One who's licence allowed this.
- woodruffw 4y ago
  Yes, the license allows it. Rust's compiler is more permissively licensed than GCC, and is roughly as permissively licensed as LLVM. This argument does not make sense: if you fork GCC or LLVM and change the language frontend for C, the thing you are parsing is no longer standard C. This is exactly the same as is true for Rust, except that the reference is the the living standard rather than an ISO standard. By the original commenter's logic, the modified C compiler would effectively be proprietary: it no longer has a public, liberally licensed specification that it conforms to. But this isn't the way anybody in the open source community uses the word "proprietary," because it precludes any open-source work that doesn't have a corresponding formal specification.
  - lelanthran 4y ago
    > This argument does not make sense: if you fork GCC or LLVM and change the language frontend for C, the thing you are parsing is no longer standard C. It doesn't make sense to you, certainly. To the type of person who've used a dozen different C compilers, all of them containing extensions to the language, and all of them still advertised as "C compilers", the argument makes perfect sense. I mean, the input to the GCC C compiler is, by default, C with extensions, and yet even you still called it a C frontend, not a "SomeOtherLanguage" frontend. You may not agree that the argument is valid or sound, but you can't with a straight face say that it is an unreasonable position to take.
    - woodruffw 4y ago
      > You may not agree that the argument is valid or sound, but you can't with a straight face say that it is an unreasonable position to take. That's not the argument I'm advancing: I'm saying it does not make sense to call that modified C compiler "proprietary." I don't care if you call it "C" or not, because everybody who writes C understands that compiler-specific extensions are commonplace. But the existence of non-formally-specified extensions doesn't somehow override the permissively licensed nature of the compiler. Similarly, going back to the original argument: it does not make sense to call Rust "proprietary" because it only has a living specification, rather than a formal one. It's permissively licensed, and you can modify it to your heart's content. The only reason people wouldn't call your changes "Rust" is because the community doesn't share the same expectations re: vendor extensions that C's community does.

mustache_kimono 4y ago

> The direction of the languages is entirely up to their private owners, and that exclusivity is enforced via intellectual property law. Can't you just fork the language, or, just re Rust, participate in the RFC process? Do we need more bureaucracy?