Continuing in from the discussions in the Works Discussion Group.

What is the feeling of the "Non Works" developers on the Runtime Licence Restrictions on creating Tables/Indexes etc?

Maybe Jennifer Scheer from RTI could respond here and post the information links she posted in the Works Discussion Pages so that more of the developer community could "understand" the restriction RTI are placing on them.

I'm not sorry for raising this issue here Jennifer because I feel that it is VERY important!

Tony

Tony, my initial raising of this subject matter with Revtech on the Advisory Board has raised some eyebrows, and a lot of questions and responses on the topic of licencing.

We have now decided to use the Development Ready licences instead of the runtimes as a result of not being able to use CREATE_TABLE, nor even COPY_TABLE.

If you would like to discuss offline please Email me at rulec@cssp.demon.co.uk

Tony -

I'm sorry you feel defensive about posting an issue to our public forum - that is why it is here. This is a forum for communication among Revelation and the user community and we do encourage the exchange of opinions. I do not want to discourage discussion on the topic of licensing.

Having said that, I want to make sure that this thread does not cross over into areas that are not supported. The following statement is from the Rules & Regulations of our online discussion forums:

The online discussion is not a source of official Revelation Software information. For official information, please refer to official sections of the Revelation Software web site. Any information gathered from the discussion should be treated as advice, to be followed only at your own risk.

The topic of this particular thread – licensing – is officially covered by the Revelation Software License Agreement for each particular product in question. No interpretations or statements made on this forum can alter or amend the terms and conditions of the Software License Agreement for any product. If there is any question about how the software may or may not be used under the terms and conditions of the Software License Agreement, you must contact Revelation Software directly. If you have [/i]any[/i] questions about whether you are in compliance with Revelation's Software License Agreement, contact Revelation Software immediately. The Revelation Softare License Agreements are not negotiable.

Following is a posting Kurt Baker made to the "For WORKS Subscribers" online discussion that clarifies the deployment methods and their licensing requirements:

Revelation provides two methods of distributing applications, "Runtime" and "Development Ready" (DevReady) licensing. A Runtime license provides an end user use of an OpenInsight application; however, it does not allow the user to change or modify the application. Applications are delivered using a runtime license when the application is fixed, and cannot be modified. The runtime license specifically prohibits the ability to create or modify database components (files, dictionaries, indexes), as well as any application components (such as reports, forms, programs, etc). A DevReady license provides end users full use of an OpenInsight application - including the ability to change or modify the application. Applications are delivered using a DevReady license when the application requires the ability to create or modify database components (files, dictionaries, indexes) and application components as designated by the application developer. As you mentioned, your application requires the ability to create tables, this capability is only available in the DevReady system. This will enable you to distribute the application without 'redesigning the whole system'. The next logical step is pricing. As I mentioned, Revelation offers aggressive volume purchase pricing for DevReady systems. Give me a call or drop me an email at kbaker@revelation.com and I will tailor an agreement that suits your needs.

I can partly understand why Revelation Software might disable these copy-file and create-file features in a Runtime.

Any runtime AREV application that dynamically creates files (say by accounting period or processing period or for every new user for temporary report data) would only be readily upgradable to Devready OI.

This may make OI more profitable for RevSoft, but doesn't it make a class of ex-AREV-now-OI applications harder to convert and sell? Every AREV application I've ever dealt with creates files dynamically.

I understand that Kurt Baker is interviewed on this matter in the forthcoming SENL, whose print deadline was delayed to enable Revelation Software to respond.

I'll be most interested to read the SENL interview with Kurt.

Steve

Steve,

I think you've summed up perfectly what is concerning most (AFAIK) developers about this issue. There really is no economic equivalent OI conversion for the vast majority of AREV applications. Without judging Revelation's intents or motives, this unfortunately makes it seem that the value claims of OI are disingenuous. We are told that the runtimes are now free - so they are more restricted. Well this sounds sensible on the surface until you start to realize that this restriction is so severe (or locked down) that no one would really want to deploy an application with it. You really have no choice but to purchase a DRSDP just to give it minimal basic functionality and maintenance abilities. So, all we have is a free RDK which is almost worth as much.

This issue can be discussed philosophically, legally, and economically - all of which RTI has in their favor. Regardless of the wording of the runtime license, and our responsibility to understand it, RTI should have known that this would be an easily misunderstood issue. Their literature and promotional compaigns contributed to this dilemma by trumping OI as the best way to take our AREV applications to Windows and beyond. Yes, I suppose it is the best…but nobody seemed to think it was a good idea to spell the cost differences in black and white.

Though the cost alone of a single user DRSDP will make applications out of range for some industries (case in point is a termite and pest control application we've developed), we are nonetheless glad that this option has been introduced. This will ease the burden of GFE and index corruption maintenance. Unfortunately, though, normal SDP's prohibit much of the creative and dynamic abilities of OI. I agree, we like to use Revelation products because they allow us to go beyond the norm. Pity that it costs so much more to get to actually implement them. (One could also argue that there are enough bugs in OI/Reporter to consider it an imcomplete product anyway.)

My final comments are based on the following quote. This comes from the Revelation OpenInsight for Workgroups 3.1 Runtime Deployment Kit manual, Page 3, under the section title Limitations to Applications Deployed with the RDK:

Because deployment of an unlimited number of single user runtime applications is allowed once the RDK is purchased, some capabilities of runtime applications deployed with the RDK are limited.

This limitation provides a level of protection to the application source code, which prevents users from inadvertently making modifications to the application. For example, Form Designer, and the UI Workspace are disabled, as is the ability to define a database. In general, features typically associated with application development are not enabled in a runtime application. These limitations are listed in this section.

We recommend[/b] that you keep these limitations in mind when coding applications[/b], so that you can use alternative techniques to achieve equivalent results.[/b] (emphasis mine) Granted this can be interpreted differently, and RTI is the final arbiter of this interpretation. But it easily gives the developer the wrong impression of what they can do. This seems to me that developers can be as creative as they need to as long as they understand that the end users are not allowed to use the tools of OI nor are we allowed to provide a tool workaround. Yet if the application requires the need to create tables (something that the application controls, not the end user) then by all means embed this functionality. I too have heard that Kurt has written some good stuff on how to maximize functionality within a runtime or with a DRSDP. I agree it should be interesting as well. dbakke@srpcs.com SRP Computer Solutions </QUOTE> View this thread on the forum...