How to stop library mde being reused

[Jeff]

Hi

I have a library mde that is used with some customer databases and I found
out that another developer discovered it while doing some maintenance work
on an old database for the same customer and has copied it to use with her
databases. Naturally, I was not impressed and that story continues. It was
not the customers fault.

I assume she took a copy of the original code from the customers database
and is working out how to use the library mde from that. For this customer
the database is supplied with all source code and not compiled into an mde.

There are also a few other situations where I suspect the mde may be getting
reused without my permission.

Basically, the mde contains a whole bunch of functions I have developed over
the years and am using it more and more in systems developed for clients and
had not really worried about it being knocked off, so to speak, until now.

After this little incident I have given this some thought.

I want to allow some customers to reuse the library with databases they put
together, but stop this rip off happening again.

I have considered a few options, but am not really that happy with any at
this stage.

Any suggestions on a reasonably simple method of stopping, or at least
limiting, this from happening again would be appreciated.

Jeff

[paii, Ron]

Include in the list future application ID information which could be
assigned to your applications as created. Combining this code with
information identifying your company name would make it difficult for some
3rd party to hide the fact they stole your library.

"Terry Kreft" <te*********@mp s.co.uk> wrote in message
news:fG******** ************@ka roo.co.uk...

If you have to touch the library every time you create a new app that sort
of defeats the point of having a library.

--
Terry Kreft

"paii, Ron" <pa**@packairin c.com> wrote in message
news:3c******** *************** *******@athenet .net...

Create a list of all your applications in the library, then have an
initialization function check the database properties of your front end.
It
would be hard for a 3rd party to know what your library is looking for. If they figured it out they would have to duplicate your application name.

"Jeff" <je************ @asken.com.au> wrote in message
news:43******** *************** @per-qv1-newsreader-01.iinet.net.au ...

Hi

I have a library mde that is used with some customer databases and I
found
out that another developer discovered it while doing some maintenance
work
on an old database for the same customer and has copied it to use with
her
databases. Naturally, I was not impressed and that story continues. It
was
not the customers fault.

I assume she took a copy of the original code from the customers database and is working out how to use the library mde from that. For this
customer
the database is supplied with all source code and not compiled into an

mde.

There are also a few other situations where I suspect the mde may be

getting

reused without my permission.

Basically, the mde contains a whole bunch of functions I have developed

over

the years and am using it more and more in systems developed for clients

and

had not really worried about it being knocked off, so to speak, until
now.

After this little incident I have given this some thought.

I want to allow some customers to reuse the library with databases they

put

together, but stop this rip off happening again.

I have considered a few options, but am not really that happy with any

at this stage.

Any suggestions on a reasonably simple method of stopping, or at least
limiting, this from happening again would be appreciated.

Jeff

[David W. Fenton]

"Jeff" <je************ @asken.com.au> wrote in
news:43******** *************** @per-qv1-newsreader-01.iinet.net.au :

Hi

I have a library mde that is used with some customer databases and
I found out that another developer discovered it while doing some
maintenance work on an old database for the same customer and has
copied it to use with her databases. Naturally, I was not
impressed and that story continues. It was not the customers
fault.

I assume she took a copy of the original code from the customers
database and is working out how to use the library mde from that.
For this customer the database is supplied with all source code
and not compiled into an mde.

There are also a few other situations where I suspect the mde may
be getting reused without my permission.

Basically, the mde contains a whole bunch of functions I have
developed over the years and am using it more and more in systems
developed for clients and had not really worried about it being
knocked off, so to speak, until now.

After this little incident I have given this some thought.

I want to allow some customers to reuse the library with databases
they put together, but stop this rip off happening again.

I have considered a few options, but am not really that happy with
any at this stage.

Any suggestions on a reasonably simple method of stopping, or at
least limiting, this from happening again would be appreciated.

Your contract with the client has to control it. After my signature,
I've appended the language I've used where I have exactly the
architecture you've described.

Assuming you have some kind of contract with your client that has
equivalent limitations in it, I believe it's the client's
responsibility to discipline its contractors to not violate the
agreements they've entered into.

If you lack such language in your contract, then it's up to you to
enforce it. Assuming you have already failed at having a reasonable
discussion with the developer who is using it without your
permission, I'd see a lawyer. Perhaps the mere threat of legal
action would get them to stop.

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

=============== =============== =============== =============== =====

APPLICATION COMPONENTS

The completed application will consist of four component parts:

1. An Access2000 MDB file for storing the shared application data
(installed on file server)

2. An Access2000 MDE file for running the application and
viewing/manipulating data in the shared application data MDB
(installed on each client workstation)

3. An Access2000 MDB file including full source code for producing
the MDE file (for reference use and as the basis for future
development)

4. An Access2000 MDE function library (installed on each client
workstation)

Items 1-2 will be fully owned by [CLIENT], while item 4 will be
licensed from David W. Fenton for use by [CLIENT] employees and
affiliates. [CLIENT] will have rights to use and further develop
item 3 as outlined in the following section. During the development
process, the architecture may be simplified to make component
testing more efficient.

SOURCE CODE RIGHTS

· [CLIENT] acquires the rights to use and distribute the finished
application as a whole to its employees and affiliates, without
limitation.

· Further, [CLIENT] obtains ownership and rights to the source code
in the application MDB (see #3 under APPLICATION COMPONENTS, above)
to alter or enhance as [CLIENT] sees fit.

· Also, [CLIENT] obtains a license from David W. Fenton to use the
supporting function library (APPLICATION COMPONENT #4) as part of
the application only, but acquires no rights to distribute, sell or
alter this library, or to utilize it in any other applications.

· Neither [CLIENT] nor David W. Fenton may distribute or sell the
application as a whole, or anything derived from the source code MDB
(component #3), unless both parties agree to that distribution or
sale.

[David W. Fenton]

Tom van Stiphout <no************ *@cox.net> wrote in
news:qe******** *************** *********@4ax.c om:

Perhaps I would in each function check the name of the domain the
code is running on. If you only run this MDE in a few locations,
that might be all that's needed. Domain names don't change all
that often, but when they do, be ready for a support call and a
free upgrade.

Well, the horse is already out of the barn, no?

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

[David W. Fenton]

"Terry Kreft" <te*********@mp s.co.uk> wrote in
news:OF******** ************@ka roo.co.uk:

I'm taking it that your distributed apps are compiled to MDEs as
well as your library database

Yes, but he already said that the client has the source code MDB and
that the developer probably took a copy of that to figure out how to
use his library. Using a GUID or any other form of validation simply
won't work, as so soon as you can figure out what *does* work, you
can write something to pass something valid to the MDE.

I don't think there's any technical solution to this problem.

There are only ethical/legal solutions.

The client should fire the other developer if she won't stop
stealing from the client's other developers.

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

[David W. Fenton]

"Lyle Fairfield" <ly***********@ aim.com> wrote in
news:11******** **************@ f14g2000cwb.goo glegroups.com:

But at night time I realize that it's my brothers' code, Dev's
code, Professor T M K Davidson's code, Terry's code, Getz's code,
Dimitri's code, Michka's code, David's code (even), Appleman's
code, J A Green's code, rkc's code, Danny's code and the code of a
thousand others who have challenged me, taught me, motivated me,
shown me, stimulated me, embarrassed me, attacked me and
encouraged me.

And I realize that if they created it in me I cannot own it. I
must let it go.

This is precisely one of the best reasons for bundling an MDE
library, because you are borrowing code from a number of people
who've not necessarily explicitly granted you the right to
distribute their code.

With an MDE library, there's a constant friction between protecting
the actual source code and exposing the functionality. If the client
wants to take over development and continue to use your library
(which is reasonable, if you've licensed it that way), then you
really ought to be documenting the interfaces for the code in your
library so that anyone should be able to use them. But you'd want to
be sure your contract limits the use of the library to the
application it was sold with.

This is also why I never use a generic library -- instead, I create
a library of only the code that is used in that particular app.

In order to make this easier, during development, I segregate all
this code in a single module, or in modules using a naming
convention that identifies them as bound for a library database. And
with class modules, you have to save them out and alter them and
import them into the libary database in order to make them fully
usable, anyway.

But the result is a libary that includes only the code that is used
in that particular application. This means you don't have to
document everything, just the code that is used and that could
conceivably be needed by another developer working on the main body
of the app.

Of course, anyone could reverse engineer your code.

But the point is that they won't.

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

[David W. Fenton]

"Jeff" <je************ @asken.com.au> wrote in
news:43******** *************** @per-qv1-newsreader-01.iinet.net.au :

That may work if they only had an MDE front-end. But a lot of
clients have the uncompiled MDB file for the front-end. That would
of course have the code to so this and therefore easily
duplicated.

That is the main problem. With a MDB front-end anything I add to
it is open to the world.

Well, the horse is also already out of the barn. It would work only
if she got hold of the new version of the library with these outside
dependencies.

You have to talk to her and ask her to do the right thing.

Failing that, talk to the client that employees both of you and ask
them to pressure her to do the right thing.

Failing that, see a lawyer and threaten her with legal action.

Failing that, take legal action. She can't possibly win, though she
may have nothing whatsoever to collect in damages.

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

[Lyle Fairfield]

David W. Fenton wrote:

"Lyle Fairfield" <ly***********@ aim.com> wrote in
news:11******** **************@ f14g2000cwb.goo glegroups.com:

But at night time I realize that it's my brothers' code, Dev's
code, Professor T M K Davidson's code, Terry's code, Getz's code,
Dimitri's code, Michka's code, David's code (even), Appleman's
code, J A Green's code, rkc's code, Danny's code and the code of a
thousand others who have challenged me, taught me, motivated me,
shown me, stimulated me, embarrassed me, attacked me and
encouraged me.

And I realize that if they created it in me I cannot own it. I
must let it go.

This is precisely one of the best reasons for bundling an MDE
library, because you are borrowing code from a number of people
who've not necessarily explicitly granted you the right to
distribute their code.

That is not what I said, nor was it what I intended to say.

[Jeff]

Mmm...that may actually work is some situations. It would be a bit of a pain
but I could create a unique version of the library to suit a clients
workgroup. In that way they can create and work on databases as long as they
remain within that workgroup.

Thanks

[Jeff]

It is for her, but as I mentioned in another post this may actually work for
some clients. Just means a uniquely compiled library for that customer,
expecting a specific workgroup.

Jeff

"David W. Fenton" <XX*******@dfen ton.com.invalid > wrote in message
news:Xn******** *************** ***********@127 .0.0.1...

Tom van Stiphout <no************ *@cox.net> wrote in
news:qe******** *************** *********@4ax.c om:

Perhaps I would in each function check the name of the domain the
code is running on. If you only run this MDE in a few locations,
that might be all that's needed. Domain names don't change all
that often, but when they do, be ready for a support call and a
free upgrade.

Well, the horse is already out of the barn, no?

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

[Jeff]

Its just that legal action is so expensive, and I would doubt it was worth
it.

Talking to the client is reasonable, and I have done this, but have not
expressed a view that it is their responsibility. Don't think that would go
down well with one in particular.

Jeff

"David W. Fenton" <XX*******@dfen ton.com.invalid > wrote in message
news:Xn******** *************** ***********@127 .0.0.1...

"Jeff" <je************ @asken.com.au> wrote in
news:43******** *************** @per-qv1-newsreader-01.iinet.net.au :

That may work if they only had an MDE front-end. But a lot of
clients have the uncompiled MDB file for the front-end. That would
of course have the code to so this and therefore easily
duplicated.

That is the main problem. With a MDB front-end anything I add to
it is open to the world.

Well, the horse is also already out of the barn. It would work only
if she got hold of the new version of the library with these outside
dependencies.

You have to talk to her and ask her to do the right thing.

Failing that, talk to the client that employees both of you and ask
them to pressure her to do the right thing.

Failing that, see a lawyer and threaten her with legal action.

Failing that, take legal action. She can't possibly win, though she
may have nothing whatsoever to collect in damages.

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