Like some software out there are demos and run out after 60 or so many days
unless they have some code to keep it going, can it be done with an Excel
workbook?
I want my workbook to be used for so many days and then they will have to
upgrade to the next version. I'm not charging the users anything to use the
workbook, but my employers are not paying me for something I've done on my
own time.

Thanks,

Mr BT

There are numerous ways to do what you want, all of which can be broken by
anyone with sufficient knowledge of Excel. Otto
"Mr BT" wrote in message
news:nObvi.50061$fJ5.26043@pd7urf1no...
Like some software out there are demos and run out after 60 or so many
days unless they have some code to keep it going, can it be done with an
Excel workbook?
I want my workbook to be used for so many days and then they will have to
upgrade to the next version. I'm not charging the users anything to use
the workbook, but my employers are not paying me for something I've done
on my own time.

Thanks,

Mr BT

I discussed this issue at some length with another individual who has a
product that he'd started in Excel with the intent of going commercial with
it. He had 2 issues: #1 protecting his 'intellectual property' - primarily
the code behind the scenes that got the job done in a very complex workbook.
#2 licensing issues to make sure that a) demo would expire when planned and
b) only licensed copies would be used - to help prevent excessive pirating.

We looked into several "Excel Compiler"s (do a search, you'll turn up some
possible ones - quality ranges from mere toys to pretty good, but still with
limitations and a learning curve to use them) as a means to protect the
intellectual property side and to try to implement some licensing use issues.
In the end, for his application, none seemed wholly suitable and he is now
having the entire project written in C using the Excel package as the
'product requirements specification'.

As Otto has said, it's just too easy for a knowledgable individual to break
any such protection you may try to implement in an Excel package. There are
very good password cracking tools available to quickly unlock a workbook or
worksheet, and even some available to unlock the tighter password protection
that can be applied to the VBA project in a workbook.

But that's the place to start: password protect your VBA project in the
workbook from viewing. As noted earlier, these passwords are tougher to
crack than workbook/worksheet passwords, so your first steps a
#1 - make a backup copy of the workbook with no password protection applied
at all.
#2 - write down the password you will use to lock the VBA application.

Then in the copy you plan on trying to distribute, go into the VB Editor and
choose
Tools | VBAProject Properties
go to the [Protection] tab and check the box next to "Lock Project for
Viewing" and then provide the password. Save the workbook. Next time you
try to use the VBEditor (after closing the workbook) you'll be asked to
provide the password before you can view the project's content, including the
VBA code.

If you want to set up a way to force them to activate macros, you can try
this (again, not proof against the determined and industrious):
Add a single sheet to your workbook that has a notice that if they are
seeing it, then macros are disabled and they must enable macro usage to use
the workbook. Include instructions on how to enable macros (recommend using
the Medium setting: pre-2007 or the 'Disable with notice' in 2007).
Go into your VB Editor and set the visible property of all other sheets to
xlSheetVeryHidden - this keeps them from even showing up in the list of
Format | Sheets | Unhide. Leave only the 'alert/instruction' sheet visible.

In the workbook Open() event, put code to make the very hidden sheets
visible again, and to hide that alert/instruction sheet! If macros are
turned off, then that code can't execute and the sheets remain very hidden
with the alert/instruction sheet staring them in the face. This will
probably force 90% of the people to enable macros the next time out - the %
that aren't in the "determined and industrious" group.

In the workbook _BeforeClose() event, do the reverse: make the
alert/instruction sheet visible again (do that first) then set all other
sheets to xlVeryHidden again.

Keep in mind that a workbook must always have at least 1 visible sheet - so
the sequence of unhide/hide is important so that you aren't trying to have
all sheets hidden at one time - ERROR!

"Mr BT" wrote:

Like some software out there are demos and run out after 60 or so many days
unless they have some code to keep it going, can it be done with an Excel
workbook?
I want my workbook to be used for so many days and then they will have to
upgrade to the next version. I'm not charging the users anything to use the
workbook, but my employers are not paying me for something I've done on my
own time.

Thanks,

Mr BT

"JLatham" <HelpFrom @ Jlathamsite.com.(removethis) wrote in message
...
I discussed this issue at some length with another individual who has a
product that he'd started in Excel with the intent of going commercial
with
it. He had 2 issues: #1 protecting his 'intellectual property' -
primarily
the code behind the scenes that got the job done in a very complex
workbook.
#2 licensing issues to make sure that a) demo would expire when planned
and
b) only licensed copies would be used - to help prevent excessive
pirating.

We looked into several "Excel Compiler"s (do a search, you'll turn up some
possible ones - quality ranges from mere toys to pretty good, but still
with
limitations and a learning curve to use them) as a means to protect the
intellectual property side and to try to implement some licensing use
issues.
In the end, for his application, none seemed wholly suitable and he is now
having the entire project written in C using the Excel package as the
'product requirements specification'.

As Otto has said, it's just too easy for a knowledgable individual to
break
any such protection you may try to implement in an Excel package. There
are
very good password cracking tools available to quickly unlock a workbook
or
worksheet, and even some available to unlock the tighter password
protection
that can be applied to the VBA project in a workbook.

But that's the place to start: password protect your VBA project in the
workbook from viewing. As noted earlier, these passwords are tougher to
crack than workbook/worksheet passwords, so your first steps a
#1 - make a backup copy of the workbook with no password protection
applied
at all.
#2 - write down the password you will use to lock the VBA application.

Then in the copy you plan on trying to distribute, go into the VB Editor
and
choose
Tools | VBAProject Properties
go to the [Protection] tab and check the box next to "Lock Project for
Viewing" and then provide the password. Save the workbook. Next time you
try to use the VBEditor (after closing the workbook) you'll be asked to
provide the password before you can view the project's content, including
the
VBA code.

If you want to set up a way to force them to activate macros, you can try
this (again, not proof against the determined and industrious):
Add a single sheet to your workbook that has a notice that if they are
seeing it, then macros are disabled and they must enable macro usage to
use
the workbook. Include instructions on how to enable macros (recommend
using
the Medium setting: pre-2007 or the 'Disable with notice' in 2007).
Go into your VB Editor and set the visible property of all other sheets to
xlSheetVeryHidden - this keeps them from even showing up in the list of
Format | Sheets | Unhide. Leave only the 'alert/instruction' sheet
visible.

In the workbook Open() event, put code to make the very hidden sheets
visible again, and to hide that alert/instruction sheet! If macros are
turned off, then that code can't execute and the sheets remain very hidden
with the alert/instruction sheet staring them in the face. This will
probably force 90% of the people to enable macros the next time out - the
%
that aren't in the "determined and industrious" group.

In the workbook _BeforeClose() event, do the reverse: make the
alert/instruction sheet visible again (do that first) then set all other
sheets to xlVeryHidden again.

Keep in mind that a workbook must always have at least 1 visible sheet -
so
the sequence of unhide/hide is important so that you aren't trying to have
all sheets hidden at one time - ERROR!

"Mr BT" wrote:

Like some software out there are demos and run out after 60 or so many
days
unless they have some code to keep it going, can it be done with an Excel
workbook?
I want my workbook to be used for so many days and then they will have to
upgrade to the next version. I'm not charging the users anything to use
the
workbook, but my employers are not paying me for something I've done on
my
own time.

Thanks,

Mr BT

Thank you very much for your assistance. What you have provided will help a
great deal.
My main concern is that my "colleagues" could claim rights to the
application that I've created. I would like the "demo" to become extinct
with a passcode (which they would never figure out just on a moment's
notice, and make it obvious they (colleagues) did not create my software
(I'm not really sure what I can call it).

Thanks again.

Mr BT

One other step you might consider taking then is to digitally sign the
project. You can create your own digital signature to use, or you can pay
big $$ to get one from some place like VeriSign. For instructions on
creating your own and signing the project with it, use Excel Help and enter
digital signature
as the search for parameter. You'll find sub topics on signing a project
and how to create the signature.
And as "proof" of creation date, perhaps save a copy somewhere only you have
access to and leave it untouched. That will show the date/time the file was
created. Of course, that doesn't prove that you didn't change the system
date/time just before saving it.


"Mr BT" wrote:


"JLatham" <HelpFrom @ Jlathamsite.com.(removethis) wrote in message
...
I discussed this issue at some length with another individual who has a
product that he'd started in Excel with the intent of going commercial
with
it. He had 2 issues: #1 protecting his 'intellectual property' -
primarily
the code behind the scenes that got the job done in a very complex
workbook.
#2 licensing issues to make sure that a) demo would expire when planned
and
b) only licensed copies would be used - to help prevent excessive
pirating.

We looked into several "Excel Compiler"s (do a search, you'll turn up some
possible ones - quality ranges from mere toys to pretty good, but still
with
limitations and a learning curve to use them) as a means to protect the
intellectual property side and to try to implement some licensing use
issues.
In the end, for his application, none seemed wholly suitable and he is now
having the entire project written in C using the Excel package as the
'product requirements specification'.

As Otto has said, it's just too easy for a knowledgable individual to
break
any such protection you may try to implement in an Excel package. There
are
very good password cracking tools available to quickly unlock a workbook
or
worksheet, and even some available to unlock the tighter password
protection
that can be applied to the VBA project in a workbook.

But that's the place to start: password protect your VBA project in the
workbook from viewing. As noted earlier, these passwords are tougher to
crack than workbook/worksheet passwords, so your first steps a
#1 - make a backup copy of the workbook with no password protection
applied
at all.
#2 - write down the password you will use to lock the VBA application.

Then in the copy you plan on trying to distribute, go into the VB Editor
and
choose
Tools | VBAProject Properties
go to the [Protection] tab and check the box next to "Lock Project for
Viewing" and then provide the password. Save the workbook. Next time you
try to use the VBEditor (after closing the workbook) you'll be asked to
provide the password before you can view the project's content, including
the
VBA code.

If you want to set up a way to force them to activate macros, you can try
this (again, not proof against the determined and industrious):
Add a single sheet to your workbook that has a notice that if they are
seeing it, then macros are disabled and they must enable macro usage to
use
the workbook. Include instructions on how to enable macros (recommend
using
the Medium setting: pre-2007 or the 'Disable with notice' in 2007).
Go into your VB Editor and set the visible property of all other sheets to
xlSheetVeryHidden - this keeps them from even showing up in the list of
Format | Sheets | Unhide. Leave only the 'alert/instruction' sheet
visible.

In the workbook Open() event, put code to make the very hidden sheets
visible again, and to hide that alert/instruction sheet! If macros are
turned off, then that code can't execute and the sheets remain very hidden
with the alert/instruction sheet staring them in the face. This will
probably force 90% of the people to enable macros the next time out - the
%
that aren't in the "determined and industrious" group.

In the workbook _BeforeClose() event, do the reverse: make the
alert/instruction sheet visible again (do that first) then set all other
sheets to xlVeryHidden again.

Keep in mind that a workbook must always have at least 1 visible sheet -
so
the sequence of unhide/hide is important so that you aren't trying to have
all sheets hidden at one time - ERROR!

"Mr BT" wrote:

Like some software out there are demos and run out after 60 or so many
days
unless they have some code to keep it going, can it be done with an Excel
workbook?
I want my workbook to be used for so many days and then they will have to
upgrade to the next version. I'm not charging the users anything to use
the
workbook, but my employers are not paying me for something I've done on
my
own time.

Thanks,

Mr BT

Thank you very much for your assistance. What you have provided will help a
great deal.
My main concern is that my "colleagues" could claim rights to the
application that I've created. I would like the "demo" to become extinct
with a passcode (which they would never figure out just on a moment's
notice, and make it obvious they (colleagues) did not create my software
(I'm not really sure what I can call it).

Thanks again.

Mr BT

"JLatham" <HelpFrom @ Jlathamsite.com.(removethis) wrote...
....
We looked into several "Excel Compiler"s (do a search, you'll turn up some
possible ones - quality ranges from mere toys to pretty good, but still
with limitations and a learning curve to use them) as a means to protect
the intellectual property side and to try to implement some licensing use
issues. In the end, for his application, none seemed wholly suitable and
he is now having the entire project written in C using the Excel package
as the 'product requirements specification'.
....

There is obfuscated coding techniques which could be applied to VBA. It
wouldn't prevent users from seeing the code, but it might make understanding
the code sufficiently difficult to give up the attempt.

If you want to set up a way to force them to activate macros, you can try
this (again, not proof against the determined and industrious):
Add a single sheet to your workbook that has a notice that if they are
seeing it, then macros are disabled and they must enable macro usage to
use the workbook. Include instructions on how to enable macros (recommend
using the Medium setting: pre-2007 or the 'Disable with notice' in 2007).
into your VB Editor and set the visible property of all other sheets to
xlSheetVeryHidden - this keeps them from even showing up in the list of
Format | Sheets | Unhide. Leave only the 'alert/instruction' sheet
visible.
....

Easily defeated by using macros in a different workbook to activate this
putatively protected workbook and unhide all its worksheets. That's the
problem with Medium macro security: it applies only to the macros in the
workbook just being opened, not to macros in other workbooks that could
still access the workbook just being opened. Just another reason why macro
security is ineffective.

There's no robust way to require macros be enabled since the cleverer users
can defeat VBA project password protection. Since macros in other workbooks
can perform operations on workbooks WITH MACROS DISABLED, macro-based (i.e.,
using events or Subs) is easily defeated.

However, in the spirit of making it too much work to tinker, another
approach is using a simple user-defined function like

Function f(ParamArray a()) As Variant: End Function

which will return the VBA variant value Empty, and make it part of all
formulas in the workbook, adding it to formulas that should return numbers,
in which case this function's return value would be treated as zero, and
adding 0 leave the formula's value unchanged, or concatenating it to
formulas that should return text, in which case this function's return value
would be treated as "", and concatenating any text string and "" leaves the
text string unchanged. When macros are enabled, the formula does nothing,
but when macros are disabled, all formulas would return #NAME? or other
errors since udfs won't work with macros disabled. Then add a warning
message formula on all worksheets like

=IF(ISERR(f()),"Macros must be enabled for this workbook to produce "&
"useful results.","")

I've found this more effective than relying on event handlers or Subs.

"Mr BT" wrote...
....
My main concern is that my "colleagues" could claim rights to the
application that I've created. I would like the "demo" to become extinct
with a passcode (which they would never figure out just on a moment's
notice, and make it obvious they (colleagues) did not create my software
(I'm not really sure what I can call it).
....

If your employer has a technology policy that says any IP you develop
belongs to them, no amount of game playing like this would alter their legal
rights to whatever you develop while in their employ, whether you develop it
on your own time or during work time. If you fail to provide them with
passwords once they ask for them, in the US (and I'd suspect the same would
apply in Canada) you'd then become liable for bad faith as well as failing
to recognize your employer's IP rights.

If you want to develop software yourself on your own time, it's much safer
to get your employer's consent IN WRITING beforehand. You may not get it if
the software you'd be developing were directly applicable to your employer's
business, e.g., you writing inventory control software when your employer is
involved in logistics (warehousing or transportation).

Worst case: you write something many people buy, your employer finds out,
very likely gets the rights to it AND terminates your employment. And if you
withhold anything, they successfully sue you for your remaining net worth
and possiby succeed in getting a share of your future earnings. Up to you to
decide if sneaking a product onto the market is worth it.

I'm writing that one down somewhere that I can find it again in the future.
As you say, you cannot keep the determined out of it. That was the reason
that the fellow I was speaking of in the first post decided to fork out the
$$ (British Pounds actually) to have it done in a language that he could
protect more securely.

The bottom lines to it all a
Is it worth the effort to them to bypass all the impediments in the way, and
Do they have the skills or access to the tools to bypass those impediments.

The only secure system is the one with the power disconnected.

"Harlan Grove" wrote:

"JLatham" <HelpFrom @ Jlathamsite.com.(removethis) wrote...
....
We looked into several "Excel Compiler"s (do a search, you'll turn up some
possible ones - quality ranges from mere toys to pretty good, but still
with limitations and a learning curve to use them) as a means to protect
the intellectual property side and to try to implement some licensing use
issues. In the end, for his application, none seemed wholly suitable and
he is now having the entire project written in C using the Excel package
as the 'product requirements specification'.
....

There is obfuscated coding techniques which could be applied to VBA. It
wouldn't prevent users from seeing the code, but it might make understanding
the code sufficiently difficult to give up the attempt.

If you want to set up a way to force them to activate macros, you can try
this (again, not proof against the determined and industrious):
Add a single sheet to your workbook that has a notice that if they are
seeing it, then macros are disabled and they must enable macro usage to
use the workbook. Include instructions on how to enable macros (recommend
using the Medium setting: pre-2007 or the 'Disable with notice' in 2007).
into your VB Editor and set the visible property of all other sheets to
xlSheetVeryHidden - this keeps them from even showing up in the list of
Format | Sheets | Unhide. Leave only the 'alert/instruction' sheet
visible.
....

Easily defeated by using macros in a different workbook to activate this
putatively protected workbook and unhide all its worksheets. That's the
problem with Medium macro security: it applies only to the macros in the
workbook just being opened, not to macros in other workbooks that could
still access the workbook just being opened. Just another reason why macro
security is ineffective.

There's no robust way to require macros be enabled since the cleverer users
can defeat VBA project password protection. Since macros in other workbooks
can perform operations on workbooks WITH MACROS DISABLED, macro-based (i.e.,
using events or Subs) is easily defeated.

However, in the spirit of making it too much work to tinker, another
approach is using a simple user-defined function like

Function f(ParamArray a()) As Variant: End Function

which will return the VBA variant value Empty, and make it part of all
formulas in the workbook, adding it to formulas that should return numbers,
in which case this function's return value would be treated as zero, and
adding 0 leave the formula's value unchanged, or concatenating it to
formulas that should return text, in which case this function's return value
would be treated as "", and concatenating any text string and "" leaves the
text string unchanged. When macros are enabled, the formula does nothing,
but when macros are disabled, all formulas would return #NAME? or other
errors since udfs won't work with macros disabled. Then add a warning
message formula on all worksheets like

=IF(ISERR(f()),"Macros must be enabled for this workbook to produce "&
"useful results.","")

I've found this more effective than relying on event handlers or Subs.

The only secure system is the one with the power disconnected.

Yep, that's about it. Even a compiled file can be disassembled. Back in the
80's I had a C disassembler. Not used to steal but to learn!

--
Biff
Microsoft Excel MVP


"JLatham" <HelpFrom @ Jlathamsite.com.(removethis) wrote in message
...
I'm writing that one down somewhere that I can find it again in the
future.
As you say, you cannot keep the determined out of it. That was the reason
that the fellow I was speaking of in the first post decided to fork out
the
$$ (British Pounds actually) to have it done in a language that he could
protect more securely.

The bottom lines to it all a
Is it worth the effort to them to bypass all the impediments in the way,
and
Do they have the skills or access to the tools to bypass those
impediments.

The only secure system is the one with the power disconnected.

"Harlan Grove" wrote:

"JLatham" <HelpFrom @ Jlathamsite.com.(removethis) wrote...
....
We looked into several "Excel Compiler"s (do a search, you'll turn up
some
possible ones - quality ranges from mere toys to pretty good, but still
with limitations and a learning curve to use them) as a means to protect
the intellectual property side and to try to implement some licensing
use
issues. In the end, for his application, none seemed wholly suitable and
he is now having the entire project written in C using the Excel package
as the 'product requirements specification'.
....

There is obfuscated coding techniques which could be applied to VBA. It
wouldn't prevent users from seeing the code, but it might make
understanding
the code sufficiently difficult to give up the attempt.

If you want to set up a way to force them to activate macros, you can
try
this (again, not proof against the determined and industrious):
Add a single sheet to your workbook that has a notice that if they are
seeing it, then macros are disabled and they must enable macro usage to
use the workbook. Include instructions on how to enable macros
(recommend
using the Medium setting: pre-2007 or the 'Disable with notice' in
2007).
into your VB Editor and set the visible property of all other sheets to
xlSheetVeryHidden - this keeps them from even showing up in the list of
Format | Sheets | Unhide. Leave only the 'alert/instruction' sheet
visible.
....

Easily defeated by using macros in a different workbook to activate this
putatively protected workbook and unhide all its worksheets. That's the
problem with Medium macro security: it applies only to the macros in the
workbook just being opened, not to macros in other workbooks that could
still access the workbook just being opened. Just another reason why
macro
security is ineffective.

There's no robust way to require macros be enabled since the cleverer
users
can defeat VBA project password protection. Since macros in other
workbooks
can perform operations on workbooks WITH MACROS DISABLED, macro-based
(i.e.,
using events or Subs) is easily defeated.

However, in the spirit of making it too much work to tinker, another
approach is using a simple user-defined function like

Function f(ParamArray a()) As Variant: End Function

which will return the VBA variant value Empty, and make it part of all
formulas in the workbook, adding it to formulas that should return
numbers,
in which case this function's return value would be treated as zero, and
adding 0 leave the formula's value unchanged, or concatenating it to
formulas that should return text, in which case this function's return
value
would be treated as "", and concatenating any text string and "" leaves
the
text string unchanged. When macros are enabled, the formula does nothing,
but when macros are disabled, all formulas would return #NAME? or other
errors since udfs won't work with macros disabled. Then add a warning
message formula on all worksheets like

=IF(ISERR(f()),"Macros must be enabled for this workbook to produce "&
"useful results.","")

I've found this more effective than relying on event handlers or Subs.

And I had one in the early 80's to disassemble Z-80 code. Used it to
decypher Radio Shack's TRS-DOS operating system to find entry points into the
code which was basically a way of hacking out API calls. Heck, I even wrote
one once to disassemble Data General Nova 3/12 code - used it for code
failure analysis and for training. Kind of miss those 'good old days'
sometimes.

"T. Valko" wrote:

The only secure system is the one with the power disconnected.

Yep, that's about it. Even a compiled file can be disassembled. Back in the
80's I had a C disassembler. Not used to steal but to learn!

--
Biff
Microsoft Excel MVP


"JLatham" <HelpFrom @ Jlathamsite.com.(removethis) wrote in message
...
I'm writing that one down somewhere that I can find it again in the
future.
As you say, you cannot keep the determined out of it. That was the reason
that the fellow I was speaking of in the first post decided to fork out
the
$$ (British Pounds actually) to have it done in a language that he could
protect more securely.

The bottom lines to it all a
Is it worth the effort to them to bypass all the impediments in the way,
and
Do they have the skills or access to the tools to bypass those
impediments.

The only secure system is the one with the power disconnected.

"Harlan Grove" wrote:

"JLatham" <HelpFrom @ Jlathamsite.com.(removethis) wrote...
....
We looked into several "Excel Compiler"s (do a search, you'll turn up
some
possible ones - quality ranges from mere toys to pretty good, but still
with limitations and a learning curve to use them) as a means to protect
the intellectual property side and to try to implement some licensing
use
issues. In the end, for his application, none seemed wholly suitable and
he is now having the entire project written in C using the Excel package
as the 'product requirements specification'.
....

There is obfuscated coding techniques which could be applied to VBA. It
wouldn't prevent users from seeing the code, but it might make
understanding
the code sufficiently difficult to give up the attempt.

If you want to set up a way to force them to activate macros, you can
try
this (again, not proof against the determined and industrious):
Add a single sheet to your workbook that has a notice that if they are
seeing it, then macros are disabled and they must enable macro usage to
use the workbook. Include instructions on how to enable macros
(recommend
using the Medium setting: pre-2007 or the 'Disable with notice' in
2007).
into your VB Editor and set the visible property of all other sheets to
xlSheetVeryHidden - this keeps them from even showing up in the list of
Format | Sheets | Unhide. Leave only the 'alert/instruction' sheet
visible.
....

Easily defeated by using macros in a different workbook to activate this
putatively protected workbook and unhide all its worksheets. That's the
problem with Medium macro security: it applies only to the macros in the
workbook just being opened, not to macros in other workbooks that could
still access the workbook just being opened. Just another reason why
macro
security is ineffective.

There's no robust way to require macros be enabled since the cleverer
users
can defeat VBA project password protection. Since macros in other
workbooks
can perform operations on workbooks WITH MACROS DISABLED, macro-based
(i.e.,
using events or Subs) is easily defeated.

However, in the spirit of making it too much work to tinker, another
approach is using a simple user-defined function like

Function f(ParamArray a()) As Variant: End Function

which will return the VBA variant value Empty, and make it part of all
formulas in the workbook, adding it to formulas that should return
numbers,
in which case this function's return value would be treated as zero, and
adding 0 leave the formula's value unchanged, or concatenating it to
formulas that should return text, in which case this function's return
value
would be treated as "", and concatenating any text string and "" leaves
the
text string unchanged. When macros are enabled, the formula does nothing,
but when macros are disabled, all formulas would return #NAME? or other
errors since udfs won't work with macros disabled. Then add a warning
message formula on all worksheets like

=IF(ISERR(f()),"Macros must be enabled for this workbook to produce "&
"useful results.","")

I've found this more effective than relying on event handlers or Subs.

"Harlan Grove" wrote in message
...
"Mr BT" wrote...
...
My main concern is that my "colleagues" could claim rights to the
application that I've created. I would like the "demo" to become extinct
with a passcode (which they would never figure out just on a moment's
notice, and make it obvious they (colleagues) did not create my software
(I'm not really sure what I can call it).
...

If your employer has a technology policy that says any IP you develop
belongs to them, no amount of game playing like this would alter their
legal rights to whatever you develop while in their employ, whether you
develop it on your own time or during work time. If you fail to provide
them with passwords once they ask for them, in the US (and I'd suspect the
same would apply in Canada) you'd then become liable for bad faith as well
as failing to recognize your employer's IP rights.

If you want to develop software yourself on your own time, it's much safer
to get your employer's consent IN WRITING beforehand. You may not get it
if the software you'd be developing were directly applicable to your
employer's business, e.g., you writing inventory control software when
your employer is involved in logistics (warehousing or transportation).

Worst case: you write something many people buy, your employer finds out,
very likely gets the rights to it AND terminates your employment. And if
you withhold anything, they successfully sue you for your remaining net
worth and possiby succeed in getting a share of your future earnings. Up
to you to decide if sneaking a product onto the market is worth it.


I don't think its so much that my employer would have rights to it that I'm
concerned about. Its more that I don't want my "not so trustworthy" peers
taking credit for my work.
So the digital signature sounds like a good path to go down.
But an issue I do have with my employer selling this software is that the
base macros are things that were provided by other people included some from
this ng.
The tool and the way it works for the company and how its applied to help
our client is my idea, but I wouldn't have done some crucial (for example
the custom toolbar loads with scripts I picked up here) programming without
your (all) help.

Does my company have rights to the application I created using scripts
provided here and elsewhere?

Mr BT

"Mr BT" wrote...
....
Does my company have rights to the application I created using scripts
provided here and elsewhere?

I'm not a lawyer, so the following is idle speculation.

I'd guess the answer was YES. Myself, I'd proceed as though the answer were
YES until a lawyer with demonstrated knowledge of local IP law clearly
stated otherwise.

As for all the macros you may have picked up in newsgroups, unless they
include explicit usage restrictions, they're public domain. They may be used
by anyone else for any purpose, and the author retains no rights to exercise
any restrictions nor seek royalties. They retain implicit copyrights to
their own code, so you can't copyright it, which means anyone else can use
their code even in products that compete with yours, and you'd have no basis
to sue them for copyright violations for using effectively public domain
code. Well, you could try, but the odds are you'd fail and very possibly
wind up on paying their legal fees and also possibly facing countersuits.