4 ms·
> Apache-2.0+MIT vs GPL-2.0 So, you may get a memory-safe su/sudo-rs, but those who distribute it in a binary form won't be obliged to show you the source code
by fdsfsdfdsffgg 3y ago
> Apache-2.0+MIT vs GPL-2.0
So, you may get a memory-safe su/sudo-rs, but those who distribute it in a binary form won't be obliged to show you the source code it was built from (potentially including some modifications).
- zigzag312 3y agoIs that really bad? You are free to not use such distributions. Regarding security, malicious actor could show you a different source code from what he distributes in a binary form. GPL or no GPL.
- EspressoGPT 3y ago> Is that really bad? You are free to not use such distributions. It's not really bad but it kinda defeats the purpose.
- pbmonster 3y ago> Regarding security, malicious actor could show you a different source code from what he distributes in a binary form. That's why hashes are published by distributors and checked by package managers, right?
- zigzag312 3y agoThat only checks that binaries are the same as what is published by distributors. It doesn't help against a malicious distributor, unless package managers also do a deterministic build themselves and verify that checksum from self-build binary matches the checksum published by a distributor.
- pbmonster 3y agoIf I'm not mistaken, many (most?) of the package managers of major Linux distributions actually build a package from source themselves in an automated process. Otherwise, getting a package to run on different architectures would be a ton of manual labor. At least Debian certainly has that automated. Besides the huge security risk involved in... just distributing random binaries?
- zigzag312 3y agoAnyone building from source has the ability to potentially including some modifications. Unless you are able to verify that checksum published (by whoever builds the code) "matches" the source code (by reproducing the build) you cannot be sure there aren't any modifications. Published checksums are often meant only for verifying that binary you got matches the original binary. Not for verifying that it is build from specific source code. Many Debian packages already have reproducible builds, but not everything. From Debian wiki: > Reproducible builds of Debian as a whole is still not a reality, though individual reproducible builds of packages are possible and being done. So while we are making very good progress, it is a stretch to say that Debian is reproducible. https://wiki.debian.org/ReproducibleBuilds https://wiki.debian.org/ReproducibleBuilds But the point is that this has nothing to do with the type of an open source license. GPL doesn't guarantee you that a build is reproducible and MIT doesn't prevent you from having reproducible builds.
- wiz21c 3y agoMoving away from the GPL is a very bad idea for such critical component. Exactly for the reason you give. (this post is just here to insist on the issue)
- mhh__ 3y agoIn general a lot of "[GNU tool] but in rust" projects do seem to come very close to violating the GPL, especially in spirit.
- tsimionescu 3y agoIn what sense? It is completely in the spirit of the GPL to reimplement a GPL tool from scratch with the same behavior and a different license. After all, that's how the free Unixes came about (though admittedly those were BSD licensed typically).
- zorked 3y agoKinda? Historically there were indeed concerns about reimplementation and copyright. One of the ways that the GNU Project tried to fight claims was to reimplement the tools using dynamically-allocated memory (instead of Unix's traditional fixed-size buffers) to make sure the implementation was sufficiently different. Other ways were making the implementation Posixly correct, adding internationalization or trying to pick different approaches (like using more modern algorithms for sorting). The GNU tools were better, not just direct ports, and that's why it was common to install them in systems like Solaris or HP-UX.
- iudqnolq 3y agoArguably writing in Rust will force a similar magnitude difference to those examples. For example, you'll probably replace that modern sorting algorithm with a call to .sort
- mustache_kimono 3y ago> Kinda? Historically there were indeed concerns about reimplementation and copyright. Free software projects should welcome multiple implementations and interoperability, because these are the mother's milk of free software. It's frankly incoherent, given values of free software, that a reimplementation of, for example, Unix coreutils (GNU) would find fault with a reimplementation of itself (uutils). Notwithstanding how philosophically incoherent it is, a desire, now that Linux and free software have some market power, to be a bully back, to grasp for monopoly power, to play AT&T, is really distasteful. What's exciting about free software is not the artifact, Linux or coreutils or sudo, but that anyone can create new and interesting alternatives. That users get to make choices about which implementation to use. The existence of FreeBSD does not make Linux worse. It makes it better! The "solution" to an MIT licensed coreutils is a GNU licensed fork which is 10x better. Instead, we get complaints which amount to a kind of free software entitlement, an endless pissing and moaning about how other people won't do new things your way. This is a major problem in the way that most normies view the GNU and the GPL. In the past, I may not have chosen the GPL for my own projects, but I'd be pleased to contribute to a GPL project. Now, I'd have a hard contributing to a GPL project, because of just how toxic this attitude (no other license matters but ours) is.
- Nullabillity 3y agoSudo is ISC-ish[0] (very permissive), not GPL. Su does indeed seem to be GPL though. [0]: https://www.sudo.ws/about/license/ https://www.sudo.ws/about/license/
- fdsfsdfdsffgg 3y agoThere are su and runuser in util-linux (GPL-2.0) [1]. [1]: https://github.com/util-linux/util-linux/tree/master/login-utils https://github.com/util-linux/util-linux/tree/master/login-u...
- ksherlock 3y agoThe GNU ~~coreutils~~ util-linux version of su would be GPL but su is from Unix V1 (1971) so there are AT&T implementations, BSD implementiations, etc.
- alwayslikethis 3y agoI wanted to write this comment too, as I have a serious concern that the effort to displace GPL tools with Rust rewrites in MIT/Apache will one day lead to a proprietary Linux, but the original sudo is not in GPL. It's in an ISC/MIT style license [1]. 1. https://www.sudo.ws/about/license/ https://www.sudo.ws/about/license/
- fdsfsdfdsffgg 3y agoThere are su and runuser in util-linux (GPL-2.0) [1]. [1]: https://github.com/util-linux/util-linux/tree/master/login-utils https://github.com/util-linux/util-linux/tree/master/login-u...
- pjmlp 3y agoLook at Android, the only GPL thing left is exactly the Linux kernel, and it hasn't been yet replaced by Zirkon because reasons. Look at the FOSS UNIX like RTOS, none of them is GPL.
- pjmlp 3y agoFor better or worse the use of GPL is going away, even the future of Linux kernel is not guaranteed. In the realm of IoT FOSS UNIX like operating systems, all the contendants are using a mix of Apache, MIT and BSD licenses, including the ZephyrOS sponsored by the Linux Foundation. When the GPL generation is gone from the face of the Earth, it won't last long that UNIX-like OSes get another steward alternative to the Linux kernel, with a more appealing license to big corps.
- NegativeK 3y agoHow would they be able to drop the GPL from the Linux kernel?
- rahen 3y ago> it won't last long that UNIX-like OSes get another steward alternative to the Linux kernel, with a more appealing license to big corps. You mean {Free,Net,Open}BSD?
- pjmlp 3y agoWhile those are the first ones would think of, they are not the only alternatives, specially in the embedded space.