4 ms·
My company deals with piracy in the following technical way, and it works well enough for potential buyers to stay buyers. I release software binaries often, s
by vortico 9y ago
My company deals with piracy in the following technical way, and it works well enough for potential buyers to stay buyers.
I release software binaries often, say every two weeks, and the software self-updates with permission from the user. The main application software is free, while the plugins (the real meat of the software) are purchased individually. When the application updates, the plugins also update. I use the semantic versioning, so releases look like 67.0, 67.1, 68.0, etc. Since the barrier to upgrade the application is virtual nothing (free, click of a button), almost everyone updates. If you're a paid customer, your plugins will also be updated, but if you aren't, now none of your plugins work. If you want to release your set of plugins to the world, pirates will have to match the versions of those plugins to the versions of their application, and if there are other plugins in the internet, they will also have to match. This requires lots of coordination from pirates, which has not happened yet. If an individual begins regularly releasing updated versions of the software, I can simply ban their user account which was used to purchase the plugins.
I imagine this can't work for your purposes since you have a single, standalone, polished application, but hopefully this could help others.
- ttoinou 9y agoWhy do your plugins need also to update ? There's a lot of changes in the API ?
- vortico 9y agoThe ABI is incompatible between different versions.
- owlmirror 9y agoI would hate to write plugins for your software
- bonesss 9y agoI have used similar versioning strategies in products... Barring something special in the app, these kinds of plugins are not for the user or customer. These kinds of plugins are for the development shop that makes the product, reuse across their product portfolio, and managing custom adaptations of the software for their specific customers. Breaking APIs in this context is just like "breaking" any other internal API, as bother the caller and callee are upgraded and deployed together.
- arca_vorago 9y agoHow do you know which user released the plugins?
- vortico 9y agoI don't, so saying it is "simple" to ban an account was mostly a lie. However, it would be simple to switch to fingerprinted plugin releases if it becomes a problem, then ban the account, which would stop any further unauthorized distribution.
- jlgaddis 9y ago... until they just create a new account and continue on. Don't underestimate the lengths some of them will go to. (Former teenage software cracker; I had way more free time than I did money.)
- vortico 9y agoYou'd have to keep purchasing new plugins on the new accounts after the old ones are banned, as opposed to buying once and re-releasing the (free) versions on every update. Since plugins are $100-1000, be my guest! Not to mention the liability you are going through by assigning your credit card info to a proven copyright infringer.
- runeks 9y ago> If you want to release your set of plugins to the world, pirates will have to match the versions of those plugins to the versions of their application, and if there are other plugins in the internet, they will also have to match. Are you relying on constantly making breaking changes to the plugin API for this to work? Otherwise, it may just be the case that pirates haven’t figured out that they need to disable the version checking-part of your app. It sounds a bit like security through obscurity, unless I’m missing something.
- vortico 9y agoYes, it's a large application that is constantly being improved, so there are always at least some changes between versions that break ABI compatibility. Even a simple change of the application that only requires a recompilation of the plugins would break ABI. Pirates would have to modify inconceivable amounts of binary code to match a 67.0 plugin to a 68.0 application or vise versa.