Sparkle 2.0: Licensing for Paid Upgrades

One problem with the Sparkle experience now is that if a paid upgrade comes out, there's really no way to handle that. The developer is forced to create a new feed for it to avoid inadvertently upgrading his unpaid users, and the unpaid users are left in the dark, not hearing of the new release unless they visit the developer's site. Then they have to download and install manually.

But what's the best solution to this? Here's a really complicated solution. It may be entirely overboard, but it'd be useful.

Encrypted Branches

If you make a paid upgrade, that's essentially a branch. You've got 2.0, 2.0.1, and so on, but you might still want to upgrade 1.5 to 1.5.1 if something catastrophic happens. The proposed new branching system would make this pretty easy: just tag 2.x as a new branch.

Now how do we control access? How do you all feel about AquaticPrime? Then we have to find a way to bridge the branches. More thoughts on this later.

"Now how do we control access?" Hm. We don't? Isn't licensing a completely separate issue? While it might be nice to offer a complete solution, I think this can wait for Sparkle 3.0. :) --AndreasM

We (Coriolis Systems) currently use appcasting, but we have our own update implementation, which solves many of the same kinds of problems as the existing version of Sparkle, plus one or two others. If you're going to do a centralised update system based on Sparkle, then I think that's something we'd want to take part in, not least because in such a case, rolling our own from scratch would be a disadvantage to our users.

Anyway, unlike most of the other people here, we aren't producing freeware or shareware apps. That is, you can't download the full version of our apps for free; you have to pay first. As a result, we have a requirement on our update system that it requires users to authenticate somehow. This would be a pain if it meant that our customers had to enter passwords and things all the time, so our feeds have an option to send authentication data to the server by doing a POST rather than a GET when trying to download. The data to be sent can be set by the application that links to the update framework.

There is also (on our feeds) an attribute for the link tag that says whether or not the feed wants authentication data, to avoid sending it where it wouldn't be appropriate.

The advantage of all of this is that it means that the decision about who can download what is delegated to the server, that the update framework doesn't have to care or indeed get involved in any way with copy protection or payments or anything like that. You can leave all of that up to the application and the update server. --alastair