The history section of the repo clears it up [0]

> LibreSprite originated as a fork of Aseprite, developed by David Capello. Aseprite used to be distributed under the GNU General Public License version 2, but was moved to a proprietary license on August 26th, 2016.

> This fork was made on the last commit covered by the GPL version 2 license, and is now developed independently of Aseprite.

Also I am not really sure if you can convince me that this is a open source license: https://github.com/aseprite/aseprite/blob/main/EULA.txt

Not that it is a unreasonable license, but it is not open source.

[0]: https://github.com/LibreSprite/LibreSprite?tab=readme-ov-fil...

Same old story, too much support requests and bad actors making it hard to make money off opensource.

This is one case where we really should support the original product, you can buy a perpetual licence of a pittance and they just 2 guys chugging along.

LibreSprite has 5000 commits, 30 in the past year whilst ASEPrite has over 10000 at this point.

The person you're replying to was making a clarification on the license, not arguing about the validity of changing the license or charging for it.

Libresprite is an important project because people can fork it and learn from it by extending it, and submit those patches upstream, regardless of how active it is.

I think aseprite is a perfectly fine project, but where possible, I like to use open source tools rather than proprietary tools.

I have paid for Aseprite, but on many machines I just install the old GPL version, usually available as a package. It is fine for most tasks, even if the latest version has many improvements.

A fork of the old version to have a slightly better version conveniently available in package repos would be nice. I don't think it has to catch up with Aseprite to be useful.

It's good to have open source software.

It's good to support honest and high quality proprietary software.

Aseprite offers the latter good, this offers the former good.

Another one just popped up recently though it does not have a lot of coverage if anywhere yet: https://corporate.e-boks.com/loesninger/e-wallet/e-boks-id/

Well they provide that if you want. they have both a OTP dongle, a OTP loud speaker and one that uses FIDO U2F (though you need to pay for that one).

https://www.mitid.dk/en-gb/get-started-with-mitid/how-to-use...

It is actually at least two agencies that is working in that direction, The Danish Road Authorities is also working on it: https://www.fstyr.dk/nyheder/2025/dec/faerdselsstyrelsen-tag...

Well the last annual report I could find actually says that they got a return of 17.65% so 3% would be pretty bad

https://wikimediaendowment.org/annualreports/2023-2024-annua...

There is a couple libc implementations:

- c-ward [0] a libc implementation in Rust

- relibc [1] a libc implementation in Rust mainly for use in the Redox os (but works with linux as well)

- rustix [2] safe bindings to posix apis without using C

[0]: https://github.com/sunfishcode/c-ward

[1]: https://gitlab.redox-os.org/redox-os/relibc/

[2]: https://github.com/bytecodealliance/rustix

realy cool thank you

xAI bought Twitter a bit under a year ago: https://www.bbc.com/news/articles/ceqjq11202ro

Wait, does this mean Space-X owns Twitter/X now?

tbh I don't think that really counts when it is a tool made by the sqlite developer.

tbh I think it is just a question about time before flask guy has something to sell: https://earendil.com/

I can't for the life of me tell what it's about.

A quick unscientific count on cve.org counts ~86 race condition CVEs in the Linux kernel last year, so you might be overstating how well bug antennas work.

If the kernel was completely written in Rust, we could have a lot of unsafe places, and many Rust CVEs. It is hard to tell, and the comparison in theory should be made after the kernel is developed only by people lacking the C experience that made the current developers so able to reason about race conditions (also when they write Rust).

That's quite the double standard. You extrapolate from one single Rust bug, but insist that "it's hard to tell" and you need completely unrealistic levels of empirical evidence to draw conclusions from the reported C bugs...

Reminds me of this classic: "Beware Isolated Demands For Rigor" (https://slatestarcodex.com/2014/08/14/beware-isolated-demand...)

It's 1 compared to 86, 86 is the baseline.

But you need to control for lines of code at the very least — otherwise you're comparing apples to oranges

Yeah I mean I could also say "there are no CVEs written in PERL in the kernel ergo PERL is safer to write than Rust". Given there's close to zero .pl files in the kernel, I think we can all agree my assertion holds

That claim relies on an absurd "in the kernel" qualifier, making it difficult to agree with. Furthermore, your hypothesis is that "we all" agree with claims that rely on absurd conditions as a matter of course.

That is no base line. That is a comparison with no statistical value.

Tbh I thought that was clear when I used the phrase "unscientific".