Pay to opt out of server-side license check

[ecornbower]

Right now all of the Distriqt ANEs do a server-side license key check every time your application is launched (see https://plus.google.com/+Distriqt/posts/Tf2rf7PQmpX for more details).

I completely understand why it is necessary to validate licences and keep piracy to a minimum. You guys work hard on these ANEs and deserve to be paid for them. However many businesses rely on your ANEs every day for critical app functions such as in-app purchases. Even an hour or two of ANE downtime would cost us a lot of money and many angry users.

I don't believe you guys have any ill intentions regarding the license key checks, but we see them as a liability for two reasons:

1. Mistakes happen; servers malfunction, updates change behavior, and code gets pushed to production with bugs in it. If something goes wrong in the middle of the night, how long will it take to get it fixed? It's good to know that the check uses positive invalid logic, but even the most robust systems can sometimes fail.
2. If anything ever happens to the Distriqt company or domain or someone hacks your servers, they could easily change your licence check script to return a "failed" response, turning off all of the extensions for everyone.

For our company we'd be happy to pay a few hundred dollars extra to be able to opt-out of the server-side check for our purchased extensions. You could still do a licence check but make it local, no server-side calls (not sure the best way to do this though).

In the unlikely event that someone pirates a key and publicly shares it, you could blacklist the key in future updates. There are many free open-source extensions out there, but the value your extensions provide is the updates and bug fixes.

By allowing users to pay to opt-out of the licence key check, you can keep larger companies happy with your ANEs while still providing smaller developers affordable ANEs for their projects.

I look forward to hearing your thoughts on this.

[marchbold]

Hi,

Firstly thanks for raising the question here. It's obviously been a topical issue over the last couple of days and we appreciate the rational question!

We have wanted and planned to move to some different form of validation for some time now, though we've always put it at the bottom of the update list, favouring functionality and updates to the extensions. We totally respect the desire to remove the check and, in fact, we want to do this as well!

Ideally we would love to move to a simpler application id - key pair check, and remove the server validation altogether. This however requires a more complex server application to allow you to generate the pairs for your applications, (which would be validated local in the extension).

Our biggest problem is being able to devote time to the task, which unfortunately comes down to money. So we're open to suggestions as to how to go forward here.

We'd love to hear everyone's feedback / suggestions.

Cheers, Michael

[minimedj]

I just want to say that I also will pay for extensions again if KEY-validation is removed.

[mola2alex]

Why does it need to validate the key every time the app is launched vs a one time check? How does it protect against piracy anyway, if someone wanted to simply share a key with another developer anyway? Does this work on Android if the Internet permission is not included in the manifest? I was unaware of how this worked until now but I agree that it is not ideal.

[shamruk]

It it's definitely less important than FB API 2.0 for me, but I am also looking forward changing server side verification to something more reliable

[greglindquist]

I'm curious if there's a way to bake the app id into the ANE. Then, you just pass the app id into the ANE to initialize it.

[mola2alex]

To me, the greatest value in buying an ANE is support. I have bought from milkman games who does not use this method and if I just stole the ANE a year ago when I launched my app, most of my apps would be breaking now with Android 5.0 and iOS 8 and I would only find out reactively vs having the app already fixed because I was notified ahead of time of a critical bug fix. If my app is at all successful, why would I want to risk it breaking without any support just to save on a one time low fee? Are ANE's really that prone to piracy?

[minimedj]

@mola2alex you are right. Support is the thing that keep me here (and great API and functionality). Whole idea about KEYs seems for me a little bit wrong. There are many libraries around that are paid but don't use any KEYs.

[mola2alex]

If there was some data on X% of paid ANE's are pirated to justify such a system then maybe but I don't think the ANE market has attracted pirates reselling pirated ANE's. Maybe I am mistaken but I think the risk is sufficiently low to have to have the key validated and that anyone serious about using ANE's for developing apps will require support and updates.

[minimedj]

@mola2alex you are right! This security is for nothing! =)

[minimedj]

I personally will feel more secure if I have to pay every year a subscription fee. That subscription should give me free updates and fast reaction on my tickets. This is all I need. (Of course no server side KEY validation).

If I pay every year, I know that guys are getting money securely, so they don't have to reply just on sales, so by growing client-base they get secured income. Secured income means we always have support.

[spinapse]

Thanks for the good work on the ANE's. Yes, the server check is a big issue. I actually thought that it only checked when running in the simulator. I guess that was naive, but if it actually checks every time a released app is run, that's a big concern for us. It's enough of a challenge to make sure that our own backend is always up, but we don't want to add another server check that could fail and wreck the user experience. It sounds like there are some other good alternatives, but worst case, I would prefer to see the check happen every few months per app install. That way, if the call fails, we won't have a bunch of users all complaining within the same two-hour window.

[marchbold]

@spinapse I just want to reiterate to ease your concerns, if our server goes down or the call fails the extension will not be affected! It's only in the case when you don't have a valid key that you'll ever be affected.

[marchbold]

@minimedj I'm glad you raised the subscription option, we mentioned this a few months ago but felt that the reaction was overly negative. Funding update development work definitely is something we need to start covering better as relying on sales is failing. What are honest feelings about a subscription and what would you consider reasonable amount?

My current thoughts on a way forward with the license are:

• Create an online application that acts as an app-id - key generator
  • This would get you to input an app-id and creates a key that you can use that app
• The keys are checked locally in the extension against the app-id
• There is no server side check
• The keys would never expire

[minimedj]

@marchbold Thank you for you attention to this topic. I would pay yearly current ANE price for each APP-ID to have free updates and fast support on bug tracker. For me it seems reasonable. I also hope that it would not affect sales for indie developers. IMHO.

About license: For me the best option is the easiest one that involves as less code as possible to eliminate potential side effects.

My thoughts about licensing in general: If you distribute your ANE only within subscribers for those who stole your ANE it would be a huge risk to use it because of no updates and no support. There are tons of open source ANE and tutorials how to make your own ANE. Why do you think we (developers) are here? Only because of security - we all hope that all business with ANE will be handled by profs - you guys. But from other side, if there is no protection there is no payments. That is :100: guarantee. You have to come up with balanced solution that will satisfy ours (at first) and your needs.

p.s. Have you ever seen evidence that somebody tried to steal your ANE?

[crooksy88]

I would agree that one of your strongest selling points is the continual support and upkeep of your ANE's, certainly to professional customers.

I believe it is vital to developers that Distriqt find this business a profitable one because as soon as those ANE's stop working we're stuffed. So I would be more than happy to pay for support.

I know Milkman Games run a similar business model. When you purchase the ANE you get 1 years access to updates and email support. When the year is up you can purchase another year, minus a 15% discount.

[mola2alex]

@marchbold I understand that it is only invalid keys that are impacted but the very thought that my app could launch and a check could turn something off is not settling. If your server gets hacked or whatever else, do you want to be responsible for bad reviews or lost revenue for your customers? While the risk may be low, I also think the risk is low in piracy of ANE's. Maybe you implement keys within the ANE so you still need a key but it only gets used locally in the app. That way, if someone posts just the ANE by itself, it won't just work easily without a real dev key.

To my earlier point, I am willing to pay support. I think 50% of the purchase price per year (starting in the second year) is fair and if you don't renew your support on time, then you have to re-purchase at full price. If developers want to risk no support, then when it breaks, they pay full pop again. Ultimately, we all want you to be successful, otherwise it may mean we lose support and I think we all don't want to see that.

[minimedj]

I am just wondering when I can expect to see some approximate resolution time for this topic?

I am not forcing to do it faster, I just want to have it in my plan for certain date.

[ecornbower]

@marchbold I'm glad to hear that you are thinking about different ways to do license validation. If you do implement such as system I hope that a single license key could still be used for all of our applications. I would hate to have to manage a different version of each ANE for every single application we develop.

Right now it is so easy to just pull the latest version of the files from Github. Before launching a new app update we read through the latest history for each of the ANEs we're using and make sure to thoroughly test anything that has changed since our last update. It sounds like your new licensing system will make it much more difficult to keep track of which files changed and why those changes were made. Your switch to Github in combination with the Github issue tracking has made it so much easier to keep track of everything.

I personally wouldn't mind if you switch over to some sort of yearly licensing fee for continued updates and support. We've developed a few ANEs ourselves and I know how difficult they can be. That's why we chose to pay to use your extensions rather than develop everything ourselves. Almost all of the extension functionality you offer is available as free open-source ANEs, but the value you provide is the continual updates and support.

That said, I'm not sure how some of your other customers would react to such a change. We first bought our ANE license when you offered all of your ANEs for a low flat rate, plus the promise of any new ANEs you develop to be included. Then you decided to begin charging for all new ANEs you developed. Now you want to start charging every month or year for access to updates. I'm sure you can see how some of your customers may feel cheated by these constant changes to your licensing.

Our main priority is to get rid of the server-side license key check and make sure that you guys have enough funds to continue providing updates and support. Your success is our success, and we all want Distriqt to profitable and continue building awesome ANEs.

[marchbold]

@kcornbower From my research I think the best way forward will be substituting the server license check with an app-id - key pair so you'll need a different key for each application. However the ANE will be the same so it'll just be a different string definition in each app. We will still be distributing through github with full version control so you'll still have all the advantages that provides.

I understand the change will be a big one for our customers so this feedback now is really important before we make any changes. The general feel here seems to be of approval though? Just a quick note about the last change, we never "promised" new ANE's. That was something that was assumed as we had been doing it for ~6 months. We had always planned to start offering them individually and was one of the most requested things at the time. Hopefully you understand that.

@minimedj We are hoping that this can all be resolved this year. I had already planned to create a new support site over the next month, which I think will now also integrate all the functionality required here. I'd like to leave this discussion open for another week or two so everyone can have input and then we'll lock down a firm timeline for you.

It's really good to hear the feedback here! I hope you all can understand we're just trying to make sure these extensions are sustainable.

[minimedj]

@marchbold Thank you very much for your reply Michael! 2-3 months frame is just perfect for me. All the best for you guys with new licensing model. I am you first client for new KEY validation approach.

[philvessey]

Will the new arrangements (whatever they are) be opt in or will we have no choice but to adapt them? What happens with the people who are more than happy with a server check. Asking them to pay a yearly / monthly fee when they are happy with the current arrangements might be a tough sell, especially when they paid a lump sum up front.

[ecornbower]

@marchbold Glad to hear that you still plan on using the Github system to distribute the ANEs. Your new licensing plan sounds great as long as it does not slow down the application startup. It sounds like you plan on using some sort of encrypted key scheme so decrypting it and verifying the key could be resource intensive for some older devices.

Perhaps "promised" was too strong of a word, it was more assumed that new ANEs would be included as you developed them. I certainly don't have a problem with it and think it was a good business decision. I think we only paid $150 for all of your ANEs at the time which is really cheap. Glad to hear that you are focusing on keeping the business viable as well as listening to your customers.

Are you planning on starting to charge yearly for the ANEs, or is the priority right now to just remove the server license check for everyone?

If you are looking for more feedback you may want to post this thread on your social media accounts or send out an email to your current customers. It would be easy to miss unless you regularly follow the Github issue threads.

[ramezrafla]

To add my two cents: there is no such thing as a perpetual license anyway. So we can pay yearly license for the ANE we want, or for bundled ones. After a year, if we don't renew, we loose upgrades (which makes the ANE useless given the pace of development in this space)

In terms of the license check, it's not bullet proof. I won't share here in the forums why not so not to encourage hackers, no system ever is. Might as well make us pay.

If someone hacks, they are likely losers anyway, so they won't pay you regardless. The moment someone is making money, they have a team, and will get caught right away stealing licenses. This is why the licensing system works. Self-policing and integrity.

[Vontre]

According to mixpanel, we get hundreds of users every day who mysteriously fail to load the store data. Is this why? An exterior dependency on a third party server for something as simple as this is an absolute dealbreaker for any serious development project.

[ecornbower]

@Vontre We're seeing the same thing on iOS where the store data occasionally fails to load. We've been trying to track it down but it's difficult to reproduce as it happens almost randomly. Either Apple's servers are really unreliable or something else is going on.

I'm certainly not saying that the Distriqt license check has anything to do with it but it may be a problem in the ANE code. We'll do some more digging to try and figure out what is going on.

[marchbold]

@ramezrafla Just wanted to confirm that you are saying you would be happy for a yearly license?

@Vontre As I've said elsewhere the license check won't be the cause, more likely its something else. Please log a separate issue with all the information you have and we'll help you track down the problem. We've pretty much decided to remove this license check, so it would be good if you could comment on the direction we should take?

[ramezrafla]

@marchbold sorry if I was not clear. Yes! Yearly license should be the way to go. Thanks for asking the community.

[glorb]

Yep, Yearly License is the way to go. I'm in.

[gskgrek]

So as I understed, if I stop paying for subscription, my apps will still work, but no updates will be available? :>

[sadensmol]

I paid for this extension once and don't want to pay again. I don't need any new functionality. it works good atm. So it's a good idea to move all validation to client side and provide new updates for all paid users for free. You can earn money by supporting people who have problems with your extensions. So just stop with all development and start with support!

[marchbold]

@gskgrek That's exactly right. Your apps will be independent of the subscription and there will be no reliance on our servers. The subscription is really just paying for support and updates.

@sadensmol I suppose the problem there is drawing a line between support and updates is actually quite hard. Support questions can end up in an update to the extension and I'm not sure that someone paying for support who helped debug or reported an issue should fund the updates for others? I know it sounds like a good idea but I don't think it would be sustainable?

It's also not viable for us to continue to provide updates for free relying on sales alone. The amount of work involved each year to keep up with the platform changes has become a lot more than the number of sales we are getting.

[opolette]

Hello

My two cents on it:

• I think your extensions are great and hope you can maintain them.
• Regarding licensing, I would suggest to make it simple, "stupid". Simply remove any Key check and have your customers (us) just a pay for one-time download and/or subscription model. As is done on most extension-based stores (Look for example at Joomla extensions).
• Before releasing a new API or maintaining an existing one, I would suggest to make a short survey to check if this makes really sense. There are several APIs that I do not use and that may be the case for others as well.

Cheers

[ghost]

I don't think a yearly subscription is fair. Most apps struggle to earn enough money to pay for updates to keep up with the speed of platform updates (iOS / Android). So adding an extra exploitation component will stop a lot of my clients to update the apps I developed for them. From a business point of view I rather like to pay for each app I implemented an ANE in. By doing this you earn money on each new app using your ANE's. As I expect you ANE's will end up in hundreds of new apps each your which I think will pay your bills ultimately. A licence check on first use of the app on a device and then keep that validation result in the app persistently is in my opinion a good way for validation. So an app-id to distriqt-key validation. But when it fail because the Distriqt servers can not be reached must not effect the app behavior (eg in-app purchase).

[philvessey]

Having read the email to customers im in - ive come to the conclusion that the extensions add a lot of value to my apps that I wouldn't be able to code myself and if you guys need more money to be able to maintain them then that's the way we should go. Below is what the email says for those not seen it,

moving to a subscription model: the cost will be low this is solely to help us cover updates we will provide some compensation for the move

[marchbold]

Thanks @philvessey I did mean to post the link to the email here but the day has gotten away on me. Most of you should be on our mailing list, but in case you didn't get it, this is the online version:

http://us1.campaign-archive1.com/?u=8e04adc4b86e5676778568505&id=77e7decab7

@wouter76 This is definitely an alternative approach, charging per app-id. Is this just so that you can budget for them in the initial development, do you not charge to do updates? I suppose it comes back to the same as the current model though. The updates roll through every year, whereas this model relies on new customers (applications) continually coming on board. I'd definitely be open to considering this model though, what do other people think about that?

[marchbold]

@opolette Thanks! We definitely plan to have more active milestones once this update is completed so you'll be able to see what's getting added etc.

[hannesjung]

Thumbs up for yearly license, thanks guys!

[thyselius]

I would be happy to pay $20 for all the ANEs for unlimited use, support and updates. You don't need KEYs.

[ghost]

@marchbold I do charge my clients for an update, but most of them are complaining not making enough money to pay me for an update. Adding an additional fee on top of that will stop them updating the apps. I can charge an initial fee, but the total development cost have to keep as low as possible to clients not running to other app development companies. In the end it comes down to the app market is a to competitive market and everyone is struggling earning enough to pay their bills.

[minimedj]

@wouter76 I am wondering, what is your total development cost if extra $100-$200 can stop your clients?

p.s. Sorry for slight off-topic. But I want to see this discussion reasonable. From my experience price we pay for ANE is absolutely nothing in total development cost.

[hannesjung]

@minimedj I agree with you! If the payment model is based on a yearly subscription fee, you could also distribute the additional costs across several apps.

[bangersandflash]

Firstly, I think you guys are doing an amazing job maintaining the number of ANEs that you do with such a small team. They're by far the most reliable, updated, and supported ANEs available. I can appreciate how much time that you invest in them and I would be more than happy to go down the subscription model path.

Looking around at other subscription models, I'd say $20 a month or $200 a year would be very reasonable especially when you consider the time the ANEs save developers vs a developer's hourly rate.

[philvessey]

I hope Indies are considered as well as not everyone is paid by a company on an hourly rate.

[ghost]

@minimedj A normal yearly update will be 20-30% more expensive. I can add a 3 year subscription in the initial development fee, then no one will notice. I only want to be transparent to my clients. But off topic so lets close this part of the discussion.

[trimedia]

Just my 2 cents. I really don't like the idea of a pay per App-ID model. That's the whole reason I don't use some of the other ANE's out there. I'm much more willing to pay a yearly subscription fee. Make it 199 or 249 or whatever but that will give access to the entire library of Distriqt's ANE's for a year. If a developer only needs a single ANE they can get it for the year for 79 or something. Have it so that using 3 or 4 ANE's will cost as much as the yearly subscription thereby promoting the purchase of the full subscription. It makes it easier for everyone. Distriqt doesn't have to worry about pricing individual ANE's differently. They are all at $XX if you get them individually or at $NN for the whole library.

Anyway, just my 2 cents.

[spinapse]

I agree with trimedia above -- I don't like the per-app model, and something like that would make me look elsewhere. The pricing strategy sounds roughly right, too. You break-even on the package of all ANE's when you get to 3 or 4.

[gtawebb]

I would also be against a per app model. I have many permutations of the same app (educational apps that are data driven resulting in different subjects). These are then doubled up with IAP (trial) versions and upfront payment (premium) versions all with different IDs, so the per app model sounds expensive and annoying to administer. It will be a shame to pay again for what I thought I'd already paid for, but then again you must do what you need to do in order to keep the ANEs alive. Annual subscriptions to GitHub could make sense? Thanks for all the good work BTW. Try not to become too expensive though as there are a lot of us Indies out there!

[philvessey]

+1 for a yearly subscription. Not keen on the per app model.

[gskgrek]

@marchbold in that case I think that subscription system would be a very comfortable solution :+1: And if prices would be quite low, I can even understand and like per app id payment...

[mola2alex]

Yeah, a per app model is a non-starter for me. I make a few hobby apps so doesn't make sense. I think it should be a per ANE yearly support. I think the model will be very elastic in nature, if you charge per app, you will lose users for roughly the same money as more users all paying ongoing support would provide. More users generally will net you more growth (maybe you can offer referral incentives to developers who refer others). Also, per app does not allow people to experiment and try things as easily which means people will look elsewhere for that flexibility.