Nancy,
I don't want to split hairs on this issue and just want to add these
comments before considering this settled for me (you may still want to post
answers to some of the points below. I certainly am learning from all
this.). I appreciate everyone's comeback and information.
I agree about access to AGSS screens that it would allow a user to create
their own Graphpak functions (invoked with rUN, e.g.) and that it would then
be saved as part of an ATF file. But how about this.
1. I still need an answer about locking functions like at risk IBM code, not
necessarily user material if the users do want to share their code. Will
that satisfy runtime requirements?
2. Let me give you an analogy -
Suppose I write and compile a Visual Basic (VB) runtime program but decide
as the programmer that I will allow the user to introduce their own code by
creating an appropriate editing (GUI) window where the code gets typed or
pasted. There is no lawyer in the country who can argue with this since
ASCII VB code is everyone's domain (are APL symbols protected by comparison
because they are symbols?). And this VB code is then used as part of the
execution of the tasks in the main program under program control and can
also be written out for sharing with other users if desired. All this is
happening in a runtime environment using VB code. In other words, I can
quite easily simulate an operating system environment under runtime
conditions within the capabilities of the runtime interpreter.
Take AGSS, I do not have to provide access to the native AGSS screens but
have available the AGSS control vector, which is APL code, and which
describes and executes a particular AGSS screen (one specific control vector
for each screen). I can easily allow the user in a non-AGSS GUI edit window
to create and/or modify a control vector using APL symbols either via cut
and paste or via some by me defined APL symbol substitution in order to
control or program AGSS that way. Mind you, all under runtime conditions.
Again, I can simulate a work session environment quite easily but probably
not as conveniently and efficiently as I can with APL Session Manager. I am
therefore permitting the user to program AGSS to their hearts content
without ever having entered AGSS and, as you pointed out save that as a file
(ATF or other) or recall it from a file.
Now, knowing that I can do all that, it is simply a heck of a lot more
convenient for me and anyone else to have the existing AGSS screens
available for doing all that. If I wanted to go further, I can simply
re-create the entire AGSS interactive environment from scratch using AP124
calls and package everything as a runtime file permitting the user access to
my encoded screens. Evidently, it is simply a question of how inconvenient
and work intensive that is that prevents me from doing that and instead
explore the alternatives.
Naturally, I could confine myself to generating highly specific runtime
routines based on the AGSS statistical and scientific/engineering functions
and try to sell those or make them available as freeware. However, my
interest is simply to create perhaps more of a user group around AGSS since
it has so much to offer unbeknown to most people. Anyway, I'll talk to you
offline as you suggested previously.
Hans S.
Hans,
AGSS, while it may be no longer available for purchase, is still licensed
IBM code and has a pre-requisite for the APL2 product (the full APL2
development system, not the runtime.)
Allowing users of your application direct access to the AGSS product
screens and allowing them to create and save their own AGSS routines
(which is in essence allowing them to create their own APL2 code) is
giving the AGSS product to a customer who does not have a license for the
product nor the prerequisite software installed.
Regardless of whether the current situation is ideal as far as providing
educational and motivational stimulus for APL, the licenses are in place
and they do not allow this.
This type of application should not be deployed using the APL2 Runtime
Library.
Nancy Wheeler
APL Products and Services
Post by Hans SeehaseHi Nancy,
I have built many AGSS runtime programs not making use of AGSS screens
and have built one that does and would therefore require the AGSS
modules. For that program I created an APL GUI front end so that you can
bounce back and forth between that and AGSS itself. Only the front end
program functions (mostly my own code) show up in AGSS as User functions
and are exported by KEEP. They can be locked though. Any other User
functions would then be procedures written by a user for making use of
AGSS capabilities. These would contain User code only, which can be
shared among interested users by way of an ATF file.
Now, J, e.g., provides access to powerful features and even the language
and operating system for personal use and on an honor system basis. Isn't
APL being a bit stingy in that regard? And would it not be motivational
and educational for novice APLers and stimulate interest in APL to be
able to make use of an environment like AGSS?
Post by Nancy WheelerHi Hans,
AGSS is not one of the standard APL2 public library workspaces and so the
rules for the APL2 runtime library really don't cover it.
I am not a lawyer, but unless there were a special agreement in place to
allow you to do so, I do not believe that any part of AGSS can be
re-distributed. Certainly you should not provide in your runtime
application namespace any kind of interface that would give your users
access to the AGSS menus, that would allow them to use it directly, or
that would expose its internals (like for example, use of the KEEP
function to create .atf files containing AGSS or APL2 source code).
If you need some of the statistical or graphic functions of AGSS to
create your application namespace, and they can be included in your
namespace and used "under the covers" by your application, then I don't
think anyone here would raise an objection. But anything beyond that
would require a special arrangement.
If you want to pursue something like that, please contact us offline at
Nancy Wheeler
APL Products and Services
Post by Hans SeehaseThis is my first append to this feed and I don't know if it will come
out. Her goes.
I am currently making use of APL AGSS in some of my runtime files. I
follow all requirements (copy right notice, allowed inclusions from APL
libraries, etc.), except that there is one problem. For AGSS to function
correctly in many instances it also requires its external module files,
e.g., PROFILE.AGS and *.AFL. These files are however not packaged by the
APL interpreter into the runtime file itself. So, can these files be
distributed with the runtime file as needed, or are there issues with
that?
Thanks,
Hans Seehase