* The Business of Software

A community discussing the business of software, from the smallest shareware operation to Microsoft. A part of Joel on Software.

This community works best when people use their real names. Please register for a free account.

Links:

» Business of Software FAQ
» The Business of Software Conference (held every fall, usually in Boston)
» Forum guidelines (Please read before posting!)

Moderators:

Andy Brice
Successful Software

Doug Nebeker ("Doug")

Jonathan Matthews
Creator of DeepTrawl, CloudTrawl, and LeapDoc

Nicholas Hebb
BreezeTree Software

Bob Walsh
host, Startup Success Podcast author of The Web Startup Success Guide and Micro-ISV: From Vision To Reality

Patrick McKenzie
Bingo Card Creator

"Don't Annoy Honest People"

As you pointed out the issue of activation/licensing is never an easy one.  As small ISVs we need to try and control piracy but not at the expense of the honest customer.

We have been debating this issue with a new product we will be releasing soon.  Currently we have implemented an activation scheme to tie an install to a specific PC based on a generated hardware ID, similar to the MS approach.

As you pointed out there is always a downisde to this and problems can come up managing issues and support.

I would be curious to know what others are using and what their feelings are on customer feedback and piracy they have run into.

We would like to make things as easy as possible for our users.  Most will be very non technical, possibly first time PC users and on disconnected standalong PCs.

What scheme do most think is the best mix for hte small ISV?
Mark Langille Send private email
Monday, February 21, 2005
 
 
I'm also in the process of writing an application that at one point was going to use online activation.

I've since decided not to implement activation, only serial numbers to unlock the demo mode.

I've come to this decision based on posts to a number of forums (including this one and the ASP), where activation turns out to be one of the biggest source of support queries. I for one could do with eliminating that kind of hassle right from the start.

--
Ian
Ian Jones Send private email
Monday, February 21, 2005
 
 
Are you planning to use a single serial number or specifc to each client?  Just curious as the issue of "serial number sharing" is always hte big issue.  Someone buys a copy and shares it with 5 friends.  No easy way around this other than activation is our concern.
Mark Langille Send private email
Monday, February 21, 2005
 
 
My app is most likely to be used by business, so there's unlikely to be much sharing going on, most businesses are pretty trustworthy in this respect.
Even so, it's a Serial Number Name / Serial Number pair, so sharing would require the person who didn't buy the key to use the sharer's name or company name. This is another good deterrent as people don't like to see other people's names in the splash screen / about box, makes them feel "dirty".

None of the above is cast iron, if someone really doesn't want to pay for the app, they won't.
Ian Jones Send private email
Monday, February 21, 2005
 
 
I don't have a quick solution to your problem - I wish I did, because I have the same problem.

I was thinking this, though. As small companies, we have different needs than big companies. MS's ideal protection systems might not our ideal.

So, I was thinking. We have small numbers of customers. How feasable would it be to create personalised builds of your software? Tools like Ant, NAnt, and make it technically possible.

When the customer tells you their name and email address, for example, you put those into a source file and build them right into the program as constants. Then, only offer support through that email address. Post updates to their home address. Put footers on printed output saying 'Printed by John Smith, 21 Feb 2005' Lock the build somehow to those details. You could even build time-limits and similar in.

You could actually turn the negatives of lockdown into a positive, customised feel. People will be less inclined to copy it in the way people are less inclined to buy engraved jewelry with someone else's name on it.

Anyway, the general point is- the solutions of big companies shifting thousands of copies might be very different from the solutions of small companies shifting tens of copies.
Steve Cooper Send private email
Monday, February 21, 2005
 
 
I wrote an essay on this subect some time back. While it references a programmers toolkit (which won't be of much interest here) the general concepts are applicable to any small ISV.

http://www.capesoft.com/opinion/CopyProtection.htm

Cheers
Bruce
Bruce Johnson Send private email
Monday, February 21, 2005
 
 
One of the things that I've done is make my registration codes time-sensitive. When someone registers a copy of a product, they get a name/key pair. The key includes an expiry date (2 weeks from the registration date), which means that if you enter the key after the expiry date it won't work. Since most people will register the day they get the key, it isn't usually a problem.

After the expiry date, or if you need to reinstall the product, you can request a new key right from within the program. I keep a list of any pirated keys (or, if I notice that one key is being used an inordinately high number of times, it goes on the list) and disallow receiving a new key with a message like "this key cannot be renewed. Please contact support for assistance." This is all handled with a simple webservice that I created for  this very purpose.

While I'm sure it could be cracked by someone with a reasonable knowledge of cracking, it's pretty much invisible to anyone who is using the software legitimately. It isn't product activation, since it doesn't need activation to run (assuming you don't dawdle entering your reg code), but it does help prevent reg code sharing.
Tim Sullivan Send private email
Monday, February 21, 2005
 
 
The main problem about activation or any other calling home scheme is that the customer will have to depend on your business for the rest of the time they need to use the program. A year back, a friend of mine wanted help to reinstall a Bible software she bought in '91. The business that sold the software was long gone, and to this date she is unable to install a sotware she paid for and loves.

As more and more customers get burned out by buying software with activation schemes by little companies and dotcoms, they will stay away from such software, except for big players like Microsoft.

Of course, for you business owner it does not matter if the customer wants to reactivate your software in 2015 and your business is long gone (or even you), but for more and more customers this is a worrisome issue.
Mauricio Macedo Send private email
Monday, February 21, 2005
 
 
I have been considering some kind of pasive system where the user can check for updates and in the background we check if the key is stolen. If it is we set a flag which will stop the product working a couple of weeks later.

What I won't use is a system where the software requires activation before use. As a customer I don't like activation and so I won't inflict it on my customers.
Tony Edgecombe Send private email
Monday, February 21, 2005
 
 
The big issue I see many systems using is assuming that the users PC is connected to the net, be it for validation, checking for pirated keys, etc.  This is not an assumption that can always be made.

In terms of reactivating the app down the road when the company may not exists this is a very valid point and one that might stop customers from buying from the little guys.  Basically any scheme that uses activation or time limited serials will have this issue :-(

There seems to be no simple solution.  Either you have a unprotected app or one with a single serial number, or you have an activation ot time limited system, both of which have issues.

I guess it does come down to the issue of trust and trade off betweem lost profit and cost of servicing activation systems.

The serial linked by name is probably the simplest yet.  It at least makes the user visibily see the info and what they might be pirating.

In the end anything can be stolen, it comes down to preventing simple theft.  My concern here is that the simple serial number seems to make even simple theft too easy by sharing keys.
Mark Langille Send private email
Monday, February 21, 2005
 
 
Perhaps it's just my personal morality, but in the event of my company going out of business I would send out keys that would work indefinitely, or, alternately, open source or freeware the application.

Not all companies, I understand, are as altuistic, but I'm not too worried about Microsoft going out of business. :-)
Tim Sullivan Send private email
Monday, February 21, 2005
 
 
"Perhaps it's just my personal morality, but in the event of my company going out of business I would send out keys that would work indefinitely, or, alternately, open source or freeware the application."

Will your customers believe that?  If not, they'll go with a big established player who is likely to be around for the next 10-20 years.
NoName
Monday, February 21, 2005
 
 
I have thought about this at length while finishing http://www.lingolanguage.com - as you rightly point out the principle is "don't annoy honest people".

"There seems to be no simple solution.  Either you have a unprotected app or one with a single serial number, or you have an activation ot time limited system, both of which have issues."

I would not release an unprotected app or one with a single serial number. At the very least, you could compile a user-name string into the code and show this in the About box etc. If you only sell a few copies a day this is the easiest solution.

Also I don't think activation based systems are suitable for shrinkwrap apps, unless you're Microsoft (this was previously discussed here). IMO online activation is only useful if the app is based on some kind of web service, in which case the activation looks like part of the service.

"The serial linked by name is probably the simplest yet.  It at least makes the user visibily see the info and what they might be pirating."

Do you mean the user enters a user name and serial number? I am puzzled as to how this works - how does the software validate the name and number? Or is any name and number allowed? Or is the information stored in some encrypted form and decoded for the About box etc.

Another possibility is to edit the compiled binary file before distribution, possibly using a resource editor or something similar. Years back, when apps were EXEs on floppy disks I wrote a program that did this. The problem is the distributable needs to be on a writeable media, eg a CR-RW or a floppy disk. Although of course you could do the binary editing on hard disk, then burn to CD.
Bill Rayer Send private email
Monday, February 21, 2005
 
 
The issue with compiling specific versions becomes a nightmare when you release an update as every version out there would require its own update version as well.
It also limits you being able to produce CD copies to give out for sale.
For a small company even with 10-20 sales this can become a headache to manage, as you basically now have 20 products not 1.

In terms of linking the serial to the name basically the user provides their name to you when they purchase the app.  The serial created then embeds this name into itself along with some other app specifc info.  When the user then enters their serial into the application it compares the embedded name to the one entered along with the serial.  If they match then all is good, if they don't then the serial is rejected.  This at least makes them enter the name and serial as a matched pair.  Almost the same as makign custom EXEs only thisway the EXE is the same, only the serial is unique.
Mark Langille Send private email
Monday, February 21, 2005
 
 
In regards to going out of business, I suspect giving out app keys at that time will be the last thing on your mind.  The bank may have seized your assets before this, you could be hit by a bus and unable to, etc.

Also not sure how you would "market" that concept.  Telling the customer you have plans in you fail wont be easy.  It is not as if we can always plan for a company shutdown.
Mark Langille Send private email
Monday, February 21, 2005
 
 
"The serial created then embeds this name into itself along with some other app specifc info.  When the user then enters their serial into the application it compares the embedded name to the one entered along with the serial."

If I understand right, the serial number is an encoded form of the user name? Surely this means the serial number needs as many bytes (or more bytes) than the serial number?

Most Microsoft products have 25 digit serial numbers (I think a 'digit' is 0-9 and A-Z less 1, 0, I and O). Using this system how could you encode names of more than 20 characters or so? Or do you suggest really long serial numbers that customers cut and paste from an email? Thus allowing user names such as:

  Horatio Edouardino Ergastelione Portentious

And what happens if I mis-type my name on re-installation? Eg:

  Joe. B. User

instead of:

  Joe B User

Just curious. There must be a better way...
Bill Rayer Send private email
Monday, February 21, 2005
 
 
I wonder how long until 'Ergastelione' exists in google...
Bill Rayer Send private email
Monday, February 21, 2005
 
 
If you mistype it then it is the same as being wrong.  Same as if you mistyped the serial.  A match is a match, you need to draw a line somewhere.  Same as if someone called the wrong phone number for your business, or used the wrong URL, its not going to work.

For the name you don't embed the name itself.  You create a hash code from the name and embed that.  Then when they enter the name and serial you compare hash codes, ie if the hash code of the name matches the one in the serial then it is a match, otherwise one of the two is incorrect.

You can also use your own algorithm to jumble/cut the name so it may not actually use all of it and will be harder for the hackers to crack.  Your serial generation code just needs ot make something out of the name it can embed and inturn your app can verify. You could use just one letter if you wanted for example.

I'd suggets having a relatively short serial number, maybe 10 or so digits.  Not all users can cut and paste if its on a disconnected PC and you sent them the serial via snail mail.  Again we cannot assume the PC they are installing on is connected to anything.
Mark Langille Send private email
Monday, February 21, 2005
 
 
Mark -

<<I'd suggets having a relatively short serial number, maybe 10 or so digits.  Not all users can cut and paste if its on a disconnected PC and you sent them the serial via snail mail. >>

A lot of this is just good ui.  Microsoft gets away with the long serial numbers by:
1) breaking into identically sized strings (6 characters?)
2) Using capital letters only in the printed number
3) Using a readable, monospaced font
4) Not deleting an incorrect serial number
5) Automatically tabbing from one field to the next

Mike
Bankstrong Send private email
Monday, February 21, 2005
 
 
Agreed on the ui for entry, it needs to be fool proof and simple.

My point was more don't make it some single long code that is hard to enter. 10-30 or so charaters should be fine but I wouldn't go much beyond this.  Also as you say keep it all in one case and make it clear which are numberic and which are alpha.
Mark Langille Send private email
Monday, February 21, 2005
 
 
Every MINUTE you spend on piracy prevention is a MINUTE not spent on product development and marketing.

Most companies become popular enough that anyone WANTS to pirate their software.


Business is war. And you're either making bullets or shooting.


If you release something function quickly, but leave lots of room for update possibilities (new features, etc.) you can ALWAYS add anti-piracy features later AFTER you get some traction in the market (i.e., get some sales $$ rolling in).

Until people are buying your product, it's all just theory.
Mr. Analogy {ISV} Send private email
Monday, February 21, 2005
 
 
+1 for Bruce's article on copy protection:
http://www.capesoft.com/opinion/CopyProtection.htm
Mr. Analogy {ISV} Send private email
Monday, February 21, 2005
 
 
Good article there, Mr A.

OP, Don't "phone home" or time out honest purchasers.

What you don't want is your full working version to be cracked and passed around unbranded, so make your free download demo a permanently crippled bait version to be replaced on purchase with a full working version activated and branded by seperately supplied key locking the client's name and organisation shown on reports, the splaxh screen, etc, to a key string with symmetric encryption. Sure it will still get passed around, but to a lesser extent as crackers have to aquire a branded full version to play with and rumour is they don't want to pay for their fun :-)

Release upgrades often. Minor/Maintenance upgrades can use the same encryption so you won't need to issue new keys. Major upgrades can be a (possibly discounted) new purchase and come with a new key generated by a different emcryption master key.

This implies a release schedule with planned upgrades where core functionality goes out in V1.0 and *DESIRABLE* new features to be added in V1.1 et seq.  The main thing is to roll V1.0 out there and start selling.

Also, the demo version has to be useful in some fashion so it's kept around and passed around e.g. you can sample net packets going past but you'll have to buy to log them ... Put a timeout in the demo so after your next release it will nag about downloading a new demo version ...

Knowing where to apply your hopefully limited supply of paranoia is learned on the job. Best of luck.
trollop
Monday, February 21, 2005
 
 
Good point about new keys with new releases.  Will at least keep those that copy it scrambling a bit more and show the value of actual purchase.

As for phoning home, no we wont use that nor can we.  For our market most all PCs will be disconnected at remote locations.

In terms of the demo we also need to release a full version that the user can easily register.  Doing another install of the full version over a a previous demo would be extra headache for our users, which may be first time PC users and again at remote locations.  We want to be able to distribute on CD or have the user download the program once, try it, and register if they want the full version.  We are planning to have a data limit in the demo so they can only add X number of entries, after which it will be read only version.  This will allow them to try it and enter real data under real conditions then register if they see value.

I guess a big part of the licensing/piracy scheme is knowing your customer and what suits their circumstances and balancing piracy against usability and support.

In the end, without some form of activation linking the software to the PC, we are at the mercy of the user's honesty.  Hopefully providing a unique valuable product with good honest support will help limit theft.
Mark Langille Send private email
Tuesday, February 22, 2005
 
 
Incidentally - regarding the "I'll give out perm codes when I go bust" approach - it may not be that simple.

Most businesses will go bust because they run out of cash. When they go bust, most businesses will owe someone (bank etc) cash. At this point "you" do not own the software anymore, the liquidator does. The liquidator will attempt to get as much revenue as possible - which includes selling your source code / copyright etc.

Thus "you" (as the developer) do not have the right to issue perm codes, or indeed do much of anything after the company goes bust. If you do it immediatly prior to going bust you might also have problems. (asset stripping etc.)

Of course you may just lose interest, and make the code "open" without the company going bust - but the customer shouldn't really rely on that scenario...

Bruce
Bruce Johnson Send private email
Tuesday, February 22, 2005
 
 
There was, possibly still is, a fashion for of putting source code or keys in escrow against the day. If the escrow is spelled out in the EULA then your creditors may not be able to interfere. IANAL. Would cost money, of course but may make it possible to sell into truly paranoid buyers.
trollop
Tuesday, February 22, 2005
 
 
Escrow agreements typically need to be created with each client.  This may be an issue when dealign with a number of customers for a smaller piece of software.  Unless you are selling if for thousands of dollars, the legal costs would not likely be worth the effort.
Mark Langille Send private email
Tuesday, February 22, 2005
 
 
One piece of software that I use all the time uses a key file that you can place in the root of the appliaction and it will pull out the user's name and zip from it to be displayed.  The key file is encrypted and the user's name shows up in the caption bar. 

I was thinking of doing something similar and embedding the user's name and email address in the licensing file.  Then the splash screen and the about have the users name and email address displayed for all to see.  The problem is that if they switch email addresses at work, likes say from first.last@company.com to Flast@company.com then it would be showing an email address that is not valid.  And people could always have just used a fake/temp email address to get it.  To an honest person, it is probably not a big deal to have their name/email there.  To a dishonest one, they will just fake it.  But you could then keep track of how many times your software was updated using the variaous email addresses and can make the software stop working like an earlier post suggests.
Steve Send private email
Tuesday, February 22, 2005
 
 
I have just changed my registration code around, thanks to the comments and the original article.

I have basically made it now to only require the user name/company, etc to be entered along with a serial tied to that name.

At time of purchase I will use that purchase name to create a unique serial that has the name, product, version embedded into the serial.  Each time the app runs it rehashes the info against the entered serial for a match.

I plan to now display the user name on the main form title and all reports to make it clear who owns the copy.

This will allow the user to reinstall as needed without getting a new key.  When a new version or update is released I will also send all registered users a new key for the update.

Hopefully this will offer enough protection with limited user hassles.  Still wont prevent sharing but hopefully the value of the product will make it worthwhile not to pirate.
Mark Langille Send private email
Tuesday, February 22, 2005
 
 
>I was thinking of doing something similar and embedding the user's name and email address in the licensing file.  Then the splash screen and the about have the users name and email address displayed for all to see

Yes, in fact, on all my reports etc, and on the top of each form, the company name shows.

So, to active a product, all I have to do is send them a small file. In that file is the company name,  tax number, and a few other things.

So, while anyone, or employees can copy the program and the key file, they can’t really take the software to another company. (well, they can, but if they do this, they will in fact be doing a demo for you!! ..as clearly they will not want to see another company’s name (especially a competitor) on all the reports!! And, some of the reports even have their tax number on it!!

So, I don’t make any restrictions in the ability of a company to make copies of the program…but I can tell you from experience that people who use the software often move on to other companies, and then call me up to ask how to get a copy! DO NOT overlook this fact that the people who USE the software, not the company or managers are the ones that sell it for you!. In one area, I now got 3 users of the software, and this is result of people working at one company, and moving on to others.

 And, in fact, right now that person wants MORE divisions (with different company names!) to use the software! And, I fully expect as people change jobs, and move on from those 3 companies to other companies, then the use of my software will again expand in that area (if your software is good, then people will like it..and they will want to use it when they move on to new jobs...and people tend to move on to jobs with simular needs!!).

And, I know for a fact that in several of these cases, these employees did in fact copy the program, and take it with them to the other companies.

And, in once case, a organization that owns several companies had a employee move. It turns out that they call up the tech support guy (who obviously also does work for both companies) to move her stuff from the old computer to the new one. Of course, my software got moved along with this!! However, I now just got a email with the new company name, tax number etc..as this person wants to use the software.

So, it is VERY difficult to use a product that shows the company name on all reports, and on top of most forms when being used!

So, I would make it VERY easy to copy your software, but make sure the original company name and info appeals on main menus, reports etc. 

Doing so allows people to market your software for you!!

Albert D.Kallal
Edmonton, Alberta Canada
Kallal@ msn.com
http://www.members.shaw.ca/AlbertKallal
Albert D. Kallal Send private email
Wednesday, February 23, 2005
 
 
Albert -

What do you make?  The only product I saw on your site was RIDES.

Mike
Bankstrong Send private email
Wednesday, February 23, 2005
 
 
It is actually a version of Rides for managing events…not tours (there is no Hotel compounets to this version).
 
And, NO, I don’t have a web site for the product yet!...but that will come in its own time. I will probably run it for about 1 more year, and then start to spend some money/time etc. to market this product.

It is only being used in a few cities right now, but as I mentioned, every time some company starts to use it, and some employees move, then that next company also wants it (so, it grows its own user base in each City it starts being used).

So, the lesson here is to make sure that you don’t put anything in the software that would prevent them from copying it. And, I can’t say this applies to all software, but you users are the best source of free marketing. You get users hooked, and they move to another company, then that company should also want my event system! (if I did good job).


Albert D.Kallal
Edmonton, Alberta Canada
Kallal@ msn.com
http://www.members.shaw.ca/AlbertKallal
Albert D. Kallal Send private email
Wednesday, February 23, 2005
 
 
Albert: so you are possibly suggesting putting ID and Key strings in a .INI file or similar rather than in the Registry to simplify snaffling a working copy with (say) XCOPY? IIRC you're into Access bigtime so maybe you'd park the ID in a table somewhere.

Very Good Point though. I brand all reports etc with ID but as I put ID and Keys in the Registry a copy of our doohickey will act as if it were unregistered awaiting the registering Registry entries (apologies for the unfortunate repetition).
trollop
Thursday, February 24, 2005
 
 
We decided to store ours in the registry but same concept if it is missing then it will be in demo mode.  Less chance of a user accidentally deleting or changing the file as well.

It is never really safe to just XCOPY an app anyway, an install would be much better to ensure the proper runtime and related files are in place.

In terms of exposure in other companies as people take it with them, again it comes down to who your target users are.  Not all will be in a position to give you this added marketing if they are not that type of user. But either way displaying their reg info on all screen and reports can only help.
Mark Langille Send private email
Thursday, February 24, 2005
 
 
>Albert: so you are possibly suggesting putting ID and Key strings in a .INI file or similar rather than in the Registry to simplify snaffling a working copy with (say) XCOPY?

Yes, that is exactly what I do. (I use a file with a dll extension, and in that file is the customers name, and a check sum key).

So, if they copy the directory with all the files in it, then the application will work on other computers...

Albert D.Kallal
Edmonton, Alberta Canada
Kallal@ msn.com
http://www.members.shaw.ca/AlbertKallal
Albert D. Kallal Send private email
Thursday, February 24, 2005
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz