During the past weeks, I developed and published a small OS X utility app that sells for ~$3 in the Mac App Store. However, due do French export laws for apps that include encryption mechanisms, the app is not available in the French app store.
(It ships and uses libssh2 and implements SCP over SSH, and therefor does not use "encryption mechanisms that are provided by the operating system" - the registration process for that is all in French and neither Apple nor the French government seems to be able to help with that.)
As I got a bunch of emails asking why the app is not available in the French Mac App Store by now, I thought about offering a non-MAS version of the app. Coming to my initial question, I'm not sure if I want to spend time on implementing any kind of license key check etc., or just offer that version completely without DRM / license checks as it surely will be cracked either way. (The Mac App Store version is available as a torrent for quite some time now, so whoever wants to steal the app will do no matter what I finally do.)
So, I'd like to ask you guys how you handle this, or how you would handle this if you were in my situation? Spend time on implementing a license key check that will be cracked either way, or just offer a non-DRM version that'll sell in France to make everyone happy?
Thanks.
Disclaimer: Original thread from HN (https://news.ycombinator.com/item?id=7796397)
Update to finish this up:
I finally decided to implement a license validation for the Mac App Store version that is very hassle-free for the user. In the best case, he doesn't even notice this, in the worst case (where no receipt is found within the app bundle) the app will trigger the storeagent to download the receipt and then successfully relaunch. Pretty simple.
For the non-Mac App Store version (which I've introduced because of the French App Store issue explained above) I stick with a 3rd-party contractor who handles all the licensing for me.
I guess this way is a good tradeoff between security and positive user experience. Thanks for your input.
In my experience, if you are going to sell the software, you should consider a very lightweight license checker. As you pointed out, people will break your DRM if they are sufficiently motivated, so you can't hope to prevent intentional piracy. However, having a simple system that reminds users who download the software online that they should pay for it (and if it makes sense providing a basic trial system) is a reasonable approach.
However, don't spend too much time implementing the system, and make sure you thoroughly test the key system before every release, because trying to explain to users that you accidentally made it impossible for them to use the software that they have paid for is something you never want to do.
Bigger than the question of whether it's going to be hacked is whether the overhead of managing the licensing will overwhelm the profit. For example, I've seen people with very inexpensive apps basically have a checkbox for users who bought the app in order to turn off the reminders in trial versions. Very shareware-like, but considering the cost and potential review hassle of a problem with licensing, it might be worth considering that approach.
If you want to put in a bit more effort, there are a couple of open source libraries, including Aquatic Prime that provide more sophisticated protection , but require integration with whatever type of online store you are using. Since it's reasonably widely used in the community, store systems like FastSpring provide built-in integration with it. Also, it looks like the open-source Potion Store supports it out of the box. I've not used it personally.
Beyond that, my experience is that they are a large pain to create/debug/support and unless your app is expensive enough to require special features like partial-enabling, expiring licenses, region testing, real-time revocation, etc., it is likely not worth the effort to do anything custom.
Related
I have developed a small app for OS X and I provided it in the Mac App Store. Some weeks later I found a cracked version of my app on rapidscene.me. It seems for me the code signing of Apple is not strong enough to prevent cracks. Are there any other techniques to make the life harder for the crackers? Maybe binary checksums? How can I implement it easily?
As always, my answer is "make better content" rather than try to battle it out with an endless cat and mouse game.
Few reasons:
Even the biggest players, were big companies dedicated to creating copy protection schemes always fail, you have very little chance of success
If you make a mistake, you will bite the only hand that feeds you. In other words, malfunctioning copy protection does not bother crackers but will bother your paying customers.
Focusing on making your application better and serving your customers better will get you more paying customers than any copy protection scheme.
What I mean with make better content is focusing on doing what you are good at. Or as Notch, creator of MineCraft puts it:
Wasting money on trying to stop pirates or laying a guilt-trip on them
are not approaches favored by Notch. Instead he prefers to offer
online-only services that will add something to the game experience
including level saving, centralized skins, friends lists and secure
name verification for multiplayer. He hopes that these subtle feature
additions can help to tempt pirates into become customers.
Apple's (or anyone's) code signing validates authenticity, it doesn't prevent cracks. Authenticity checks can be bypassed easily. If you search for ways to prevent cracking here on SO, you'll generally find answers about spending time on enriching the application rather than preventing cracking of the software. As long as the code runs on the a user's computer, they will be able to modify how it is executed.
I am interested in making a trial version of an application I am distributing via the Mac App Store. What is the most secure manner of doing so? Simply writing the first run date into user defaults seems a little easy to circumvent.
It's better to make trial versions be feature-limited rather than time-limited - features you can just actually leave out of your trial version's code, whereas you can't leave out "the rest of time eternal". You can try to artificially make your app stop working after a period of time, but rest assured that someone who wants to will find a way to bypass that restriction.
If you're dead-set on making it time-trial based, though, store a timestamp somewhere obscure in a non-obvious (e.g. basic encryption) format, and check against it. Yes, it'll get circumvented by someone determined, but it's not worth your time to try to prevent that.
Just do something that's "good enough" to encourage the mostly-honest users to pay for the app, and ignore the hardcore reverse engineers; they're a tiny segment of the market who probably wouldn't pay for your app no matter what you did (except possibly, they might pay for it if you didn't lock it down in the first place, as a matter of principle - some of them are fickle like that).
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
We plan to sell a Windows portable application. By 'portable' I mean that it can be run from any Windows computer without installing it. For example from an USB stick etc. However the application while (theoretically) it can work anywhere, is targeted to LAN environments.
What solutions do you see that while keeping this advantage (in a more or a lesser degree) to still make money from it?
PS: The application is/will be written in Delphi.
If you are offering your product for sale and not for free, then you will most likely make money from it. If what you are asking is how to maximize the income and prevent piracy, then that is a more specific question.
The key to making money with software is to make the purchase route less painful then the piracy route. Usually the biggest hurdle to purchasing software is the price tag (but not always, some people just will never buy software and always pirate, but you can't do anything about that). And the biggest hurdle to piracy is some sort of DRM scheme, which is actually the second largest hurdle to purchasing software. Often times DRM only annoys the legitimate purchases, while the pirated version has all the DRM removed with less effort then you spend to put it in. Thanks to the wonder of electronic duplication, once the DRM is removed, then everyone can have a DRM free copy.
So you want a solution that only annoys illegitimate usage, but not legitimate purchases. This is much harder to do then expected.
Depending on the price tag for your software you might consider deploying it on a keyed USB drive (i.e. Dongle or USB stick with some special key). Then it is portable, but only on the hardware you provide. The user never has to worry about a secondary authentication scheme, and the DRM only becomes an issue when the hardware (which is harder to duplicate) is changed.
You say that it is only for a LAN environment, which doesn't necessarily mean that the computers will have internet access (and if they do, they probably have a proxy requirement) which means "phoning home" will be problematic. If you want the product to only be used on a specific LAN then you might require a license server to be installed on the LAN. Then the software could always check with the license server to make sure it is authorized. That won't work if you want it to run on multiple LAN's though.
Conversely if your price is low enough then most companies and people would rather buy the correct licenses and not risk the piracy. In actuality, depending on your clientele, most people will prefer legitimate licenses when they can, and DRM can actually discourage them from buying licenses.
Some alternatives:
Use a dongle, where the user of the software must plug in the dongle before your application can work.
At startup read a configuration file and if this is invalid or missing, halt the application or reduce its functionality. The configuration file should contain information about the user or company that licensed your software, and also a checksum to prevent users from changing the file. With such a file, serious companies are less likely to distribute this configuration files to others. Of course, you should then create one such configuration file per user that licenses your software.
Optionally, include specific computer information (type, memory, bios date, system guid, ...) that prevents the application from being run on other computers.
Make sure you make money from the service you can deliver, not only from the software you are selling. This service can include: providing upgrades, taking suggestions for improvements, assisting with problems, helping with domain-specific knowledge, ...
You can use some sort of license file and a "phone home" option that makes sure the same license is not used at more than one place concurrently.
If you have a large ordfer, you could try to get a memory stick with a special serial number and/or value in it that you can read out in the software (eg the exe must reside on a special memory stick)
Please note that a lot of users get quite annoyed by these things (we've used the first option)
Also please note that if commercially interesting, your app will be hacked. Make sure the effort someone has to take outweighs the profit the could make
One approach that also helps some is by custom branding. Each copy you sell would have compiled into it the name of the company it was sold too, which can be displayed as part of the splash screen as well as the about screen (along with a button to view the license terms). Most often this branding is done by using an external file which contains the information encrypted that when placed in the same directory as the executable is used to unlock the application as well as possibly provide additional functionality.
Unfortunately with todays software firewalls, most of the simple solutions to disallow running multiple copies on a network are not practical while still maintaining true portability, or requiring internet access to a server that you fully control.
Yes, piracy is a problem, but if you continue to offer great support and there is an additional "visible" benefit to purchasing, you can help offset this in your favor.
If you need trial protection, you can count uses/days if you have any sort of database where the user will have invested time and data, and won't want to lose it. Just encrypt the counter and place in the database somwhere. The user can then only reset the trial by wiping out the database. Depending on the type of app, this may be effective, or not.
Another approach is to not have a portable trial at all, but offer it as an incentive for purchase. i.e. conduct the trial on the desktop, and when they purchase a license, they get a license key that allows it to run on portable devices.
I recommend the PortableApps.Com framework for launching your app. It's free. You need to make your "launcher" open-source, but not your app itself. You can still run on a bare drive, if you follow their pattern.
I have inherited a project from a client, who believes he has all the source code, but unfortunately this particular VB6 application used a bunch of custom controls that the original programmer will not give up (he may in fact have purchased the licenses himself, so he may be right in not turning them over, on the other hand since he has been cut-off from the project there may be a bit of spite involved - I have no idea and it doesn't really matter.)
Anyway, the project uses the following controls:
PVOutlookBar.ocx
PVList.ocx
PVCombo.ocx
PVXplore8.ocx
PVDateEdit.ocx
PVTime.ocx
PVDt80.ocx
and as far as I can tell they were from a company called Protoview which was bought up by Infragistics...and none of these controls are supported anymore, though they can be purchased at full price.
My client is very reluctant to spend over $1000 to get his hands on these controls, especially since
1) they are no longer supported at all by the vendor
2) we have no guarantee that if these are purchased that it will work (i.e. maybe there is a lot of other stuff missing too).
3) there are no refunds, even if we bought the wrong stuff...
4) we only need to get it running enough to start the port to a more updated language, either vb.net or C# (and thus would need to possibly buy the controls again).
My question is, is it legal if someone had these controls, and was no longer using them, to sell them? I would assume that the if you were no longer using a piece of software, you could transfer the license (the hope would be to find someone who has them lying around and would be willing to part with them for a lot less than buying the new).
Anyone know any sources for buying "old" software, especially controls such as these? I found Retrosoftware website (no longer operational) but they don't have any of the stuff I need.
Thanks.
I Am Not A Lawyer, but I think the legality of transferring a license depends on the original license terms for the controls used by ProtoView. Some licenses allow it and some explicitly forbid it.
Certainly the license agreement Infragistics is currently using does not allow you to transfer the license.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
I have a game that I'd like to sell with the following system: give away a demo (say, with the first few levels) and sell the full version. I'd like to make the transition to the full version as seamless as possible for the user. I've never sold anything before online, so I'm not sure how that would work (even if there were no free demo).
This seems like a very common issue, so I'd imagine there's a standard solution. I'm writing in C++, targeting Windows, and my installer is generated by NSIS.
There are two options:
A separate demo and full version. Your ecommerce provider will send the full version to people who buy it.
A demo that is unlocked by a registration key or online activation process. Registration keys can be generated on the fly (or taken from a pre-generated list). Ecommerce providers can then send the keys to customers immediately after purchase.
Both approaches have their pros and cons.
Separate full version
Smaller demo file, saves bandwidth
Less technical support required for customers who buy full version (in my experience)
Two builds of the game, more testing
Harder to distribute updated versions to customers - need to keep a login for each customer or a secret URL that expires after a few days.
Unlockable demo
Contains all assets, may waste bandwidth
Easier to distribute cracked version (pirates can distribute a 10KB patch or reg key and link to your demo file, more bandwidth waste)
Single build, less testing
Easy to distribute updated versions (everybody can download the same public version)
Regarding a "general" solution, look around for commercial DRM wrappers such as this one. Some game portals/publishers also require that you use their own wrapper.
Don't ship your full product as a demo that can be activated. This way you don't eliminate piracy (which will still be something you will have to deal with) but at least you remove the possibility of someone just downloading the demo, cracking it, and spreading it around (or even just a cracked executable). They would at least have to buy the full version first.
As for checking a legit customer is using the software, you can indeed do some online authentication as Danny suggest but note that this will only stop people from using your online services and it often is just a matter of time before a qualified cracker/reverser makes sure that your product's offline features can be used without purchase.
By not shipping the full product immediately, it does make upgrading a little harder, but there are ways around this, ex: Updater that only works after online authentication.
If you develop it correctly you should be able to have a checking mechanism after the Xth level. This checking mechanism could basically hit a registry key. This registry key could have some encoded information which was generated by your program. The key could basically represent an MD5 hash (or SHA-1 or SHA-2 if you really concerned with high security) of the installed machine MAC Address, the first and last name, so and so forth. When someone purchases the game, you have them input that data in a form and then generate a code to send along to the user to unlock the game. You could even take that same algorithm and put it on your ASP.NET website and automate the key generation after a purchase has been made.
My 2 cents:
Dont spend too much time devising methods against piracy. Use simple serial generator mechanism to unlock the game which user can enter manually during the execution.
I would say have a single build which can switch to trial mode or full based on the serial key entered. This will reduce the overhead of maintaining two separate code.
It is a personal opinion, that people who really buy software at first place will buy your game no matter how many pirated versions are available. So make registeration purpose as simple as possible which will deter a normal user from cracking it and at the same time easy to use. Hackers will crack it no matter what protection you use it. Otherwise we wont see the pirated copies of microsoft/adobe products etc who spend so much on making their products piracy free. No matter what they charge, people do buy it. Its the quality of the product which will encourage your users to buy your product.
Also, try not to impose locks on your software like using MAC address etc for generating the serial numbers etc. Online activation may be a good idea but remember people are skeptical as to what information you try to transmit while activation. Also you might have to provide an alternate mechanism for offline activation if your customers dont have internet connection or work in separate LAN.
Once you see that you game is getting popular and you see more pirated copies with users, you may invest more time and money on developing anti-piracy techniques.