Date: June 18, 1999

About SHELF

Why is Applix doing this?
How does an Extension Language benefit me?
What is the relationship between open-source SHELF and Applixware?
What are the licensing restrictions?
Does this mean that Applixware and/or Anyware are free?
Why amake?
What are the long term plans?
Why ELF rather than PERL or Tkl?
How stable and reliable is this version?
Will there be more Applix Open Source Products?
How do I start using SHELF?

Why is Applix doing this? top of page

Applix is a public, for-profit corporation that develops and sells Applixware, Applix TM1 and Applix Enterprise. These are, respectively, desktop productivity tools, OLAP servers, and customer relationship management products.

The success of Applixware in the Unix and Linux markets has been largely a result of a macro language Applix developed called ELF (Extension Language Facility) and its ability to allow customers to extend the functionality of Applixware by integrating it with other applications. These extensions range from new Applixware features to applications where Applixware plays a subordinate reporting or arithmetic-engine role, to completely new non-Applixware applications.

ELF is the cornerstone of the SHELF project. We believe that making SHELF available at no charge to developers will increase the appeal of Applixware in the open-source community of Linux. We further believe that Linux open-source developers will help evolve ELF better and faster than the single company development team at Applix.

Applix will continue to sell products that take advantage of ELF and SHELF. We will continue to sell supported and
quality-assured versions of SHELF. We will continue to sell hard-copy documentation, release media, and consulting services. We will also continue to make the current version of SHELF freely available for download.

At Applix, we see SHELF as a crucial part of a computing platform, and as such, it should be free to grow.

How does an Extension Language benefit me? top of page

ELF owes many of its core principles to the Lisp interpreter in EMACS. We believe that high-quality layered applications are best built using a user-interface-intensive language, that wraps core product functionality. A principal benefit of this is that it enforces well-defined public interfaces. The choice was made, however, not to use a parenthesis syntax. Instead, we chose as a baseline syntax-extended BASIC. The dynamic data model is much more like modern versions of Lisp, excluding Lisp's car/cdr.

Comparatively small applications, where performance isn't paramount, are also well suited for ELF. Like Java, it is memory safe and machine portable -- even in "binary" format. It is easy to produce relatively robust and powerful applications quickly with little time spent dealing with the tedium of memory management.

An error-throwing language like ELF allows the developer to code "optimistically." Unforeseen errors will simply shut the program down, along with a meaningful error message that describes the failure and where in the program it was triggered.

Ever since ELF was introduced commercially in 1988, it has held to this strategy. In many ways, this strategy is consistent with the Unix/Linux watershed notion of creating commands that can be chained together to form powerful scripts. In this sense, ELF is the next evolution of awk and sed-based scripting.

What is the relationship between open source SHELF and Applixware? top of page

The open-source SHELF project consists of a number of libraries, executables, and data files. The same set of files are used by the newer versions of Applixware 4.42. Therefore, if you extend SHELF's capabilities, you can immediately take advantage of your work from within Applixware.

Additionally, ELF programs can make calls to Applixware-based servers using the RPC and AXNET built-in ELF functions.

If you have Applixware running on your machine, the SHELF help facility is automatically routed to the Applixware help displayer. This provides you with a high-performance help display, and superior searching facilities in comparison with the limiting HTML-based help that comes with open-source SHELF. As not all the on-line help is available in HTML format yet, we suggest you enable this feature. There is a simple profile setting that allows you to automatically launch Applixware for help.

What are the licensing restrictions? top of page

The software is being released under the GNU Lesser General Public License (LGPL) as defined by the Free Software Foundation in Boston, MA. Strictly speaking, you should read the "GNU Lesser General Public License," but this section will attempt to answer some of the intent of the document.

The LGPL is a software license agreement that mandates policy on such issues as redistribution rights, the provision of source code, and pricing policies. In summary:

All files that make up SHELF, whether source or outputs of the SHELF build procedure, are LGPL files. You may use (free of charge) either the original or the modified versions of these files as part of your program. However, you must distribute the program in such a way that these files are accessible and usable by your program's recipient in a similar manner to an unmodified version of SHELF; further, if you modify the SHELF source, you must make this modified source available.

Here are some scenarios:

  1. The major function of SHELF is to provide an interface to construct and test ELF macros and Builder applications, as well as to execute such items. An ELF macro or Builder application is an ASCII file that is not "attached" to SHELF in any way. Suppose you create an ELF macro or Builder application and wish to distribute it to current SHELF users.

    You are under no restrictions; you may charge what you wish and do not have to provide the source code.
  2. You create an ELF macro or Builder application and wish to distribute the application along with SHELF.


    Again, you may charge what you wish and do not have to provide the source of your macro or application. However, you must provide the SHELF source.

  3. You wish to redistribute SHELF.

    You may charge a media, distribution, and/or warranty fee. You must provide the SHELF source.
  4. You modify SHELF (e.g., fix a bug) and wish to redistribute it.

    You may charge a media, distribution, and/or warranty fee. You must provide the SHELF source, including your modifications. Note, your modifications are now covered by LGPL.
  5. You extend SHELF (e.g., add a widget) and wish to redistribute it.


    If all your changes fall within elfmain.so, you may charge a media, distribution, and/or warranty fee. You must provide the SHELF source, including your modifications, which are now covered by LGPL

If some of your changes fall outside of the SHELF files, you may charge whatever fee you like for the distribution. You must provide the SHELF source, including your modifications to the files, which are now covered by LGPL. Your changes outside of the files are not covered by LGPL unless you declare them to be. However, the modified files must be separable from your other changes, and still operable in the absence of your other changes. Finally, the recipient must have the ability to modify the files and continue to use them in the context of your non-SHELF changes.

Applix and others in the open source community hope and expect you will be a "good citizen." We believe that good open source citizenship includes the release of source code that is not mission critical to your organization. Therefore, for example, if you add "matrix multiply" capability to SHELF, we would expect that you provide it "free," unless your company is explicitly in the business of selling "matrix multiply" or related software.

Beyond the LGPL license, Applix hosts the "official" version of the SHELF source tree. Included in this site are the "baseline" SHELF sources from Applix, and all of the modifications made by Applix and other organizations. We request that when you complete a set of SHELF modifications, you send us the "free" source in the form of a "delta" project directory. Applix will make your project directory part of the free public Applix site. Applix may also choose to include your modifications in future free "baseline" versions of SHELF. Only Applix can generate and distribute an "Official Applix SHELF Release."

Any program that uses SHELF files (e.g. links with a SHELF library) must acknowledge the use of "Applix SHELF" in the same manner as they do for any other third-party component (e.g., as we do in the Help -> On Version dialog box.) If you use modified SHELF files, the acknowledgment must include "Applix SHELF modified by <customer name>."

For further information on the LGPL license, see the shelf_license.txt in the source directory, visit the web site www.gnu.org/copyleft/lgpl.html, or write to the Free Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307, USA.

For further information on project directories, see the related FAQs in this document.

Does this mean that Applixware and/or Anyware are free? top of page

No. Applixware and Anyware are per-user licensed products. Applixware includes all of the program and data files shipped as part of the Applixware release.

You are free to distribute any data files or executables you build from the source. You may not distribute data files or executables obtained from the Applix per-user licensed distribution.

In summary, you are free to build from source, use and distribute the result. You are not free to use the result with any Applix product from a non-free distribution. The result may only be used with a non-free Applix product if the usage of the combined product meets the licensing requirements of the non-free Applix product.

Why Amake? top of page

SHELF (and Applixware) are compiled and linked via a non-standard makefile system called amake. The choice of using amake is based on the sum total of several factors -- history, performance, platform independence, auto-dependencies, developer independence, and the separation of sources and build files. First a bit of history. The Applixware source tree began in 1983. This was in the days of slow computers, low functionality, and often unreliable make programs. On some of the platforms to which Applix was ported, make wasn't even available. Equally important, Applix wanted a build process that supported developers that were simultaneously working with a large source tree. Crucial to the choice was the ability for each developer to perform his or her edits in a private directory and still use the public copies of all other sources. In a sense, all per-developer edits are done in a sandbox directory, usually called "delta." As developers produce objects for multiple platforms, and with varying degrees of debug support, based on varying include files, the resulting objects must be kept separate from the sources. In terms of performance, on most machines amake is able to read its cache and begin checking datestamps for a large project within seconds, which is an order of magnitude faster than would be the case with makefiles. amake scans all .c, .h and .elf source files to compute #include file dependencies, which it keeps in a cache. Developers are freed from the drudgery of manually entering include file dependencies. amake uses automatic prototype generation. The signatures of all functions in the system are held in a single dictionary. Whenever amake compiles a module, it produces a .p file for inclusion in the source. The .p file has the signatures for all functions called from this file.

Having stated this, it should be quite possible to build a makefile that can build the product. If demand is sufficient, we would suggest that it be added as an amake feature. Just as amake builds the opensrc.amk file, it could build the opensrc.mak file. This was our original thinking, but it is MUCH simpler for us to put out amake. Who knows, maybe there will be an amake following. We certainly think there would have been if we put it out in 1984!

What are the long term plans? top of page

Applix is motivated to see ELF become a standard language for layered applications and lightweight application building. It will never replace more scalable languages like C++ and Java. It may, however, become the standard way to glue applications together and powerfully automate them.

We believe that even though ELF predates some single-platform, monopoly-driven GUI languages, ELF will blossom in the open source community!

Why ELF rather than PERL or Tkl? top of page

ELF is not as robust and sophisticated as C++ or Java. However, it was designed as a true programming language with rich data management capabilities. Inherent in ELF programs is readability and maintainability. Yes, it is quite possible to write non-maintainable spaghetti code in ELF. But ELF does not reward it. At this time, ELF is very weak as a shell programming language; PERL and Tkl are far better at launching shell commands and piping their results. Unlike ELF, they tend to be more "write-only" in nature.

How stable and reliable is this version? top of page

As of version 4.42 of Applixware, ELF has been fully quality-assured. In the future, Applix will update the open source tree on its web site. Applix may also perform other updates for enhancements or bug fixes. Applix may not provide prior notice on updates, but it will offer a complete set of archives of older versions.

Please report any bugs to support@applix.com. Even better, please feel free to fix any issue and send us a project directory as described below!

Will there be more Applix Open Source Products? top of page

At this time, Applix expects to release additional software to the open source community. Our plans will be based on the reception of the ELF open sources, and customer demand. We believe the open source movement is the most viable way to create a new standard in desktop and server software. Developers who would like to add value to Applix products not currently open-sourced should contact info@applixware.org.

How do I start using SHELF? top of page

Download SHELF (from www.applixware.org) and follow the installation and build instructions. Refer to our Getting Started with SHELF document for more information.