12 ms·

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 mak

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.
  - lelanthran 4y ago
    > it does not make sense to call Rust "proprietary" because it only has a living specification, It doesn't have a "living specification", it has a reference implementation. There's a difference. HTML is a living specification without a reference implementation. Rust (and many other languages) have a reference implementation without a living specification. > The only reason people wouldn't call your changes "Rust" is because the community doesn't share the same expectations That's not true; you cannot call it Rust because Rust, the programming language, is trademarked. It is protected, you understand? There are legal barriers to calling your NewLanguage "Rust", as explained by the foundation themselves over here: https://foundation.rust-lang.org/policies/logo-policy-and-media-guide/ https://foundation.rust-lang.org/policies/logo-policy-and-me... Writing your own language and calling it Rust is legally forbidden.[1] You are, of course, free to use the permissive copyright but the name is trademarked. Now, with C, OTOH, as an ISO standard it has no trademark so this argument does not even arise. [1] As far as I can tell, it would be legally forbidden even if your new implementation of Rust behaves identical to the reference implementation. The best you can do is call it Rust compatible.
torstenvl 4y ago
There is a difference between open software and open standards. The two are orthogonal. Open software can use closed standards (though must usually reverse-engineer them); closed software can use open standards. See, e.g., LibreOffice support for .doc files; Microsoft's TCP/IP stack. Please make an attempt to engage with intellectual honesty, and stop intentionally conflating the two. The issue at bar is whether Rust the language is proprietary, especially as compared to C. Something is proprietary within the standard meaning of the term if it "is used, produced, or marketed under exclusive legal right of the inventor or maker." Merriam Webster, Online Edition, available at https://www.merriam-webster.com/dictionary/proprietary https://www.merriam-webster.com/dictionary/proprietary. In this case, The Rust Foundation maintains and exercises exclusive legal rights over Rust that nobody exercises over C. If I make a C compiler with extensions, I can still call it C and I can still participate in C governance. C is an open standard. See https://www.open-std.org/ https://www.open-std.org/. However, the same is not true for Rust, where governance happens entirely under the auspices of one vendor, who uses trademark law to ensure that no competitors can exist without its explicit approval. Specifically, any Rust variants other than those required for porting require explicit written permission. See https://foundation.rust-lang.org/policies/logo-policy-and-media-guide/ https://foundation.rust-lang.org/policies/logo-policy-and-me.... Furthermore, even if I accepted my impotence in the governance process and even if I resolved to call my Rust variant something else (FeO?), competition in the market would still be chilled by The Rust Foundation's refusal to commit to fair, reasonable, and non-discriminatory (FRAND) licensing (something that is required as part of the ISO standardization process). If a competitor ever did arise, patenting the borrow checker mechanism would be all it would take to completely crush them. I am glad that rustc is open source. I am glad that The Rust Foundation is a non-profit. I accept on faith that they want to do the right thing. However, they have deliberately created a monoculture that they enforce through IP law. Rust is proprietary, i.e., it is "something that is used, produced, or marketed under exclusive legal right of the inventor or maker." There are no open standards, there is no FRAND licensing obligation, there is no allowance for any Rust variants other than those explicitly permitted by the primary vendor of Rust compilers. You brought up Python before, which is appropriate: Python explicitly is a "benevolent dictator for life" language. The difference with Rust is that the dictator is a legal personhood instead of a single living, breathing person. But dictatorships, even benevolent and well-intentioned ones, are ill-suited to the requirements of stability and predictability that are so vital to systems programming. Imagine, God forbid, that The Rust Foundation goes defunct at some point in the next 100 years, and its IP bought up by the next generation's SCO or Novell or whatever, and they decide to patent the borrow checker and whatever other innovations are in Rust. Do you think that would be a bad thing? Because it can only be bad if you agree that Rust is proprietary. If Rust were an open standard (including the borrow checker as part of the standardized compilation process and subject to mandatory FRAND licensing), then that outcome would be mitigated against.

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.
- lelanthran 4y ago
  > it does not make sense to call Rust "proprietary" because it only has a living specification, It doesn't have a "living specification", it has a reference implementation. There's a difference. HTML is a living specification without a reference implementation. Rust (and many other languages) have a reference implementation without a living specification. > The only reason people wouldn't call your changes "Rust" is because the community doesn't share the same expectations That's not true; you cannot call it Rust because Rust, the programming language, is trademarked. It is protected, you understand? There are legal barriers to calling your NewLanguage "Rust", as explained by the foundation themselves over here: https://foundation.rust-lang.org/policies/logo-policy-and-media-guide/ https://foundation.rust-lang.org/policies/logo-policy-and-me... Writing your own language and calling it Rust is legally forbidden.[1] You are, of course, free to use the permissive copyright but the name is trademarked. Now, with C, OTOH, as an ISO standard it has no trademark so this argument does not even arise. [1] As far as I can tell, it would be legally forbidden even if your new implementation of Rust behaves identical to the reference implementation. The best you can do is call it Rust compatible.

torstenvl 4y ago

There is a difference between open software and open standards. The two are orthogonal. Open software can use closed standards (though must usually reverse-engineer them); closed software can use open standards. See, e.g., LibreOffice support for .doc files; Microsoft's TCP/IP stack. Please make an attempt to engage with intellectual honesty, and stop intentionally conflating the two. The issue at bar is whether Rust the language is proprietary, especially as compared to C. Something is proprietary within the standard meaning of the term if it "is used, produced, or marketed under exclusive legal right of the inventor or maker." Merriam Webster, Online Edition, available at https://www.merriam-webster.com/dictionary/proprietary https://www.merriam-webster.com/dictionary/proprietary. In this case, The Rust Foundation maintains and exercises exclusive legal rights over Rust that nobody exercises over C. If I make a C compiler with extensions, I can still call it C and I can still participate in C governance. C is an open standard. See https://www.open-std.org/ https://www.open-std.org/. However, the same is not true for Rust, where governance happens entirely under the auspices of one vendor, who uses trademark law to ensure that no competitors can exist without its explicit approval. Specifically, any Rust variants other than those required for porting require explicit written permission. See https://foundation.rust-lang.org/policies/logo-policy-and-media-guide/ https://foundation.rust-lang.org/policies/logo-policy-and-me.... Furthermore, even if I accepted my impotence in the governance process and even if I resolved to call my Rust variant something else (FeO?), competition in the market would still be chilled by The Rust Foundation's refusal to commit to fair, reasonable, and non-discriminatory (FRAND) licensing (something that is required as part of the ISO standardization process). If a competitor ever did arise, patenting the borrow checker mechanism would be all it would take to completely crush them. I am glad that rustc is open source. I am glad that The Rust Foundation is a non-profit. I accept on faith that they want to do the right thing. However, they have deliberately created a monoculture that they enforce through IP law. Rust is proprietary, i.e., it is "something that is used, produced, or marketed under exclusive legal right of the inventor or maker." There are no open standards, there is no FRAND licensing obligation, there is no allowance for any Rust variants other than those explicitly permitted by the primary vendor of Rust compilers. You brought up Python before, which is appropriate: Python explicitly is a "benevolent dictator for life" language. The difference with Rust is that the dictator is a legal personhood instead of a single living, breathing person. But dictatorships, even benevolent and well-intentioned ones, are ill-suited to the requirements of stability and predictability that are so vital to systems programming. Imagine, God forbid, that The Rust Foundation goes defunct at some point in the next 100 years, and its IP bought up by the next generation's SCO or Novell or whatever, and they decide to patent the borrow checker and whatever other innovations are in Rust. Do you think that would be a bad thing? Because it can only be bad if you agree that Rust is proprietary. If Rust were an open standard (including the borrow checker as part of the standardized compilation process and subject to mandatory FRAND licensing), then that outcome would be mitigated against.