Is there a way to rank programming languages in terms of how "security oriented" they are?
- Login o registrati per inviare commenti
Or is it necessarily a ludicrous idea, since security is squarely determined by the quality of the code, i.e., the competence of the programmer?
I was reading this about plans to make CPython faster (within four years, so this still sounds like SciFi), and I was wondering whether similar measures could also be taken to increase security at the language level (memory access stuff, or whatever): https://www.theregister.com/2021/05/19/faster_python_mark_shannon_author.
Then I fell for clickbait, and was delighted to learn that "Cook arrived around 0735 Pacific Time wearing a dark grey suit, a white shirt with grey tie, black shoes, and a clear face shield" from this article: https://www.theregister.com/2021/05/22/apple_ceo_tim_cook_faces.
"He also had trouble remembering just how much Apple gets paid by Google to make Google Search the default on the iPhone. Gary Bornstein, representing Epic, suggested the amount was $10bn. “I don’t remember the exact number," said Cook. Bornstein asked if Cook didn't know it was upwards of $10bn. "I don’t know," Cook replied." This is intolerable Spanish Inquisition. How on Hell could poor Tim Cook remember every bunch of $10bn that freely flows in and out his company?!
"New programming languages such as Go and Rust rely entirely on static linking, and there’s nothing we can do about it. Instead of packaging the dependencies and having programs use the newest versions, we just fetch the versions pinned by upstream and make big blobs out of it. And while upstreams brag how they magically resolved all security issues you could ever think of (entirely ignoring other classes of security issues than memory-related), we just hope that we won’t suddenly be caught with our pants down when a common pinned dependency of many packages turns out to be vulnerable.
Added 2021-04-27: Deadlock vulnerability through embedded app-emulation/containers-storage (CVE-2021-20291) is an example how a vulnerability in a single Go package requires hunting all affected ebuilds."
-https://blogs.gentoo.org/mgorny/2021/02/19/the-modern-packagers-security-nightmare/
"We found that all memory-safety
bugs involve unsafe code, and (surprisingly) most of them
also involve safe code."
https://cseweb.ucsd.edu/~yiying/RustStudy-PLDI20.pdf
"surprisingly"
Here is the paper I was referring to in the post that got erased when someone pulled the plug:
https://greenlab.di.uminho.pt/wp-content/uploads/2017/09/paperSLE.pdf
I have now become a fan of Pascal. It feels both neater, clearer and safer than C/C++.
Rust feels like a hooded tentacular monster which will show you a few tricks about safety in C++ while you stay safely out of its range. The tricks are interesting, though.
> "Rust feels like a hooded tentacular monster..."
Someone's been watching too much weird Japanese anime. Or reading Lovecraft's old Cthulhu books. One or the other. Or both.
You say this because you have obviously never heard of "Rustonomicon", "RustBelt", "crates" and "interior mutability".
What about this: "Rust developers should first try to properly encapsulate unsafe code in interior unsafe functions before exposing them as unsafe." I find this massively more frightening than Cthulhu chum. At least, Cthulhu is not hiding under a safety hood.
EDIT: Chtulhu -> Cthulhu. Sorry for that, Cthulhu boy.
I could also have mentioned "phantom data", "coercion" and "transmutes", but maybe you would rather read about it yourself: https://doc.rust-lang.org/nomicon/meet-safe-and-unsafe.html.
"Well, unlike C, Rust is a safe programming language. But, like C, Rust is an unsafe programming language. More accurately, Rust contains both a safe and unsafe programming language."
If you are not running away from your computer screen in panic yet, let me add the final touch: https://thenewstack.io/microsoft-rust-is-the-industrys-best-chance-at-safe-systems-programming.
>"If you are not running away from your computer screen in panic yet"
I did, I ran away screaming, I'm running down the road, typing this with my thumbs into my cell phone. I hope I can hit the "submit" button before the Cthulhu's tentacles wrap around m.......................
Never say or write "submit" before Cthulhu, or worse, nearby Rust. You had been warned.
Farewell, proud Andy. Your soul will endure and, in time, Cthulhu might start using Devuan+Trisquel 24, somewhere in Egypt. Except of course if you manage to spin round and round three times while saying or typing "GAFAM" six times before you reach his stomach. This might work if you had been using safe Rust. Or unsafe Rust, but only if encapsulated into interior unsafe functions. Otherwise, farewell.
I got lucky, Cthulhu forgot to run "rustup update", and his rust toolchain was too outdated, especially his old version of cargo. He couldn't compile me, and so he puked me up. I walked away with nothing more than a good sliming. And who doesn't love a good sliming?
I am a translator!
I am amazed by how many languages people felt the need to create, all of them supposed to be nicer. I only learned and used C and a bit of Lisp, I try using bash and awk sometimes, all of that is already a big effort. My feeling is that it just makes it more difficult to exercice software freedom as one needs to study more languages to read programmes.
As for when I had to write web pages, I just wrote HTML directly and never used a style sheet, and it was not less readable than all the fancy sites that one can see nowadays.
Rust is bloated and non-free, and their arguments are senseless to me. For example, mobile "apps" from crap stores= is in technically memory safer languages? Fool me once? I should trust the JavaScript on some sketchy website because JavaScript is memory safer (sarcasm)?
"Another advantage of free software for businesses that use software is security and privacy. And this applies to individuals as well, but I brought it up in the context of businesses. You see, when a program is proprietary, you can’t even tell what it really does. It could have features deliberately put in that you wouldn’t like if you knew about them. For example, it might have a back door to let the developer get into your machine. It might snoop on what you do and send information back. This is not unusual. Some Microsoft software did this. But it’s not only Microsoft. There are other proprietary programs that snoop on the user. And you can’t even tell if it does this. And, of course, even assuming that the developer’s totally honest, every programmer makes mistakes. There could be bugs that affect your security that are nobody’s fault. But the point is: If it’s not free software, you can’t find them. And you can’t fix them."
Rust is non-free? Can you elaborate? It is included in Trisquel btw.
It is the usual issue with Mozilla's trademark: it prevents commercial redistribution of exact copies (for modified copies, it is not an issue: trademark actually aims to help the identification of a product and it is reasonable to ask whoever modifies Rust to change the name and logo). Changing the name and logo would remove the problem.
> for modified copies, it is not an issue
"It is unfair for someone to ask you to remove a trademark from modified code if that trademark is scattered all throughout the original source." -- GNU FSDG
https://bonebaboon.tilde.site/rust-trademark-policy-issue/#Frequency-of-Trademarks-in-Source-Code
Although I do not deny the work it would represent to change name, the reported counts are gross overestimates: "rust" appearing somewhere (often as a prefix of a variable) in the repository (src/tools/clippy/CHANGELOG.md contains most occurrences: 1407) is quite different from "rust" appearing in a string of the actual code and that may (or not) end up being shown to the user. In https://github.com/rust-lang/rust/archive/refs/tags/1.54.0.tar.gz :
$ grep --recursive --ignore-case rust * | wc --lines
grep: src/test/ui/raw-str.rs: binary file matches
51866
$ grep --recursive --ignore-case --word rust src | grep --ignore-case --count '".*rust.*"'
grep: src/test/ui/raw-str.rs: binary file matches
1308
I cannot guarantee that every relevant occurrence of "Rust" is kept (the string may be multi-line, etc). On the other, looking at the 1308 lines, I can affirm most of them are not to be changed, i.e., the real number of changes to make must be on the order of 100.
> looking at the 1308 lines
> I do not deny the work it would represent to change name
Work which gets in the way of freedom, which is not "reasonable", be it ten, a hundred or thousands of occurrences, to be done after each revision. Or so was I told be a friend.
That said, being nonfree because of trademark issues might not be the main problem of Rust. Rust is obviously not making codebase maintenance and security fixes easier. If anything, it is making it more difficult, which also gets in the way of freedom - and, incidentally, safety - while pretending the opposite. There might be reasons why some distros rejected it.
"If the Rust compiler ends up doing hidden allocations, and they then cause panics, then one of the main *points* of Rustification is entirely broken. That's 100% the opposite of being memory-safe at build time." -- Another friend.
By the way, Rust does not pretend to be "free", but to be "open".
"Rebranding the entire language to avoid the trademark restriction. Such as IceCat was made to replace Firefox and Iceweasel-UXP to replace Basilisk; however it is a programming language, not a browser. A rebranded version of Rust maintained by the GNU Project and FSDG-compliant distros could be the way. However, we would need patches to adapt all Rust-dependant applications to the modified version of Rust, since it is a programming language. We would also need to maintain a list of nonfree cargo packages to blacklist those for your-freedom."
https://wiki.hyperbola.info/doku.php?id=en:main:rusts_freedom_flaws
Work which gets in the way of freedom, which is not "reasonable", be it ten, a hundred or thousands of occurrences, to be done after each revision.
Such changes would not be manually done, but with scripts, like Trisquel's package helpers, which use simple sed substitutions.
Trademarks aim to easily identify what you get. It has value. Think of the *modified* LibreOffice suites out there that add advertisement or even malware. They are proposed on some download sites as "LibreOffice". Trademark policies, such as Mozilla's, preventing commercial redistribution of *exact* copies do not fulfill the purpose trademarks are supposed to fulfill. They are unacceptable.
Rust is obviously not making codebase maintenance and security fixes easier. If anything, it is making it more difficult, which also gets in the way of freedom - and, incidentally, safety - while pretending the opposite. There might be reasons why some distros rejected it.
That has nothing to do with "freedom". As far as I understand (I have never tried programming in Rust), compared to C or C++, Rust does make it easier to write safer code, isolating unsafe code (unavoidable for efficient low-level code) in functions clearly labeled as unsafe. By your argument, distributions should reject C and C++.
> Rust does make it easier to write safer code
I believe this affirmation is not based on experience. Rust does pretend to do this, while many users have noticed that, in effect, it does not do it. That's the core problem. And yes, adding hindrances to code reviews does get in the way of freedom, whatever narrow definition of "freedom" one might agree on.
We can see people pushing Rust all over the place. Why would they need to push it so hard if it really had all the good safety properties they pretend it has? In most places, people have been pushing back against it because they see no benefits, while they see how much additional workload transitioning to it would mean, not to mention added maintenance load. Your argument about C and C++ is preposterous, because C and C++ have been around for quite a while, have massively matured and do not pretend to do the progammer's job. This is not a debate in the theoretical void.
To be fair, I see several benefits in Rust, as a tool to improve safety awareness among C/C++ developers and as a whip to keep improving the C/C++ toolchains. This is already happening, and imho is the best that can be achieved from these two worlds.
The fact that a language is harder to write code in isn't a software freedom issue. At least not in the common sense of the term.
The only possibly legitimate freedom issue that I see here is that you might not be allowed to sell unaltered copies of Rust. But this wouldn't apply to distributions which produce their own builds. I can't really comment on the security part, though that isn't relevant to software freedom.
> We were discussing the memory safety of Rust
> I can't really comment on the security part
I believe this affirmation is not based on experience.
As I said, I have never tried programming in Rust. But I have been programming in C++ for the past 18 years. I know what a buffer overflow, a dangling pointer or a data race is. Can I ask you how much of C, C++ or Rust you have written?
Rust does pretend to do this, while many users have noticed that, in effect, it does not do it.
Not without the "unsafe" keyword, unless you show us how.
And yes, adding hindrances to code reviews does get in the way of freedom, whatever narrow definition of "freedom" one might agree on.
Please concretely explain how Rust adds hindrances to code reviews? Knowing that problems such as those I listed above can only occur in blocks marked as unsafe must significantly help code reviews.
As for the "freedom" issue, like Legimet, I still do not see it.
We can see people pushing Rust all over the place. Why would they need to push it so hard if it really had all the good safety properties they pretend it has?
Here are the conspiracy theory arguments. Who is that mysterious "they", by the way? Nobody is forcing any software project to choose Rust.
In most places, people have been pushing back against it because they see no benefits, while they see how much additional workload transitioning to it would mean, not to mention added maintenance load.
In the places you frequent maybe. If you read the latest survey on Stack Overflow, you will see that:
For the sixth-year, Rust is the most loved language, while Python is the most wanted language for its fifth-year.
https://insights.stackoverflow.com/survey/2021#section-most-loved-dreaded-and-wanted-programming-scripting-and-markup-languages
82,914 developers answered.
Your argument about C and C++ is preposterous, because C and C++ have been around for quite a while, have massively matured and do not pretend to do the progammer's job.
Is "the progammer's job" to code with little help from the compiler and, doing so, to take the risk of shipping a program that will segfault in untested circumstances or suffer from vulnerabilities?
Your arguments make little sense, probably because you have little experience with C or C++. With programs written in those languages, problems such as buffer overflows and null pointer dereferencing are common, because the compiler cannot possibly catch such problems, given the language. They happen even in code such as Linux, written by top-tier programmers.
The Rust compiler complains unless it is certain no such problem can occur. Reading the error message, the programmer can then either correct a mistake or, if there is a good reason for the unsafe instructions (interfacing with C, low-level efficiency in the performance-critical part of the code, etc.), she can use the "unsafe" keyword and, in the sole code marked as such, memory safety is not guaranteed by the compiler but a promise of the programmer. Such a promise must cover the whole source code written in C or C++.
To be fair, I see several benefits in Rust, as a tool to improve safety awareness among C/C++ developers and as a whip to keep improving the C/C++ toolchains. This is already happening, and imho is the best that can be achieved from these two worlds.
I do not understand what you are referring to but would like to. Could you give some links?
> "As I said, I have never tried programming in Rust. But I have been programming in C++ for the past 18 years."
I learned Fortran in 1986, so I'm twice as qualified as you to state an opinion on Rust. And I opine that it is part of a demonic plot by Cthulhu to enslave all of humanity.
Banana, you should mix in a little humor when you are debating. As the Joker said in the internationally acclaimed documentary "The Dark Knight", "why so serious??" You are a magic banana after all. Magic bananas are supposed to be funny, they are supposed to be the life of the party.
I think you are being slightly unfair here, life is not always easy, even for magical bananas. Actually, Rustic Banana here has been known to make cerebral jokes. From time to time.
I have changed my mind, I think Rust is our past, present and future. I have started to study Rust again, and as I write these lines I can already foresee many avenues to improve it. Of course, that means rebranding. So I rushed to register "Rast", "Roast", "Wrist", "Rest", "Rush" and "Thrust". Also, "Mold", "Decay" and "Rot". I think it is sane to have as many competing versions of Rust as possible, so the Rust people do not indulge in self-satisfaction, as the C/C++ people shamefully did.
I strongly support developing Metal Rat in Rot.
> "Thrust"
So this is a pR0no programming language? We will have to work on a totally new set of function names. Have to work "booty-call" into it somehow. The possibilities are endless.
> So this is a pR0no programming language?
It seems so: "The Rust for Linux project, sponsored by Google..."
Mozilla, Google and Red Hat have a child: Rust could only be a tentacular monster with a red hood.
https://www.theregister.com/2021/07/05/rust_for_linux_kernel_project
https://opensource.com/article/21/6/dust-linux
https://opensource.com/article/21/3/replace-ls-exa
Red Hat is not even a member of the Rust Foundation.
"The recently announced proposal to make the Rust programming language one of two main languages for the Linux kernel is getting a major boost thanks to Google and the Internet Security Research Group (ISRG), the group behind the Let's Encrypt certificate authority. "
https://www.zdnet.com/article/rust-in-the-linux-kernel-just-got-a-big-boost-from-google/
If you check out the sponsors there is red hat and ibm
There is no sponsor on that page. And nobody from Red Hat is apparently a board member of the Internet Security Research Group: https://en.wikipedia.org/wiki/Internet_Security_Research_Group
Even if Red Hat sponsors a research group pushing Rust "to wipe out an entire class of memory-related security bugs in the kernel", that would not make Red Hat involved in the governance of Rust.
Well, except for conspiracy theorists. For them, the absence of evidence is an evidence that there is a secret conspiracy. The presence of evidence too. That is very convenient. And, despite all the good it did to GNU/Linux, Red Hat always has to oversee the conspiracy.
If Cthulhu does not wear a hat, a red hat, it is to purposefully hide the identity of his overlord.
"At Red Hat, we believe that the work Let’s Encrypt is doing is important to the industry, and they have made it easier to run secure sites. We sponsor Let’s Encrypt because we support their mission, and recognize their work and the value that we have received from it."
NB: it also says "under the hood", so our theory is hereby unequivocally confirmed.
Bet you didn't know about RedHat "Ceph" storage? Named after "cephalopods" - or octopii. Each version of RedHat Ceph Storage gets named after a different kind of octopus or squid.[1]
And the logo for RedHat Ceph Storage is a red octopus, with its tentacles hanging down.[2]
How much more proof do you need? Clearly this is all driven by RedHat's Cthulhu worship.
[1] https://people.redhat.com/bhubbard/nature/cephmods/releases/general/
[2] https://www.c-sharpcorner.com/UploadFile/NewsImages/06242016053514AM/Red%20Hat%20Ceph.PNG
There is only one Cthulhu, and Rust is their language.
Hood color may vary, in order to confuse trolls.
I have now taken to cook rusticini in lieu of patches. Seafood rusticini.
Today I did not have time to cook Rusticini, so I bought something similar at the supermarket deli corner.
It was amazingly gorgeous, they must be using genuine Rustentacles.
I've invented a new ultra-ultra-safe programming language I'm tentatively calling "Snail". Programs written in Snail perform so slowly that computers don't recognize them as programs at all. By the time a Snail program completes its instructions, the computer that was hosting it has long since corroded and lost all ability to power on or perform.
Of course, that's not nearly safe enough, so my next programming language I'm tentatively naming "Glacier". It will take hundreds of thousands of years to complete a simple set of instructions, such as drawing a round ball on the screen. With Glacier, we will finally achieve the kind of safety that the Rust fans can only dream of.
> drawing a round ball on the screen
That already sounds like a highly dangerous activity: if the drawing was to never be completed because of memory leak, you would trigger a cosmic panic and the Nataraja dance would resume and destroy us all, at best.
At worst, we would end up frozen forever, like he who shall not be named. Now I think about it, maybe Glacier itself is not so safe.
Did you see the comments on that RedHat lady's article where she attempted to force everyone to use the Rust replacement for the "du" disk usage command? She got blasted! "Get off my lawn, evil RedHat lady" was the basic idea from each commenter.
Jokes on them though - RedHat hasn't even legally existed for a year and a half since they were swallowed alive by the big blue Borg. She's actually an IBM'er, and this whole plot to infest the world with rust tentacles is just another insidious global dominance scheme by IBM.
You forgot to mention Microsoft by the way:
>"Microsoft's Linux Systems Group is contributing and hopes to submit "select Hyper-V drivers written in Rust."[1]
[1] https://www.theregister.com/2021/07/05/rust_for_linux_kernel_project
I've also programmed quite a bit in C and C++ and can confirm that it is very easy to accidentally introduce memory safety bugs.
"Please concretely explain how Rust adds hindrances to code reviews? Knowing that problems such as those I listed above can only occur in blocks marked as unsafe must significantly help code reviews."
"We found that all memory-safety
bugs involve unsafe code, and (surprisingly) most of them
also involve safe code."
https://cseweb.ucsd.edu/~yiying/RustStudy-PLDI20.pdf
https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=rust
"Here are the conspiracy theory arguments. Who is that mysterious "they", by the way? Nobody is forcing any software project to choose Rust"
Both red hat and Mozilla signed the anti rms defamation letter, now that IBM bought out red hat i bet they are in the club of "them" and i wouldn't trust it.
"These vulnerabilities are exploited, to the peril of hospitals, human rights dissidents, and health policy experts. Using C and C++ is bad for society, bad for your reputation, and it’s bad for your customers."
https://alexgaynor.net/2019/aug/12/introduction-to-memory-unsafety-for-vps-of-engineering/
stackoverflow is a trash website nowadays annoying pop up filling the screen if you don't have JavaScript enabled.
> "stackoverflow is a trash website nowadays annoying pop up filling the screen if you don't have JavaScript enabled."
Agreed. They've nearly destroyed an otherwise useful site. That popup is ridiculous.
https://csts.ua.edu/ama/more-doctors-smoke-camels/
^ More doctors smoke camels deception commercial perhaps a bit too similar to stackoverflow most developers "love" rust?
In a "you"tube video entitled "Kitty Is A Fast And Feature Rich Terminal Emulator" about 13 minutes in a comparison of a terminal in python and rust is done, it may appear the speed of non-free rust = lies as well from the rust trolls. With multiple "unsafes" resulted in 13 seconds vs 15. The rust trolls seem to try and sell rust as being so much faster than python but of course omitting cython in their commercials? 6 seconds with older computer similar command using the suckless st terminal i got.
https://packages.debian.org/experimental/rust-coreutils
amd64 9,640.8 kB 88,537.0 kB [list of files]
https://packages.debian.org/sid/coreutils
amd64 8.32-4+b1 2,799.5 kB 17,478.0 kB [list of files]
^ The seemingly more incomplete (less commands in total?) coreutils in rust is wasting so much disk space, hopefully the rust propaganda wont fool to many people and gnu linux wont be a hog with disk space like slowdows vista and above?
https://users.rust-lang.org/t/rust-says-tech-will-always-be-political/43627
^ Lol politricks to divide and conquer? So toxic?
"We found that all memory-safety bugs involve unsafe code, and (surprisingly) most of them also involve safe code."
And the next sentence is:
"Mistakes are easy to happen when programmers write safe code without the caution of other related code being unsafe."
As any C/C++ programmer knows, a segfault can happen at a correct instruction because of a remote buggy instruction that used the same pointer/array. As far as I understand, in Rust, the sole first instruction is necessarily in an unsafe block, not the second one, the actual bug. So, I am not sure why the authors find that particularly surprising.
And I still do not see how that "adds hindrances to code reviews". It still looks useful to know that memory-related problems can only occur in unsafe blocks (although, yes, possibly caused by bugs in related code, out of those blocks). Using in Rust the "unsafe" keyword everywhere is like using C or C++. The idea is to only use that keyword when there is a good reason to so: most of (if not all) the written code should be unrelated to unsafe code. The performance-critical part of a program is usually a tiny proportion of it. For hardware-interacting code, I am not experienced. Nevertheless, since Linux developers seem to forecast benefits in adopting Rust, I guess it is the same.
https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=rust
That is a list of CVE records. Would you take any of them and comment on it, so that we can see how much (or little) you understand about the technical issues you apparently have a strong opinion about?
Both red hat and Mozilla signed the anti rms defamation letter, now that IBM bought out red hat i bet they are in the club of "them" and i wouldn't trust it.
Again, Red Hat does not take part in the governance of Rust. Sorry about that: I know there somehow needs to be Red Hat involved for the conspiracy theory to be valid.
"These vulnerabilities are exploited, to the peril of hospitals, human rights dissidents, and health policy experts. Using C and C++ is bad for society, bad for your reputation, and it’s bad for your customers."
Those two sentences come with six links pointing to exploited vulnerabilities, with terrible consequences, attributed to memory unsafety in C and C++ code. They make the author's points. The links you provide do not make yours.
I like C++. I have written tens of thousands of lines of code in it and will certainly continue to do so, mostly because, over the years, I have become reasonably good at it and lack the time to learn another language that is as complicated and serving the same needs, such as Rust. That is because I have some experience in C++ that I understand the arguments in favor of Rust. Not because I hate C and C++ or because Red Hat (again: not even involved in the governance of Rust) brainwashed me.
I was under the assumption that trademarks that require you to change the name of the software if you modify it were OK even under FSF policy; the issue with Firefox was that you can't sell copies of the official unaltered build (and of course DRM and the proprietary addons). I think if such trademark restrictions made software nonfree, then we would have to reconsider a lot of other software (e.g. Libreoffice).
Personally I don't have an issue with using trademark-restricted software, but it's fine if others disagree. In fact I use the version of Firefox in Debian. Obviously it's not suitable for inclusion in an FSF-approved distro, but I disable EME and don't install nonfree addons and that's good enough for me.
The debian version of firefox-esr is modified and can redistribute it with mirrors, they used to have to call it iceweasel? Works much better than if you download firefox spyware fresh from their website for like slowdows, in my honest opinion.
"With Firefox 75, we’re launching a new scheduled task for Windows that will help us understand changes in default browser settings. As with all other telemetry related changes here at Mozilla, this scheduled task has gone through our data review, a process designed with user choice and privacy at its core…"
https://blog.mozilla.org/data/2020/03/16/understanding-default-browser-trends/
^unbelievable
> "If the Rust compiler ends up doing hidden allocations, and they then cause panics, then one of the main *points* of Rustification is entirely broken. That's 100% the opposite of being memory-safe at build time." -- Another friend.
That was in fact from my friend Linus. From Finland.
He does kernel stuff: walnut, chestnut, etc.
Are you saying that based on this policy: https://www.mozilla.org/en-US/foundation/trademarks/distribution-policy/ ?
That applies to "unaltered copies of Mozilla Firefox and other Mozilla software from Mozilla.org". Rust is now independent of Mozilla and is not distributed on mozilla.org as far as I can tell, so I'm not convinced this is a real issue.
https://www.rust-lang.org/policies/media-guide#rust-trademarks says:
This document supplements the official Mozilla trademark policy which governs use of all Mozilla trademarks.
And which part of the official Mozilla trademark policy forbids selling copies of Rust? All I can find is this: https://www.mozilla.org/en-US/foundation/trademarks/distribution-policy/
Which seems to explicitly refer to software that is distributed on mozilla.org.
"Rust" is still on the "Mozilla Trademarks List": https://www.mozilla.org/en-US/foundation/trademarks/list/
So, the commandment "You may not charge for the software" on the page you link to probably still applies. Hopefully that will change for the better soon:
The various trademarks and domain names associated with Rust, Cargo, and crates.io will move into the foundation, which will also take financial responsibility for the costs they incur.
https://blog.rust-lang.org/2020/08/18/laying-the-foundation-for-rusts-future.html#starting-a-foundation
The Rust Foundation was announced in February this year: https://blog.mozilla.org/en/mozilla/mozilla-welcomes-the-rust-foundation/
- Login o registrati per inviare commenti