Joseph O'Connell
joconnell at indy.rr.com
Thu Jan 20 12:53:09 CST 2005
Jim, In the USA, if the contract does not contain specific language conferring ownership on the customer, then the contractor retains ownership. There was a land mark case a few years ago where a shoe manufacturer in Mass. paid mega bucks for custom software to run its business. Six months later they sued the contractor when they discovered that their competitors were using the same software. The judge ruled that since the development contract did not specifically grant ownership to the customer, that all the customer received was a license to use the software. Karen's case is different. She wants to disable the customer's right to use the software. If she does not have a legal right to do so, then she has a potential liability for loss of business/profits by the customer. Of course, she should not have any further responsibility to continue to provide services for which she will not be paid. This is definitely a legal question and a lawyer should be consulted before taking such a drastic step. The discussion of when a client is worth retaining is very relevent to a job that I just finished for a service company (not IT). They wanted very detailed analysis of services provided and revenue derived from their customers. After looking at the results they "fired" 1/3 of their customers. They found out that it cost more to provide the service than they were receiving in revenue. Unusualy, but they felt it was justified. Joe O'Connell -----Original Message----- From: Hale, Jim <Jim.Hale at fleetpride.com> To: 'Access Developers discussion and problem solving' <accessd at databaseadvisors.com> Date: Thursday, January 20, 2005 1:21 PM Subject: RE: [AccessD] The Polyp Problem <while you do own a program> I presume you mean if the contract is silent on this point the programmer is presumed to own the code. Are you sure? My recollection is last time we had this discussion we concluded that, while this is generally true, it is not universally so. Jim Hale -----Original Message----- From: Jim Dettman [mailto:jimdettman at earthlink.net] Sent: Thursday, January 20, 2005 10:55 AM To: Access Developers discussion and problem solving Subject: RE: [AccessD] The Polyp Problem Andy: Great advice. Part of the problem is that while you do own a program, you don't own the data. You can get yourself (so I've been told - I'm not a lawyer) if you put a time-bomb in the program and don't allow a client to access to their data. I've never stopped a program working for this reason. If I had to though, I would put in logic so they can't add new data. I've been very fortunate over the years and only once have had to resort to the "you want work done? then pay me what you owe me". As you say, they fork over pretty quick if they really need it. The other thing I've done that helps is that I bill everything by the hour. No flat fees and I invoice every two weeks. That way a lot of time doesn't go by between payments and if their is a disagreement about something that gets billed, it gets spotted quick as well. Karen: Really think if this is a client you want to keep or not. Sometimes it's just not worth the hassle. Jim Dettman -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com]On Behalf Of Andy Lacey Sent: Thursday, January 20, 2005 10:36 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] The Polyp Problem Hi Karen The 'bomb' in the system sounds more of a legal question rather than a technical one. You ought to get advice on how you'd stand if the system stops and their company comes to a stand-still. I know they'd deserve it but does the law agree? In any case they sound like all-too familiar sort of customer. At some point you have to decide on what YOU want to do next. Are they a customer worth having for the future? I doubt it but if yes, you'll probably have to grit your teeth and keep asking nicely for your money. If not then you are going to have to stop them doing what they're doing, i.e. taking advantage. At some point you just have to say that you are doing no more work and no more support until you have been paid. And having said it you have to stick to it. The first time they really need you, and you won't go, they will suddenly find it perfectly easy to raise a cheque. It's not hard. The only time it's actually hard is if they have no money - and if that's the case bail out. But assuming you do get the August money are there more payments due? If so you then have to decide if you're ever likely to get them. If not, ask them for the rest of the money up-front, explaining that because of past performance you've lost confidence in their willingness/ability to pay. If they say no then consider pulling out. I know it's easy to say, and hard to do, but you have to start saying 'no'. We all bend over backwards for a new customer, assuming that if we treat them right they'll do the same. When they prove otherwise it's time to stop your side of that deal. If you do stay with the contract then at least stop doing the extras. When they ask for a change quote them. If they won't pay they don't get. This is the downside of being an independent, and it's bloody horrible. FWIW we can all empathise. But you just have to get tough with these b******s. -- Andy Lacey http://www.minstersystems.co.uk --------- Original Message -------- From: Access Developers discussion and problem solving <accessd at databaseadvisors.com> To: accessd at databaseadvisors.com <accessd at databaseadvisors.com> Subject: [AccessD] The Polyp Problem Date: 20/01/05 13:14 > > 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 > > > > > ________________________________________________ Message sent using UebiMiau 2.7.2 -- 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 *********************************************************************** The information transmitted is intended solely for the individual or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of or taking action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you have received this email in error please contact the sender and delete the material from any computer. As a recipient of this email, you are responsible for screening its contents and the contents of any attachments for the presence of viruses. No liability is accepted for any damages caused by any virus transmitted by this email.