LibreSprite – fork of last open-source release of Aseprite pixel art editor

EDIT: The author's post from 2016.09 outlining the background of his decision:

http://dev.aseprite.org/2016/09/01/new-source-code-license/

Super recommended reading!

---------

It's not clear to me if you're aware, but aseprite's author actually had a very interesting approach to monetization already live for some time, AFAIK. Namely, code was GPL, but official Windows binary builds were paid-only. I found it ingenious, though from this change I assume it was deemed not good enough. Curious what were the numbers.

As a side note, the original ASEprite (Allegro Sprite Editor) was what made me first discover the Lua language back in the early 2000s. For which I'm eternally grateful :)

Yeah, that usually happens. However, the sway creator (SirCmpwn) is doing surprisingly well; having received $5,480 for his sway crowdfund[1] and getting over $500 per month in donations if my math is correct.[2] That's not really that much, but it is surprisingly much for a single open source dev. I'm not sure if it's the community or the fact that he works on a bunch of different projects, but given that Krita was able to raise $38,579[3], we should perhaps re-evaluate the preconception that the open source community (in this case the artist community inside the open source community) is opposed to paying. It certainly used to be true, but I'm not sure if that's still the case. Perhaps Aseprite is too niche in comparison to Krita, but then you can still get Aseprite for free since the code is free on Github, you just have to compile it yourself. So it seems like the creator is less concerned about users not paying him and more about someone making a fork that users can get for free (or perhaps even worse: said forker selling the fork.) And in that case, there's unfortunately not much you can do. Donations or subscriptions would work a bit better since users are now paying you to work on improving the software and producing updates (which a simple fork can't do) rather than for the work you've already done (which can be easily duplicated, open source or not), but that won't help if people think that the fork is the official product. So now it's an issue of branding and advertising, I think.

And maybe, the reason why SirCmpwn, Krita, Blender (well, that one's a bit of a special case), and the several Youtube channels that are doing fine on Patreon donations is that they emphasize that you're paying them for the work they're doing and not for the product. That you're enabling them to continue making what you like. With traditional marketing, there's a disconnect between the product and the work. You think "this movie/this video game/this software can be copied over a thousand times in a matter of seconds, so downloading a pirated copy isn't going to hurt anyone", but you don't think "by buying this copy, I'm going to support its creators who can then go on to improve it or make something else that I'll like." And that's probably where the anti-piracy messages go wrong. "Don't steal", "you wouldn't download a car"; those messages don't exactly make sense when it comes to digital products. Of course people would download cars if we could clone them for free with the click of a button. And it's not like we need to support the creators so they can make car2. One car should last long enough. It's such a silly comparison. And of course people don't want to throw money at a company that thinks they can milk infinite cash out of a product that they can duplicate infinitely, who would? Couple that with the fact that piracy from those who couldn't afford to pay for the product anyways doesn't actually cause any loss, and it's obvious that the analogy doesn't make sense. How can something that's more easily multiplied than water be considered a product? It gets even more confusing when you consider ownership. For every other product, you buy it to obtain ownership, but in the case of software you buy it to obtain a license, which is really abstract with most licenses being incomprehensible for most end-users. And not just is it abstract and hard to understand, it also feels unfair. You pay money money for this thing, which doesn't even seem to have any value on its own because value is usually defined by scarcity - this thing is just made scarce artificially - and you don't even get to own it. You don't get to lend it. You don't get to resell it. You just get to use it, and even there you just get to use it exactly how the author wants you to use it. At least for software, it makes a lot more sense to market the service of creating the software, in my opinion.

I'm not sure if that would also be better for artistic creations, but considering that the service model also seems to work well for Youtube donations (and early access video games) it might work. I think it makes more sense to pay the artist to create more of the things that I like rather than paying for a copy (that cost a cent to create) of something they made 20 years ago. It's even worse when the creator is long dead, but that's a story for a different time. But on a related note, part of the problem may be that companies push themselves in front of the creative minds when it comes to advertisement. While it makes sense to have a unified representation for a series of movies when you go to watch it, you feel like you're giving your money to Disney, not the people who made the movie. You feel like you're giving your money to an inanimate entity that has already amassed millions, led by some rich people who don't have a single creative bone in their bodies. Which is partially true, but you're also paying the creative staff to make the next movie that you'll probably enjoy.

Small projects, however, have the benefit that you can feel like you're directly supporting the creator, you just have to make sure to emphasize that aspect: that supporters pay you to make stuff, not for stuff you already made.

Obviously this doesn't cover all cases like one-off projects that don't require any more work (but let's be honest, when would that ever apply to a piece of software? there's always stuff to fix) and where the author doesn't plan on making anything else, but I think for active creators the "Asks to be supported" model would probably work a lot better than the "I made this, now pay me to get a copy of it" model.

That said. I just saw another link to the Aseprite blog[4] and it seems like the author was also displeased with the current state of Linux packaging, which is also important but a different issue from monetary support.

[1] https://www.indiegogo.com/projects/sway-hackathon-software/

[2] https://drewdevault.com/backers

[3] https://www.kickstarter.com/projects/krita/krita-2016-lets-m...

[4] https://dev.aseprite.org/2016/09/01/new-source-code-license/

The author's reasons are his own; arguing them with me doesn't get us anywhere. If you're suggesting that he doesn't really believe what he said and must have other motives, I can only say I find that very unlikely.

Huh, thanks for that - I don't really use github and didn't know you could pull up that graph.

In that case it looks like most of the other contributors contributed after the CLA was added but there are still a few commits from before that point. Accordingly he should have sought permission from those people before changing the license.

> Sadly, it's why there's more and more projects adopting CLAs. Some that say that all the code you're contributing is owned by the project and not yourself. Allows for future relicensing in some cases.

You're conflating CLA and CTA/CAA, the difference is explained here [1], and it matters.

[1] https://opensource.stackexchange.com/questions/860/what-is-t...

> All four of those projects are free and open source.

Aseprite is 'not fully proprietary', as it has 'sources open', but not free as other FOSS.

> How are schisms in free, open source projects relevant to the inability for Linux.

You manipulate about "inability for Linux"? For what?

This news about cross-platform software. There NO any words in this thread about any Linux packaging issues.