Is there a standalone .qvw product?

[#1]

In the past, we have seen at the demo site (demo.qlik.com) several of the demos avaliable for instant view through a "standalone qlikview client", it was something like QlikView Analyzer, but without the need to download anything except the .qvw-file which you wanted to open.

Many of us out there are looking for ways to distribute a product developed in QlikView without the need to sell licensed copies of the developer-program. The FREE edition is another matter altogether, but it still doesn't change the fact that it is a program that you need to download and install in order to run a .qvw-file.

The working solution for implementations made at other companies is a serverside solution, distributing the document as JAVA/AJAX, and thus reducing the need for downloading and installing anything on the end-users computer. Serves are costly, and therefore mainly affordable by companies.

HOWEVER, if we ever intend to reach the general population with solutions developed with QlikView, there is a need for "productified standalone qvw's", just like the ones we used to see in the demo site.

My question to QlikTech:
Clearly, the technical solution already exists, but what would it take to make possible the use of this solution for developers who wish to make their applications avaliable to the masses?

And for the discussion on this forum:
Do you think it is fair to reduce the possibilities for using QlikView only to developers(including FREE-edition entrepreneurs) and companies?

One argument I've heard many times to deny this need is that you need to reload the data often.
There are many cases of products where you don't have to update the data every day, but more on a quarter to quarter basis, or even year to year, or never at all. Such updates could be sold as add-ons or a new and updated product could be shipped to existing users who paid for an upgrade service.

QlikView is the program which makes all of this possible. Within QlikView, we build .qvws, which themselves can be "programs". The end user often see each qvw as a different program (Twitter analytics, Earthquake monitoring,Stock Market Analysis to name a few VERY different qvws).

Just like with "normal product subscriptions" shouldn't there be a way to do this with QlikView, without having to pay for a license(qlikview) and the product(qvw)?

All thoughts welcome! Debate open..

//Jakob Berglund

[#2]

Normally, I hate bumping, but there has to be someone else out there with an opinion on this matter?

To at least add a little to the discussion, there has been circling a rumour that an australian based Qlikview partner have/had access to a tool to make qvw files "productified" for their clients. Can anyone confirm or falsify this rumour?

And yet again, it would be nice to hear from any QT officials aswell.

[rwunderlich]

Jakob Berglund wrote:ways to distribute a product developed in QlikView without the need to sell licensed copies of the developer-program.

I believe products are already being delivered this way by embedding Qlikview using an OEM license.

Jakob Berglund wrote:Just like with "normal product subscriptions" shouldn't there be a way to do this with QlikView, without having to pay for a license(qlikview) and the product(qvw)?

I think it's fair to Qliktech that someone should pay. Either the Developer for an OEM license or the End User for a standard license.

-Rob

[#4]

Well, true for the OEM licensing, but there is still a need for the QlikView program in some form (analyzer, developer, plugin, etc) or am I completely of track? I have always understood it as you sell the program along with your application to a customer for a fee, of which QlikTech gets a fair share.

The idea of a separate "standalone .qvw client" would be to integrate the .qvw into the product, like the old demo site.

It is fair to QlikTech that someone should pay, but does it have to be for a license? Of course, what you call it is of less importance, and I guess there is the need to keep track of the amount of users for each copy of the application..

Imagine selling an application, like through qlikapps.com. It is a catalogue showing all different kinds of cargo ships in the world. This data only updates every year, and thus the need for updating the application on a regular basis doesn't exist. Selling that application as a "standalone .qvw" would probably attract a wider range of customers than selling it with a bundle of licensed software to open the only application you want. Maybe John who is a real fan of cargo ships would buy it instead of just the local freight company who can afford a license. QlikTech would of course get their fair share out of each sold item, just like with OEM solutions.

I guess my own conclusion is that having a licensed software to go along with the "product" (standalone applications) is a good way to deal with unauthorized access to the application by people who simply copied it.

Rambling on here I see.. created this thread not only for criticism, but for constructive critisism and ideas. An open discussion is always a good way to make people share great thoughts.

[johnw]

As you indicate, QlikTech has the ability to create standalone applications. They simply don't let anyone else create standalone applications. So to me, it isn't a technical issue. It's only a licensing issue.

So all that really needs to be solved is how QlikTech can charge for and profit from people creating standalone applications. And I think that QlikTech should be interested in solving this problem. I can't guess how popular it would be compared to their current licensing approach, but I do know that this subject comes up fairly often. There is at least SOME interest.

I suppose you'd want to then treat QlikView as a development platform, but not necessarily as the delivery platform. So for guidance, I guess we'd be looking at other development platforms. How DO companies charge for development platforms? Honestly, I don't know. But that's the direction I would look.

As for the standalone applications themselves, at that point, I'd suggest that they be owned by the developer, not by QlikTech. They could be sold, licensed, given away, or whatever you want, just like applications developed in C++, Java, .NET, or whatever. If you as a developer don't want your applications being copied freely, then it's up to you to copy protect them in some way. Free distribution of the application while charging for data updates seems like one good approach. I'm sure there are plenty of approaches. Not my area of expertise, though.

[#6]

Not a technical issue at all then. Then since the possibilities have been clarified, maybe the discussion can make a turn towards licensing solutions.

In history there are many possible, and successful ways to charge for a program and making profit without having to deal with either licensing or piracy. A one time sell can be of either a product "as is" or an upgradeable version. Depending of the model of distribution and sales there are a number of different solutions to choose from.

I suppose you'd want to then treat QlikView as a development platform, but not necessarily as the delivery platform.

I couldn't have said it better myself. The best way to make money in this for QlikTech uncharted territory is to see how others did it, since obviously the product and the demand for it already exists.

One of the many issues with ownership is that we wouldn't be able to build anything at all without QlikView. In the past, before "free" edition I would say that QlikTech would be the ultimate owner of anything created with QlikView. However, since they released the development platform to the public, although somewhat limited, this inherited ownership no longer exists. Just like all the other languages of development.

Free distribution of the application while charging for data updates seems like one good approach.

Your last idea was very good. If all new data would be distributed as additional QVD-files to the customer, and in the hidden script, the load statement would load information from all qvd:s found in a particular directory, then it's a simple matter of adding new data on the fly. It's even possible to limit existing applications and sell them piece by piece.

To me, it would be a big step forward for a great product to make it avaliable to the masses without the trouble of licenses. The more people that become familiar with the use of it, the easier it will be to sell in the big systems to companies and corporations where workers already know how to use the tool.

[#7]

Hi Jakob

Now that you have raised the question, we have are looking to build a business around opportunities created by the personal edition in Qlikview.

The biggest issue we have to overcome is protecting our intellectual property contained in the script. For now we are planning to hide the script with a password. But this will not prevent users from distributing the file to other potential customers.

For now we do not see that this could be a viable business opportunity.

[#8]

Hi!

I didn't think I would receive any more comments on this as the thread has been dead for just about a year now. This makes me wonder; who are the "we" you are talking about?

Secondly, if other vendors selling software licenses have the possibility to restrict access to their software through different methods, why shouldn't it be possible with QlikView aswell?

Say for instance that you would deliver a .txt-file with each distribution, containing a hexadecimal number. In the hidden script, a check is made if the hexadecimal number in the .txt checks out compared to your computer model, filedate, operating system, etc. QlikView script can fetch a wide number of system variables from the operating system. Combining these with an encryption, you can create a license-file that locks the usage of your application to the very computer you intend to use it on. A simple macro can prevent the file to be used on opening if the key is not correct.

The .txt-file can be copied to other computers, but will there not match the system, and not give the same hexadecimal, rendering it useless. Creation of the .txt in the first place would supposedly happen during the purchase of the application where the user has to enter valid system credentials matching the computer intended for use on.

Basically, there are a number of ways to "copyright" an application avaliable already with the hidden script, and the possibility to lock module access.

The main problem as I see it, is to create the standard to be used for copyrighting like this. If the solution proposed above is used, each originator could be given a specific encryption key to have in their hidden script to make their .txt different from others on the same system.

So, I still see this as a "viable business opportunity", as the use for these products can range from a simple product database, recipe collection, search engine to clever analysis tools fetching online data or price comparison. Only imagination is the limit, as we have previously seen i.e. in the "app store".

Just my 2 cents..

[rwunderlich]

Ferdinand Strydom wrote:The biggest issue we have to overcome is protecting our intellectual property contained in the script. For now we are planning to hide the script with a password. But this will not prevent users from distributing the file to other potential customers.

Take a look at QvGuard http://www.qvguard.com/. Have not used it yet myself.

-Rob

[#10]

Jakob Berglund wrote:
This makes me wonder; who are the "we" you are talking about?

Hi Jakob

For now it is more a past time exercise with one of my friends. We are both full time employed and we are looking at ways to get a piece of the action. The risk that we could have our application pirated is just to great to to have a go at it on a full time basis.

Thanks for the ideas though. From your sugestion, I just wonder what would happen if you disable macros on the file. Then all the copyright checks will fail on opening the model and you are exposed to piracy again.