Hi there,
Adding an activation system to a component like this is no minor issue and I advise notifying customers of the change. Any module that requires activation is an operational risk with results that have cost me more unnecesary outages and work than I care to ever have again.

I'd like to know how the licensing works. I want to know what the exact scenario is that negates the license and what happens when it does.

This is requirement so that I can determine what has to be done when I: delete and rebuild my portal, move to a new server, change the application ip, change domain names/aliases, upgrade/change hardware/software/database... and so on.

Also, can you please confirm that the licensing is a one-off process for the host user to carry out, that it is not visible to non-hosts, nor does it require repeat activity each time the module is added to a page on the portal system it has been activated on. there are some nightmare licensing systems out there, but also some that work fine.

Thanks
Rob

I have to admit I was extremely annoyed to discover this activation scheme was incorporated into the product.  And my annoyance is a direct result of the lack of communication about the new licensing scheme from DataSprings in your email press release about the new version of Dynamic Forms.

You have every right to protect your products from unauthorized use.  If you look at my purchase history, you will see that I currently own at least 3 copies of Dynamic Forms.  As a fellow developer, I support your efforts to protect your profits, but I would strongly advise you to communicate a major change like this next time you implement one.

Now for the questions:  How many times are we allowed to install each purchased copy of the module?  Can we have a development installation as well as a live installation? 

Hi Rob / Barry - Thanks for your feedback and suggestions. Ultimately I think you will find our licensing system is very easy to maintain with few drawbacks and truly will end up helping clients by us knowing how we need to plan for the future for support requests, how we need to price our modules and components to meet support demands, etc... I can understand more direct communication if the licensing had to be activated per portal and not per host, or maybe even if the licensing was added to a previous version and not a new release. Ultimately we have had to enforce stricter licensing to keep up with support and more specifically to keep up with support from some abuse of our license.

Rob - the license is a one off process per DNN installation and doesn't need to be handled per individual portal. If you entered the wrong or invalid InvoiceID the licensing will still go through, so ultimately the licensing system will in no way stop the module from working and once submitting the licensing details the message will be removed. If you uninstalled/reinstalled, changed sites, changed IP's, and so forth this shouldn't affect the license and even if you submitted the license again (say you completely removed from a site and added to another)...

The major part of the licensing is how we need to be able to support your license. There has been some abuse from either pirated versions or versions added which we have had to previous handle support for, and this allows us to only handle support requests from customers who are paying customers and are operating within our licensing model. This has much less to do with 'profits' and more to do with making sure we can have enough support staff to handle requests now and in the future.

I would think our customers would be more frustrated if you knew someone else was receiving support and taking our time away from any requests (support or enhancements) that was abusing our licensing and so forth.

There are other benefits to licensing which can help us and our customers for future growth and what licenses clients might need. Many clients have wanted to be able to offer reseller licenses, the new developer license, etc... If we know ahead of time what types of support we might need to be able to offer, we can plan prices and support staff ahead of time to be ahead of the curve (hopefully ). The more complex a module becomes (especially involving SQL, JavaScript/Client Side Events, and many more complex features) can bring about support requests that are often outside of actual supporting a bug and more about supporting an implementation itself. With more knowledge of our clients and their needs we can also create more limited versions such as 'lite' versions that we know would not necessarily generate as much support requests as a lower rate. These lite versions could include all major features but maybe limit the features that generate the most support requests (i.e. clients side events, SQL, etc...)

So - with all of that being said, I hope you can understand how this is much less about forcing a difficult or time consuming process, much less about trying to simply make more money, and much more about making sure that we are here to answer your emails, support requests, and continue to build quality releases.


Barry - The standard edition is licensed for a single DNN installation with unlimited portals, the license includes the ability for 'localhost' development but not a development environment outside of a localhost environment (in fact I don't think the licensing even is requested for localhost environments).

You can find our full licensing differences here:
http://www.datasprings.com/Support/...tions.aspx

I should also note: Our licensing for Standard and Enterprise has not changed between releases or in general at all over the last several years.

Thanks for your understanding and I encourage your communication on this topic.


-Chad

Thanks for the information Chad, that sounds fine. The main thing I don't want on my portal is a mechanism that breaks the system when it fails.

I feel very strongly about activation systems because of what I've been through with them and the potential risk they are to my business. It's one thing to expect a company like Microsoft to run activation servers for 20 years, but quite another for us to expect the same from individual DNN developers; the majority of whom weren't around 5 years ago and won't be around in another 5 years. I went through a nightmare moving my portal system to my current server. Total outage was 1 week, solely due to a couple of activation issues.

Just last night I had yet another example of this when 4 modules from another developer, for which I have an enterprise license, all of a sudden all stopped working and began publically displaying licensing errors plus a link to the developer website. I spent a couple of hours trying to reactivate the modules and am now in email communications over the issue and have lost confidence in the licensing system. I want to be able to have a holiday and not worry that my websites are going to break.


I also have a followup comment about the information Chad provided above, especially seeing as the focus is so closely on the support aspect of the modules.

I've previously asked Datasprings to not display the Datasprings links and action menu items to non-host users. This is because I myself am responsible for supporting all users on my system and leading them elsewhere is a policy 'no-no', not to mention confusing and a waste of my and your time.

I'm the purchaser of the module license and I'm the only person you need to be supporting. Datasprings is not to be supporting my portal users and, although obviously well-meaning, the links are therefore innappropriate.

Some modules I have from another developer also have an action-menu link to the developer site, but it is only visible to me as host, so that's fine.

And for supporting end-users, DNN already provides a help action menu and a module settings help-link for inserting useful information for module edit and page edit roles. These links are consistent and localisable across all modules and therefore actually worth using.

I realise this is not to do with the licensing, but it is everything to do with providing support, both on your and my part, so hopefully it makes sense to you and perhaps you can eventually restrict those items to your customer.. me

Regards
Rob

Thanks for your feedback Rob - Yes, you really shouldn't run into any issues where it would break or fail... This is much more about us having reports and being able to support customers properly.

Thanks for your feedback on the Data Springs branding and so forth... I would note that we don't actually include any branding unless you are signed in as an admin or with edit rights (some modules do which I consider frustrating especially for end-users and not admins). We get the requests every once in a while but they represent a very small percentage of our clientele and so we often have to review what is best for the majority of our customers. We do typically like to remind / mention to any host or company that is offering edit/admin access to our modules that they are very powerful database tools and (in the wrong hands) can be pretty destructive. This has come up before as well from a few customers and I do agree it would be beneficial to either have a lite version or a version where the host can disable certain features (such as SQL Events, SQL Options, SQL Defaults, and other areas that they would not like end users to be able to access). We will continue to review these and hope to offer future releases that will add some of these configuration options. I would also mention though that you can change the localization for any resource (the hyperlinks for assistance and help or pointing to a forum thread, blog post or something would still go to Data Springs site but you could possibly take the text out directly).

Thanks again for your feedback.

-Chad