Protecting Runtime Solutions from being copied

[Peter Ardis]

Any suggestions on how I might protect my runtime solution from being copied and recopied. I am close to trying to sell a program or two, but how do I stop a school from buying a copy and giving it to all schools in the district. I have passwords set up, but that does not stop them from sharing passwords. I am aware that this thread might lead me out of the domain of filemaker but perhaps its a start.

[Sunshein]

I'm not sure there are ways to keep it from being copied. I would, of course, utilize a licensing agreement which requires the user to sign in agreeing to a binding and limited usage of your software. Obviously if multiple copies are shared without authorization, you have some recourse.

 

Beyond that, I will also look forward to a better suggestion to surface from a more experienced developer on this forum.

[touchMe]

contract, contract, contract...

 

when you really stop and think about it, someone copying your solution for their use is really quite a compliment... imo, don't stop folks from copying your work, just work out a way to keep yourself informed about who has

 

a simple email routine which kicks-in and sends you a nice little info package can be a good idea... it can lead to additional sales for you

 

in terms of protecting your stuff microsoft (even FileMaker) style... there must be one-hundred and one ways to do this, a variable license.key code that needs to be matched to a record by contacting you each twelve-months, or when initially opened, or after thirty-days etc. can work well

 

contract, contract, contract

[Peter Ardis]

Touchme

 

Any links/readings/advice you could provide that would help me establish the email link as you suggest would be appreciated. Would the user have to have a specific email program for this to work? I know that FM will only allow certain email programs to send data files 'as an attachment' for example.

 

I need to know more about a variable license.key code system. Any hints/readings? Are their ebusinesses out there that can set this up for me?

[Peter Ardis]

P.S. I just noticed a great response to what I am looking for at the bottom of this thread from two years ago. Has FM added the features he suggests? Is he right?

[touchMe]

Peter, sorry I did not reply earlier... I missed the thread. Short answer; I am going to change my name to something more appropriate and join the cafe here, I think then I will be able to post files etc., - I have a couple of ideas that might be of interest.

 

Just my opinion but I tend to agree with the second poster in the thread you mentioned below.

 

The way I look at it, if someone steals my work... then I can steal their name, address etc., (it is only fair). Your users (legitimate or pirate) no doubt have the ability to setup their 'preferences' in your solutions... to personalize their user experience and make the product functional for their own use etc., does this include their contact details? (hopefully) - are they on-line? - or are potential pirate copy users liable to be on-line?

 

Macs or PCs? both? - I cannot speak to the PC side of things, but from what I read SmartPill (or other) might do what I have in mind for SMTPit (given that users may be, or are liable to be, on-line)

 

If specified user details change (at any time), then have your app send an email from within FM to you with a packet of data from user-detail fields. It may just be a change of primary user, or even a change to telephone/fax etc., from a legitimate client, but... maybe not (just one thought)

[Maarten Witberg]

The way I look at it, if someone steals my work... then I can steal their name, address etc., (it is only fair).

You can technically, but I am not sure you can legally do this.

 

How about this... (not tested)

Issue registration keys. in the startup script run a subscript "first run", store the nic-address of the workstation and compare the registration key to a list stored in a utility table (remove it from the table). set a boolean FirstRun to 1. Then at each following startup, skip the first run script, compare the nic-address of the computer to the one stored in the utility table. If it does not compare, ask the user to register with you to obtain a new registration key. If you have a list of say, twenty keys in the runtime, then conceivably you have enough reinstalls by the original user covered.

Then if he refuses to register, have him opt to quit the program or run a trial version of some kind (limited time, limited records, whatever). If he can produce a valid registration key, reset the nic address and remove the registration key from the list.

 

As far as I know removing admin access to a solution will make it impervious to password crackers but I'd appreciate if someone can enlighten me on this. Possibly nothing in the end is safe from malicious hackers, but is your solution likely to be a target of this? You'd have to make a balance between perfect protection and cost to set up and maintain versus lost income. That depends on your situation.

[touchMe]

problem with a startup script is that the user can cancel it... [cmd-period]

 

what about something 'hidden-in-plain-sight' ?! - like, eh... a startup script (that the user could cancel, ha!)

 

the thing is... most users are just to damned scared of software, even if they have full-access... otherwise they would simply build the mouse-trap themselves!

 

the way I picked up on the question was I got the feeling that someone experienced might steal the software and pass it off as their own or sell it on without 'royalty' etc.,

 

you are probably correct to concern about the legality of 'stealing' data, I think it could even be categorized as mail fraud... that's federal dude! - have you ever looked at the data microsoft grabs when registering??? - crap, that really should should be illegal

 

I just think FMP folks are cleverer than all that... something real creative!

 

Some kinda plugin, a dongle without the 'dongle' ???

 

Hey what about the file comment field... the file info window that few ever open - the comment field is cleared when the file is copied, now something in there could be useful, man I need to switch-off and sleep!!!

[Maarten Witberg]

problem with a startup script is that the user can cancel it... [cmd-period]

in file preferences, set the startup layout to be a no-access layout with a menu set that is essentially empty (simply lock it from all privilege sets except [full access]

so if he manages to cancel the startup script, he'll end nowhere.

see sample here.

 

 

Some kinda plugin, a dongle without the 'dongle' ???

I have software that won't run without a license file installed. It stores type of license, and some encrypted key built from (I gather) the machine's nic, a product key and possibly more stuff. I'd like to know how to build that key, but it's probably math above my head. nevertheless...

[touchMe]

I kinda like your idea for registration keys, register on-line or by phone (MS or FM style)... all software is copied, so provide the option for a 30 day trial or whatever, automate Phlink to handle the 'registration' through phone key presses (the user enters the product code, shown on startup screen) and Phlink looks up FMP and uses synthesised voice to provide user PIN

 

this would keep track of trial user source(s) [ref: original product code registrations] and stats from trials to sales, and so on... that might be something worth considering, just for the 'feel'

[touchMe]

damn! I can't see your file, and I can't upload an idea or two I have... how the heck does Pay Pal work?? - can I not even stick up a jpg or three?

[Jack Rodgers]

I've established on another thread that startup scripts can be stopped.

 

I've also shown how to create a log file using all of the gets to grab tons of data about the user and save it into a table.

 

Now if the startup script can be stopped, can the user stop every attempt to gather the info? No.

 

Why not, well if you included a perform script in every important script that would perform this startup script action, how could the user interrupt this and still use the solution?

 

So, set up your table of authorizations and then create a script putting the get info into variables.

 

Set Variables for Gets:

Get Nic

Get User Name

Get Preference Name

etc.

 

Now just use a quick search for $Nic in your table or whatever and if not there set $Flag to true or false accordingly.

 

At some point performing that script will set $Flag to true or false after these hundreds of attempts.

 

So you need at least two scripts to perform:

 

If ( isempty ( $Flag )

...perform script set variables for Gets

else if ( $Flag = "No License" )

...perform script No License Gotta Quit

end if

 

No License Gotta Quit:

Dialog: This computer is not licensed to run my solution.

Dialog: Step back from the computer as I am goingo to Destroy It...

Dialog: Just foolin...

Quit Filemaker

 

By mixing in the Performed Script at various critical points in your important scripts it will act quickly and not be noticeable and since it is triggered in a hundred different places your user will not be able to determine when or where to stop it.

 

Using just the startup script to check is so boring and unimaginative and easily defeated...

 

Maybe I'll market the idea? Any buyers?

[Maarten Witberg]

my solution (post #9) has the same aim. If you don't run the startup then you're in a dead end layout with nothing to do except quit. Unless you point out how that can be circumvented - not counting having admin access, which can be removed from distributed copies anyhow - I'm not going to buy. And even then... smiley-undecided

[hugh71158]

Why can't the buyer run a script that captures their nic address - then you hard code it into the solution before you give it to them. A script can then compare the numbers.

 

Hugh

[JeffGagne]

Any suggestions on how I might protect my runtime solution from being copied and recopied. I am close to trying to sell a program or two, but how do I stop a school from buying a copy and giving it to all schools in the district. I have passwords set up, but that does not stop them from sharing passwords. I am aware that this thread might lead me out of the domain of filemaker but perhaps its a start.

 

This has been an issue long before the Developer Edition and is far more complex a topic than even FileMaker. ALL software is subject to piracy and misuse. Having said that in your example above I would find it VERY hard to believe a "school" would do as you have said and copy your solution. The IT Director would soon find themselves out of a job if that were going on. In that case a flxible licensing arrangment and volume discounts are your best tools. If you think your software is valuable to the entire district look to a server based solution either with FMP, web-based, or both.

 

The suggestions here, tracking the NIC, etc., will only upset your users, cause you support issues, and give your product a bad name. Sure protect your work with passwords etc., but to force ligitmate users to jump though hoops will only give your competitors an advantage.

 

IMHO!

[Jack Rodgers]

The suggestions here, tracking the NIC, etc., will only upset your users, cause you support issues, and give your product a bad name. Sure protect your work with passwords etc., but to force ligitmate users to jump though hoops will only give your competitors an advantage.

 

Perhaps you were referring to someone else's suggestion as I know mine happens so quickly that the user won't notice anything... So Cool!

 

There were no hoops involved although that might not be a bad idea to give the users a little excercise since they are mostly immobile and never sweat...

[David Head]

The suggestions here, tracking the NIC, etc., will only upset your users, cause you support issues, and give your product a bad name. Sure protect your work with passwords etc., but to force ligitmate users to jump though hoops will only give your competitors an advantage.

 

IMHO!

So Jeff, you would not support the current FileMaker activation process?!

smiley-wink

[JeffGagne]

So Jeff, you would not support the current FileMaker activation process?!

smiley-wink

 

I really don't think you can make a comparison. If the runtime had a internet enabled activation capability that might be different. I also think if every developer had the resources and sales FileMaker where every sale wasn't important then I might also agree.

 

Having said that, no I don't agree with the current 30-day trial version expiration thing for FileMaker. I think the old way with record limits and watermarked printing was just fine. The 30-day thing can easily be reset if the persons intent is to do so while those that are still learning are put at a disadvantage as if that will some how cause them to buy.

 

I would have argued against the change.

[Jack Rodgers]

So Jeff, you would not support the current FileMaker activation process?!

smiley-wink

 

No. It installs a third party application as a root process and that software company has a history of causing problems in Windows. Also, if you open that exe file with a word procesor you will find all kinds of interesting calls that it is making.

 

Hackers have already found a way to bypass it and there is only a little time before someone discovers how to use it as a way to hack your system.