By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
435,500 Members | 2,809 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 435,500 IT Pros & Developers. It's quick & easy.

How To Give The Client Peace Of Mind

P: n/a
I am a one man enterprise and have been asked by a prospective client
what happens to their database regarding ongoing changes etc if I get
hit by a bus.

Obviously my databases are distributed as mde files in an effort to
protect my intellectual property. How do I give the client peace of
mind, short of giving them a backup mdb file that any programmer could
work on to provide required changes etc if I wasn't around?

Of course this method would defeat the purpose of distributing mde
files in the first place.

Any ideas are appreciated.

Jul 18 '06 #1
Share this Question
Share on Google+
11 Replies


P: n/a
DFS
Wayne wrote:
I am a one man enterprise and have been asked by a prospective client
what happens to their database regarding ongoing changes etc if I get
hit by a bus.

Obviously my databases are distributed as mde files in an effort to
protect my intellectual property. How do I give the client peace of
mind, short of giving them a backup mdb file that any programmer could
work on to provide required changes etc if I wasn't around?

Of course this method would defeat the purpose of distributing mde
files in the first place.

Any ideas are appreciated.

No offense, but your IP on display in an Access system can be duplicated in
short order by many, many people. Some are even right here on cdma. In
this thread.

If your client had been smart, they would have insisted on owning the
copyright and source code. I give my source code files to the client, and
transfer copyright upon payment. I suggest you do the same, or maybe give
them a copy of the source code with the understanding you retain the
copyright and the ability to license it to other customers. Such generosity
will help your relationship with them.

Or you can always write a will.

"To Whom It May Concern,

In the event of my death or other incapacitating event, the copyright to
FPSdata.mdb is hereby transferred to XYZ Corp."

Jul 18 '06 #2

P: n/a

Thanks for the reply DFS. I have always been under the impression that
the code can't be extracted from a mde file. This is what I was
referring to.

Thanks for your other comments. The worry that I have with distributing
the mdb is that an unscrupulous person could pass the database file/s
on to someone else to use or alter to suit their own environment and I
may never know about it.

Jul 18 '06 #3

P: n/a
The point that DFS is making is that it would be fairly straightforward for
someone to copy the concept of your software just by looking at the
interface, so the effort you put into "protecting you intellectual property"
would be better spent gaining brownie points with the customer by just
giving them the source code.

This is how it works:-
1) Most people are basically honest, if you treat them honestly they
will reciprocate. Give them the source code and they will be more relaxed
about this issue and it will increase their trust in you. Also because they
know there investment in you is protected they are more likely to come back
to you for later work.

2) Some people are not honest, if you give them the source code they
will go and find someone cheaper to maintain it. Because you have an
agreement that the intellectual property is yours there should be no problem
about you re-using any routines in later software you write. Your
obligation to these people is over and you can get on with finding paying
work elsewhere. You also have the fun of imagining the problems they will
have when there cheap alternative messes up.

If you want to be clever there are software escrow services. These work by
putting your source into escrow which your customers can then retrieve under
certain circumstances. This costs money so you would have to agree who will
pay for it. You have the added hassle that if you update the software you
need to issue a new version to the escrow service (this will cost money as
well). At the end of the day most people find it more hassle than it's
worth.

The bottom line is; if you don't trust your customer then don't do work for
them, if you do trust them then show them that you trust them. If your
customer is dishonest they can find a way round any protection you put in if
they are determined enough.
--

Terry Kreft
"Wayne" <cq*******@volcanomail.comwrote in message
news:11*********************@s13g2000cwa.googlegro ups.com...
>
Thanks for the reply DFS. I have always been under the impression that
the code can't be extracted from a mde file. This is what I was
referring to.

Thanks for your other comments. The worry that I have with distributing
the mdb is that an unscrupulous person could pass the database file/s
on to someone else to use or alter to suit their own environment and I
may never know about it.
gat

Jul 18 '06 #4

P: n/a
DFS
Wayne wrote:
Thanks for the reply DFS. I have always been under the impression
that the code can't be extracted from a mde file. This is what I was
referring to.
That's supposed to be the case, but someone here on cdma claimed he could
extract all the code from an .mde (or he claimed he could bypass whatever
trial limitations I built-in to an .mde - I forget which claim he made). I
don't doubt it at all. It's not hard to reverse engineer compiled code.

Thanks for your other comments. The worry that I have with
distributing the mdb is that an unscrupulous person could pass the
database file/s on to someone else to use or alter to suit their own
environment and I may never know about it.
This is a justified concern, and you don't want to make their "thieving" any
easier than necessary, but is it realistic to think someone else couldn't
recreate your app functionality just by viewing it in operation? ie they
don't really need the source code to duplicate your app, so why worry about
them getting it?

Take a sophisticated application like OpenOffice (an open source office
software suite). They've apparently spent years cloning the features and
functionality - and often the exact menu wording and exact order - in MS
Office, and they didn't have the source code.

A client once wanted me to "recreate/duplicate" a proprietary time-tracking
system they paid big bucks in annual maintenance for. I had the screens to
view (in fact I had to log my time in the thing), and I could see the db
structure. That's it. In a few weeks I built a reasonable facsimile they
could use forever at no yearly cost. One thing I didn't duplicate was the
way the original system stored time at the lowest level. I found that the
Person-Tasks-Hours table stopped at the person and date. Further detail
(person-task-date-hours) was buried in an unreadable, binary file object
stored in a BLOB column, which was extracted/written in real-time when you
ran their system. I didn't need the source to discover this; the table
structure revealed it. I could have duplicated this as well - I didn't, and
went with full disclosure.

Terry Kreft gave you some good advice as well. If I were you I'd go ahead
and give them the source code outright, even if there's some risk they'll
recreate it internally, or find someone cheaper. If they're cheaper,
they're not as good as you, right? :) And the client will find out and come
back to you in short order anyway.

Jul 18 '06 #5

P: n/a
"Wayne" <cq*******@volcanomail.comwrote in
news:11**********************@b28g2000cwb.googlegr oups.com:
I am a one man enterprise and have been asked by a prospective
client what happens to their database regarding ongoing changes
etc if I get hit by a bus.

Obviously my databases are distributed as mde files in an effort
to protect my intellectual property. How do I give the client
peace of mind, short of giving them a backup mdb file that any
programmer could work on to provide required changes etc if I
wasn't around?

Of course this method would defeat the purpose of distributing mde
files in the first place.
I, too, have encountered this same problem.

One solution that many clients are comfortable with is to
subcontract you through a larger organization, so the larger
organization takes on the liability for supporting the project
should you be unavailable. For that to be credible, the larger
organization needs to have existing relationships with at least one
other experienced Access developer.

Another solution is to bring in another developer on the project,
subcontracted by you. Train that developer on how the application
works, involve him/her in new projects. I've never had this work
well for two reasons:

1. good developers end up getting better gigs and don't end up being
available indefinitely.

2. the client hates paying 1.5 to 2 times more from the development,
even if you point out that that's the cost of peace of mind.

For some reason, they don't mind paying a premium for contracting
through an organization (I'm usually billed out at my regular rate
plus 40-50%), but hate paying for more *hours*. In other words, for
some reason they don't mind a much higher hourly rate, but hate
buying more hours at the same rate.

If #1 were not true, bringing on another developer would be more
efficient in the long run, because the subcontracting organization
will have to bring in the other developer when you get hit by the
bus, so to speak, and then there will be a long period of time where
that developer is being paid just to learn the ropes of the app. And
the hourly rate is going to be substantially higher for *all* work,
even before you get hit by the bus.

But it does defer the expense of the switch over until it's needed,
at the cost of the inconvenience that will lead to (i.e., turnaround
on fixes won't be nearly as fast under the new developer until
she/he gets up to speed on the app).

The key point:

Having peace of mind of the type your client wants cost BIG BUCK$
and is slower and less efficient than depending on your lone wolf
developer.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
Jul 18 '06 #6

P: n/a
"DFS" <nospam@dfs_.comwrote in
news:F0*****************@bignews2.bellsouth.net:
If your client had been smart, they would have insisted on owning
the copyright and source code. I give my source code files to the
client, and transfer copyright upon payment.
Well, that's rather problematic if, for instance, you're using other
people's code in your app and don't have the rights to take credit
for it.

My standard contract retains rights to the source code. If they want
the rights and the code, they have to pay extra for that, as it
necessitates a complete restructuring of my code, which often
incorporates other people's code, and code that I've created for
other projects and which I don't want the client to have.

Engineering for client rights to code adds significant time to
development, in my experience, and you should be compensated extra
for that.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
Jul 18 '06 #7

P: n/a
"Terry Kreft" <te*********@mps.co.ukwrote in
news:LL********************@karoo.co.uk:

[]
1) Most people are basically honest, if you treat them
honestly they
will reciprocate. Give them the source code and they will be more
relaxed about this issue and it will increase their trust in you.
. . .
And in my experience, those clients who insist on the source code
never do a damned thing with it -- they really are buying nothing
more than peace of mind. The same thing could be accomplished by
some kind of escrow system that would be activated at the death of
the developer, for instance, or at some other contractually
agreed-upon time when the original developer decided to bow out.

[]
2) Some people are not honest, if you give them the source
code they
will go and find someone cheaper to maintain it. Because you have
an agreement that the intellectual property is yours there should
be no problem about you re-using any routines in later software
you write. . . .
Uh, you can't have it both ways. Either the client has the rights
and you can't re-use it, or you have the rights and the client can't
re-use it.

For apps where the client insists on source code, I structure the
code so that the client app includes only that code written
specifically for the client and the code I'm retaining rights to is
delivered in a library MDE, along with documentation of how to use
the routines encapsulated in that MDE. The client contract says that
the client has the right to distribute this MDE as part of this
original application *only* and no secondary distribution rights, or
any rights to use that MDE in any other application. They have full
rights for the main application MDB's code to do with as they like.

[]
If you want to be clever there are software escrow services.
These work by putting your source into escrow which your customers
can then retrieve under certain circumstances. This costs money
so you would have to agree who will pay for it. . . .
No, the *client* should pay for it.

You have the added hassle that if you update the software you
need to issue a new version to the escrow service (this will cost
money as well). . . .
And the client should pay for it.
. . . At the end of the day most people find it more hassle than
it's worth.
I can't see how there's any difference in regard to *not* using a
formal escrow service. If they client wants the code, they want the
up-to-date code, and so you'll constantly have to be refreshing the
client's copy of the code, just as you would with the escrow
service. And, of course, you'd bill the client for that service, as
well.
The bottom line is; if you don't trust your customer then don't do
work for them, if you do trust them then show them that you trust
them. If your customer is dishonest they can find a way round any
protection you put in if they are determined enough.
They can spend the money to re-engineer your app, but that's
substantially more trouble than just using your source code.

Making source code available to the client is more time-consuming
for the developer, and the client has to pay more for rights to the
code. It's that simple -- peach of mind costs $$$$.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
Jul 18 '06 #8

P: n/a
"DFS" <nospam@dfs_.comwrote in
news:yB*****************@bignews2.bellsouth.net:
Wayne wrote:
>Thanks for the reply DFS. I have always been under the
impression that the code can't be extracted from a mde file.
This is what I was referring to.

That's supposed to be the case, but someone here on cdma claimed
he could extract all the code from an .mde (or he claimed he could
bypass whatever trial limitations I built-in to an .mde - I forget
which claim he made). I don't doubt it at all. It's not hard to
reverse engineer compiled code.
Reverse engineering compiled code is not going to be the same as
extracting the original code. Not by any stretch of the imagination.
>Thanks for your other comments. The worry that I have with
distributing the mdb is that an unscrupulous person could pass
the database file/s on to someone else to use or alter to suit
their own environment and I may never know about it.

This is a justified concern, and you don't want to make their
"thieving" any easier than necessary, but is it realistic to think
someone else couldn't recreate your app functionality just by
viewing it in operation?
Of course not, but that would cost a lot more money than using the
original source code.
. . . ie they
don't really need the source code to duplicate your app, so why
worry about them getting it?
You're increasing the cost of stealing your app by not providing the
source code. Thus, since you're exposing yourself to the risk of
theft, you have to charge more for providing source code, thus
making the cost of having the source code and the cost of
re-engineering your app more or less comparable.
Take a sophisticated application like OpenOffice (an open source
office software suite). They've apparently spent years cloning
the features and functionality - and often the exact menu wording
and exact order - in MS Office, and they didn't have the source
code.
And they've spent millions of dollars in uncompensated developer
time in doing so. Not as much as Microsoft, since they are copying
an existing design (copying an Access MDE should never cost as much
as creating the original, since the outward design decisions have
already been made, just as with cloning MS Office).

And they haven't gotten it all right in OpenOffice yet, either.
A client once wanted me to "recreate/duplicate" a proprietary
time-tracking system they paid big bucks in annual maintenance
for. I had the screens to view (in fact I had to log my time in
the thing), and I could see the db structure. That's it. In a
few weeks I built a reasonable facsimile they could use forever at
no yearly cost. . . .
Key difference: yearly maintenancecosts. Eliminating those balances
out the cost of re-engineering from scratch. Unless Wayne is
charging maintenance fees for his app, that's simply not an issue.

[]
Terry Kreft gave you some good advice as well. If I were you I'd
go ahead and give them the source code outright, even if there's
some risk they'll recreate it internally, or find someone cheaper.
If they're cheaper, they're not as good as you, right? :) And
the client will find out and come back to you in short order
anyway.
Another thing to point out to them is that if they take over the
source code, they become responsible for maintaining their archive
of it. This means that if they bring you back after attempting to
hand it off to someone else, they have to have maintained the code
base so that they have the most recent versions (and they may want
earlier intermediate versions if the new hired gun screws things up
badly enough to necessitate a revert to an earlier version). If they
don't do this, costs escalate enormously.

An escrow system managed by the original developer and paid for by
the client seems to me to be the best system. That way the client
would get access to the code if they needed it, and they don't have
to maintain the codebase themselves (something the vast majority of
clients would be completely unequipped to do themselves).

Peace of mind costs $$$$$.

That's the key point.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
Jul 18 '06 #9

P: n/a
"David W. Fenton" wrote
Uh, you can't have it both ways. Either the client has the rights
and you can't re-use it, or you have the rights and the client can't
re-use it.
As you know, the bulk of the paying development I do is "bespoke systems"
tailored for individual clients. My standard practice is that I retain
ownership and, thus, my rights to re-use it, but grant non-exclusive rights
to the client that protect them in case I should be so inconsiderate as to
walk in front of a truck, or if they just want to find a cheaper source for
maintenance or enhancements.

Much of what I do, though is samples and examples... my view is that when I
post something on the Internet, I've pretty much lost control over it,
anyway, so I don't really worry about it, except to include a kind of
disclaimer.

Larry Linson
Microsoft Access
Jul 18 '06 #10

P: n/a
Bri
David W. Fenton wrote:
>
Uh, you can't have it both ways. Either the client has the rights
and you can't re-use it, or you have the rights and the client can't
re-use it.
Sure you can (at least here in Canada this works). The developer retains
ownership of the source code but grants the client a licence to do what
ever they want with the source code. Or visa versa, sell the rights to
the source code to the client who then licences your usage of it back to
you. I've done contracts both ways, but charge more for the second.
For apps where the client insists on source code, I structure the
code so that the client app includes only that code written
specifically for the client and the code I'm retaining rights to is
delivered in a library MDE, along with documentation of how to use
the routines encapsulated in that MDE. The client contract says that
the client has the right to distribute this MDE as part of this
original application *only* and no secondary distribution rights, or
any rights to use that MDE in any other application. They have full
rights for the main application MDB's code to do with as they like.
This is a good solution to cover your common functions. I might have to
do this too someday just to make things simpler.

--
Bri

Jul 18 '06 #11

P: n/a

--

Terry Kreft
"David W. Fenton" <XX*******@dfenton.com.invalidwrote in message
news:Xn**********************************@127.0.0. 1...
"Terry Kreft" <te*********@mps.co.ukwrote in
news:LL********************@karoo.co.uk:
<SNIP>
>
2) Some people are not honest, if you give them the source
code they
will go and find someone cheaper to maintain it. Because you have
an agreement that the intellectual property is yours there should
be no problem about you re-using any routines in later software
you write. . . .

Uh, you can't have it both ways.
Uh, don't be silly of course you can.

You can
Own the code and licence it to them
Sell the code and licence it from them
Own the code in tandem.

In any case you can contract that any unauthorised use of the code reverts
all ownership to yourself.

I'm not a lawyer but I've seen all of the above in contracts.

If you want to be clever there are software escrow services.
These work by putting your source into escrow which your customers
can then retrieve under certain circumstances. This costs money
so you would have to agree who will pay for it. . . .

No, the *client* should pay for it.
The client _should_ pay for it but that still needs agreeing.
>
You have the added hassle that if you update the software you
need to issue a new version to the escrow service (this will cost
money as well). . . .

And the client should pay for it.
The client _should_ pay for it but that still needs agreeing.

<SNIP>
>
--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

Jul 19 '06 #12

This discussion thread is closed

Replies have been disabled for this discussion.