Methods of License Enforcement

Methods of License Enforcement

Post by Spam Bai » Tue, 15 Jul 2003 18:04:59



Hi all.

I'm not sure whether this is the most appropriate newsgroup, but anyway...

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

 
 
 

Methods of License Enforcement

Post by buckwhea » Wed, 16 Jul 2003 00:02:08



> We've been asked by a client to develop a method of license enforcement
> for some software they've developed and intend to sell.

but you work for Micro$ith, yes? ;-P

 
 
 

Methods of License Enforcement

Post by Juha Laih » Wed, 16 Jul 2003 02:47:00



Quote:>We've been asked by a client to develop a method of license enforcement
>for some software they've developed and intend to sell.
...
>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...

If you want it secure, you'll use some external hardware. Now the problem
will be to decide how to connect that hardware to the machine. Another
problem might be the cost.

As for activations by contacting the vendor; I might well have reasons
to wish to switch the piece of software from one machine to another
very long after the original provider has gone belly-up/been acquired/
decided to drop support for the product/... . So, this just isn't a good
idea.

One possibility might be to make the customers contact the provider after
the installation media has been delivered, and request for an activation
key (which would be independent of the hardware; just code to activate the
software). Here the provider would need to keep records on the customers,
and whih activation key(s) have been assigned to which customers. Then,
if seeing an unauthorized use of an activation key, at least the provider
would know whom to sue.

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

This comes up rather frequently in various groups, and isn't an easy topic.

As you've read, I pretty much frown upon any "license enforcement", as
it's a potential cause for service downtimes. F.ex., I've seen a firewall
refuse to start after a reboot -- and the cause was that the serial
number chip on the machine had failed; otherwise the machine worked
perfectly.

As an example of a company not using license enforcement, but still
making a rather nice profit I tend to use Oracle.

When evaluating software, I tend to take the licensing method into
account, and heavily favor those without license enforcement. And
there's also some preferences which kinds of license enforcement
I rather see in the environments I run.

As a conclusion, choosing the enforcement system badly may hurt sales
more than piracy ever would.
--
Wolf  a.k.a.  Juha Laiho     Espoo, Finland

         PS(+) PE Y+ PGP(+) t- 5 !X R !tv b+ !DI D G e+ h---- r+++ y++++
"...cancel my subscription to the resurrection!" (Jim Morrison)

 
 
 

Methods of License Enforcement

Post by all mail refus » Wed, 16 Jul 2003 02:53:30



>As for activations by contacting the vendor; I might well have reasons
>to wish to switch the piece of software from one machine to another
>very long after the original provider has gone belly-up/been acquired/

This particular concern can be handled by placing the source code in
escrow so that it will be released to the customer if the s/w is
abandoned.

Quote:>When evaluating software, I tend to take the licensing method into
>account, and heavily favor those without license enforcement.

Agree.  When using s/w with license enforcement I've sometimes wondered
about the egos of the authors who think anyone wants their rotten product.
Put some effort into making it worth using instead.

--

5% will be use for upsetting all the expenses

 
 
 

Methods of License Enforcement

Post by Dimitri Maziu » Wed, 16 Jul 2003 09:53:06


Spam Bait sez:

Quote:> Hi all.

> I'm not sure whether this is the most appropriate newsgroup, but anyway...

> 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.

Right. Yes. OCX in Perl on Linux. What'll they think of next?

Dima
--
...the mainstream products of major vendors largely ignore these demonstrated
technologies...  [Instead, their customers] are left with several ineffective
solutions collected under marketing titles like "defense in depth".
             -- Thirty Years Later: Lessons from the Multics Security Evalution

 
 
 

Methods of License Enforcement

Post by Spam Bai » Wed, 16 Jul 2003 13:53:51



> Spam Bait sez:

>>Hi all.

>>I'm not sure whether this is the most appropriate newsgroup, but anyway...

>>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.

> Right. Yes. OCX in Perl on Linux. What'll they think of next?

> Dima

Please grow up. I said 're-use parts of it'. Not 'and I intend to use
these OCX objects in Linux'.
I hope that you're a uni student and not a lecturer.
 
 
 

Methods of License Enforcement

Post by Dimitri Maziu » Thu, 17 Jul 2003 06:38:56


Spam Bait sez:


>> Spam Bait sez:

>>>Hi all.

>>>I'm not sure whether this is the most appropriate newsgroup, but anyway...

>>>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.

>> Right. Yes. OCX in Perl on Linux. What'll they think of next?

>> Dima

> Please grow up. I said 're-use parts of it'. Not 'and I intend to use
> these OCX objects in Linux'.
> I hope that you're a uni student and not a lecturer.

No, I work for living, and I can actually do IT so I don't have to
teach it.

Commercial software licenses and their enforcement are a non-technical
problem, and all existing technical solutions make customer's life
difficult, are expensive, fragile, and easily defeated (pick any three).

But then, anyone with enough clue to not say "OCX objects in Perl"
already knows that.

HTH, HAND

Dima
--
The most horrifying thing about Unix is that, no matter how many times you hit
yourself over the head with it, you never quite manage to lose consciousness.
It just goes on and on.                                    - Patrick Sobalvarro