[freudling]

What a weird world... after so many years of software development, it appears as though selling software as a free trial and allowing people to purchase licenses is a pain in the butt.

We have an ecommerce system. What we need is that when someone buys one of our programs, they get a serial number that works with the program.

In other words, how can we license our software? I've seen a few things out there but man is it a cryptic area of software development.

Can anybody give me advice/wisdom?

[shifuimam]

I've seen some options where the customer pays, and when payment is rendered a serial number is generated that is then validated remotely. Or, if you prefer, it can be a hash of some kind based on information the user gives - but then you're opening yourself up to people using key generators to pirate your software.

Depending on what you're developing, is it worth charging for at all, or would donationware suffice? Are you concerned about piracy? Is this your main source of income?

If it's the last one, then I'd definitely recommend using some kind of client/server validation that prevents anyone from using a key that (a) wasn't generated by you or (b) is already being used by someone else.

You could maybe (not sure how you'd do this in an OS X app; I've only done desktop application development in C#) do some kind of key activation. If the customer buys the software over the Internet, they're emailed a key that was generated at time of purchase. Activate the key and transmit back some kind of anonymous but unique data, like a one-way hash of a combination of the machine's serial number and, say, MAC address. That way the customer can reactivate on that machine as many times as they want, and you can reset the activation if they want to install on another machine. Or something like that.

If it's just a hobby of yours, I'm not gonna lie - it drives me crazy when I find an app I might only use once or twice, and the developer wants fifteen bucks for it. I'd much rather donate to devs I support than constantly spend money on stuff I don't plan on using frequently...

[besson3c]

Is it possible to make your money elsewhere so that your OS X app is simply a sales catalyst?

[freudling]

Originally Posted by shifuimam 

I've seen some options where the customer pays, and when payment is rendered a serial number is generated that is then validated remotely. Or, if you prefer, it can be a hash of some kind based on information the user gives - but then you're opening yourself up to people using key generators to pirate your software.

Depending on what you're developing, is it worth charging for at all, or would donationware suffice? Are you concerned about piracy? Is this your main source of income?

If it's the last one, then I'd definitely recommend using some kind of client/server validation that prevents anyone from using a key that (a) wasn't generated by you or (b) is already being used by someone else.

You could maybe (not sure how you'd do this in an OS X app; I've only done desktop application development in C#) do some kind of key activation. If the customer buys the software over the Internet, they're emailed a key that was generated at time of purchase. Activate the key and transmit back some kind of anonymous but unique data, like a one-way hash of a combination of the machine's serial number and, say, MAC address. That way the customer can reactivate on that machine as many times as they want, and you can reset the activation if they want to install on another machine. Or something like that.

If it's just a hobby of yours, I'm not gonna lie - it drives me crazy when I find an app I might only use once or twice, and the developer wants fifteen bucks for it. I'd much rather donate to devs I support than constantly spend money on stuff I don't plan on using frequently...

This is good info. I'm going to PM you. The application is not a hobby. Our business is VC backed. It's a big App that will be competing with Adobe and Apple.

[freudling]

Originally Posted by besson3c 

Is it possible to make your money elsewhere so that your OS X app is simply a sales catalyst?

Good question. We will make money elsewhere but it's not mutually exclusive

[shifuimam]

Originally Posted by freudling 

This is good info. I'm going to PM you. The application is not a hobby. Our business is VC backed. It's a big App that will be competing with Adobe and Apple.

Incidentally, this is similar to how Windows is activated. It works very well and prevents piracy. Windows has to be hacked to bypass activation, unlike, for instance, Adobe CS applications. Adobe had such enormous problems with their new activation method in the original Creative Suite that they had to revert back to something more reliable but that easily allowed the creation of a key generator.

Windows activation uses a unique ID that is generated from various pieces of hardware in the machine. A technology called DMI allows software to read serial numbers, manufacture dates, model numbers, and other things from the installed hardware (even stuff like RAM and chipsets). If your software is going to be Mac-only, you can use anything that you can read via software. Just make sure it's unique. As a safety net to prevent activation issues you can allow more than one activation per serial (Microsoft allows like five activations on a retail copy of Windows now, before you have to call an 800 number and use an automated system to reset your activations).

I don't really know the details of why Adobe CS1's activation method was so buggy. It would definitely be worth researching to know what pitfalls to avoid.

If you're making your application for enterprise customers first and consumers second, keep in mind that the bulk of your profit will come from businesses. Small-time piracy may not have much of an impact, although you have every right to do what you can to prevent it.

[Waragainstsleep]

My understanding is that CS talks constantly to a long list of adobe activation servers so using illegitimate keys never works for long. That was the case for CS5 and I think 4 too. Adobe would have far fewer problems if they didn't charge so damned much for their software.

Another part of their problem is the strength of their brand. You suggest to someone that they get Photoshop Elements, they'll ask how it differs from the full version, you explain its a cut down version but has all the features they are ever likely to use, they still go steal the full version because they know a guy who will do it for a few bucks. I only mention this because if you plan on releasing a reduced-functionality version of your app its worth bearing in mind.

[shifuimam]

+1,000 on the price of Adobe software. If I'm not using their applications to make money, I don't remotely see the justification in spending $1200 for a frigging image editor. The problem is that alternatives like Paint.NET and Gimp don't really cut it when you've become completely accustomed to Photoshop's nuances.

I should also point out that piracy hasn't exactly hurt Adobe. They're the industry standard for a lot of markets, and businesses definitely aren't going to run around pirating software. So if they're not actually taking a big financial hit from piracy, why not start a program to make their products affordable for students and people who are just interested in hobby work?

To clarify - the $300+ "student" pricing is not affordable to a college student. Meanwhile, Microsoft has DreamSpark, which makes nearly every single one of their applications free to college students.

WRT CS talking to Adobe constantly - there are really easy ways around that. Or so I've heard.

[freudling]

Originally Posted by shifuimam 

+1,000 on the price of Adobe software. If I'm not using their applications to make money, I don't remotely see the justification in spending $1200 for a frigging image editor. The problem is that alternatives like Paint.NET and Gimp don't really cut it when you've become completely accustomed to Photoshop's nuances.

I should also point out that piracy hasn't exactly hurt Adobe. They're the industry standard for a lot of markets, and businesses definitely aren't going to run around pirating software. So if they're not actually taking a big financial hit from piracy, why not start a program to make their products affordable for students and people who are just interested in hobby work?

To clarify - the $300+ "student" pricing is not affordable to a college student. Meanwhile, Microsoft has DreamSpark, which makes nearly every single one of their applications free to college students.

WRT CS talking to Adobe constantly - there are really easy ways around that. Or so I've heard.

I find this to be a very touchy subject with engineers. "Why are you offering serial numbers, it's so easy to hack!" Blah, blah.

Yet, nobody offers any alternative solution. I don't care about geeks hacking it. That's reality. Free trials is the best thing that ever happened to software. There are no other competing approaches to offering your software for sale to people that are better than this.

If somebody has a better option, I'm all ears. And don't say offer it for free, not happening.

Oh, you think monthly payments works? Offer software based on low monthly subscription fees? Turns out, it's a bigger pain in the butt for both parties than you can imagine.

It's much more complex. Customers credit cards fail... people want to stop the service... restart it... complain about not having access... the engineering is much more difficult and same with the customer support. And for consumers, who wants to have monthly payments? Just another thing to worry about.

Better thing is offer your software for cheap so people can afford and forget the complexity.

Any comments on either of these options guys?:

SIGPIPE 13 � OpenSSL for License Keys

https://github.com/bdrister/AquaticPrime

[besson3c]

Freudling,

The SSL license keys thing looks like a basic challenge/response mechanism like most authentication schemes (Kerberos, SSH private/public keys, etc.) I don't know what your business is, I don't think you've ever disclosed the details, but I think if I were you I'd consolidate all of this authentication stuff across all of your apps to rely on a single web app if your app requires internet access. This will reduce your development costs, because I think what you haven't accounted for is the fact that once a serial number has been authenticated, you still need to prevent people from zipping up that application and passing it on. The major weakness with my scheme here though is that it requires internet access.

What I would suggest is utilizing the same basic encryption mechanism that web apps use, along with a salt for extra security that would be modified regularly.

I would give people a username or some sort of authentication token and tell them that it will expire within a month if they don't register it within that time. On first launch it will prompt the user to create a password to go along with that authentication token. That password will be sent over HTTPS POST to your site where it will be encrypted and stored as an SHA/MD5 hash after being combined with your aforementioned salt value. Your app would store these values into the website's database, allowing your customer a means to login to your website, should you currently have a web app of some sort or would plan to create one in the future (I know a guy that does this for a living

On consequential launches, the user will have to provide their password if their IP address or MAC address (or whatever else) changes, I believe Steam does the same sort of thing. This whole idea is probably a rip-off of what Steam does.

With this system you are basically consolidating on HTTPS POST for all authentication - a method that I'm sure your client apps will have no trouble supporting. In doing this you are also killing too birds with one stone in providing a single sign-on that will work to access your web app as well, as well as to control how many devices using that user/pass combo are permitted via your web app, and to allow downloads of your client for other operating systems without making them obtain a new license.

[freudling]

Originally Posted by besson3c 

Freudling,

The SSL license keys thing looks like a basic challenge/response mechanism like most authentication schemes (Kerberos, SSH private/public keys, etc.) I don't know what your business is, I don't think you've ever disclosed the details, but I think if I were you I'd consolidate all of this authentication stuff across all of your apps to rely on a single web app if your app requires internet access. This will reduce your development costs, because I think what you haven't accounted for is the fact that once a serial number has been authenticated, you still need to prevent people from zipping up that application and passing it on. The major weakness with my scheme here though is that it requires internet access.

What I would suggest is utilizing the same basic encryption mechanism that web apps use, along with a salt for extra security that would be modified regularly.

I would give people a username or some sort of authentication token and tell them that it will expire within a month if they don't register it within that time. On first launch it will prompt the user to create a password to go along with that authentication token. That password will be sent over HTTPS POST to your site where it will be encrypted and stored as an SHA/MD5 hash after being combined with your aforementioned salt value. Your app would store these values into the website's database, allowing your customer a means to login to your website, should you currently have a web app of some sort or would plan to create one in the future (I know a guy that does this for a living

On consequential launches, the user will have to provide their password if their IP address or MAC address (or whatever else) changes, I believe Steam does the same sort of thing. This whole idea is probably a rip-off of what Steam does.

With this system you are basically consolidating on HTTPS POST for all authentication - a method that I'm sure your client apps will have no trouble supporting. In doing this you are also killing too birds with one stone in providing a single sign-on that will work to access your web app as well, as well as to control how many devices using that user/pass combo are permitted via your web app, and to allow downloads of your client for other operating systems without making them obtain a new license.

Interesting.

However, we have an OS X native application that this needs to work with, not a Web App.

[besson3c]

Originally Posted by freudling 

Interesting.

However, we have an OS X native application that this needs to work with, not a Web App.

I know. My suggestion would involve putting the web app at the center of the picture, but would work with all of your client apps on all platforms: OS X, Windows, mobile, etc.

I don't think anybody is going to be able to really help you much though without knowing anything about your business. What is your business website URL?

[freudling]

Originally Posted by besson3c 

I know. My suggestion would involve putting the web app at the center of the picture, but would work with all of your client apps on all platforms: OS X, Windows, mobile, etc.

I don't think anybody is going to be able to really help you much though without knowing anything about your business. What is your business website URL?

I'd rather remain more anonymous.

Bottom line is, it's an OS X application that needs to be serialized. I think that should be enough information? It's Mountain Lion compatible only.

[besson3c]

Originally Posted by freudling 

I'd rather remain more anonymous.

Bottom line is, it's an OS X application that needs to be serialized. I think that should be enough information? It's Mountain Lion compatible only.

As long as your application requires internet access my suggestion will work then. There are many Google search results of people doing Cocoa HTTP/HTTPS POSTS.

I'm not sure how serialization is relevant though.