In the past I have downloaded kernel modules & SDKs for Linux, which were partially open (i.e. had binaries, compiled libraries, etc. alongside open parts), and they were intentionally compiled for highly specific environments, tying the modules or SDKs to (archaic) OS releases which are very hard to obtain, or cannot be obtained from anyone except the hardware vendor.
We wanted to use these thing in newer systems, but it was not always possible, and made our lives way harder than it should be. At the end of the day, you buy vendor's hardware and want to couple it with more modern software, but the vendor doesn't want this for some unknown reason. Planned obsolescence, maybe.
Now, consider that a company pulls the same shenanigans, but by moving the magic to the compiler. All source is open, but can't be compiled because, while the code valid, its correct compilation needs a specific compiler behavior, and the vendor who opened the source cannot share the compiler in source form due to "trade secrets". They may require you to send the code in to "make sure that it's fine", or "sign an agreement" to get the compiler, for a fee, maybe.
I don't want to live in this world, or leave anyone accidentally in that state.
> Many Rust people don't want to live in the C/C++ compiler world, because they don't have to. "Oops this code won't build with GCC" is a battle they'd just as soon avoid.
As someone else noted, gccrs people say that "We strive for rustc compatibility. We will not extend or mangle the language, and consider rustc as our test suite." This is a pretty strong commitment to "many implementations, single behavior" promise.
I started my computing journey in a very open and flexible ecosystem, and with every stopgap put as in the name of security, this openness and flexibility eroded step by step. With this pace, programming and development will be confined to corporations which design the hardware and OS running on them, and PCs will be consoles with keyboards.
I don't want to live in such future. This is why FSF/GPL is important, for me.
We wanted to use these thing in newer systems, but it was not always possible, and made our lives way harder than it should be. At the end of the day, you buy vendor's hardware and want to couple it with more modern software, but the vendor doesn't want this for some unknown reason. Planned obsolescence, maybe.
Now, consider that a company pulls the same shenanigans, but by moving the magic to the compiler. All source is open, but can't be compiled because, while the code valid, its correct compilation needs a specific compiler behavior, and the vendor who opened the source cannot share the compiler in source form due to "trade secrets". They may require you to send the code in to "make sure that it's fine", or "sign an agreement" to get the compiler, for a fee, maybe.
I don't want to live in this world, or leave anyone accidentally in that state.
> Many Rust people don't want to live in the C/C++ compiler world, because they don't have to. "Oops this code won't build with GCC" is a battle they'd just as soon avoid.
As someone else noted, gccrs people say that "We strive for rustc compatibility. We will not extend or mangle the language, and consider rustc as our test suite." This is a pretty strong commitment to "many implementations, single behavior" promise.
I started my computing journey in a very open and flexible ecosystem, and with every stopgap put as in the name of security, this openness and flexibility eroded step by step. With this pace, programming and development will be confined to corporations which design the hardware and OS running on them, and PCs will be consoles with keyboards.
I don't want to live in such future. This is why FSF/GPL is important, for me.