Can I Licence my macros?

[Michelle]

Is it possible to produce something which I can give to my client, but which
they can't just pass on to others.

I want it to work for them but not if they give it to someone else.I know I
could password protect it, but then they can just tell people the password.

Any ideas?

Thanks

M

 

[Jarek Kujawa]

maybe sth. like this?

http://www.cpearson.com/excel/WorkbookTimeBomb.aspx

 

[JLGWhiz]

If you are doing business as a provider of software or if you hold copywright
to software or both, you can include a provision to the buyer that they
cannot pass the product you sell them to others. This does not prevent them
from doing it, but if you can prove they did, then you can bring legal action
against them.

That is the simple version. I would advise you to seek professional legal
advice if you intend to sell your software products, or to develop products
under contract to others.

 

[Jon Peltier]

Don't give the password to the client. If you really don't trust them,
charge a lot more for the work, or install a time bomb and make them retain
you to extend the life of the program. If you want to be completely OCD
about it, you could include a mechanism that lets it work on each separate
machine, using a key you provide that is based on an encryption of the
machine's hard drive serial number. This is more work, but gets closer to a
secure solution.

- Jon

 

[JE McGimpsey]

No problem at all with the former, but if anyone ever did the latter, it
would be the last time I used their services...

And if I still had any interest in using the macros, I'd be tempted to
take the 30 seconds and disarm the bomb. My business operations
shouldn't depend on your not getting hit by a bus...

 

[Michelle]

Is there a simple API to get the machine's hard-drive serial number - I like
that idea

Thanks

M

 

[JE McGimpsey]

Are your macros *so* valuable that your clients will pay you to
hard-code their drive serial # into a compiled add-in, leaving
themselves crippled if they have a hard-drive crash?

And if you're not planning on distributing them in a COM add-in, adding
protection is rather useless - it takes about 30 seconds to disable VBA
protection.

 

[Jon Peltier]

Are your macros *so* valuable that your clients will pay you to

hard-code their drive serial # into a compiled add-in, leaving
themselves crippled if they have a hard-drive crash?

Value is relative.

I would implement a routine that gave them a 30 day introductory period,
during which they send me an email with a code provided by the program. This
code would be some kind of crypto of the HD serial number and the date of
initial use or date of renewal. I would input this code into a routine on my
computer which would spit out another code, which they enter into a
registration screen. Their copy of the program would accept the returned
code, compare the unencrypted HD SN with the HD present on their machine,
and if it matches, it would add 12 months to the expiration date.

And if you're not planning on distributing them in a COM add-in, adding
protection is rather useless - it takes about 30 seconds to disable VBA
protection.

30 seconds for you or me, 10 minutes for Michelle, and an indeterminate time
for Joe Client.

Granted, for a generally trustworthy client, none of this is necessary. But
Michelle may have a sleazoid on the line. In fact, I developed a similar
system for a client who had some sleazoid clients who wanted to ignore the
EULA and install one licensed copy of a large package onto dozens of
machines.

- Jon

 

[Jon Peltier]

I haven't had this problem with clients. But I usually put a time bomb into
the first project I do for someone, just to make sure they will pay to use
the work I've provided. In my experience, even the most advanced of my
clients have no idea how to bypass VBA passwords, or even sheet passwords,
and the simple code that makes up the time bomb is beyond them. I think I
could tell them that there's a complex protection scheme, and 99% would
never figure out that there isn't.

And really, in this context, the time bomb is like any other renewable
service. If you're worried about your provider being wiped out by a meteor,
you should negotiate for a more permanent solution.

- Jon
-------
Jon Peltier, Microsoft Excel MVP
Peltier Technical Services, Inc.
http://PeltierTech.com/WordPress/
_______

 

[JE McGimpsey]

Value is relative.

I agree - that's why I asked the question...

I would implement a routine that gave them a 30 day introductory period,

The motivation behind the question was more to the point that, while the
type of system that you describe may well be warranted for a
comprehensive commercial application, it's probably NOT worth the
development costs for a few macros.

Either spend a lot on developing the protection scheme, and charge a lot
for the application, or sell it cheap enough and provide good service to
encourage payment.

My skepticism came from the type of questions asked by the OP, which
suggested to me that there would be a sharp learning curve to produce
anything solid.

The flip side is, only the most foolish of businesspeople, IMO, would
agree to license anything critical (and so worth substantial
remuneration) containing a time-bomb on a period-to-period basis from a
single individual, and that therefore the potential return on investment
was low compared to the investment in developing comprehensive
anti-piracy solutions.


That doesn't mean that there aren't foolish businesspeople out there, of
course.

 

[JE McGimpsey]

I haven't had this problem with clients. But I usually put a time bomb into
the first project I do for someone, just to make sure they will pay to use
the work I've provided. In my experience, even the most advanced of my
clients have no idea how to bypass VBA passwords, or even sheet passwords,
and the simple code that makes up the time bomb is beyond them. I think I
could tell them that there's a complex protection scheme, and 99% would
never figure out that there isn't.

Dunno - you may be right. I'm probably jaded by how easy it is to find
info on bypassing VBA protection. I've got lots of clients that "just
want to peek under the hood".

I'm also jaded by the fact that the first commercial application I ever
produced, in 1979 on a CBM/PET, was pirated...

And really, in this context, the time bomb is like any other renewable
service. If you're worried about your provider being wiped out by a meteor,
you should negotiate for a more permanent solution.

Agreed.

 

[Harlan Grove]

. . . In my experience, even the most advanced of my
clients have no idea how to bypass VBA passwords, or even sheet passwords,
and the simple code that makes up the time bomb is beyond them. I think I
could tell them that there's a complex protection scheme, and 99% would
never figure out that there isn't.

....

Maybe, but there's that nasty last 1% ready to rob you blind.

The best approach may still be code obfuscation, which is simple
enough to implement in scripting languages, e.g., declaring twice as
many variables as needed in every procedure, each with 31 char long
filenames with 28 of those chars picked at random and the 3 truly
identifying chars at different char positions. Also good to use as
many : statement separators as possible.

Still, that'll only discourage 999 out of 1000, leaving the nastiest 1
out of 1000 who know how to unobfuscate.

As is always the case, if you need robust IP protection, use a
compiled language.

 

[Jon Peltier]

"Jon Peltier" <[email protected]> wrote:

So we're both right.

The motivation behind the question was more to the point that, while the
type of system that you describe may well be warranted for a
comprehensive commercial application, it's probably NOT worth the
development costs for a few macros.

Generally true, but I sensed some hard feelings.

Either spend a lot on developing the protection scheme, and charge a lot
for the application, or sell it cheap enough and provide good service to
encourage payment.

My skepticism came from the type of questions asked by the OP, which
suggested to me that there would be a sharp learning curve to produce
anything solid.

I sensed this as well, but continued on knowing the animosity toward the
client.

The flip side is, only the most foolish of businesspeople, IMO, would
agree to license anything critical (and so worth substantial
remuneration) containing a time-bomb on a period-to-period basis from a
single individual, and that therefore the potential return on investment
was low compared to the investment in developing comprehensive
anti-piracy solutions.

But think of the learning opportunity.

That doesn't mean that there aren't foolish businesspeople out there, of
course.

Yep.

- Jon

 

[Jon Peltier]

Dunno - you may be right. I'm probably jaded by how easy it is to find
info on bypassing VBA protection. I've got lots of clients that "just
want to peek under the hood".

Bill for a day or two of "repairs" and they'll learn their lesson.

I'm also jaded by the fact that the first commercial application I ever
produced, in 1979 on a CBM/PET, was pirated...

Ouch. I had a few clients hose me back when I was starting, one guy for a
couple grand, so I started inserting the time bomb. Since then I have had
nobody welsh on payment. But as I said in an earlier post, I think all I
have to do is say I have implemented a security feature, and they think
since I did it, it must be good. Ha!

Actually it did help one time. A client's Accts Payable department tried to
change our terms to net 90 days. The time bomb knocked off in 30, and the
techie called me. I gave him ten more days, but told him I hadn't been paid
yet. He was aghast, I got my check, and he got his fully operational and
unlimited program, all within that ten days.

Now I have my own commercial utilities on the market, and I haven't taken
any steps anywhere near as draconian as I've described. I guess I could if I
had to. But the utilities are pretty cheap, they're pretty decent, and they
fill a feature gap, so the barrier to purchase is low.

- Jon