Search the Community
Showing results for tags 'copy protection'.
Found 1 result
I know the question's been asked many different ways and answered, or not answered, in many different ways. I think that one problem in answering the question is that every developer has a slightly different situation. There are too many variables and that makes it difficult to provide a solid answer. Also, I think in part, there is no good answer. My questions, comments and downright personal opinions are all blended together but hopefully the format reads well and in addition to getting answers for myself, I hope you'll post your thoughts so other shrink wrap developers can get some definitive answers. FIRST - WHAT I'VE DONE IN THE PAST... I have a solution that's currently on FMP6 and has hundreds of users worldwide. I'm almost done developing the FMP11 version. Generally it's an ERM solution and I sell it per seat. Some companies buy a single-user copy and other companies buy up to about 10 multi-user and run FM Server. Some companies have one location, some have multiple locations and some customers are US Military and DOD who have restrictions that I'm not completely familiar with. The solution is currently at version 5 and is about 25 years old. I have a 15 day 'trial' period written in the software but actually don't provide anyone with the software until after they've received free training and then purchased the software. The solution uses about eight plug-ins for everything from date pickers to license control, although a new solution with the same features would only need one or two plug-ins. When a customer purchases a single-user license we provide a runtime solution while multi-user customers receive a non-runtime and a copy of FMP. We actually charge $100 more for the runtimes so we make less per license for multi-users. The solution is Windows only (because of the plug-ins and at the time) and I selected InstallShield as an installer. It provided a professional impression. I felt it was important that the installer or installation process didn't look cheap or unworthy of the cost of the software. I also had to install plug-ins that were dependent on the OS version so I had to be able to check for the computers OS version. For copy protection it uses a plug-in to get the HD Serial Number of the server and each client. The user must first open the solution locally on the server to record the HD Serial Number, then send us an encoded ID Code that the software generates. We enter the code in our license management database to generate a matching License Number then return that to them. The encoded License Number includes the number of clients they've paid for, the company name and the installation timestamp. They enter that License Number then, if multi-user, the HD Serial Number of the next x number of clients to login get recorded and are active. An administrator can deactivate any client so they can replace computers themselves. The first recorded HD Serial Number cannot be removed thus a single-user license cannot be moved. The process of changing a client license themselves is intentionally a little difficult so users don't just switch clients around on a daily basis depending on who's out sick that day. SECOND - THE PROBLEMS I'VE FACED AND HOW I'M ADDRESSING THEM... I won't use plug-ins. Over time, managing them becomes a nightmare. Managing different OS versions, FM versions and updates in the plug-ins will kill you. Even at the cost of missing features. I will use them myself and for my few custom software customers, but managing hundreds of different systems is impossible. And that was only on Windows. I won't use a complex installer. One reason I used InstallShield was because of the plug-ins. For the next version I either won't use an installer at all or will use a simple one named InstallBuilder by BitRock (just a personal choice - cross platform). Building, screwing-up, testing and screwing-up installation packages would sometimes take a whole day and I'm sure I've done it 50+ times in a rush to get a fix published. It just wasn't worth it. I won't use runtimes anymore. Although it's saved me in FM licensing costs, I've found it's very difficult to manage different versions and also it isn't worth the problems. It's easiest to have one golden copy of the database and one distribution copy. Even without plug-ins and a complex installer, some type of compression is required for distribution (such as WinZip) and documentation. Having to only create one set of documentation is a big benefit. THIRD - MY EXPERIENCE WITH COPY PROTECTION AND MY THOUGHTS... Within FMP and without plug-ins, using the MAC/NIC address is probably the best way to provide copy protection. The issue of multiple NICs isn't a problem (I don't want to get into specific coding but there are probably many threads about this) and even though the address can be spoofed or the user may need to replace the NIC card, it provides an internal serial number that every modern computer has. Unless you sell a technical product, I wouldn't worry about MAC address spoofing. Most people don't know about it and most who do, probably don't want to hassle with it. Other than on servers or extraordinary environments, NICS don't die much and don't need to be changed. Notebooks that have both of their NICs integrated into the motherboard are probably the biggest source of problems when using the MAC/NIC address as a unique identifier. If a NIC goes out you will have to provide a new license number. You don't want your copy protection wound too tightly for inexpensive products. Some of my sales are over $10,000 and customers STILL are annoyed by the copy protection. Just think of yourself (and maybe a company like Adobe that makes it nearly impossible to move software). Personally, I want to get my work done and not fight with the software publisher about if I did or didn't pay for the software. Two thoughts about piracy come to mind; 1) You can't stop it completely. 2) Sometimes you want it. Up to version 3 of my software I had no copy protection. One customer in particular made at least 10 copies and used it at his 10 locations. He got a real deal. But when I release version 4 of my software - that included copy protection - his company was hooked on it. He had to purchase 10 copies because now he 'had' to have it. His business operations became dependent on it. You will always have some 'leakage'. Just look for a way to leverage it. If you're selling a small $29 utility, you may not want any copy protection. People won't buy two copies for themselves and for the hassles you create you will probably waste a lot of your time and lose an unknown number of $29 sales. Having essentially said "Don't worry too much about copy protection"... I worry a lot about copy protection. Just because you need to face the reality that some people will steal your software doesn't mean you don't avoid it. After all, that is the basis of the long and convoluted question I'm asking here. FM Inc. learned this the hard way when they added the activation process to FMP (even with strong pre-release complaints) then later removed it. My point here is that giving copy protection a lot of thought and consideration isn't the same as having air-tight copy protection. People are honest - at least when they think you're watching. Our license agreement (that nobody reads) says the customer can receive up to three license codes within a 5 year period. It's written to imply they can get a replacement code twice but it really says, they get three installations. Since we do a low volume of sales, customers have to call us for a replacement code. They always have an excuse. Sometimes bull crap but usually they sound valid. I don't think we've ever limited the number of license numbers we provided but I can count on one hand the number of customers that have gotten more than three in five years. As I add functionality to the solution, they'll want those possibly illegal computers to work together in a multi-user environment and will then need to purchase three licenses. I won't play lawyer and don't know the details of the law but you MUST allow the customer two installations. Technically, one is a backup but this needs to be kept in mind in how you manage the copy protection. For single-user customers, we handle this as mentioned in the paragraph above but for all users (single- and multi-user) we keep a golden copy of every release and will provide the originally purchased version to any customer upon request. (We have customers still using a DOS version and one who just got a replacement copy about 5 years ago.) FOURTH - MY COPY PROTECTION DOESN'T WORK... I'm only mentioning this because this vulnerability is being overcome in a way that I'm not mentioning here and that's unique to my market. Although I don't think any of my customers know it, capturing the HD Serial Number, MAC/NIC address, etc. doesn't work for multi-user. If FMP could capture more data about devices that would be helpful but the issue comes into play with FM Server. There is no way to definitively tie the solution to the server from a client. Once the user registers a client in the database, they can move that entire database with the one PC to a new network thus creating a second copy of the database at a second company location. Most screens and all printed output includes the company's name and most all screens include a link to our website. This feature assures that if a customer did run across this vulnerability, they would still be compelled to keep it within their company and not provide it to a friend. In the upcoming version, the user/administrator will have to access the database directly from FMP on the server (with FM Server off) to remove client computers. This still leave some vulnerability but greatly reduces the likelihood of piracy. (more below for other readers looking for answers and not necesssarily about my question) FIFTH - ABOUT TRIAL PERIODS... Personally, I think if you're building a small solution, you need one. If you're building an expensive solution, you definitely don't. Based on posts I've read, many people make the mistake of thinking everyone who downloads their solution is using it thus downloadQty - salesQty = pirateQty. Keep in mind that a trial period is so people can try it. Hopefully they'll get addicted but most won't. Depending on the solution, some people may only need it for 30 days so they'll use it for free. I'm not a top tier developer - just a FileMaker guy so I'm sure there are smarter, more detailed ideas that can be contributed, but in general, for the best copy protect for a trial period you have to have a plug-in to write a file to somewhere most users won't find it. There's other ways such as writing to the registry or modifying an existing file but I think that's beyond the requirements of a FileMaker developer who would be asking the question about Trial Period Protection. The file can be a simple text file - maybe with an obscure extension - that only has the installation timestamp in it. Anytime an unregistered solution runs it will check if the file exists. If so, it checks the date to see if the trial period has lapsed. If not, it creates the file and continues. You'll also have to consider current anti-virus software and when the file is written. If you don't use an installer, the A/V software may catch that you're writing the file and expose the filename and location. Going further on this concept is beyond my skill level. If your solution creates valuable data, a simpler way is to disallow any data output other than the screen (no printing or export) until the trial period is over. This way when a user uninstalls then reinstalls the trial copy, they lose their data. If you do this, you have to enter in the license agreement that they don't own their data during the trial period. Again, I don't want to play lawyer but unless you specify otherwise, the customer owns the data and has to have access to it after the trial period expires. If you're Apple or Microsoft, the market (people) wouldn't let you take ownership of their data but for a small app, it seems practical. SIXTH - PHONE HOME... You can have a hosted licensing server that every database connects to either through an external file reference or using the web browser. For example, monthly have the software contact your server and have a verification code/process to assure the license isn't being bounced around the globe. In the event the software isn't legal either disable through pre-established scripts or maybe set it back to trial mode and provide the user with a message offering them to purchase it. Users will likely be turned off by a "You're busted!" message and may respond with a payment by a "No problem, just send in the money" type message. I can't use Phone Home because some of my customer's are in areas without Internet access or installations are in military field units. I do think this is the best for a large solution though and may add it later. If so, I will add a feature that allows me to turn it off via the License Key that I provide the user. SEVENTH - THE LICENSE KEY... You can do a lot with the license key. There's little need for a UUID or xxxx-xxxx-xxxx-xxxx style key. Since the key may be provided directly database-to-database or via an email where a user can cut-and-paste, you can make it as large as you want. A larger license key (and license request key - sent to you to get the license key) allows you to embed more data. You to send more data to activate or turn off certain features. Turning on or off the phone home feature is a good example. Some large corporations or a deployed military unit won't accept a phone home system so it would have to be turned off. You may not need to encrypt it but you may need encryption for user data anyway. Consider Brian Dunning's Easy Encryption or Ray Cologon's Data Vault Maker. They're good FileMaker quality encryption. Maybe not perfect but I think good enough. I used to just create random numbers then convert some of them to letters and mix them with the real data which was also scrambled. Again, I don't think anyone's ever figured it out. Part of security is keeping it secret (and again, my solution is 9 years old and is being retired otherwise I wouldn't mention it) EIGHTH - USERS PASSWORDS... Here's where I'm sure I'll get kicked in the teeth by some people! If you don't use the separation model, you either have to not use FileMaker user accounts or you need to capture, encrypt and store the user's passwords in the database. Since I don't use the separation model, I won't mention all my methods here. When a user updates their (your) solution, they have to be able to move their user accounts. Assuming your not using external authentication, you have to have the data available to create the user accounts in the new database. The only way to do that is to store the passwords in the database. FileMaker Inc. (and some other smart and trusted FM consultants) will say this is an absolute no-no, but until FMI creates a way to securely migrate passwords, it's the only choice. You can not only encrypt the passwords, but also be creative and deceptive in how you store them. Having said that, an idea that just came to mind - under the separation model umbrella - is to have a seperate privileges table. Hopefully someone will comment on this. Since it just came to mind, I'll have to sleep on the idea. NINTH - THE SEPARATION MODEL... I'm not using the separation model for the new version and don't see myself ever using it. This is in part because of a unique issue I've run into with speed using many hundreds of relationships and probably tens of thousands of repetitions of the Evaluate() function during a commonly run set of scripts. Also, any time you need to change the structure of your database, you need to update the whole thing. So you need a solution that is very static or a method of updating the entire database. Many people use the separation model and are very profitable with it. There are ways of reducing the frequency of complete updates required by pre-creating fields and scripts with external references, etc. but for me it seems that unless FMI creates total separation it's best to just update the entire solution. I know there's many opinions for and against the separation model and there are situations that I would choose it but I think that's an entirely different conversation. FINALLY - MY QUESTION... How do I protect a multi-user FileMaker solution in a way that's manageable, won't take all my time, and won't *** off all my prospects and customers? Like I said at the start; there have been a lot of questions about this. The responses always seem to be more questions. Questions about the size of the solution, the market, the number of users, the network configuration and so on. Hopefully I've helped educate some people who have asked about copy protection for their solution. Also, hopefully I've also provided enough information about my situation that someone can provide a good answer to the giant question... "How do I copy protect my FileMaker solution?" Thanks!