You are not logged in. Please login or register.
We are very pleased and happy to announce the newest release of Hyperbola GNU/Linux-libre with v0.4.4.
See our official news for further details.
HyperForum → General → Rust's new much stricter trademark
strict principles of hyperbola paid off. hopefully enough people realize how bad this trademark is and either fork rust and remove its branding and that becomes adopted in gnu/linux or they put enough pressure on mozilla to make trademark non freedom restricting
@Librecat
I agree on put pressure on mozilla part. I think there will be a shift sooner or later, by people who think mozilla is being arrogant by trying to have such unreasonable standards.
I think one of two things will happen, one rust becomes fully proprietary and people in the open source world get sick of their bs.
The second one, is that they are forced to make compliance easy without any huge issues or better yet just get rid of their dumb trademark bs altogether by making their trademark license less restrictive to where it is a python like setup.
Maybe a link: https://blog.rust-lang.org/inside-rust/ … dback.html
The Rust Foundation appears to have the same problems as the Linux Foundation and those are way bigger than trademarks:
https://foundation.rust-lang.org/members/
Rust is a bad thing for the same reason as .NET / mono as it puts the FOSS developer and by extension users, entirely at the mercy / subject to the agenda of "Big Tech" / FAAGS corporations.
This kind of open washed "Open Source" is not free software. It is first and foremost a business.
There's always the ADA implementation with GNAT (gcc-ada in packages) for memory safety.
There's always the ADA implementation with GNAT (gcc-ada in packages) for memory safety.
thanks for that suggestion
@blackhole Ironic, given that OpenBSD is one of the leanest operating systems in modern times that is still functional and at the same time they heavily support open source and yet... some libre distros utterly reject open source ideals instead choosing to preaching the libre software ideal and they ignore the lessons the BSDs teach which have value.
Ubuntu derivatives for sure, most Arch derivatives too, Definitely most RPM distros and even some Debian derivatives too tend to have bloat.
I am aware OpenBSD isn't a distro btw and that open source is a problematic road in many situations.
The problem being, another problem has spawned that has been largely ignored, which is:
Corporate Libre Software
This adds another annoying dimension and makes it harder to sort out the problems.
Bloat adds vulnerabilities and makes them harder to fix long term, etc... then the rabbit hole just gets larger in such a case.
Btw, in my opinion, unless the open source people are directly aligned with bloating hardware/software, I don't think BSD devs should be enemies of libre devs.
I have not seen any definition like "Corporate Libre Software" and therefore I think also this would lead to a misconception: No company would follow the generic approach of free and libre software as not only the license make something like it. Free, libre software is for sure including open code / source, but "open source" is NOT including free, libre software and its ground reasoning. 
Therefore systems are either free, libre defined or just oriented towards some shady "open-source". But they are not using "corporate libre software". It is correct that those pragmatic perspective is not really helpful and endangering free and libre culture. Ignoring those courses, not running after any of them and just draw a line with good values and principles. Either free, libre software and culture is seen as something worthy - in time, in engagement and also support - or not. If it is drawn into shady definitions - and "open-source" is that for sure - this is no longer free and libre culture. It is just the known "corporate" perspective.
I would also like to see an example of "Corporate Libre Software", not to say that there isn't any, but at the moment I can't think of any examples.
zapper may be referring to software which is licensed under e.g. GPL v2 or v3, but is either partially or entirely corporate backed and/or developed, but I wouldn't term this "libre" software.
Corporations don't necessarily always opt for permissive licensing when developing free code. They may use the GPL licenses for a very specific reason for a certain project, as they want to harness and abuse the viral nature of GPL. In some cases a permissive licence is not just the "best" option for such projects, but it's a necessity, as they would rather "disown" the code and just put it out there, than deal with all the GPL entanglement pitfalls. In certain other cases, using GPL means your competitor(s) can't reuse the code without making all of their changes and additions available under the same license - so licensing GPL makes more sense, than e.g. ISC, MIT or 2 clause BSD, where you're effectively just giving the code away.
In other examples the license becomes almost irrelevant due to the a hideously complex code base, bespoke build system and an overall design which makes portability next to impossible.
Many large projects, such as Android, were designed in such as way that the GPL parts (the kernel some other elements) are deliberately masked from the rest of the OS, by LGPL and permissive licensed code.. If you read the earlier presentations on Android's design, it's all in there.
3 bullet pointed mission objectives for bionic libc and look at the first one:
https://image.slidesharecdn.com/android … 33-638.jpg
https://web.archive.org/web/20160408053 … ndroid.pdf
@blackhole that was what I meant, actually.
But you do raise a good point, because its developed in a sneaky way that is broken by design. So yes, it isn't "libre"
If anything it is, fully open source, which seems to be not good enough in this example, if nothing else.
Even without non-free licenses, annoyances and crap can hit the fan.
As an edit:
This is why at one point I said even if Purism could develop fully libre operating system I still would be shifty of buying their stuff still.
Although when I said that, I meant open source probably.
So yeah... things are rarely as simple as people think them to be.
On secure languages, we have ADA with gcc-ada and partially, ocaml.
If we have some bindings for ADA as gtkada with GNAT and textools, if would be a different alternative to write security compliant software.
The Arch Wiki has a good list and Debian (Hyperbola's package version base?) has a big package list related to ADA.
ADA it's older than Rust and it's an industry standard with SPARK which can use GNAT for the FSF.
I would state that many people look on Rust foremost to get a more modern webbrowser or what is called something like that. Personally I tend to the opposite, because when your webbrowser is able to emulate something like "Windows 95" for example or even start a complete DOS-environment there is something going wrong for sure. We just speak about a software original used to display static sites. What is done today? Playing movies, emulate whole environments and even use some games within. Sorry, but that's the complete wrong direction and calling that "modern" is looking like a joke. Same for "streaming" and more: It is not to forbid something, but just to question what price is needed to manage and execute that. While we are heading towards in a complete different direction with "open-source": It will never hit the point as the word includes not the freedom to learn or do whatever is possible. Everything can be called "open-source" today, when only the source-code is available. But this does not make corresponding projects not per definition "free and libre". It is just a statement about the current state and location of the source-code. Is the resulting application able even to be executed without further parts and data? Is it something different? That's all not included and to use that makes "free and libre software" going down under wrong wording. The action taken now by Rust is just another approval. And even a fork from this desaster won't get more free, even using another license. A broken project stays also broken!
We have too many quick constructed projects with languages like NodeJS and Rust running those days. Maybe they look promising at a point? The aftermath of them is just another dark and sinister story. So compiling Rust without Rust is not possible, even a forked project would need to begin with Rust to be compiled and packaged. All wrong within!
I would state that many people look on Rust foremost to get a more modern webbrowser or what is called something like that. Personally I tend to the opposite, because when your webbrowser is able to emulate something like "Windows 95" for example or even start a complete DOS-environment there is something going wrong for sure. We just speak about a software original used to display static sites. What is done today? Playing movies, emulate whole environments and even use some games within. Sorry, but that's the complete wrong direction and calling that "modern" is looking like a joke. Same for "streaming" and more: It is not to forbid something, but just to question what price is needed to manage and execute that. While we are heading towards in a complete different direction with "open-source": It will never hit the point as the word includes not the freedom to learn or do whatever is possible. Everything can be called "open-source" today, when only the source-code is available. But this does not make corresponding projects not per definition "free and libre". It is just a statement about the current state and location of the source-code. Is the resulting application able even to be executed without further parts and data? Is it something different? That's all not included and to use that makes "free and libre software" going down under wrong wording. The action taken now by Rust is just another approval. And even a fork from this desaster won't get more free, even using another license. A broken project stays also broken!
We have too many quick constructed projects with languages like NodeJS and Rust running those days. Maybe they look promising at a point? The aftermath of them is just another dark and sinister story. So compiling Rust without Rust is not possible, even a forked project would need to begin with Rust to be compiled and packaged. All wrong within!
a fork has happened and there are developers working hard at implementing Rust support in GCC which should help get a unencumbered bootstrap by compiling the fork with GCC and compiling the fork with itself, of course that is just the beginning because even librsvg rust and icecat need source tarballs ending in .crate to build their dependencies so to make rust actually libre a build tool that supports detecting and linking to static rust dependencies installed in the system would also be needed and yes this shows rust is a flawed language
EDIT: fork seems to be called crablang and the rust gcc efforts are named gccrs
EDIT 2 : im not intrested in rust for a new version of icecat im intrested in developing with rust myself
We should see: https://github.com/crablang/crab
As long as there is no stable release possible the project needs time. And GCC-Rust is for sure interesting, but also again: GCC-Go needed a long time and is not even now on pair with GO itself. So it is not easy to build a GO-project with gcc-go, some possible but for sure not all.
I'm for sure interested, but as you have pointed out: GO and Rust has some comparable problems. GO is downloading dependencies at build-time, while Rust is in need for crates to build further. 
But thanks for pointing on crablang - besides that the current project is also referring cargo direct so they would need to go further. Question stays if in the end the Rust-Foundation is all okay with it. Hyperbola is staying there for a reason on our current legacy version of librsvg.
And crablang is then also using non-free platforms for communication, like Discord and Twitter. Their decision for sure. But that's one of the problems: Just to look on convinience within the browser, not to underline that part for anyone here. Just the perspective to watch.
update: crablang made a cargo fork named crabgo
Is Nim also suited as a secure programming language Does it have ethicala nd technological faults making it unsuitabke for free software development?
To be fair, I almost decided to write rust is the systemd of programming languages but then I remember, java and javascript are all equally crappy on bloat and java is a security nightmare... perhaps that's the reason android is almost barely more secure than windows?
[*]
Aka, android is written heavily in java.
[/*]
EDIT: maybe just apps are developed by it... either way, its just absurd to think java is needed for anything modern.
Unless modern means crap.
Which for some software/hardware seems to be completely true.
Please make more differences between Java, JavaScript and others. Same also for Rust! There is a difference between the original idea of the programming language, its semantic work, the compiler being built and than the whole eco-system around it. All of this is different for all mentioned. Sure thing that all of this is most not common "good" but also not all details "bad". It is clear to state that Java and its interpreter has flaws. The original compiler and idea of bytecode is nevertheless interesting. JavaScript as language used on servers and for full applications is a full blown bad idea, having its origins within D-HTML and AJAX meant. Rust with its memory-safety on the one side, on the other side the eco-system around for compilation which is now no longer possible for any difference as "cargo" is needed nevertheless.
So my original meaning here: Don't fall into the trap to be too less into details. There are always details to be looked at and Android being "bad in design" is also a point on which ROM with what applications and services used / installed.
As some may be expecting a response from the FSF, I should note that the FSF has recently said something about this in its news digest (the Free Software Supporter): https://www.fsf.org/free-software-supporter/2023/august
"
### Software freedom & trademarks: Examining Rust's new policy through the lens of free software history
*From July 27 by Denver Gingerich*
This article, recently published by the Software Freedom Conservancy,
examines the programming language Rust's new trademark policy through
the lens of history. Other similar trademark policies in the past such
as Java's, PHP's, and Mozilla's have had consequences for the free
software community. Inform yourself about this relevant and important
topic by examining these case studies, and use this knowledge to
prepare yourself for the inevitable discussions ahead.
* <https://sfconservancy.org/blog/2023/jul … -and-rust/>
"
This is for sure not the helping hand the FSF should grant and it makes me personal very angry reading such ignorance from the FSF. It is like stating the blunt and cheap "Help yourself!". Okay, but how when people have not really the abilities doing so because the field of free and libre software is going smaller by every day counting? That's the opposite of technical emancipation as the system should be in the hands of the users and not the users in the hands of licensing or asking to be allowed doing modifications.
Okay, so the FSF has recognized that there are issues. Fine, they are nevertheless going with the absolute wrong ideas after that. Time for discussions is long over.
BUT: The article here ... https://sfconservancy.org/blog/2023/jul … -and-rust/ ... is helpful as it notifies us to think again about PHP. It is not copyleft so far when looking on it.
Next, consider PHP. Starting in 2000, the PHP authors decided to remove the option to use PHP under the General Public License, beginning with PHP version 4. This left users with only the PHP License as an option, which is non-copyleft, but includes extra restrictions beyond most non-copyleft FOSS licenses. Those restrictions specifically related to use of the PHP name. This policy led to substantial debate within many communities, including Debian. Debian eventually decided to create a special policy for PHP in order to feel comfortable redistributing and modifying PHP, which is memorialized on the FTP Masters' web site. Imagine the time and effort wasted by redistributors like Debian, who had to consider special cases for a specific software program. Ultimately, such licensing makes extra work for distributions like Debian, and creates uncertainty for people wishing to modify PHP — as they navigate a license used nowhere else that awkwardly pulls in a trademark policy as part of it.
So this is another point for a possible very fast and needed removal in the future. Instead of discussing endless: There is work needed as otherwise projects get out of the free and libre spheres. It is not good to build on projects not staying true for free, libre and copyleft licensing as this tower-building is not stable otherwise.
HyperForum → General → Rust's new much stricter trademark
Powered by PunBB, supported by Informer Technologies, Inc.
