"Since https://github.com/aseprite/aseprite went proprietary on Aug 26th, 2016 (aseprite/aseprite@5ecc356), this fork and corresponding GitHub organization were created to preserve the last GPLv2 version of the code.
Our reasons for doing so are multiple and likely different for all fork initiators, but a strong belief in free software is definitely to name, and as the GPLv2 license allows us to, we want to safeguard this nice open source piece of software."
I love open source and I wish it was still GPLv2, but am also a huge fan of Aseprite. It was the best $15 I've spent on software. Every time I open it up there is some update that I'm excited about (and absolutely tonnes of new stuff since 2016 [edit: "1274 commits behind aseprite:master" to be precise]). Plus, the interface makes me smile every time.
I'm certainly not against LibreSprite - I'm keen to see where they take it - but just saying, "hats off" to Aseprite!
"Asks to be supported" is different from "changes the license from FOSS to proprietary". Sure, they can do that, but don't complain when someone forks your software then.
Because "Asks to be supported" usually boils down to a few donations and patreon accounts that hardly pay the bills for most developers, unless they have other sources of income.
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.
Krita as a proprietary, for-profit software venture could probably bring in closer to $38k per day, although some of that would have to flow right back out to marketing. Whenever I see someone with a Patreon link, I click just to see how well it's working, and it's far more likely to be $5 per month than $500.
It's great to see attempts to monetize creative output more directly instead of subsidizing it via advertising and copyright enforcement, since the creative output is what people actually want, but I don't think anyone has hit on a model that truly works yet (a few notable exceptions notwithstanding).
The lesson from that suggests the original dev shouldn't have made the project open source in the first place. That a sad but possibly true unintended consequence.
I don't believe this is true. Feels like confirmation bias a bit. Lots of companies or people make money on their open source software. Vue.js, Red Hat, etc. That's just the top of mind and I'm sure there are more.
It looks like lots because you count each failure as confirming your bias, but if you correlate that against over 80% of small businesses failing then it's not a valid assumption unless you have data showing they fail at a higher rate.
Don't get me wrong this is a shitty situation for sure, but it's always sad when an entrepreneur of any stripe fails.
As an aside I think it's a more valuable conversation in general to look at the business models available to someone approaching this model of development and for us to make suggestions on how he could have built a successful product in this way and succeeded. My thoughts as a total outsider on this issue are going to be more general, but since it's my suggestion to do this I'll start.
1. I believe that when someone creates software in a broad usage category then consulting and especially training must be central to any business goals if you wish for similar projects to succeed.
2. Support contracts for large orgs are also very important because companies need security whether software is free or not. Without support contracts it's likely you won't get the kind of benefactors that are required to be financially sustainable.
3. Marketplaces seem to be in vogue as are extensions. These often work well for one very simple reason; people are paying either directly or indirectly (via their marketing of their extension) to promote your product/service. Nothing says win like others promoting your stuff for you.
4. Build a currated network of developers and promote them. Talk about them to others. Helping them is helping yourself. The more people or orgs investing in your marketplace developers the more stickiness a product will have.
5. Talk about the product everywhere. Conferences. Even start a conference around your vertical. Invite your dev circle to speak at the events. If nothing else it'll boost their careers.
Anyway that's my off the back of the napkin 'just saying' for today. I hope it helps someone who's interested in following this gentleman to Foss joy and success.
The examples you cite work in enterprise space, not when selling desktop applications to regular consumers.
Red-Hat explicitly moved away from desktop because of it. Even Ubuntu has given up and decided to pivot into IoT and server.
Average steet consumer does not care about consulting, and if some kind of training is needed they ask around to friends or local teaching associations.
The original author sees zero from those teachings and everyone in the business knows that desktop software books are more about building CV than actually living from them.
It's hard to make money by selling desktop software, period. In 1995 it was a reasonable model, but there's a reason why everyone goes SaaS in 2018. The market isn't growing, and consumers aren't used to paying for typical desktop software anymore (with Mac a possible exception).
Glad someone is doing this. The author pulled a bait and switch and got away with it because the software wasn't really a community project to begin with. The switch happened right after I spent a good amount of time getting Aseprite's finicky build system to work so I could package it for a distro. If I had known the author was going to betray the users I wouldn't have bothered.
Most open-source projects aren't "community projects" and "betray the users" is an interesting way to phrase "tried to get people to support the project, they by and large refused, and so he made it distinctly less optional".
You're better than that, man. This stuff goes both ways.
Well, I bought Aseprite while it was FOSS, and license was one of the reasons I chosen it instead of PyxelEdit. I wound't say I feel betrayed... more like disappointed.
Don't get me wrong--I bought it, too. But I'm not disappointed in the author. I am disappointed in the userbase that wouldn't put up to make it viable. Like I said, this stuff is a two-way street.
(This is also why I, for a project I'm about to release, am doing an OSS/commercial split with higher-end features not part of the OSS version. But my software is designed for enterprise use, and they're used to paying for things.)
People have contributed to the project under the original license terms. It's absolutely a betrayal to the contributors (and possibly illegal, requiring consent) to change the license terms from under their feet.
Grafx2 is also very much like Deluxe Paint if that's your thing. Moving from Deluxe Paint IV to Grafx2 was pretty seamless for me for that reason.
I'll note that it's probably best to run an old release (the 2.3 version that ships with Debian is OK) or build from master at this point, because there were some bugs in the 2.5 release that I couldn't get over. The project maintainer is very active and quickly accepted my patches, though.
The software is also pretty interesting from a developer's perspective. It has basically grown organically for 20 years, originally starting out as a freeware closed source Deluxe Paint clone for DOS. The source code reflects this, and there is some low hanging fruit ripe for improvement.
> If I had known the author was going to betray the users I wouldn't have bothered.
I'm a FLOSS developer. I understand FLOSS development, ethics, and licenses. And I don't understand why you're casually referring to a change to a proprietary license-- a change I agree is for the worse-- as a betrayal of users.
Nobody "turned free software into proprietary software". He released some free software, then later he released other non-free software. He also explained his reasoning[0] - that developing the project as FOSS wasn't working out, for specific reasons he goes into, so he needed to try something else.
Honestly, this kind of thing is the ugly side of FOSS culture. I get why you were hoping he'd continue under the old license, but the fact that he didn't is no grounds to say he betrayed people.
Some of the author's reasoning amounts to arbitrary justifications. They have a section describing the difficulties of integrating contributors patches, suggesting they're unwelcome, which is quite the high-horse stance to take when people are going out of their way to contribute code to your project. The rant against Linux packaging betrays the author's position, in that they would prefer to spam the user with donation/payment links in the most obnoxious way possible.
For example, they claim "[Distributions] do not show who is the real developer of the application in a clear way" and "They do not show buttons/links/a simple way to contribute to the real developer of the program", but in reality all properly documented programs handle this themselves in one or more of their --version/--help output, the manual, and the interface. This is especially true for GUI applications, which typically have an "About", etc menu giving details. If the author neglected to document their program properly, it's no fault of the packagers. I have never had problems finding the upstream source and authors from properly documented packages.
The article also brings up improper association of a package with a given disto. This is partiality true (e.g. users reporting bugs upstream for outdated packages when they should be contacting the packagers), but largely such end-user ignorance has nothing to do with Linux distributions, and is applicable to all OSs.
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.
If he's the one who was putting the work in to the software, he has a right to ask to be paid for it, even if he previously was nice enough to give it away
I must have bought it right when it went proprietary, I think I was introduced to it via HN but I dont remember any mention of it formerly being libre. I only bought it because I thought my kid would enjoy playing with it, I chose it because it was on sale, DRM free and I couldn't find a decent libre editor. Guess I didn't search hard enough. My kid hasn't opened it since :/
You're comment made me look into it. So it's still open source, just not GPL? Looks like I simply fell for a sales tactic targeting compulsion and naivety. They got my money, good for them. Anything associated with their name is an immediate pass for me from here out. No one did the right thing here.
It’s open source but not free software. I’m honestly ok with that because I think making a living is important & the Linux distros are really bad at supporting authors of software.
> LibreSprite is taking the GPL religion religion into the kool-aid zone.
False. LibreSprite is fork of last GPL commit of Aseprite, not even in active development. They are actually preserving cool piece of software. Maybe one day someone will want to develop it further or learn form it. Do you expect people not to fork when Aseprite author decided to close the source?
He did the overwhelming majority of the work, and put it out there for free for a long time. If he is at a point in his life where he needs to monetize, I'm glad to support him just out of gratitude.
Who's really got skin in the game? Perhaps the author who spent countless hours pushing the project along all those years, he took all the risks and uncertainties. Yes, all contributions did help but being a humble contributor I wouldn't ask for any kind of eternal obligation. Otherwise what kind of help is that? If one wants to give, they just give, full stop. Why not stick to free will? Notice the word free.
If you feel this way you should never open source your work. Licences like the GPL as well as licences like BSD/MIT explicitly allow for forks like this.
This was my thought exactly. The author isn’t asking the world, the tool is just $15. I believe in open software too, but this is pretty niche and if I really needed it I’d rather pay than not have it at all.
> The author needs to eat, therefore relicense (I think).
In my opinion it's the author who should have been seeking a fork then. Getting the approval of all the contributors to do so, knowing that those people won't be able to help anymore.
Also, that kind of thing is usually handled by a Pro version or advanced support for paid subscribers.
I took a brief look around the repo and it looks like the author is the sole contributor (at least the few files I looked at had plenty of commits but all by the author).
A project being GPL'd doesn't necessarily mean the copyright isn't owned by one party.
He's clearly the top contributor, but not the sole contributor.
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.
> 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.
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.
I purchased Aseprite because it's nice. I'm curious if the author has ultimately benefited from changing the license, though. I'm not sure what it does practically aside from that Linux distributions can no longer package it.
All four of those projects are free and open source. Aseprite is, as of 26AUG16, paid proprietary software. jchw's statement was about the ability, or lack thereof, for Linux distributions to package such software.
How are schisms in free, open source projects relevant to the inability for Linux distributions to package and distribute paid proprietary software?
The license prohibits the distribution of compiled binaries. This prohibits Linux distros from shipping it. It also prohibits most Windows and Mac users from using it as well.
I tell that issue is not only in Linux packaging, but in full changing poject development strategy: moving from "FOSS", to "proprietary+open sourcecode".
That's why I asked, what he know about "QCAD & LibreCAD; OpenOffice & LibreOffice" stories.
@jchw told that he don't know any reason why Aseprite forked to LibreSprite, other than Linux distribution issue.
I give him an answer, that issue with Aseprite was NOT only in Linux packaging, but in changing strategy of original project development (including re-licensing of source code to non-FOSS software). And according that I told that there are already precedents for similar situations -- as result we has now LibreOffice & LibreCAD.
> @jchw told that he don't know any reason why Aseprite forked to LibreSprite, other than Linux distribution issue.
That is not at all what the post said. jchw's post (with my annotations):
> I purchased Aseprite because it's nice. I'm curious if the author has ultimately benefited from changing the license [of ASEprite], though. I'm not sure what it [making ASEsprite proprietay] does practically aside from that Linux distributions can no longer package it [ASEprite].
Nothing in that post is referring to LibreSprite. jchw is not asking why LibreSprite exists. jchw is asking whether taking ASEprite actually benefitted the author of ASEprite in the long run.
"Since https://github.com/aseprite/aseprite went proprietary on Aug 26th, 2016 (aseprite/aseprite@5ecc356), this fork and corresponding GitHub organization were created to preserve the last GPLv2 version of the code.
Our reasons for doing so are multiple and likely different for all fork initiators, but a strong belief in free software is definitely to name, and as the GPLv2 license allows us to, we want to safeguard this nice open source piece of software."
- also included in the Readme.