License Enforcement

Discussion in 'Computer Security' started by Guest, Jul 15, 2003.

  1. Guest

    Guest Guest

    Hi all.

    We've been asked by a client to develop a method of license enforcement
    for some software they've developed and intend to sell. Their software
    is an Access app ( yeah I know ... not particularly secure, but they are
    the customer ) but we intend to build some OCX objects, maybe in Perl,
    and re-use parts of it in later projects in Linux.

    I'm currently researching our alternatives. I have NO experience in
    this, so if I say something stoopid, go easy OK?

    I've already checked out some commercial implementations - none of which
    are cross-platform - which isn't necessary but is a big one of our
    wish-list, so I'm now looking at the option of doing it in-house.

    I've pretty much decided to use a product-activation scenario, where an
    installation ID is made from a combination of hardware IDs and some
    other stuff we can pull from the system. This will be encrypted and sent
    to the license provider ( eg via email / phone / something ) and an
    encrypted activation key will be created.

    Some issues with this system are:

    - hardware changes mean they have to re-register ... a possible solution
    is to only use the motherboard ID ( which isn't likely to change without
    a re-install anyway ), though this may not be unique enough.

    - users don't like product activation. I can see their point here...


    Any comments / suggestions? I have done a pretty extensive search of
    groups.google.com and found almost nothing on the topic.

    Am I approaching this the right way?

    Thanks for any help!

    Dan
     
    Guest, Jul 15, 2003
    #1
    1. Advertisements

  2. Guest

    Jim Watt Guest

    although you can do all sorts of things, they are more likely
    to piss off the end user of the product.

    stick with an activation key based on the users name.
     
    Jim Watt, Jul 15, 2003
    #2
    1. Advertisements

  3. Guest

    Bill Unruh Guest

    ]Hi all.

    ]We've been asked by a client to develop a method of license enforcement
    ]for some software they've developed and intend to sell. Their software
    ]is an Access app ( yeah I know ... not particularly secure, but they are
    ]the customer ) but we intend to build some OCX objects, maybe in Perl,
    ]and re-use parts of it in later projects in Linux.

    ]I'm currently researching our alternatives. I have NO experience in
    ]this, so if I say something stoopid, go easy OK?

    ]I've already checked out some commercial implementations - none of which
    ]are cross-platform - which isn't necessary but is a big one of our
    ]wish-list, so I'm now looking at the option of doing it in-house.

    ]I've pretty much decided to use a product-activation scenario, where an
    ]installation ID is made from a combination of hardware IDs and some
    ]other stuff we can pull from the system. This will be encrypted and sent
    ]to the license provider ( eg via email / phone / something ) and an
    ]encrypted activation key will be created.

    ]Some issues with this system are:

    ]- hardware changes mean they have to re-register ... a possible solution
    ]is to only use the motherboard ID ( which isn't likely to change without
    ]a re-install anyway ), though this may not be unique enough.

    ]- users don't like product activation. I can see their point here...


    ]Any comments / suggestions? I have done a pretty extensive search of
    ]groups.google.com and found almost nothing on the topic.

    a) Any activation procedure will make your customers your enemy. Not
    only do youtak e their money but thenmake them jump through hoops to use
    the damn stuff. suddenly a computer goes down and not only do they have
    to pay for a new one and find those damn backups, but then the program
    they need nolonger works and that manual with the license number got
    lost in the fire as well. One of the most precious comodities a business
    can have is its customer good will, and you have just blown it to hell.
    b) Physical 'Activation'-- eg the cdrom must be in the drive to run
    theprogram. Better, but then that cdrom gets chewed up by a dog, and
    theprogram is useless. No backups possible. Would you trust your
    business to this?
    c) License server. Again how well do you handle corruption, and media
    loss?

    You are selling service. How much are you doing the equivalent of a car
    manufacturer demanding that you take the car back to detroit, even if
    you live in California, if something goes wrong? Your program willhave
    bugs in it, which you expect the customer to accept instad of suing the
    pants off you. Treat them with some of the same consideration and
    respect you ask of them.
     
    Bill Unruh, Jul 16, 2003
    #3
  4. Guest

    Bill Unruh Guest

    ]In article <bf01ip$mk6$>,
    ] says...
    ]> Hi all.
    ]>
    ]> We've been asked by a client to develop a method of license enforcement
    ]> for some software they've developed and intend to sell. Their software
    ]> is an Access app ( yeah I know ... not particularly secure, but they are
    ]> the customer ) but we intend to build some OCX objects, maybe in Perl,
    ]> and re-use parts of it in later projects in Linux.
    ]>
    ]> I'm currently researching our alternatives. I have NO experience in
    ]> this, so if I say something stoopid, go easy OK?
    ]>
    ]> I've already checked out some commercial implementations - none of which
    ]> are cross-platform - which isn't necessary but is a big one of our
    ]> wish-list, so I'm now looking at the option of doing it in-house.
    ]>
    ]> I've pretty much decided to use a product-activation scenario, where an
    ]> installation ID is made from a combination of hardware IDs and some
    ]> other stuff we can pull from the system. This will be encrypted and sent
    ]> to the license provider ( eg via email / phone / something ) and an
    ]> encrypted activation key will be created.

    ]As I've read, the people are saying that your customers will hate you.
    ]While I'm sure that customers will be upset when they have to do an
    ]install in the middle of the weekend or night, if you overcome the need
    ]to contact you for reinstalls then it's a non-issue.

    ]I suggest that you follow the hardware/user ID method, then make a file
    ]that they can export and save so that if they have to reinstall on the
    ]same computer they don't need to call you. Make it so that a key is
    ]saved on Diskette.

    ]If you pick something like CPU type/speed, Hard drive, Memory, Video
    ]card, OS - let them change any one without a reset.

    And what would be the prupose? anything someone changes teh cpu, almost
    all of those are liable to change as well-- since if you are upgrading
    of fixing a dodgy system you will change more than one thing. And if you
    can change any of them what is their purpose?
     
    Bill Unruh, Jul 17, 2003
    #4
  5. Guest

    mto Guest

    Take a good look over at Extremetech at the user backlash towards Intuit and
    both their tax prep software and Quicken over DRM before you proceed -

    http://www.extremetech.com/article2/0,3973,1088341,00.asp
     
    mto, Jul 17, 2003
    #5
  6. Guest

    joe Guest

    joe, Jul 25, 2003
    #6
  7. Guest

    sotwr9

    Joined:
    Apr 28, 2009
    Messages:
    1
    Likes Received:
    0
    Product activation

    While some of these criticisms used to apply to product activation systems, the technology has improved.

    Search on knol (dot) google (dot) com under 'product activation' for a couple of articles on the topic.
     
    sotwr9, Apr 28, 2009
    #7
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.