GNU social JP
  • FAQ
  • Login
GNU social JPは日本のGNU socialサーバーです。
Usage/ToS/admin/test/Pleroma FE
  • Public

    • Public
    • Network
    • Groups
    • Featured
    • Popular
    • People

Conversation

Notices

  1. Embed this notice
    Dr. Quadragon ❌ (drq@mastodon.ml)'s status on Thursday, 08-Aug-2024 13:40:06 JST Dr. Quadragon ❌ Dr. Quadragon ❌

    A nice compact explanation for permissive vs. copyleft licensing I found:

    Both models provide freedom and protection at the expense of the developer;
    Permissive model provides more freedom and protection for your *immediate downstream user* at the expense of the end user;
    Copyleft model provides more freedom and protection for your *end user* at the expense of the intermediate users.

    It's pretty context-dependent which way you wanna go, but personally, in a toss-up, I'm gonna side with the end user. Because that's what actually matters in the end: the ability to actually use the software freely.

    At the end of the day, if I have to use a proprietary, locked-down system that spies on me, doesn't let me modify it, or even look at its insides, and generally treats me, the user, like crap, it doesn't make a nick of difference to me that it has a BSD kernel inside, or MIT-licensed coreutils, right?

    In conversation Thursday, 08-Aug-2024 13:40:06 JST from mastodon.ml permalink

    Attachments

    1. No result found on File_thumbnail lookup.
      users.it

    • Haelwenn /элвэн/ :triskell: likes this.
    • Embed this notice
      Dr. Quadragon ❌ (drq@mastodon.ml)'s status on Thursday, 08-Aug-2024 13:41:57 JST Dr. Quadragon ❌ Dr. Quadragon ❌
      in reply to

      There's an argument that permissive licenses offer more freedom.

      And to that, I say - yes. If you subscribe to the naïve, individualistic definition of freedom, where everything is permitted, without restrictions.

      And in the ideal world, maybe that's where the story ends. But we don't live in that world. No man is an island, and if you allow anyone to do anything unrestricted, that means you permit somebody to take someone's freedom away using force. And eventually you end up with a very unfree world.

      How do you combat this? Well, with solidarity, of course. There needs to be a concerted effort to protect freedom from those who tend towards smashing it to pieces. That means, some boundaries must be set up. People who respect freedom must stand together and declare that freedom and non-freedom don't mix.

      You know how the corpo kind tends to say that GPL "viral" and compares Free Software movement to Borg? Well, that shows what they fear the most. Copyleft represents this solidarity.

      In conversation Thursday, 08-Aug-2024 13:41:57 JST permalink
      Haelwenn /элвэн/ :triskell: likes this.
    • Embed this notice
      Dr. Quadragon ❌ (drq@mastodon.ml)'s status on Thursday, 08-Aug-2024 13:41:59 JST Dr. Quadragon ❌ Dr. Quadragon ❌
      in reply to

      We already have GCC basically obsoleted by LLVM (which, again, is great - but it's also permissive, it was made by corpos); GlibC still holds, but I doubt it's for too long, as Musl is coming along nicely, and the Linux kernel we pretty much lost to tivoization. What remains of the GNU project, then?

      I mean, I'm in no position to tell the author what to do, he can do whatever the hell he wants to, but it's still sad to see that sweet free software protection for the base OS to slowly erode and fade to irrelevance like this.

      Again: it doesn't make a difference to me, the user, if, say, the new Windows effectively becomes a *nix system and adopts those while staying just as proprietary. (it still would be better than what they have right now, by a mile, but merely technically)

      And what I always liked about the Free Software movement, is that it turns the power dynamic of the copyright law on its head, therefore making an actual, tangible, political difference. Which is what I'm after.

      In conversation Thursday, 08-Aug-2024 13:41:59 JST permalink
    • Embed this notice
      Dr. Quadragon ❌ (drq@mastodon.ml)'s status on Thursday, 08-Aug-2024 13:42:00 JST Dr. Quadragon ❌ Dr. Quadragon ❌
      in reply to

      Why have I brought this up at all?

      Well,

      https://github.com/uutils/coreutils

      It's a nice project, I quite like it. But the license choice kinda irks me.

      The author states that its goal is not to fight the GNU project. While that might not be the intention, in my opinion, this is actually one third of the way to the EEE scenario.

      MIT license means it's easy for corporations who choose to make proprietary software to adopt it for their projects. So the "Embrace" step is basically done, voluntarily.

      The next step is to Extend it, to make it on par or better than GNU Coreutils. Which has not been achieved yet, but this is the goal.

      If this has the potential to be better than GNU coreutils (and it does, being written in a more modern language, and by that virtue having more potential for modernization), then why use GNU coreutils at all? That will be the Extinguish part.

      In conversation Thursday, 08-Aug-2024 13:42:00 JST permalink
    • Embed this notice
      Dr. Quadragon ❌ (drq@mastodon.ml)'s status on Thursday, 08-Aug-2024 13:42:52 JST Dr. Quadragon ❌ Dr. Quadragon ❌
      in reply to

      What I fear the most is that, by washing out copyleft licensing in favour of permissive licensing, the movement basically gets atomized. We revert to that naïve individualism which is yes - highly seductive, but it's what's eventually going to be our collective undoing. Because we don't have that end-user protection anymore. We don't have a competitive edge over the non-freedom, we basically brought everything on the silver platter to people who don't subscribe to any definition of freedom in software at all, and couldn't care less about free usage, study, distribution or modification of software, it's just not in their interest.

      An incredibly grim picture. I hope I am overrreacting.

      In conversation Thursday, 08-Aug-2024 13:42:52 JST permalink

      Attachments


      Haelwenn /элвэн/ :triskell: likes this.
    • Embed this notice
      Haelwenn /элвэн/ :triskell: (lanodan@queer.hacktivis.me)'s status on Thursday, 08-Aug-2024 14:03:03 JST Haelwenn /элвэн/ :triskell: Haelwenn /элвэн/ :triskell:
      in reply to
      @drq Ooof even uses the coreutils testsuite as reference.

      That said it makes me wonder if uutils could have used a *GPL license, like strangely coreutils has been linking to OpenSSL since ~2013 starting with *sum utilities[1] while and OpenSSL prior to 3.x isn't GPL-compatible[2] (and so LibreSSL and BoringSSL also aren't IIRC the latter's code is used in rustls, woups).
      And those kind of shenanigans is why I tend to default to a file-copyleft license like the MPL-2, because when you actually do a license review the "viral"-copyleft quite often ends up non-binary redistributable.

      1: https://git.savannah.gnu.org/cgit/coreutils.git/commit/configure.ac?id=b53b0fd940382497e58a9e912f1262c2084fe534
      2: https://www.gnu.org/licenses/license-list.html#OpenSSL
      In conversation Thursday, 08-Aug-2024 14:03:03 JST permalink

      Attachments

      1. Domain not in remote thumbnail source whitelist: git.savannah.gnu.org
        coreutils.git - GNU coreutils
      2. No result found on File_thumbnail lookup.
        Various Licenses and Comments about Them - GNU Project - Free Software Foundation
        from mailto:webmasters@gnu.org
    • Embed this notice
      Haelwenn /элвэн/ :triskell: (lanodan@queer.hacktivis.me)'s status on Thursday, 08-Aug-2024 14:41:31 JST Haelwenn /элвэн/ :triskell: Haelwenn /элвэн/ :triskell:
      in reply to
      • Haelwenn /элвэн/ :triskell:

      @drq Also wondered about the size of it as Rust means static linking and… yeah even with explicitly aiming for coreutils compatibility, you get a pretty small install size.
      - https://archlinux.org/packages/extra/x86_64/uutils-coreutils/ ~10MB
      - https://archlinux.org/packages/core/x86_64/coreutils/ ~15MB
      - https://pkgs.alpinelinux.org/package/edge/community/x86_64/uutils-coreutils ~4MB
      - https://pkgs.alpinelinux.org/package/edge/main/x86_64/coreutils ~1MB (multicall saves a lot, GNU should really end up making gnulib an actual library)

      For reference here the install size of coreutils on gentoo-musl:
      - USE="multicall nls xattr -*" ⇒ 6.20MiB
      - USE="multicall nls static xattr -*" ⇒ 7.35MiB
      - USE="nls static xattr -*" ⇒ 56.41MiB
      - USE="nls xattr -*" ⇒ 25.36MiB

      In conversation Thursday, 08-Aug-2024 14:41:31 JST permalink

      Attachments

      1. No result found on File_thumbnail lookup.
        Arch Linux - uutils-coreutils 0.0.27-1 (x86_64)
      2. No result found on File_thumbnail lookup.
        Arch Linux - coreutils 9.5-1 (x86_64)
      3. No result found on File_thumbnail lookup.
        Alpine Linux packages
      4. No result found on File_thumbnail lookup.
        Alpine Linux packages
    • Embed this notice
      Haelwenn /элвэн/ :triskell: (lanodan@queer.hacktivis.me)'s status on Thursday, 08-Aug-2024 15:14:38 JST Haelwenn /элвэн/ :triskell: Haelwenn /элвэн/ :triskell:
      in reply to
      • :umu: :umu:
      @a1ba @drq Implementing crypto doesn't seems that dangerous, specially for hashes where so far I've just seen pure math without logic beyond a for-loop with a typically static number of rounds.
      So the test vectors you get are probably enough.

      And like it's utilities so if somehow they fucked around and managed memory corruption, there's process isolation.

      Like the types of failures in cryptographic libraries are more:
      - Failed to protect users' sensitive data or keys, typically either massive fails at memory safety like heartbleed (don't do a malloc without safety mechanisms) or failing at constant-time
      - Failed at certificates verification, typically logic error but using wrong functions appends pretty often as well. Like don't use str*cmp to compare length-prefix strings, or even memcmp, loop strictly over the length, no breaks.
      In conversation Thursday, 08-Aug-2024 15:14:38 JST permalink
    • Embed this notice
      :umu: :umu: (a1ba@suya.place)'s status on Thursday, 08-Aug-2024 15:14:39 JST :umu: :umu: :umu: :umu:
      in reply to
      • Haelwenn /элвэн/ :triskell:
      @lanodan @drq why they had to link with openssl for hashing.

      I understand the reason why one shouldn't implement their own cryptography, but hashes are... simple enough
      In conversation Thursday, 08-Aug-2024 15:14:39 JST permalink

Feeds

  • Activity Streams
  • RSS 2.0
  • Atom
  • Help
  • About
  • FAQ
  • TOS
  • Privacy
  • Source
  • Version
  • Contact

GNU social JP is a social network, courtesy of GNU social JP管理人. It runs on GNU social, version 2.0.2-dev, available under the GNU Affero General Public License.

Creative Commons Attribution 3.0 All GNU social JP content and data are available under the Creative Commons Attribution 3.0 license.