# Installation and Licensing

JDK dependency

Saxon on the Java platform now requires J2SE 5 (often called JDK 1.5) or later. It no longer works with JDK 1.4.

Repackaging

Saxon is now available in three editions: Home (HE), Professional (PE), and Enterprise (EE). The Home Edition is open-source, available free of charge, and runs without a license file. The Professional and Enterprise editions both require a license key obtainable from Saxonica.

The Saxon-SA product has been renamed Saxon-EE (for "Enterprise Edition") to reflect the fact that it contains many added-value features beyond schema-awareness: for example, streaming, XQuery Updates, compilation of queries to Java code, separate compilation of query libraries, and an advanced query optimizer.

The JAR and DLL files are renamed accordingly (for example saxon9ee.jar, saxon9ee.dll).

The `Configuration` class for Saxon-EE (previously `com.saxonica.validate.SchemaAwareConfiguration`) is now renamed `com.saxonica.config.EnterpriseConfiguration`. This change reflects that fact that use of this Configuration enables all features that are exclusive to Saxon-EE, of which schema-awareness is only one. The Configuration class for Saxon-PE is named `com.saxonica.config.ProfessionalConfiguration`, while that for Saxon-HE is simply `net.sf.saxon.Configuration`.

The JAXP factory classes for Saxon-EE (previously `com.saxonica.SchemaAwareTransformerFactory` and `SchemaAwareXPathFactory`) are renamed `com.saxonica.config.EnterpriseTransformerFactory` and `com.saxonica.config.EnterpriseXPathFactory`.

Similarly, Saxon-PE (professional edition) offers `com.saxonica.config.ProfessionalTransformerFactory` and `com.saxonica.config.ProfessionalXPathFactory`.

Some features that were previously available in the open-source product Saxon-B are not included in the Saxon-HE (home edition) product build. These features are all optional extras, in the sense that they are not required for conformance to the W3C or Java API standards. The relevant features are:

- The traditional mechanism for binding extension functions by reflexion (searching the classpath for matching names) is now available only in Saxon-PE and Saxon-EE. In Saxon-HE, the only way to define extension functions is the new mechanism of "integrated extension functions", which need to be explicitly registered with the Configuration.

- All extension functions in the Saxon namespace `http://saxon.sf.net/` now require at least Saxon-PE.

- All EXSLT extension functions now require at least Saxon-PE.

- The XSLT extension instructions `saxon:assign`, `saxon:call-template`, `saxon:doctype`, `saxon:entity-ref`, `saxon:import-query`, `saxon:script`, and `saxon:while` now require Saxon-PE.

- The SQL extension: that is, the extension instructions `sql:connect`, etc, is not available in Saxon-HE. The code for this extension remains available as an open-source plug-in for use with Saxon-PE or Saxon-EE.

- External object model support for JDOM, DOM4J, and XOM is not available for Saxon-HE "out of the box". However, the source code for these extensions remains available in open-source form, and can be used by compiling it and registering it with the Configuration.

- Memo functions, previously available in Saxon-B, now require Saxon-PE or Saxon-EE. Any request in a stylesheet or query to create a memo function is ignored under Saxon-HE with a warning.

- The ability to "compile" stylesheets (that is, to create a Java serialization of the internal representation) is now available only in Saxon-EE. The command to achieve this is renamed `com.saxonica.CompileStylesheet`. Such stylesheets can be executed under Saxon-HE, but because they have always required a dedicated `Configuration`, this is now packaged for use only from the command line (if you need to run it from a different application, you can copy the relevant code from the `net.sf.saxon.Transform` source, and you must take responsibility for ensuring that the application runs in its own `Configuration`.)

- Localization support for a number of languages other than English in `xsl:number` and in the `format-dateTime()` family of functions is provided by means of modules in package `net.sf.saxon.option.local`. These modules are included in the JAR files for Saxon-PE and Saxon-EE; if required for Saxon-HE they can be compiled from source code. In all cases they are no longer picked up automatically by virtue of class naming conventions, instead they must be explicitly registered with the Configuration either by using the method `setLocalizationClass()` or, in Saxon-PE and Saxon-EE, via the configuration file.

Some features that were previously available only in Saxon-SA are now available in Saxon-PE (without open source code). These include:

- The PTree persistent XML tree format

- A number of extension functions: saxon:analyze-string(), saxon:call(), saxon:find(), saxon:index(), saxon:for-each-group(), saxon:format-dateTime(), saxon:format-number(), saxon:function(), saxon:generate-id(), saxon:try()

- Support for a subset of the new facilities in XQuery 1.1 (grouping, format-number(), format-date(), etc)

Schema-awareness is now a property of a compiled query, stylesheet, or XPath expression. By default, these executables are schema-aware if they contain an import schema declaration in the source code, or if a schema was imported programmatically into the static context for the compilation. If the executable is not schema-aware, then all the data supplied at run-time must be untyped. The reason for this is that there is a considerable performance penalty if it is not known statically whether data will be typed or untyped; therefore, code that is not explicitly declared to be schema-aware is now compiled to handle untyped data only. (This allows the type annotations `xs:untyped`, `xs:anyType`, and `xs:untypedAtomic`. Of these, `xs:anyType` will appear only in nodes constructed from within a query, and only when construction mode is "preserve".)

For XSLT a transformation can be set to be schema-aware, even if it does not import a schema, by setting the Configuration property `FeatureKeys.XSLT_SCHEMA_AWARE` to true. For XQuery, the same effect can be achieved by setting the Configuration property `FeatureKeys.XQUERY_SCHEMA_AWARE`.

The command-line interfaces `Transform` and `Query` will now load an enterprise configuration if they can (that is, if Saxon-EE and a valid license file can be located). The `-sa` option is now needed only to enable schema-awareness in a transformation or query that does not import a schema. This might be needed, for example, if the transformation or query uses untyped input but validates its output. The option is no longer needed to enable other Saxon-EE features such as advanced optimization or streaming.

Licensing changes

The notes below are non-normative: for definitive statements, you need to read the license text.

Saxon-PE and Saxon-EE (professional and enterprise editions) are available under commercial license terms. These impose the usual commercial restrictions, for example redistribution of the software is allowed only under an explicit agreement.

The open source product, Saxon-HE, is available under the same conditions as its predecessor, Saxon-B: that is, the Mozilla Public License.

The effect of this is that there are very few restrictions on applications built using Saxon-HE: the JAR file can be distributed with the application, and the application can be issued under any licensing terms you choose, whether commercial or open source. The only restriction you need to watch out for is that there is a requirement to distribute the notices contained in the `notices` directory whenever you distribute the JAR file itself. Some popular software distribution mechanisms such as `maven` are currently unable to satisfy this obligation.

License keys

Saxon-EE and Saxon-PE on .NET now uses the same license key files as Saxon on Java. For the time being, Saxon-EE on .NET will also work with previously issued .NET license keys, but all new license keys issued will be in cross-platform format.

For Saxon-EE and Saxon-PE on Java, it is no longer necessary for the directory containing the license key file to be on the classpath. Instead, the license file `saxon-license.lic` can be installed in the directory containing the `saxon9ee.jar` or `saxon9pe.jar` file, where Saxon will find it automatically. Saxon now looks first in this location, and then on the classpath.

Since the license key directory no longer needs to be on the classpath, the class `net.sf.saxon.Transform` is now the registered entry point for all three JAR files: saxon9he.jar, saxon9pe.jar, and saxon9ee.jar, making it possible to run all three products using the `-jar` option on the command line.

There has been some abuse of evaluation licenses, notably in developing countries. Two measures have been introduced to discourage the use of evaluation licenses for production work:

- Saxon now disables the use of evaluation licenses for a short period each day (typically five minutes, but random). These events are designed to be sufficiently rare that genuine evaluation projects are not impacted, but sufficiently frequent to cause a nuisance when attempting to run a production workload using an evaluation license.

- Occasionally and at random, in about 1% of runs, when running with an evaluation license Saxon will insert asterisks into the output when serializing.

Next