As free software users, we all enjoy using the latest and greatest in free software, but we need to make sure that the software we are using really does respect our freedom. The desire to run Rust and build software with that programming-language is clear to be seen, since it appears to be fully free software, but it still fails in several ways.

Therefore we rely on the clear definition what free software is, being defined through the four freedoms:

• Freedom 0: The freedom to use the program for any purpose.
• Freedom 1: The freedom to study how the program works, and change it to make it do what you wish.
• Freedom 2: The freedom to redistribute and make copies so you can help your neighbor.
• Freedom 3: The freedom to improve the program, and release your improvements (and modified versions in general) to the public, so that the whole community benefits.

Please remember here also:

So right at the beginning the question: Why do we make that kind of detailed perspective especially on Rust, when theoretical the language itself cannot be restricted? Because the situation is right away not that easy stated: The reference implementation has as said freedom-flaws, the foundation behind Rust itself has stated strict trademark-perspectives and there are surely enough patents and copyrights gone into the development of the language itself. The current state of free and libre software has shown clearly that companies and corporations have no interest into this, neither in altruistic motivation nor also in further giving away something for “free for everyone to learn”. That is the clear motivation behind this article and the results for Hyperbola itself as project! Yes, we could finally state that we do not bother with trademarks, patents and copyrights, that we also recognize everything else stated from the FSF as “working” for us, but the reality beyond the illusion shows that this is not finalized picture working. Starting here we already can say:

• The license for a project is not enough.
• The people standing for a project and behind it are very important and when being in connection with companies and corporations there are high doubts that there is no outright questionable, even just self-oriented and egoistic motivation in the first place. Please refer to the people then as employees getting the task to manage and develop for and with the project.
• Companies / corporations are never trustworthy, only when they follow their ways to defend and protect their own interests.
• Nothing is given away for “free” from companies / corporations, so they will not give away control.

Rust is fully controlled by companies / corporations, was developed also under those circumstances. From here with those details we can surely start. Last short note: But why do we write then that much text for this analysis here? Why do we have that amount of problems with companies / corporations? Because free, libre software and culture surely needs support, financial and also with helping hands, but this should be done from the motivation of people, because they really appreciate the software and the values ​​behind it. Not just stating to support free, libre software but afterwards only because the software is being delivered “gratis for their own egocentric imagination of freedom”.

Rust and also Cargo (the Rust package manager) violate the freedom to redistribute without “explicit” approval. Their approach to protect their trademark imposes requirements for the distribution of modified versions that make it inconvenient to exercise freedom 3. To quote:

Distributing a modified version of the Rust programming language, compiler, or the Cargo package
manager with modifications other than those permitted above and calling it Rust or Cargo requires
explicit, written permission from the Rust Foundation. We will usually allow these uses as long as the
modifications are (1) relatively small and (2) very clearly communicated to end-users.

Exactly the phrases relatively small and very clearly communicated to end-users are parts of the problems: They are vague in their meaning and it is clear that the Rust Foundation has no real interest to have modified versions distributed. So for example to have Cargo removed as otherwise non-free packages could be used from projects being compiled. In fact Rust is that kind of complex with demanding dependencies that a removal of its internal package-management (Cargo) makes it not working and so there are even plugins to control licenses before applying something. That violates also Hyperbolas point of minimalism and the possibility to rebuild any package with own modifications from users at any given time! We talk here about making free, libre software good to handle and learn for technical emancipation, while Rust is going even more complicated and complex.

In short, the Rust Foundation won't be happy with applying patches and modifications to their language without “explicit approval”, so it is a freedom issue. We should not have to ask for modifications and we do not ask for permission.

But that is not the only point: If we would remove Cargo, we would need to ask for permission when we call the package Rust. And if we remove the package-manager (Cargo) we also create a not useful result as Rust depends on it fully when building. If we add needed dependencies for software based on Rust, we enlarge the number of our packages provided. In fact the intention of Hyperbola to offer a system oriented on simplicity and minimalism is breached when we add more complexity. And Rust itself cannot be build from source without using another version of Rust. We noticed alternative methods of bootstrapping surely using mrustc, but this consumes that much memory being not possible to manage for 32bit-environments.

To summarize the issues:

• demands to ask for allowing modifications
• complex structures
• mandatory package-manager for building
• packages downloaded at build-time can be non-free, so keeping that outside makes the whole build-system and infrastructure even more complex
• issues for building and providing a concrete package for Rust itself

The listing above only shows the major points, furthermore the Rust-Foundation is overreacting in our perspective with their language and demands handlings violating in fact free, libre software as it is based most on ethics and moral decisions as important, not what possible legal issues could be there.

There are important applications integrating Rust as a first-class language. Tor is one of them, and they have concluded their new implementation called "arti" written in Rust and the Linux-kernel with its Rust-implementation is also growing.

Also many other projects are changing their approach or get a complete rewrite in Rust as first-class language, some further examples:

• implementation for libsignal as libsignal-protocol-c is no longer active maintained
• neovim adding tree-sitter as mandatory dependency since v0.7.0, as tree-sitter is a full Rust-depending project
• librsvg being completely rewritten in Rust
• ClamAV is enforcing the Rust-toolchain since v0.105
• GNU coreutils getting a cross-platform implementation in Rust

The list can be enhanced for sure and clear to say that Rust is not only some sideload toolchain. As the buzzword “memory safety” is being in usage more and more projects get on this. Yes, the rewrite of GNU coreutils is not the main project. But who says exactly that this won't be the near future? As all the other points in this article were long before described, not solved and just accepted. It is a bad and foul compromise, endangering freedom of choice, user freedom for sure and also the freedom for system-distributions and operating-systems like Hyperbola.

It should be also mentioned that the Rust Foundation has a comparable members-list like the Linux Foundation. Speaking about a “community” is therefore not fitting in any way as those members are just companies and corporations. Neither Rust nor Linux are real community-oriented software and the FSF has failed to fork the kernel as GNU/Linux-libre for a long time now. That's the point for Hyperbola to become independent in a whole. You think we are wrong here within the concrete analysis? Please have a look at the “Board of Directors” of the Rust Foundation, where the majority of persons working for corporations being neither reliable nor trustworthy in regards of free, libre software.

The point here is that Rust is not only a programming-language and the build-process needs essential Cargo to download further dependencies. As a current perspective there are 178.665 so-called “crates” available at crates.io (growing while we have written this article and you, dear readers, are reading here). Every so-called crate is comparable to an own third-party library, possible to be downloaded and included right at build-time. In fact there is no complexity-reduction with Rust at any given point it is also not possible to patch any kind of simple solution back into this failed architecture. While Rust itself is also not a community-driven project and therefore only driven by corporations and companies throughout the Rust Foundation.

In fact Rust is failing any further simple solution, so we only list the common ones possible for a generic compilation. Without any doubt Rust fails to correspond towards the claims and principles Hyperbola is following:

• 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 (crates) for blacklisting purpose.

• Getting Rust to change its trademark agreement to allow modifications on the rust binary for any purpose in respect of Freedom 3.

• Keep all Rust-based projects aside and focus only on the ones with a clear stance and accept not to include Rust in any way.

Hyperbola has taken the decision to keep Rust complete out of the repositories, including also all applications and libraries using Rust. We decline this kind of “freedom” under the influence of overreactions and enforcing a non-permissive approach for also more comprehensive changes. We also decline complexity generic so we do not accept package-managers for every single language or interpreter.

We know that there is the claim it would be “easy to rebrand like Mozilla Firefox”, so we want to take this point and explain further why those things are different levels of complexity.

Rust is a complex language and framework including also an own package-manager, documentation and sources for building. Firefox is an application for users. Rebranding an application is one thing and rebranding a complete programming-language is not comparable. When people use this claim for Rust, they are doing something being not honest in the perspective that it is not sufficient to just rename some resulting binaries: The rebranding of Rust includes not only the binaries and some messages, there is the documentation, the included sources, naming for files, possible notes within the source-files, libraries and also the whole building-framework around. Yes, we also know about the project CrabLang. But that exactly underlines again our points: If it would have been that easy as some people say, this project would have already made a stable release and informed about that. Also CrabLang has not really shown more interest into stable releases and only follows the development of Rust while keeping builds direct from the source-repositories working. Therefore Hyperbola is not able to provide any package based on stable tarballs released and even though tags from Rust itself are not preserved in the repositories of CrabLang, making it impossible to create own stable marked tarballs on pair with Rust or providing any kind of alternative replacement.

And all besides rebranding alone is also not enough: As we also mentioned already that Cargo may pull non-free packages and dependencies. Again to point out: It is not enough to talk about “rebranding” as Rust itself needs therefore also to be completely reworked for having it easier to handle with its dependencies at build-time.

Yes, we have seen, read and heard about gccrs as an alternative frontend being part of the GCC-project in the future. Besides being interested in this the approach is not finalized until now and needs surely more work until being fully useful. Until this point it is also not finally clear how Rust itself with compilation and dependency-management is being handled throughout gccrs itself.

So for the moment we have the only trademarked reference-implementation onwards and this relates back to our points brought into before. The Rust Foundation has provided an article about gccrs showing that the funding of this project is also not related to a community itself: gccrs was initially funded by the companies Embecosm and Open Source Security.

Some users have correctly mentioned that many other software packages have trademarks, do we plan to remove them all? No, but we see trademarks generic also not under a positive aspect when they are used that kind of harsh.

As an example, neither Python PSF nor Perl Trademarks currently prohibit patching the code without prior approval. They do prohibit abuse of their trademarks, e.g. you cannot create a company called “Python”, but this does not affect your ability to modify their free software and/or apply patches. And to underline again: We just refer towards patching the software-packages, not towards the generic trademark.

Due to the very strict written modification-clause, Rust is a non-permissive trademark that violates user freedom.

Both projects have a clear trademark to protect the usage of the software itself against fraud. But there is a difference as Python and Perl allow patching and modification defined within the four freedoms.

From Python:

(...)

Use of the word "Python" when redistributing the Python programming language as part of a freely 
distributed application -- Allowed. If the standard version of the Python programming language is 
modified, this should be clearly indicated. For commercial distributions, contact the PSF for permission if 
your use is not covered by the nominative use rules described in the section "Uses that Never Require 
Approval" above.

(...)

From Perl:

(...)

People sometimes ask if TPF's use of an onion in the Perl logo means that independent projects that use or 
relate to Perl need TPF's permission to use an onion of their own design in connection with their project.
​
The answer is "not necessarily" as long as no likelihood of confusion is created. One of the fundamental 
legal bases for trademark protection is to make sure that the public can depend on a mark as an accurate 
indicator of a particular source or relationship, and one way of defining trademark infringement is to say 
that the infringing mark creates a likelihood of confusion. Likelihood of confusion is determined based not 
only on making a comparison of the marks side-by-side, but also on making a comparison of the contexts 
in which they are actually used. Thus, it's easy to imagine independent onions that would be fine, and 
independent onions that might not be. Contact us at trademark@perlfoundation.org if you have any 
questions, or would like us to evaluate a particular logo or usage to see if it would be an infringement.

(...)

The comparisons are done intentional as Rust has no further interest within patching and modifications outside for special use-cases.

So is the language itself as conception free and libre licensed?

This important question is depending on how to handle the trademarks, patents and copyrights gone into the conception of Rust as programming-language. A finalized approach besides the reference implementation is not possible to be given at this point. Per definition the language seems “open” for others to be implemented, but time will tell how other approaches can be seen.

Is the reference implementation free and libre licensed?

The reference implementation has severe freedom-flaws within their approach to handle bigger patches and depends clearly not on a model Hyperbola can use further. Therefore we have concluded to describe and callout the severe freedom-flaws and issues within this article.

Do you call Rust therefore non-free even when they provide the project under a free, libre license?

We definitely call Rust nothing more than the information provided grant us. We just point out that we do not include the reference-implementation of Rust and therefore also Rust-based projects and implementations out of a reasoning: Rust is not an independent, community-driven effort and project, but foremost developed from and with focus on companies and corporations.

It is always possible to build a community around any project and stating after this also that there are community-efforts. Surely they are there without any doubts. But there is a difference between clearly own community-projects oriented from the start only on this focus and companies / corporations creating those and people later on organize around this a “community”. Is the last one a wrong approach? No, people are free to do what they want. But the results are different and also the orientation with the focus on power to change something or just follow what others command.

But other trademarks are not different handled, why is Rust that of a concern and problem?

We have pointed out the differences towards other trademarks (in this article Python and Perl). It is possible to modify Python and Perl, calling both same way. It is not possible to modify Rust and a modification and complete rebranding is beyond possible without approaching that generic. So this is surely no point for a small team and project like Hyperbola!

You could just rebrand Rust as a new package and include symbolic links to preserve compatibility?

Please understand that rebranding is always connected with the upstream software using this. So we would need on-going to do this with every new release. Hyperbola's perspective is towards long-term stability, so we also do not just rename binaries. We would therefore need to rename everything including the name of the trademark Rust: Resulting binaries and therefore output-definitions for those, source-files with commentaries, documentation included and also removal of images and logos. We would then need to offer a new created tarball for creating this package, a repository and in fact we would clearly fork Rust as software-project in a whole. This is not possible for a small team with a complete different focus. This is too much work! We have referred to this also here in the article.

No Rust, no software based on Rust, do you think this is sustainable for the future?

Nobody clearly can forsee the future and the further development, but every project has its major focus and Hyperbola has neither the interest nor the orientation to follow always the newest development or include even problematic oriented projects like Rust. See here also that Hyperbola only lookout for community-projects, not for software coming from companies and corporations.

And we close again for all interested with the definition of freedom: Freedom is the power or right to act, speak, and change as one wants without hindrance or restraint. Demanding the opposite is not freedom per definition and surely freedom always is included with responsibility. So we speak only on behalf for Hyperbola as project as we write down our reasoning. Others may see it different, but this does not redefine our points here. Free as in freedom means for us at Hyperbola that people need to take responsibility, not companies and corporations on behalf of people (or better on behalf of their interest and telling later that people need this). When freedom within software has not that much meaning that people do not take either time or support and therefore also with money when needed, we see here issues upcoming. Who has then the power to decide? People running their system? Or others in the end? And who controls those “others”?

You have written about overreacting, don't you think you do the same?

A free and libre oriented system cannot provide a package-manager besides its own to preserve the autonomy of the free system itself. What the users are doing is their own decision, but they should be always able to assure a consistent free and libre oriented system outside their own decisions that they are responsible for. Hyperbola decided clearly on behalf of the users: If they want to build Rust with its reference implementation, they can always do this. But we see our responsibility to provide just a working system with software around being clearly free and libre for users, not to grant more likewise packages with even their own package-management. That is a point of complexity we reject now and will always do. An operating-system has not the task to grant more complexity, especially when it is free and libre. It should grant insights when the users want them, at any given time. To manage and compile software should be transparent, not with growing listings of needed dependencies. Rust is outgrowing this and on technical and social scaling the project is for Hyperbola clearly questionable.

Don't you spread false arguments especially when it comes to companies and corporations?

First and foremost the common argumentation is therefore that people think adoption of languages would be only possible with the support of companies and corporations, especially from the technology-sector. We are surely aware how this relates also to Python and Perl, besides there being also corporate sponsoring aboard. Nevertheless there is a difference we already pointed out several times: We want to preserve the autonomy of our operating-system. Whatever other projects and people think they accuse us, we never wanted anything else. Technical programming languages and implementations with their own package-manager are not trustworthy for keeping a free and libre system safe enough from problematic dependencies and therefore also under the control of their users.

Yes, Hyperbola as project was and is accused of spreading so-called “FUD” (Fear, Uncertainty and Doubt). A propaganda-strategy to bring up an appointed target into discredit. So we clear up with this point here also: Sure we mention doubts and problems, but we just do this in the context of our project and why we exclude Rust. We said several times here in the article that others can always handle different. It is sidewise mentioned interesting how often Hyperbola is accused while just listing the issues we see. When others do not see the outgrowing complexity as an issue, please be invited doing so. We have a different approach and list just the reasoning for us doing this. But accusing Hyperbola to spread propaganda is a quite different thing and in itself not outright correct. If you read through our wiki-articles and also include the generic perspectives Hyperbola is following, we never talk about some “evil masterplans” or “nefarious motivations” when talking about companies and corporations. When you use those assumptions, then those are born within your own thoughts and you just relate them to us. We just talk about arrogance and ignorance as companies and corporations are following always only those motivations. Ask yourself what kind of motivation any company might have to be a sponsor of a project. For sure not the orientation on the community-aspects or to bring people something better just without not getting anything from it. We have and will always mention the altruism being part of the free and libre culture, including the right to distribute derivative works without asking for permission, without doing even more work to even rework a whole copy of a project. If you see all of this different under the circumstances of copyrights and trademarks, is this surely your own perspective but not fitting the point of free and libre culture being kept working, dear readers (read here more about free culture).

In the end: If people think it is worthwhile to use “argumentum ad hominem”-argumentation to accuse Hyperbola as project for example to spread FUD (as noted here), we cannot do anything about except to point out that this does not compare to our motivation and the reality of our arguments. We like to work together, even when there are different perspectives and we also invite everybody to discuss with us so we can learn from each other. So it is up to the people themselves deciding, you may go on for sure accusing us or we can learn from each other.

Okay, more or less understood, but even when not on agreeing: Do you bother other projects then?

No, we do not bother others and also not other projects with our perspective. We just ask kindly to accept at minimum that we have clearly a different perspective, when Rust is then no real issue. We also do not motivate others to tell elsewhere that projects doing and handling this different are “worse”, “not good” or “not complying”. We enforce nobody using Hyperbola or see it the way we do. So we clearly also accept that others may see all the points and information not that critical. If people think to criticize elsewhere based on this article here and want to enforce something, we also now here ask to stop this immediately: You can present the information, refer to them using this article but if then the rejection comes we also ask everyone to accept and draw own conclusions and decisions. We are doing the same also as we want to preserve a colourful landscape of free and libre software, where Hyperbola has the same place and rights as every other project oriented on free, libre culture and software. But we just also want to remember everyone: Free and libre culture has a meaning, principles and values! Giving those away or ignore them, treats neither users fair nor the near future for free, libre software better.

So the more we reject to take responsibility for our systems running, the more others will fill out this empty position and then take on power to command us instead we command the operating-systems. You have not to agree on that, dear readers. But without any doubts the results speak clear we have already now alike shown in this article.

This wiki article would have not been possible without the help and support of community-members. So thank you towards people trying out several ways for compiling Rust, communicating with the project and opening issues for reporting the critical points. This is the result of many people's work!