@dthompson @catonano @pho4cexa I don't think it's a problem that languages have their own language-specific infrastructure, in fact I think it's a good thing, as long as it's made to cooperate well with distribution infrastructure. I have a long, half-unwritten post about this that will probably become an #HPRep .
If the GCC library, which ends up in basically any code compiled by GCC, were plain GPL, all code produced by GCC would have to comply with the GPL because it would be derivative of the library.
Before GCC 4.2.2, there was a blanket exception that the GPL did not apply to the code that included the library as a result of GCC compiling it. Not literally the LGPL, but functionally similar (and older).
By 4.2.2 GCC switched to the GPLv3 and also took the chance to update the license clause. The lack of a plugin infrastructure had long been evident and yes, that was because people (rightly, see LLVM) worried that plugins might be proprietary.
The solution was to leverage the library exception to demand that to be eligible for the license exception, the process producing a binary that included the library would have to be all GPL-compatible.
@dthompson @catonano @pho4cexa I stopped writing it specifically because I was going to say something about the interaction between Rust/Cargo and Nix, and I realized I didn't know enough about that and had to read up. Short story: Actually apparently #carnix seems to work pretty decent (but isn't used to package anything but carnix itself in nix -- the other package use the flattened Rust builder), even though the nix definition are pretty human-unfriendly and convoluted. Cargo is out of the picture at Nix time (I think!) and it just runs rustc.
@dtluna @pho4cexa Yes, because what they want might be to take away your property rights for software-containing devices you bought, and threaten you with government thugs if you try to find out how your property functions.