More On Policing Shareware

RHW22 writes "Washington Post's Rob Pegoraro looks at shareware, focusing on the question of whether or not this industry can survive if people never actually cough up $$ for the product. He mentions Ambrosia Software, 'a developer of Macintosh games and utilities in Rochester, N.Y., could stop guessing after it revised its payment system last year. The new system aims to stop people from using pirated registration codes in two ways.' Read his column here." We mentioned this several weeks ago, with a link to Ambrosia's description of their system and what led to its adoption.

Comments

Most shareware these days isn't really shareware

[Tyler Eaves]

IMHO, most stuff marketed as shareware is really demoware.

If it can't save - It's a demo
If it pops up excessive nag screens - It's a demo
If major functionality is locked - It's a demo

The only effective way

[TheSHAD0W]

You want to make money on shareware? Charge less. Make it very convenient to pay. And don't annoy the end user.

Headlight Software has made lots of money from Getright registrations, despite some people having pirated it. I've registered it myself. (I think it was $20, not $25, when I did, though.)

If a software company wants too much money for a piece of shareware, users will get a patch or key generator rather than pay. If the software nags the hell out of the user when he installs it, he'll get mad. I know I do.

Re:The only effective way

[silentbozo]

Pricing lower only works if pricing is an issue. For some users, any price is too much. For other users, you can charge quite a bit. From what I've seen, piracy is mainly an issue for popular software, where people who fall into the first camp publish kracks/keys, which are then used by the second group...

That's where the real revenue hits come in - when downloading the key/krack is easier than registering, and users who would have paid, if they had been forced to, take the easy way out.

BTW, there was a brief experiment done by a shareware author (Colin Messitt), who inserted code that would cripple his app for half the users, and have full functionality for the other half. Who would get which version activated was totally at random. One of the observations from this experiment was that the crippled version had a MUCH higher rate of registration/payment than the non-crippled version. The price for the utility was $25. A copy of the article is here (google version).

Mind you, if you release "true" shareware (no restrictions), you essentially provide the "krack", and can fall victim to users just being too lazy to register (or falling victim to the perception that since they can use the software for free, that's all its worth.)

This isn't true of all users, of course. But the grim truth is that there aren't enough scrupulously honest users out there that value your software enough for you to build a thriving business without some protections in place (at the very least, some sort of nag.) Most of the shareware authors I know would agree with me on this point.

Re:The only effective way

[Reziac]

Getright has other things going for it, too:

It's probably the best-designed shareware I've seen in my almost 9 years of computing. You can really feel like you got your money's worth.

And registration really does kill off the adware component.

I've seen altogether too much shareware that is either ill-behaved junk, some species of spy/adware that doesn't turn off gracefully when registered, or is overpriced for what it does, to the point where now I very rarely download shareware at all. Free alternatives aside, sometimes a much better commercial product costs less!

Then you never really own the software!

[zerofoo]

When I purchase software, I own the product. The problem with expiring registration codes is that you only own the software as long as the company is in business.

What happens when Ambrosia goes out of business and the software code expires? Your product that you PAID FOR stops working.

Can you imagine the impact of GM going out of business and then finding your car doesn't start the next morning? You paid for that car, and you expect it to function correctly for the expected life of that car.

Expiring codes, WPA, and all the other software piracy/protection schemes out there remove control of the software from the end user and shift it to the software vendor. It is only a small step to software as a subscription service after that.

I'm really glad my Linux machine is totally free and if Microsoft, or Ambrosia goes out of business it will still keep working.

-ted

Re:Then you never really own the software!

[Michael Woodhams]

I think you have misunderstood. Once you have given a legitimate, non-expired key the software will work forever. The only time you need to go back to Ambrosia is if you bought the key and didn't get around to applying it before it expired, or (I expect) if you reinstall. The reinstall is a problem, but not as bad as your scenario. (More like spare parts becoming unavailable when GM goes out of business.)

Re:Then you never really own the software!

[MajroMax]

When I purchase software, I own the product. The problem with expiring registration codes is that you only own the software as long as the company is in business.

If done right, this isn't strictly true. A registration system only needs to rely on central servers if data used for the authentication process changes, such as a System ID or a timestamp, the latter being used in Ambrosia's system.

A simple authentication system would take the registree's name, address, and perhaps a keycode given at regtime to create a hash for the authentication server. If that hash is valid (meaning the registration actually happened), the authentication server will respond with a countercode that the program uses to unlock itself. If this countercode is not time-limited in any way, there's nothing logisticially preventing it from beging shown to the user, and thus permanently recorded; it will still be valid so long as the user remembers his name/address/etc.

If changing data is used for the hash, however, then there's a trickier situation if the authentication servers go permanently down. Most schemes would have the server respond with a sepereate countercode, and thus an old one would not work to unlock the program.

One solution to this problem is a master-key; a nonchanging constant that could be released if the company goes out of buisness. This creates security flaws, however, if the key is found out before the company goes out of buisness. Also, having a master key for the product out there would significantly reduce the possible value of the software "asset" in bankruptcy proceedings, so the courts might not allow the key to be made public.

A possibly better alternative would be to have the company release a patch that turned off the date-checking code in the program. Although this doesn't create any security holes in the product while the company's still alive, it does require that the company know it's irrevocably going bankrupt, and the programmers must have enough knowledge about the banakrputcy and power to release the patch -- neither of which are particularly likely in large corporations... after all, management can spin off the now-crippled masses as a "customer base" for future revisions to be sold at auction.

What's really needed is some sort of "dead-man's switch" so that if the company suddenly drops off of the face of the earth, the software will still work. To do this, the software should become non-functional if it receives a negative response from the auth server, instead of becoming non-functional if it fails to receive a positive response. The reg-server hostname should be hardcoded into the software somewhere (binary data file or program executable -- NOT a plaintext file), and the software (given use of an expired regcode) will try authenticating with the server on run and every hour or so until it receives a positive or negative response, in which case it will update its datafile and not try again (with that regcode).

"But Wait!" you say, "Isn't that system inherently insecure, as malpeople can crack the software or selectively block access to the auth servers?"

This is true, but, as the Ambrosia article says, the vast majority of people will do very little beyond trying a cracked regcode -- even installing a crack is beyond the vast majority of people who would typicially use the software; configuring special firewall rules is probably out of the question. (This is also why I said "put the server info in a binary file", as instructions to remove the data from a textfile is easy enough for most users.) Software registration is a game of 90%'s, so eliminating 90% of potential copyright infringers is about as good as you can get for reasonable effort. For people who _do_ tell Zonealarm to not allow the program to connect, a nag screen on startup to the effect of "This software has not verified its registration, click OK to continue" will get another fraction or two to register -- admittedly, it would be a pain if the company went out of buisness, but it doesn't have any bearing on the functionality of the software, especially for something noncritical like a game.

Running the software on a computer without internet access at all is another possibility of getting aroud the auth scheme, but that's becoming increasingly less likely as time goes on -- more and more computers are getting connected in some way, shape, or form, and shareware is largely distributed over the Internet now anyway.

Admittedly, this isn't a 100% perfect solution to the tradeoff between infringement-possibilities and functionality in the face of bankruptcy, but I'd guess that it's 80% of the way there, and it would require no changes to the keygen routines themselves.

--
The ideas expressed in this writeup are expressly placed into the public domain.

Re:Then you never really own the software!

[glwtta]

I'm really glad my Linux machine is totally free and if Microsoft, or Ambrosia goes out of business it will still keep working.

Isn't it the other way around? If your Linux machine keeps working then MS will go out of business?

:) (oh, all you MS-bashing bashers - try not to take this too seriously?)

yeah, yeah - off-topic. I've learned my lesson and will never stray from the righteous path of the all important "topic" ever again. After this one.

Re:Then you never really own the software!

[cant_get_a_good_nick]

What happens when Ambrosia goes out of business and the software code expires? Your product that you PAID FOR stops working.

• Ambrosia programmers spend the time to remove the licensing stuff, they recompile and release a FreeWare version to the net.
• They release a key generating program/algorithm.

• No, these things are not guaranteed, they could just piss all over you. But considering they trusted you enough to pay, maybe you can trust them not to leave you high and dry if they go out of business.

Re:Then you never really own the software!

[Queer Boy]

No, these things are not guaranteed, they could just piss all over you. But considering they trusted you enough to pay, maybe you can trust them not to leave you high and dry if they go out of business.

Uh, the whole point is that they didn't trust you to pay. This is a company that's out to make money (that is not a bad thing), and they admittedly will inconvenience the end-user if that means they can make more money (that is a bad thing). From a business standpoint, when you're going out of business, it's because you can't make money anymore, or because you can't make enough money, so it doesn't make business sense to pay people to work on the very thing that is causing the company to go out of business* (*see also BeOS). The only probable scenario is that they might release the source, which has been mentioned, but that's just a scenario. We've yet to see that played out by anyone but Bungie, and if I recall correctly, the Marathon source code release was under the radar of Microsoft.

Re:Then you never really own the software!

[Sloppy]

What happens when Ambrosia goes out of business and the software code expires? Your product that you PAID FOR stops working.

I think either you or I have misinterpreted how Ambrosia's system works.

My reading of Welch's explanation is that if Ambrosia goes out of business, your key file will still work. It's just that if you lose it (e.g. hose your system and don't have a backup), you won't be able to make a new file from your old numeric registration code (assuming Ambrosia is out of business).

So really all you have to fear is: you have a catastophic data loss and Ambrosia goes out of business. Only then do you face the situation of losing the game you paid for. That is bad. But it doesn't sound any worse than old-fashioned commercial software, where if you lose your distribution media and all backups, you're equally screwed.

Is troll your middle name?

[WIAKywbfatw]

The way I see it, shareware authors shouldn't expect to turn a profit. They should just see being profitable as a nice perk.

Why shouldn't shareware authors expect to make a profit? Because you say so?

Shareware is a distribution model - you like it so you register it, recommend it to your friends, etc - nothing more, nothing less.

Too many people equate shareware with free, and those that resort to password cracks are the worst kind as they can't even use the "I just wanted to see if it was what I wanted" defence.

Sure, most people will take advantage of the situation and never register software that they decide to use beyond the trial period, but some people are more honest and will happily pony up $20 for a package that does the job they want done.

But saying that the authors, the people who invested their time and effort into code that other people benefit from, shouldn't expect to see a return on their work is downright unbelievable.

Re:Is troll your middle name?

[Night Goat]

All I'm saying is that they shouldn't expect to be in the black if it's easy as running a Google search to find a way to circumvent their protection. I don't condone the practice of cracking software, I just think software designers should wise up instead of pitching a fit when their weakly protected software is pirated. Find a better way to convince people to pay you. Doom was the first shareware program I registered, because it was the first that gave me something that made it worth registering, besides a warm fuzzy feeling. And look at how well Id did, they became millionaires. They're savvy businessmen.

Re:Is troll your middle name?

[swb]

First you asked:
Why shouldn't shareware authors expect to make a profit?

And then you answer your own question:
Sure, most people will take advantage of the situation and never register software that they decide to use beyond the trial period, but some people are more honest and will happily pony up [...]

That's exactly why they shouldn't expect to make a "profit", because most people aren't going to pay for something if they get it up front without having to pay for it.

Re:Is troll your middle name?

[The Original Bobski]

Why shouldn't shareware authors expect to make a profit? Because you say so?

No, because the shareware model, having been around for a long, long, time only makes money if you have something really slick to offer. You only deserve remuneration commensurate with the quality of your offering.

Years ago I released several useful programs as shareware. While they were useful to some, they weren't, in any way, "killer apps." I found out that even though I spent my time on creating quality - though marginally useful - applications, that time didn't translate into monetary remuneration.

Should I be bitter about the fact that a few used my programs and didn't pay? Or more accurately, should I re-examine what I think is valuable?

An example of a shareware program that made money is ProComm. It stands alone as a defacto standard of exceptional usefulness, a 'killer app' that deserved its success.

Profitability in shareware is a measure of the author's ability to offer something of fantastic value. While the author spent hours in development and thinks he deserves monetary gain for doing so, the public will decide whether it merits squat.

So, no, shareware authors should not expect to make a profit.

Re:How does this work?

[jmaslak]

It can be very secure.

I don't know what they mean by "polynomials", but a public key algorithm would avoid any realistic possibility of a key generator. You would have to crack the codes a different way.

Not Shareware

[wandernotlost]

I find it disturbing that so many people continually show such complete ignorance of the history of this industry.

Shareware is fully-functional software for which you are *encouraged* to pay the developer (if you find it useful). You are also encouraged to share it with your friends, hence the name shareware. It is not time limited. It is not missing any functionality necessary for normal operation. It may have annoying messages nagging you to please pay, but if it is hampered in any way in which you must pay to get the fully-functional version, it is a commercial demo.

It's offensive that so many people these days seem to be freeloading off the good will and generosity of the shareware community in order to sell their commercial products!

Re:Not Shareware

[vukv]

thats not the definition of shareware program... it might have been 15 years ago, but it definetly isnt anymore.

Basically, shareware is an trialware that never expires. Every single shareware program that came out in past 5 years is exactly like that (if not more restrictive). Check their licenses and you will see...

Futhermore, this was never ever point of shareware - it was always ment to be free to try & share but pay if you use it (not pay if you want to pay).

You wishing it to be something else, does not make it so... I work for shareware company and we depend on sales to pay out salaries... the fact that we hold to the true meanings of shareware (full functionallity, no expirations) only hurt us today. We dont drive BMW's or have expensive office's, we dont have overhead yet most of shareware companies are struggling. I suspect this to advance futhermore and you will see more and more restrictive shareware programs in future, same way you see more and more freeware going into some kind of payware.

Reason that modern shareware went into trialware zone is that people like yourself do not want to pay for something if they dont have to, hence developers could not pay off their own bills anymore, much less anything else. What you are talking about is modern freeware programs, most of which have donation pages for people to donate few bucks for developement... and few ever do, even with huge freeware programs, I doubt anyone would get enough money to pay their own hosting bills.

Sad part is that pioneers of modern shareware, such as Jasc (whose Paint Shop Pro was one of the major shareware contributors long, long time ago) now release time limited demoes because thats the only way to sell their own programs.

Why I hate shareware

[IvyMike]

Actually, I'll just quote Linus: " In my opinion, shareware tends to combine the worst of commercial software (no sources) with the worst of free software (no finishing touches). I simply do not believe in the shareware market at all. "

Perhaps I've been spoiled by Linux, but I'm getting into Mac OS X now, and there are tons of little apps that on Linux would be free, but some chump wants $9 for on OS X. Yeah, part of it is me being cheap, but I keep going back to Linus's quote and end up not buying it.

"Shareware + source" might be interesting, even with a non-RMS-compliant license, but I haven't seen it. (And of course, I'd prefer full GPL if possible.)

Re:How does this work?

[The Cookie Monster]

You don't need to auth with a server to prevent keygens from being possible.

You can't write a keygen if the key system uses public key encryption to sign the timestamp (a few implementation details ignored here as you get the idea). You'd have to crack the software instead then - and who knows what that software crack will install on your system.

This kind of 'strong' key isn't appropriate in all situations due to its length - for instance where the user has to type it out (eg a key printed on the softwares CD), but in the case of shareware where it is emailed to you (or supplied on a web page) and the user can just cut it and paste it, it's fine.

I thought the idea of only accepting keys less than 30 days old was quite a good one actually (one of those really damn obvious in hindsight things), sure the determined user can roll back their clock (if the key was provided with a date) but it adds two more hoops a pirating user has to jump through without affecting a legitimate user - calling up the server to auth the key is a Very Bad Idea, you get a tonne of paranoid users telling their friends and posting everywhere that you are spyware because their zonealarms went off (found that one out the hard way too ;)).

OSX

[TellarHK]

What's really needed are more people learning how to port some of the freeware utilities from Linux and other *nixes over to OSX binaries, using Cocoa. I sure as hell can't do these things, but there're a ton of other developers out there that can.

Mostly what needs to be ported, IMHO, are small things. Network and system monitoring tools that can go in the dock, or other little things like that. Sure, the big stuff would be nice too, but I'm certain there are a ton of little apps that might even only take a few days to port for someone who can get used to Cocoa.

Some helpful links with reg code generation info?

[EMIce]

Ok, strange that slashdot posts something like this just as I am in the process of writing some copy protection (due in the morning!). I just read the Ambrosia Software story while searching google for some tips and techniques for writing copy protection. I am trying to avoid the very problems they had. All I hear is that the key is "use polynomials!," wherever I go. If you can't tell yet, I'm a complete newbie to this, I've been programming a while but haven't had to protect my applications before. So how about some helpful advice on how to write a decently secure registration system. Some links with mathematical explanations would be nice.

Right now I am just creating a 32-bit value from a random 32-bit number the application gives the user and a name. The name is hashed using something like (2^0 * char0 + 2^1 * char1 + ... + 2^N * charN), with a 31 char limit to keep the number 32 bits. I'm wondering if there are ways to check parts of such a hash without actually regenerating it, so that I don't give away the key generation algorithm in the software. I know it can't be bulletproof, I just need something that's not so simple it'll be breakable by a casual cracker.

Re:Most shareware these days isn't really sharewar

[Alizarin Erythrosin]

It seems most "shareware" these days has forgot the true meaning of the word. True shareware just used to have a screen at the beginning that says (basically) "Hey, if you like this program, how about send some $$$ the developer's way for his troubles... and pass this on to a friend if you'd think they'd like it!" and let you go on your merry way... If you didn't want to send them money, then you didn't have to, unless the program expired after X days, or X uses and you wanted to continue using it.

One of my friends is the co-developer of Cover Your Tracks and I joked with him once that he made it to the "big time" when there were cracks published for his program's licensing code algorithm.

Re:Some helpful links with reg code generation inf

[jmaslak]

Okay, you want to write your own key generator.

My advice:

1) Use RECOGNIZED encryption & hashing algorithms. Do NOT invent your own!

2) Don't shorten the result from a hash. I recommend at least 128 bits of entropy in the key (if you use Base64 to represent your key, you need 22 characters)

3) Use public key encryption to prevent giving away your secrets.

An example protocol:

User sends his name (case sensitive) and the current timestamp (both of which the client stores to use in future validation) to the "authentication server" which also takes his credit card number. After receiving payment and validating the timestamp, it generates the registration code as follows:

1) Take the username, timestamp, and a secret symetric string (which will be embedded into the client, but, thus, vulnerable to attack). Concatenate them together with some sort of seperator (like a NUL character).

2) Take this new concatenated string and do some bit scrambling if needed. Take the MD5 hash of this new string and use for the next step.

3) Using RSA and a PRIVATE KEY (*NOT* embedded in your application!), encrypt this hash. Send the encrypted hash value in Base64 to the user. Remember he may need the timestamp as well to re-enter this value. The timestamp can be simply a day/month/year string.

To VALIDATE a registration string,

1) Decrypt the encrypted hash string using the PUBLIC KEY (embedded in your application). Because it is a public key, it doesn't matter if anyone knows it.

2) Verify that that hash equals the value of a hash constructed on a client using the user's name, his registration timestamp, and the shared secret embedded in the application.

Really, this isn't a secret science. But every game designer seems to think he is more creative then hundreds of experts on encryption. This is basically no different then a FFI (Friend or Foe Identification) system used on a military aircraft.

Re:Some helpful links with reg code generation inf

[Anonymous Coward]

Of course if you find where in the code this all happens, you just patch the binary to jump right around it and that's the end of that story.

Re:What do these folks expect?

[amccall]

This is a good point.

Shareware authors, and everyone on the internet for that matter, need to ask "Why would I spend my money on this"? I'm sick of hearing websites complain that people don't register for what amounts to a few worthless extras. Would you register for that worthless trash? No? Don't complain.

A good example: If I didn't view the slashdot subscription as a tipjar, there is no way I would EVER consider paying for it. As a long time /.'er, I probabably will.

The shareware, software, or service I see being successful is that which has a service behind it.

Codeweaver's Crossover plugin is arguably worth the money. (As an above poster said, this really isn't shareware as much as it is a demo though.) Those that provide extras for registering - such as sending a CD. For the internet age, DigitalBlasphemy is a another excellent example. Providing an excellent freeware sample gallery, and then a relatively low annual fee for access to the full gallary and then discounts to artwork CD's/etc...

When providing something extra to those that pay, the honor system works. When treating your customers DECENTLY, the honor system works. But when you suspect your cutomers to be criminal from the start, and treat them like trash, you deserve what you get. Registration of shareware should be EASY - not something that requires a complete hardware identification of my machine, 3 CDKey's, all my personal information, and a blood sample. - And if they aren't having that many people register - they're probably asking too much or selling trash.

What the internet needs a little bit of old-style business sense. Something I see almost none of.

Re:Most shareware these days isn't really sharewar

[doubtless]

A quick run on Dict.org to check shareware.. well, according to this, I was somewhat right. Again, there is not a definition that will be accepted by everyone.

From The Free On-line Dictionary of Computing (13 Mar 01):
shareware

/sheir'weir/ {Freeware} for which the author
requests some payment, usually in the accompanying
documentation files or in an announcement made by the software
itself. Such payment may buy additional support,
documentation or functionality.

See also {careware}, {charityware}, {crippleware},
{guiltware}, {nagware}, {postcardware}, and {-ware}; compare
{payware}.

{The Conception of Shareware
(http://www.halcyon.com/knopf/history.htm)}.

[{Jargon File}]

(1997-10-11)

Re:Blatant theft?

[American AC in Paris]

I fail to see how this amounts to theft. It is a violation of a modern law, but theft is almost so obvious one has to think about it to even define it. Theft is the act of depriving someone of some 'thing' that they have exclusive rights to, either by earning it, or having been given it by someone who themselves earned it.

...so you're suggesting that a software developer hasn't 'earned' the right to distribute her own creation as she sees fit?

If a developer spends 1200 hours of her life making a game, is it your right to disregard her terms?

The DEVELOPER is the OWNER of her own product. She does indeed have exclusive rights to her own creation; if she kept the only copy of the software encrypted on a CD and locked in a filing cabinet, you have absolutely no right to tell her that she must give it to you. If she gives it to you on the condition that you don't give it to anybody else, you have absolutely no right to give it to other people. She can choose to develop and distribute it however she sees fit, and she gets FINAL SAY in this matter. It doesn't matter if you don't want to cough up ten dollars; it doesn't matter if she wants to set up a registration scheme that forces you to call a 900 number every time you want to use the program. The terms are completely up to the DEVELOPER, not the consumer.

If you don't like the terms a developer has set forth, then don't use that developer's product. It's that simple. Cracking a developer's product for the express purpose of using it on your own terms is incredibly disrespectful to the developer. She worked hard to produce that software, she deserves respect, and she has the right to set out her own terms. You the end user, on the other hand, did exactly jack shit to create said software. Where do you get off telling us that it's morally okay to tell the developer to go piss up a rope?

If you disagree with a developer's terms, them do not use the software. Period.

Software development takes time. Software development takes energy. Software development takes thought. Software development is always, at some point, a royal pain in the ass. Software development is a labor of love. That you have the gall to even suggest that the end-user has the right to dictate their own terms to the developer tells me that you have never, ever developed software of any real magnitude.

There are precious few ways to keep people from pirating software, but damned if I'm going to let you claim that it's the right thing to do.

Re:Yawn... Copy Protection...

[pclminion]

When oh when will the software publishers learn? COPY PROTECTION DOESN'T WORK. IT D O E S N ' T WORK! So long as the 'puter can execute the code, I can:

Blithering idiocy (that doesn't impress me in the slightest) deleted

Translation: "Please stop using copy protection so I don't have to go to all this trouble."

That's like asking the attendant at the gas station "Please, can you do me a favor and allow me to rob you WITHOUT a gun this time?"

If you're going to be a thief, then you're going to be made to jump through hoops. Tough luck for you, you thieving loser.

Captain Hector

[Y-Crate]

In case you are wondering who the often-referenced Captain Hector is, he is a character that would appear in Escape Velocity: Overrride.

You would be cruising along the galaxy when a ship buzzed by and a Captain Hector would send you a message reminding you to register if you liked the game.

If you waited too long to register, or just never bothered, Captain Hector wouldn't just buzz by anymore. He would stop, and train his guns on you and blast away at your ship.

He proved to be quite effective, to say the least.

THe guy is a moron

[BoneFlower]

"But in the shareware industry, which can't function without Internet distribution, this freedom of theft can be much worse."

Hmm... Sharware worked fine on BBS's and through mail order in the late 80's and early 90's. In fact, at least 75% of the software my family used when we started in the computer world was mail order shareware through regular old snail mail. WE didn't even have a modem until we had the PC for about 3 and a half years.

In fact, it was truly shareware... These days, whats called shareware is little more than functional demos. If it dies after a period of time, lacks critical abilities, etc... it isn't shareware.

Shareware registration normally wasn't required to use the program. REgistration generally got you nice things like automatically mailed upgrades, clip art collections(in the case of programs that used such things) printed manuals, document templates, level editors, stuff like that... Cool stuff that made the program more useful, but the program still did all that it was advertised to do even without registration.

These days, it may do all its advertised to do... For 30 days.

I *TRIED* to buy shareware.. this is the problem..

[takochan]

This is an interesting debate.

I think shareware authors should be paid for their work. Shareware is cheap, shareware is great..

But...

In fact, I tried on 3 instances to buy/register shareware.. and this is what happened.. I think this is part of the problem...

1)Trumpet (a TCP IP stack from several years ago).
Buy the program, registration never shows up in m ail.. wait.. email back and forth..wait some more.. in meantime, trial expires, re-install wait somemore. Client I am billing hours for is getting unhappy.. Calling to Australia to get it sorted out was not fun either.

2)DFX (an sound effects addin for winamp)
Liked it, and tried to buy a copy with their VISA card purchase screen... then.. nothing happens.. no registration comes.. nothing..wait days... nothing happens, no reply, no program... nothing.. I write email to them.. nothing happens..no reply..

Finally I *CALLED* the company, to ask them what is going on. They said that my visa transaction was rejected (but they never bothered to inform me of this, even though they collected my email address (just to send me spam I guess?). When I asked the sales rep at DFX what is wrong, they told me that my destination address and billing address were different, (I am an expat overseas) so.. transaction just gets automatically rejected, bin'ed.. period. No mail, no reply, no followup, nothing.. rejects just goes to /dev/null..

They didn't email me when the Visa was rejected (or ask where I live.. or anything), nor did they even bother to reply my original emails.
The answer the DFX rep gave me on the phone to all this was... "well, it is just a $15 program, so we can't spend too much effort (ie any!) to deal with things that might come up".

3)NJstar
It is a great program. But they wanted me to send checks to Australia or something in AUS dollars.. gee.. how to I do that.. the bank will charge me $50 in processing fees (after waiting in 3 lines at 20 minutes a pop because no one would know how to draw up a foreign denominated check), for a $25 program..

Those are my stories..

..and people wonder why they don't register their shareware...?!. ..

...because it is too complicated
to pay for it, thats why.. fix that, and then
I am ready to buy lots of great stuff.. but
right now it is just too much hassle I discovered,
so I just stay away from it..

Re:Some helpful links with reg code generation inf

[captaineo]

There is a variant of this system that would be virtually impossible to crack... Intel & AMD would have to embed a private key in the CPU core. When buying software, you would present the public key that corresponds to your CPU. The software vendor would check this against a list of valid keys published by Intel (to prevent people from making their own key pairs), encrypt the software using your public key, and then send it to you. Your CPU would decrypt the code as it executes using the private key embedded in it. The binary would not work on any other CPU.

A hardware-based system like this is many orders of magnitude more secure than a software-based system, because the software remains encrypted all the way up to the CPU. The only way to break it would be to find one of the embedded private keys ($$$ equipment)... Or to convince a software vendor to encrypt with a made-up key that you know both public & private parts of...

BTW, this is also the basic framework for audio/video copy-prevention systems. (CSS works like this, except there are only a handful of private keys, and the CSS encryption algorithm is flawed)

The problem with today's Shareware

[viktor]

As I see it, I can understand that people won't pay up. Looking at Windows, PalmOS and MacOSX shareware markets the same trend is obvious: The majority of today's shareware seems to be minute utilities, that performs one very simple task and costs $15.

I can definately understand that people get a very strange idea of the Shareware market. Originally, Shareware was fully functional and often complex software packages that the author asked $10 or so for. Today it's often nagware or crippleware (i.e. not at all fully functional software), and the price is often set way to high.

Of course people get the idea that Shareware is (somewhat exaggerated) "expensive crap".

I think that if the Shareware market cleaned itself up, by making sure that crap software, or very simple software, is released as PD (or Open Source) as it "should", and also making sure that the prices asked are, in fact, cheap, things could be very different.

I personally am glad to pay $10 for a better datebook for my Palm, but I won't pay $15 for a program that edits one entry in the Windows registry. And the very fact that so many people release shareware waaay to expensively puts me off the entire market.

/Viktor...

Price as a Barrier to Entry

[awol]

There are many people who will use "cracked" software (take cracked to mean made available by means other than as the author intended). And yes many of those people will try and use the channels of "legitimate" users to get upgrades, new keys, whatever.

What is important is that most of these people will not pay for the software if it is made inaccessible to them. This is the reason why the software industry has been pretty soft on places like China. If they force compliance they will just lose users because the people in question find the price (whatever it's level) a barrier to entry.

Look at a given game. You like it, you install it and you find the "crack" to make it forever playable. Play it lots and then find that the software stops working, you are miffed, (since no new crack can be found) but because its just a game, you move on to the next crackable game, or better yet an 80% as good freeware version. This _is_ the way a lot of software consumers work. A specific piece of software is worth nothing to them whilst "accessable" alternatives exist.

So there are two alternatives. Make all variants inaccessible (and oh how the media industry is burning cash to do that) or change the pricing model so that until you have a viable paying user base the software does not exist.

Oh and in case you didn't notice, Free Software falls into the latter category (really. It does).

Re:I *TRIED* to buy shareware.. this is the proble

[Queer Boy]

I would venture a guess that your experiences have been atypical. I'm pretty sure that Ambrosia has done what they can to ensure that people will have an easy path to registration.

Actually, Ambrosia themselves admit they have a flawed design. They admit they have inconvenienced paying customers. The fact that I should ever have to interact with them after the initial purchase of their product, just to use the product is absurd. Their prices for their products are more than reasonable (except SnapzPro X, I can create an AppleScript that does everything it does with only a default install of Mac OS X), but if any time I go to run an application, and it won't run because of something the author has programmed, that sounds like a bug.

The story on their website is fascinating in terms of a study of human nature, but they have twisted the reality that they tried to base a business around their hobby (which is exactly what they said), then throw in the "baby factor" (which sounds suspiciously like stories you hear from welfare queens: "I need money for my baby I made without thinking about the fact I had to have money to support it.").

Their editorial would have been more effective if they had left out all of the starving artist ridiculousness, it only sells their talent short. I wish more shareware authors would just say, "I am a talented programmer that makes worthwhile applications, and I made them with the intent of being paid for it. Stop ripping me off." Instead you always hear, "You should pay me for my program so I can eat and put diapers on my baby."

The truth of it is that shareware is a sketchy business model, and if you're going into it without realising that, you're going to get burned. I also don't see any difference between these new shareware registration schemes and Windows XP's Activation.

Sorry if I sound like I'm downing shareware, I'm just downing shareware authors attitudes. It's just in my mind Shareware = Application one or a couple talented programmers have worked on, Open/Free (as in speech) = Application tens to hundreds of talented programmers have worked on, and you don't hear OpenSource or collaborative programmers spouting the "will program for food" mantra.

Re:Some helpful links with reg code generation inf

[swillden]

A few points:

• The shared secret is unnecessary and adds a small amount of complexity without adding any security. Just hash the username and timestamp and encrypt it with RSA.
• Don't implement RSA yourself. Grab the source to OpenSSL and borrow an implementation from there. Take their code for implementing padding of the hash as well, because bad padding can make RSA easy to break. Note to overzealous protectors of GPL: OpenSSL is distributed under a BSD-style license.
• A cracker can find where your shareware program does the registration checking and hack it out. Ultimately, there's nothing you can do about this, but you can make his job a little harder. Use Google to find out how to implement debugger detection code. I don't believe really advanced debuggers can be detected, but you can make it harder. Sprinkle the operational code of your software with registration checks (although it's a good idea to avoid checking during heavy processing, and don't make the UI unresponsive, ever -- you don't want to make your software slow). Use some bad software engineering and duplicate the registration checking code in many places, and, if possible, structure it somewhat differently in each. Have the registration-checking code set a bunch of global values, and have other mini-checks scattered around that just test those. Even better, do the same with weird and overly clever side effects. Have different versions of the major checks set different values and place the mini-checks in your code in such a way that you know which major check should have been called last, so that you can test for the right values. Encrypt portions of your registration-checking code and scatter the decryption routines and keys around (use some good crypto, like DES, and some crappy, ad-hoc stuff you invent yourself; the weirder the better, since this whole thing is an exercise in security through obscurity). Decrypt and execute it on the fly. Write your own tiny bytecode interpreter and implement some of your registration checks in your own interpreted language. It's a real pain to trace the operation of an interpreter with a debugger to try to figure out what the code it's executing is doing.

Doing everything mentioned in the third bullet is obviously a significant amount of work, probably more than you put into the software to begin with. You decide how much effort is enough. If your software is both very good and very expensive, you'll need a lot of protection. If your software is really cheap, you don't need much protection at all. If your software sucks, find another hobby, because chances are you aren't a good enough programmer to implement a good and bug-free registration system. Also keep in mind that this sort of registration checking may prevent some amount of infringement, but it's also likely to piss off some customers who would have paid a reasonable fee if you'd just asked nicely and made it easy to do so.

IMO, however much effort you spend on making it hard to crack, you should spend ten times that much on making payment easy.

Re:I *TRIED* to buy shareware.. this is the proble

[llywrch]

> In fact, I tried on 3 instances to buy/register shareware.. and this is what happened.. I think this is part of the problem...

Shareware for Palm OS devices have a nice solution for this: they have agreements with various online sites to take payment for them, & apparently have ways to accept foreign currencies. (For an example of this see http://www.tealpoint.com/register.htm.)

Is there an equivalent service for Windows & Mac customers?

Geoff