[AccessD] The Polyp Problem

John Bartow john at winhaven.net
Fri Jan 21 12:59:56 CST 2005


Also good clauses. I can't say if your glasses are rose colored or not but
legalities and realities aren't the same thing to most people I've known. I
cover every avenue I can when setting up an initial contract agreement or in
my license agreements with my non-custom software. However, when push comes
to shove one has to look at what the cost of the shoving is going to be.

I lost a government contract some years ago because one of the "staff"
people who was present at my dealing was also the front person for a
developer. She took my materials (which in hindsight were much too specific)
and had him write a program - thinking that she would get the contract via
him because she had an "in" with her employer. When she started talking her
app up to other employees I caught wind of it and got a hold of some of
"her" applications specific (which just happened to be directly derived from
my materials). I called a lawyer that deals with these matters and after
much discussion it came down to making a decision to spend as much money to
get what I had potentially lost in the deal. I decided to drop the issue
from my recovery standpoint. I contacted the employer and simply told them I
would sue them if they used her program (not just bought it). I also
contacted all other employers of that nature in her general vicinity and
informed them of the same. 

Immediate aftermath:
She never (to my knowledge) sold one copy. I didn't gain but she lost more
for her deceit because someone had to pay that partner in crime to program
all of that. (BTW: I tried to contact him to see if he knew what had gone on
but he would never return my calls). The employer has been through two other
applications to meet this need and are now looking at a third.

More recent events
I was recently contacted by one of the people that sat in on my original
presentation/meeting concerning this application. They are interesting in
meeting with me again. Guess who will have a rock solid agreement for
non-disclosure before I even discuss the matter with them again?

John B. 

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Porter, Mark
Sent: Friday, January 21, 2005 12:16 PM
To: Access Developers discussion and problem solving
Subject: RE: [AccessD] The Polyp Problem

I do not develop for outside clients anymore, and I have never had any
problems when I did.  Yes, I was probably lucky.

But can you simply put a clause in all of your contracts or development
agreements that:

a) the customer cannot utilize your application in a production environment
until the contract is complete, and
b) you do not support any production work done with the application until
the final release - which you can hold back on until they are current on
their payment schedule. 

With clauses like these stated clearly up front you should never have to
worry about the legalities.

Or am I looking through rose colored glasses?

Mark

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of John Bartow
Sent: Thursday, January 20, 2005 8:16 PM
To: 'Access Developers discussion and problem solving'
Subject: RE: [AccessD] The Polyp Problem

Karen,
I'm sorry to hear that you have run into bad a client. I've been lucky in
that regard. I have a client that has recently had one of their customers
file for bankruptcy. They have thousands of dollars in income they may never
see because of it. They actually had a policy to limit this customers line
of credit but they had been lulled into ignoring because the customer was
paying the bills. Ran up a bunch of bills quick and then filed, major
bummer.

Rocky and David's ideas of warnings and new license code inputs are very
good ideas. You could also add in time delay code so that at each level the
application either started slower and/or ran slower. I experimented with
this idea for awhile. More so because of people "lending" my software to
others than not getting paid by a client. It was simply a timedelay function
that would be called before a form or function was called to actually
perform its real duty. Once the license term was not met it would display a
message similar to David's idea (below) and then set the timedelay to a
higher number. It worked on custom properties and would be simply to defeat
if you knew how to change custom properties but then if they knew how to do
that they wouldn't be buying my apps anyway. I kind of overwhelmed myself
with the various techniques on how to do this and never did implement it. It
was more of a VBA programming boost for me since I picked the brains of all
the gurus here and I got into classes, etc. yada, yada, yada...
:o)

In the end I decided that I would let them screw themselves by using it
without a license. I hard coded certain information into any output method -
reports, data exports, etc. So essentially they could use it as long as they
like but in the end all of my apps are based on the idea of easy input for
later output. They would either buy a license to get their output or they
would have used it to no purpose. One small app which collects survey data
and is sent in once a year  is what prompted this idea. The output only came
once a year. By the time they get to the time for output the ability to
input the data is gone. I've sold a few copies to places where I strongly
suspect this may have had results.
;o)

Also, and this of course is for future reference, my software license states
that my company owns the software, code and all that and the user is just
purchasing the right to utilize it. My individual contracts for custom work
all state that my company retains all rights to the code and this right may
be purchased via a different contract agreement. I specifically have my
company name listed and avoid any personal connection for a number of
reasons. Company names sound more serious (impression) and if I ever sell my
company I can sell it with all rights to any previous software and
contracts. I don't want any support calls while I'm on the beach by Rocky or
William :o)

I hope all your woes begone!

John B. 

 


-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of
dmcafee at pacbell.net
Sent: Thursday, January 20, 2005 11:45 AM
To: Access Developers discussion and problem solving
Subject: RE: [AccessD] The Polyp Problem

This is what we did with our machines at the company that I used to work
for. A timer was set at ship time counting down from 800 hours. At 200 hrs
remaining the user received a warning, then again at 100 and 50 hours.
You'd
be surprise how quickly they pay when the time has actually run out.

:)

David

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com]On Behalf Of Rocky Smolin -
Beach Access Software
Sent: Thursday, January 20, 2005 9:20 AM
To: Access Developers discussion and problem solving
Subject: Re: [AccessD] The Polyp Problem


Karen:

When they pay, send them an updated mde with no date bomb in it.  And I'd
set the date bomb out like 6-12 months.  Let them get thoroughly hooked on
it.  Then, if they've stiffed you, suddenly it quits working.  I usually put
some kind of cryptic message in like "Fixed Overflow.  Call Tech Support'
followed by my phone number.  Then Application.Quit.

With the key, when the expiration date is within 60 days, upon opening the
app they get a pop up which says 'Your license will expire in xx days.
Call
for a new key.', but wordier.   And there's a place on the pop up where
they
can enter the new key.  My key is like a Microsoft key - six groups of four
alphanumeric characters.  I encrypt several pieces of information including
serial number.

HTH

Rocky Smolin
Beach Access Software
http://www.e-z-mrp.com
858-259-4334


----- Original Message -----
From: "Nicholson, Karen" <cyx5 at cdc.gov>
To: "Access Developers discussion and problem solving"
<accessd at databaseadvisors.com>
Sent: Thursday, January 20, 2005 8:33 AM
Subject: RE: [AccessD] The Polyp Problem


> That sounds interesting.  But what if they do pay?  I just want to 
> torture those clients who think of us as prostitudes to be used when 
> needed, and after they get what they want, and you never hear from 
> them again.  How can I treat those with respect that deserve it?  Does

> this encrypted date require you to keep sending them updated .mde's?
>
> -----Original Message-----
> From: accessd-bounces at databaseadvisors.com
> [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Rocky 
> Smolin
> - Beach Access Software
> Sent: Thursday, January 20, 2005 11:17 AM
> To: Access Developers discussion and problem solving
> Subject: Re: [AccessD] The Polyp Problem
>
>
> Karen:
>
> If you're delivering an mde it's a snap.  Just put a date check in the

> opening form open event and quit the program if the date is past.  I 
> also put a 'date last accessed in a table and check to see if today's 
> date is
>
> less than the date last accessed.  That's so that they don't just move

> the clock back to a date prior to the date bomb.
>
> In my commercial product I have a key with an encrypted expiration 
> date which the user has to get updated every so often.  That way I 
> don't have to worry about illegal copies being made.  I can send out 
> an evaluator with a 30 or 60 day expiration.  Bu that's probably more 
> elaborate than you need.
>
> Rocky Smolin
> Beach Access Software
> http://www.e-z-mrp.com
> 858-259-4334
>
> ----- Original Message -----
> From: "Nicholson, Karen" <cyx5 at cdc.gov>
> To: <accessd at databaseadvisors.com>
> Sent: Thursday, January 20, 2005 5:10 AM
> Subject: [AccessD] The Polyp Problem
>
>
> I know this has been discussed before, but I sort of removed a polyp 
> from my client abuser list last night, as a woman has the right to 
> flip out on deadbeats.  That is the law.  Here is the story.  Client 
> contracts for a job; agrees to pay whatever way - some do in stage I, 
> more in stage II and the rest in stage III.  It is clearly stated that

> changes to the requirements of the system will be discussed and 
> additional invoicing will be required.  Polyp continuously *forgets* 
> to pay invoices as that is not is department, makes wild changes to 
> the system - "Oh, didn't I tell you?  Truck A, B or C can not go on 
> streets with a 2 Ton Limit?  You can just program that in, right?"  Or

> emergency call - finger nail bimbo's system won't work and it is the 
> hub.  Your system broke it, we can't function, come over here right 
> now.  Drop everything, run over, and low and behold the cable is 
> unplugged.  Three hours out of your day, gee thanks.  Oh, we can't pay

> you, it has been a bad year.  And that $2000 we still owe you from 
> August?  That is coming soon.  Hello, it is snowing!
>
> In my warped world, I would like to put code in the program that when 
> a payment is not received, the system stops working.  When the bill is

> paid, the user can have the encrypted password to keep working.
>
> Doesn't that sound easy?  One final password when the system is paid 
> in full.  I know a geek could break into it and get around the 
> password, but these people are cheap to begin with if they won't pay 
> and not work continuing working for anyway.  Ideas?
>
>
> --
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com
>
> --
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com
> --
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com
>

--
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com

--
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com

--
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com

****************************************************************************
*******
This transmittal may contain confidential information intended solely for
the addressee. If you are not the intended recipient, you are hereby
notified that you have received this transmittal in error; any review,
dissemination, distribution or copying of this transmittal is strictly
prohibited. If you have received this communication in error, please notify
us immediately by reply or by telephone (collect at 907-564-1000) and ask to
speak with the message sender. In addition, please immediately delete this
message and all attachments. Thank you. ACS


--
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com




More information about the AccessD mailing list