Expanding FilePro Market

Brian K. White brian at aljex.com
Fri Aug 19 16:24:47 PDT 2005


----- Original Message ----- 
From: "Richard Tartaglias" <fp at masscollector.com>
To: <filepro-list at seaslug.org>
Sent: Friday, August 19, 2005 2:24 PM
Subject: Expanding FilePro Market


>
> I have been using FilePro since the days of the Tandy model IIII and it 
> was called ProFile. Now I about to venture into unknown waters. I may 
> offer for sale a program that I use in house that there seems to be a 
> market for.
>
>
>
> I am sure a lot of the people on the list write "for sale programs", so I 
> thought I would ask the questions rather than take 2 steps forward and 10 
> back.
>
>
>
> When I buy a FilePro license do I keep it in my name and lease the rights 
> to the end user along with the program or do they own the rights.
>
>
>
> Should I put some type of security in the code to shut down the software 
> if maintenance fees are not paid when do.
>
>
>
> I hope these questions are appropriate for this list. It is about 
> expanding the use of FilePro.

The end user owns their own license for their own filepro binaries.

You are free to do whatever you want with what you created in filepro.
Note, if you ever hired progrmmers to do work for you, and any of that work 
is in your app now, you better look at your contracts and/or contact the 
people again and make yourself certain about your rights & obligations wrt 
that work. Some things might never have been spelled out enough in the first 
place and you should probably resolve it and nail it down now before 
proceeding.

Filepro provides several means for you to protect your code. Most of them I 
think most of us don't use because it makes it too inconvenient to do 
further development for the end user, and that is where we make a lot 
(most?) of our livings in the form of hourly programming rates.

You could also write any number of protection schemes into the app yourself. 
In the past our app used to have a demo windows version that included plain 
old filepro code in some of the key input processing tables that incrimented 
a counter file with each transaction and stopped working when the counter 
reached the set mark. Then if the user bought the system, we either arranged 
to log in to the system via pcanywhere, which was a neccessary part of the 
setup anyways for support, and accessed a hidden menu that removed the 
setmark and walked through other initial setup chores. So if they wanted, 
they could just pick up where they left off and not lose any real work they 
did in the demo. But that was just for a demo before we had the superior 
unix+internet+facetwin based demo. Once purchased, the app has no limits.

We charge more for more users, but don't have anything in the app that tries 
to count users and enforce a limit. fp and facetwin and the os already do 
that too much for _everyones_ convenience.

We also don't bother trying to protect the source except legally by terms in 
the sales contract. If we were selling a canned app to a million individual 
people instead of an evolving app to a few businesses, we could provide only 
*.tok (rather, tok.* on unix) files to the customer and they could never see 
the source. A less thorough option would be to remove "ABE=ascii" from your 
config file, set a site password, and resave all your process tables. Then 
the prc.* files would all be encrypted and you could include them in the 
customers copy. If you didn't give the customer a copy of your fppath file 
(which has the site password in it), then you could still do development for 
the customer by entering the site password every time you go to open a 
process table and they couldn't see the code ouside of rcabe/dcabe, and they 
couldn't use *cabe to see the code without knowing the site password you had 
in your fppath file when you resaved all the tables.

Some murkier areas I don't know exactly what we do.
* can they sell the app in the form of transferring ownership as a business 
asset when selling the business?
* what about when a customer grows and spawns one or more child/sister 
companies that need the same app? It happens all the time to our customers 
and I know we do make copies and/or new qualifiers because I help do the 
work, but I don't know who pays who for what exactly.

I've only seen perhaps 20 fp installations that werent our own code 
(including the first time I ever saw fp and I was the customer) but every 
one of them also included the source in an accessible format, either plain 
ascii or with a matching fppath file so that rcabe/dcabe didn't ask you for 
a password.

Lately, for those smaller users who might be potential "no ongoing 
development, no source" type of customers, we handle by letting them log in 
to our server over the internet instead of them buying a server and a 
seperate copy of the app (and facetwin, and vsifax, and pcmiler, and unix, 
and backupedge, and filepro). In that case, the source is both available to 
us for development, and yet protected, because these users simply don't have 
any access to the server outside of their filepro application menus, which 
does not include the filepro main menu or any other way to run *cabe or the 
other development programs. The filepro binaries are a single set, owned by 
us, that all customers use. We have to keep upping our license counts for 
fp, facetwin, and sco to accommodate. These customers pay a monthly 
subscription for access to the system and we can just disable user accounts 
at will, so these customers do have timeout limits but it's not written into 
the app and we're not strict about it. If someone has a problem we'll work 
with them not just shut them off, which aleviates a lot of what I'd be 
worried about if I was running my business on some kind of subscription. Not 
that relying on subscription software is much different from relying on your 
subscription electricity, phones, insurance, rent, etc...

How rabidly to protect your source and/or limit the functionality of your 
app is a pretty philosophical issue that any 10 people will collectively 
have at least 100 different opinions about.

Brian K. White  --  brian at aljex.com  --  http://www.aljex.com/bkw/
+++++[>+++[>+++++>+++++++<<-]<-]>>+.>.+++++.+++++++.-.[>+<---]>++.
filePro  BBx    Linux  SCO  FreeBSD    #callahans  Satriani  Filk!



More information about the Filepro-list mailing list