One of the things that excited us about the new .NET support was the possibility of using all the .NET objects that our VB/C++ side of the house has created. Our suite of products contain .NET and Progress applications, all that communicate with each other, and try to share components when possible. Maybe times there are great objects written that do some great behind the scenes stuff that we could reuse. Well after reading a recent KBASE and then the OpenEdge EULA again, I'm stunned to find we can't use any non-UI .NET objects. Yes we can continue to wrap the .NET objects in COM wrappers, but that is just one more layer and set of objects to maintain. I just wanted to get some input from others to see how they feel. I feel Progress allows me to take a step forward once and a while, but then limits where I can step...
KBASE ID: P138026
EULA Text:
The products listed below include the “OpenEdge AVM to Microsoft .NET CLR intra-process communication” (“AVM to CLR Bridge” or the “Bridge”). At this time, the allowable uses of the Bridge are restricted to developing or deploying Microsoft .NET Winforms User Interfaces for business applications using OpenEdge products, and for one-way usage of AVM calling the CLR (and not vice versa).
Any use of the Bridge other than as set forth in the previous paragraph is prohibited. Additionally, the Bridge may not be used for multi-threaded processes.
Progress Software reserves the right to modify the allowable uses listed above in future releases of OpenEdge products, as well as to modify the list of OpenEdge products that include the Bridge.
PSC Products that contain the AVM to CLR Bridge in this 10.2A release:
Development Products:
• OpenEdge Architect
• OpenEdge Studio
• 4GL Development System
Runtime Products:
• Client Networking
• WebClient
I don't know the reasons behind these terms. Maybe PSC is protecting their interest (prevent people from writing their own SQL server interface or calling 4GL from C#) or protecting the product and the customer (instability by for example using multi-threading) or protecting technical support; I can image that this can be a potential nightmare for tech support if people are going to mix and match ABL and .NET objects. I don't know.
I think we must be somehow misinterpreting the terms. I would like to think the restrictions do not apply to "supporting" code.
I think the idea of the EULA is to prevent code like the example below and not to force people to put supporting code into forms that would normally put in procedure libraries.
A lot of assumptions...
/* pseude code */
USING System.Data.SqlClient.*.
DEFINE VARIABLE myConnection AS SqlConnection NO-UNDO.
DEFINE VARIABLE mySqlCommand AS SqlCommand NO-UNDO.
DEFINE VARIABLE mySqlDataReader AS SqlDataReader NO-UNDO.
myConnection = NEW SqlConnection().
myConnection:Open().
mySqlCommand = NEW SqlCommand("SELECT * FROM mytable", myConnection).
mySqlDataReader = mySqlCommand:ExecuteReader().
DO WHILE mySqlDataReader:Read():
MESSAGE mySqlDataReader:ToString().
END.
myConnection:Close().
I'd like to be as optimistic about "supporting" code, but if you read the KBASE which "explains" the EULA and I assume that came from PSC Legal via Tech Support. The gist of the KBASE is:
...using .NET objects / classes in ABL programs which are not .NET UI forms is not acceptable. For example, if you have created a .NET UI Form and from that form you want to issue a RUN statement to run a .p which does some work for you, that .p cannot instantiate any .NET objects / classes other than a .NET UI Form (see below for samples).
Which I read as supporting code isn't allowed...
FROM KBASE ID: P138026
The End User License Agreement (EULA) for OpenEdge 10.2A states the following:
At this time, the allowable uses of the are restricted to developing or deploying Microsoft .NET Winforms User Interfaces for business applications using OpenEdge products . Any use of the Bridge other than as set forth in the previous paragraph is prohibited.
What this means is that using .NET objects / classes in ABL programs which are not .NET UI forms is not acceptable. For example, if you have created a .NET UI Form and from that form you want to issue a RUN statement to run a .p which does some work for you, that .p cannot instantiate any .NET objects / classes other than a .NET UI Form (see below for samples).
.NET UI Form -> RUN .p which uses .NET objects /* not acceptable */
.NET UI Form -> RUN .p which uses another .NET UI Form /* acceptable */
.NET UI Form -> RUN .p which uses .NET objects /* not
acceptable */
.NET UI Form -> RUN .p which uses another .NET UI
Form /* acceptable */
I think many people on the forum would appreciate a little information from PSC why they decided to put this restriction in the EULA. It really sounds like a bad joke.
The knowledgebase referred to in previous postings used terminology that was too generic and the examples were too simplistic. We will work to make it clearer.
--
There have been a number of postings with comments about some clauses in the 10.2A EULA. I will try to shed some light to the issues:
The primary objective of OpenEdge GUI for .NET is to address the needs of customers to build competitive desktop .NET Winforms Graphical User Interfaces with ABL and OpenEdge tools.
OpenEdge GUI for .NET includes a very significant and sophisticated engineering body of work both from a development -- e.g. new Visual Designer in OpenEdge Architect, ProBindingSource, etc -- and a deployment e.g. WebClient and Client Networking -- perspective. Very shortly, we have built intra-process communication (aka bridge) between the OpenEdge AVM and the Microsoft .NET CLR for runtime, and between AVM, JVM and CLR for the development environment using the Eclipse foundation.
OpenEdge 10.2A is the first release of "GUI for .NET" and we are fully committed to make you, our customers, successful using this functionality to build and deploy state-of-the-art GUI for your business applications.
As briefly illustrated in some postings to this very forum, as well as postings to the beta forum throughout the beta programs, the "bridge" could be used for many purposes. We have been, and still are, gathering all those use cases to assess them from a business and a technical perspective, with the potential objective to relax the EULA restrictions in future unnamed releases.
Having said this, time and resources are always limited and the potential use cases for the bridge are very broad, therefore for 10.2A we decided to focus on the primary objective of "GUI for .NET": the User Interface! We are very excited with the extremely positive reaction from you all, hinted already by the largest and busiest beta program ever, and we are and will continue to work hard to meet your requirements. For example, we know about some ABL restrictions (e.g. generics) that need to be addressed to be able to use some 3rd party user interface controls. We are already working on them based on the type of requests, the uniqueness, robusteness and popularity of the actual controls.
In summary: the OpenEdge GUI for .NET restrictions in the EULA are meant to provide a framework to focus our efforts to make you successful with OpenEdge GUI for .NET, and provide you with clarity regarding what is supported or not supported in 10.2A. Further, we will continue to enhance the product to meet your needs, as well as assess the possibility of lifting restrictions in future releases based on the business and technical cases.
Thank you all for your continued support!
Salvador
Salvador, I'm so glad, that finally someone from Product managment jumps into the discussion:
In one of my posts from the already named beta discussion, I've used the following sample: I'm desiging a Form using an Infragistics Calendar Control and for what ever reason I decide to create a .p file, that returns an AppointmentCollection (or array) to be added to the UltraCalendardInfo component:
/* readappointments.p */
FOR EACH appointmenttable:
oAppointment = NEW Appointment(...) .
oAppointmentCollection:Add (oAppointment) .
END.
Is that a supported configuration?
Is that violating the EULA?
So will I receive news from your advocates, when I'm using it that way?
I hope the answer is YES and NO, NO. Even if it's NO and NO, NO, the confusing K-Base entry should be removed and replaced by a clearer explanation.
Nobody here that startet the threads had the plans to write an alternative to the ODBC data server using the System.Data.SqlServer namespace.
We just want clear guidelines and the biggest possible freedom of writing ABL code. Usually we are pretty good at doing that once we know what we are allowed to do. Currently there is too much confusion to be creative.
Absolutely Yes, No, No.
Sorry to be brief, I have to run.
Salvador
Salvador, glad you joined us ...
One of the things that strikes me about your discussion is that you could have given all of the same reasons in defense of why some uses of the bridge are supported while others are not. We would clearly understand that. Even within the UI, you are supporting the native Windows controls and Infragistics and beyond that people have to forge their own path with help limited only to the ABL side of things. All very understandable.
Also perfectly understandable to say explicitly that controls using generics are not only not supported, but don't work in this release and that any use of multi-threading produces unpredictable results.
And, similarly, perfectly understandable to say that any non-UI use is not supported since you have no control over what is on the other end.
What is not so understandable is why it is necessary to go beyond "not supported" to "not allowed". Possibly, I could understand not allowing reverse use of the bridge, but why the rest? As long as you are clear about what is and is not supported, you are off the hook.
Among other things, if you allow it but don't support it, think of the huge R&D effort that will be done without PSC having to spend a penny.
Sorry to be brief, I have to run.
Don't stay away long!
Moltes gràcies, Salvador!
Even within the UI, you are supporting the native Windows controls and Infragistics and beyond that people have to forge their own path with help limited only to the ABL side of things. All very understandable.
We are working to make information about our testing and findings with other 3rd party controls (other than MS and Infragistics) available to the community through PSDN as a live document.
What is not so understandable is why it is necessary to go beyond "not supported" to "not allowed".
Updated industry regulations require us (most vendors, really) to be more strict with legal constraints that we need to abide to.
Gern geschehen!
Catalan! Wow, I'm speechless. Thank you Mike.
What is not so understandable is why it is necessary to go beyond "not supported" to "not allowed". Possibly, I could understand not allowing reverse use of the bridge, but why the rest? As long as you are clear about what is and is not supported, you are off the hook.
My thinking exactly. There have been many times over the years I was doing something that wasn't supported, but worked well and became the cornerstone of some of our techniques. Some of these things became supported and others faded away. Being able to call custom UI .NET objects that we wrote would be our issue to deal with if we had problems as should non-UI .NET objects. Waiting for another release, how about just relaxing the EULA in a patch...
Updated industry regulations require us (most vendors, really) to be more strict with legal constraints that we need to abide to.
Could you expound on this a bit? I know that Sarbanes-Oxley has some funny impacts ... having just encountered some in a sales context that I hadn't heard of before ... but I have heard nothing about a "not supported" versus "not allowed" restriction.
Relaxing the EULA would indeed be appreciated!
I'm the guy that made the solution p138026 appear by asking tech support about the meaning of the EULA... (for some reason, the solution is not available on the Knowledge Center anymore, maybe to take the time to relax it a bit)
But we of course need, with the relaxing of the EULA, continued Progress development to further support the ABL to .Net bridge on the AppServer: Have some of you taken a look at the report creation capabilities of the Infragistics controls that are available with 10.2A? That would be great on an AppServer to generate modern looking reports as a service without spending one more penny for other third party non-.Net reporting objects (just one example of the usefulness of the bridge on the AppServer). The enhancement request number is 3847, vote in mass.
you got my vote.
mine too.
But more detailed explainations on the current EULA first... !