7 ms·

The goal of modernizing coreutils is great, and doing it in rust is even better. However, it makes me very sad that this is licensed under the MIT licence. Bei

• vfsignal 6y ago
  Agreed. It would also be good of this Rust project to state that all of the utils are original works and no one has peeked at the C sources. Perhaps the maintainers of the C versions should do the same in reverse.
  • moocowtruck 6y ago
    https://github.com/uutils/coreutils/search?q=gnu https://github.com/uutils/coreutils/search?q=gnu "This is the way it was implemented in GNU split." i dunno maybe there are cases where they copy more than behavior... but interesting to look through
    • okl 6y ago
      There are more examples, here is one: // a few global constants as used in the GNU implementation
    • danudey 6y ago
      It's pretty easy to ask someone "Hey, can you go take a look at GNU split and see how they handle this case?" and then implement your own clean-room solution afterwards. Alternately, to solve the problem yourself and mention it to someone and have them say "that's how GNU split does it, so why not?"
      • eximius 6y ago
        Isn't that, by definition, not a clean-room solution?
        • moonchild 6y ago
          ‘Clean-room reverse engineering’ refers to the practice of having one person look at disassembled source code, spec sheets, actual behaviour, etc. of some program; describe that behaviour to a second person; and having the second person implement the described behaviour. https://en.wikipedia.org/wiki/Chinese_wall#Reverse_engineering https://en.wikipedia.org/wiki/Chinese_wall#Reverse_engineeri...
          • eximius 6y ago
            Ah, that's interesting! I didn't know that was a sufficient insulation of IP.
            • moocowtruck 6y ago
              yea seems pretty easy then right, sounds like no source that is available for eyes to see is safe from 'clean room reverse engineering'
  • amenod 6y ago
    > Perhaps the maintainers of the C versions should do the same in reverse. Nitpick: they don't need to, they can just attribute the Rust developers if needed. They can also just take MIT code and publish it under GPL (reverse is not true).
    • flangert 6y ago
      Taking MIT code and re-licensing it under the GPL will cause a huge uproar: http://undeadly.org/cgi?action=article&sid=20070913014315 http://undeadly.org/cgi?action=article&sid=20070913014315 I'm not sure that is even legal.
      • ben_bai 6y ago
        It's doable if you can get OK from every single copyright owner of the source files. LLVM did it. Switching from "University of Illinois/NCSA" to "APL 2.0". But not without some big discussions.
      • amenod 6y ago
        I didn't mean re-licensing it - the parts that are under MIT stay under MIT, but the patches on it have a different license. That is completely legal and license doesn't forbid this. (ianal, yadda yadda...) A similar thing happened to OpenOffice / LibreOffice: [0] > OpenOffice uses the Apache License, whereas LibreOffice uses a dual LGPLv3/Mozilla Public license. > For some legal reasons, then, anything OpenOffice does can be incorporated into LibreOffice, the terms of the license permit that. But if LibreOffice adds something, take font embedding, for example, OpenOffice can’t legally incorporate that code. [0] https://hackaday.com/2020/11/02/openoffice-or-libreoffice-a-star-is-torn/ https://hackaday.com/2020/11/02/openoffice-or-libreoffice-a-...
• coldtea 6y ago
  >Being licensed under the GPL is an essential part of the GNU project and their philosophy. Having "won the desktop from Windows" and "finished a next-gen OS (Hurd)" was also part of that plan, but it didn't really pan out, did it? I'm glad for MIT software since I can use it in more places I can use GPL (which companies often wont touch, in it's later license version).
  • AlchemistCamp 6y ago
    Do the places you work forbid the use of Linux or the GNU Coreutils? In what context are you using Rust Coreutils? Windows? MacOS? BSD?
    • coldtea 6y ago
      >Do the places you work forbid the use of Linux or the GNU Coreutils? They allow them. I had cases where clients forbade some GPL code (banks, etc) - worse with GPL3.
      • wizzwizz4 6y ago
        They'll stop doing that if most code is GPLv3. If most code is GPLv3, we're all better off – but while people are still prepared to work around GPL-rejecting companies, those companies can still reject the GPL. It's the tragedy of the Commons.
        • ben_bai 6y ago
          The GPL license usage is falling, and even Linux is GPLv2 and rejects GPLv3. Some Linux code is dual licenses GPLv2 and MIT. ApacheV2, MPL, MIT, ISC and BSD licenses are gaining in popularity.
        • Master_Odin 6y ago
          Alternatively, if more OSS was GPLv3, we might see companies more default to recreating the software in house and nobody really wins.
        • 6y ago
• robocat 6y ago
  Your argument seems to imply that GNU was the progenitor of the utilities. A quick sample of the first 10 utilities from the first column of http://maizure.org/projects/decoded-gnu-coreutils/ http://maizure.org/projects/decoded-gnu-coreutils/ on my machine showed 80% of the utilities were copied from existing sh utilities. Sure, GNU has added features, but there is nothing unseemly about creating new utilities using a different licence that are largely compatible - that is exactly how GNU coreutils came to life in the 90s. arch - GNU chgrp - Descended from chgrp introduced in Version 6 UNIX (1975) comm - Descended from comm in Version 2 UNIX (1972) dd - Descended from dd introduced in Version 5 UNIX (1974) du - Descended from du introduced in Version 1 UNIX (1971) factor - Descended from sort in Version 4 UNIX (1973) head - Descended from head included in System V (1985) join - Descended from join introduced in Version 7 UNIX (1979) ls - Spiritually linked with LISTF from CTSS (1963) mktemp - GNU
  • anamexis 6y ago
    Where does their argument imply that GNU was the progenitor of those utilites?
    • augusto-moura 6y ago
      I think he/she commented on the wrong parent comment, it makes a lot more sense about the current top comment
• mouldysammich 6y ago
  Yeah I really agree here. Especially when it comes to coreutil implementations. I've seen multiple implemented under MIT/BSD and it always makes me a little sad. I have access to an incredibly high quality easy to use router firmware in the form of OpenWrt by virtue of GPLd coreutils. I wish FOSS developers weren't so afraid of it these days
• JulianMorrison 6y ago
  In the case of coreutils, there is really no issue with presence or absence of GPL. cp is just cp and nobody is going to hang a proprietary extension off the side.
• eeZah7Ux 6y ago
  > it could be preferable not to rewrite parts of it under weaker licences that go directly against their mission +1. It's very sad to see user freedom being thrown away as a goal and replaced by software that becomes unpaid labor for FAANGs. Especially since the SaaS takeover.
  • imhoguy 6y ago
    GPL does not protect against SaaS provider creating derivative as there is no further distribution of binary or source code. Only AGPL (and other more strict licenses) addresses SaaS derivatives issue.
• gregwebs 6y ago
  Richard Stalman and others that believe the GPL is generally the best license are not against ever using the MIT license. Stalman has been willing to be pragmatic and support tactical choices of other licenses besides GPL when licensing. So it is worth having some deeper thoughts about what the implications are for different licenses of coreutils. When does using coreutils create a derivative work that requires GPL?
  • mrob 6y ago
    Tactical considerations exist, but even so, a copyleft license might have better long term results in promoting software Freedom. The FSF supported a non-copyleft license for Ogg Vorbis, because at the time it seemed reasonable that this was the best way to fight the (at the time) patent-encumbered MP3 format. But in practice it had little benefit: "However, we must recognize that this strategy did not succeed for Ogg Vorbis. Even after changing the copyright license to permit easy inclusion of that library code in proprietary applications, proprietary developers generally did not include it. The sacrifice made in the choice of license ultimately won us little."[0] [0] https://www.gnu.org/licenses/license-recommendations.html https://www.gnu.org/licenses/license-recommendations.html
    • moonchild 6y ago
      I don't know when that was written, but vorbis is used pervasively today, including in proprietary applications.
• oehtXRwMkIs 6y ago
  I think this is more of a reflection of mainstream OSS culture in general. Rust development currently is heavily tied to proprietary services (e.g. GitHub required for contributions, issues, crates.io login, CI, etc., Discord and Slack communities rather than Matrix, Zulip) and likes to license things under MIT. I think the lack of awareness/care for the big picture of fighting for software freedom is simply not there just as it is missing from mainstream OSS culture. Because convenience and network effect are king.
  • pdimitar 6y ago
    You do have a point but in case you are saddened by this phenomena, let me just point out that we live in a VERY different age compared to when GNU coreutils were born. Nowadays you only get a few minutes -- or hours if you are lucky -- to answer a ton of fundamental questions like "where do we host code?" and "how do we communicate on this project?" or "how do we do CI/CD?" etc. The people in the past had all the time in the world to tinker and invent. Maybe I am mistaken though, past is usually looked through rose-tinted glasses right? But the fact remains: nowadays answering the above questions is beyond my pay grade: in fact it's beyond anyone's pay grade. Services like GitHub are deemed a commodity and questioning that status quo is a career danger. I really do wish we start over on most of the items you enumerated. But I am not paid to do it. In fact I am paid to quickly select tools and never invent any -- except when they solve a pressing business need and are specific enough for the organization; in that case it's not only okay but a requirement. Beyond anything else however, we practically have no choice. If I don't host a new company project on GitHub I'll eventually be fired and replaced with somebody who will.
    • HDMI_Cable 6y ago
      I would also onto your point and say that one reason why Rust is easy to get into is because of the convenience that these semi-proprietary platforms provide. We here on HN have both the time and ability to set up things like CLI Git, and Matrix. But for a new language, forcing people onto esoteric (& superior) platforms makes them less likely to use them. It would be nice if Matrix and self-hosted Git were the default, but when acquiring users/programmers is your goal, Rust doesn't have that luxury.
• stjohnswarts 6y ago
  I think people should be able to license under whatever they choose to license under. Diversity is good for the most part.