By purchasing, asking for and/or using customer support you agree to be bound by the following terms and conditions. You are not required to sign these terms, however if you do not agree to these conditions then you should not buy, ask for or use support. The general conditions (available at http://www.atomikos.com/Main/GeneralConditions) are an integral part of this document; if you agree to the present document then you are also assumed to agree to our general conditions. Should this document contain any clauses that are incompatible with the general conditions then the content of this document prevails.

Art 1: Bug, Incident, Issue and Status

An issue (or ticket) is defined as a problem caused by an ATOMIKOS product and experienced by you. A support incident is a single, specific, issue–based request for support. A request that raises multiple issues will generate the need for and use of multiple support incidents.

A bug is a special type of issue where the behavior of an ATOMIKOS product is different from what is advertised in our documentation.

An incident is considered closed (resolved) when any of the following occur:

The issue in question is a feature of the software and may involve you to take training or education.

There is a functional clarification related to the use of the software.

A workaround procedure was made available to address your needs.

In case of a bug: a new release was made available that fixes the issue, requiring you to upgrade.

The issue concerns additional functionality that may or may not be addressed in future versions of the software.

The issue cannot be reconstructed by ATOMIKOS.

Any incidents opened by you will be closed automatically if you cannot be reached by ATOMIKOS within 3 attempts on 3 different business days.

Catastrophic production problem which severely impacts Your production systems, or in which Your production systems are down or not functioning; loss of production data and no procedural work around exists.

Production support.

1 business day

Work continuously until resolved or expired.

2

High-impact problem in which Your operation is disrupted but there is capacity to remain productive and maintain necessary business-level operations.

Production support.

1 business day

An immediate workaround or a fix in the next planned release.

3

Medium-to-low impact problem which involves partial non-critical functionality loss impairing some operations but allowing Your systems to continue to function. This may include a minor issue with limited loss or no loss of functionality or impact to Your operations and usually includes documentation errors.

Production support.

2 business days

An immediate workaround or a fix in the next planned release.

Business days are counted as Monday to Friday.

Support is limited to 12 months from your purchase date of an Atomikos support subscription or until the date mentioned during purchase. A response to an issue/incident may consist of the acknowledgement by ATOMIKOS of your incident report, and may not necessarily resolve your incident.

Art 4: Property

ATOMIKOS warrants itself to be the legal owner of the software and to have the right to all royalties originating from it. Consequently, ATOMIKOS warrants that no part of the present contract interferes with the rights of any third party and that you may make full use of the license granted to you in the full knowledge of the above.

The software is protected by Belgian intellectual property laws, other intellectual property laws and international treaty provisions. The software and all associated intellectual rights remain either the exclusive property of ATOMIKOS or that of certain licensors to ATOMIKOS.

The intellectual property rights on the software and its documentation, any feedback provided by you as well as all copies, updates or possible extensions, including new functions that may be developed by ATOMIKOS for you, remain the sole property of ATOMIKOS, or of certain licensors to ATOMIKOS, unless otherwise agreed in writing.

Art 5: Limitations

Support concerns issues that arise from the usage of the software, conform the specifications in the ATOMIKOS documentation. Not included are new features that you request, modifications to features that are not causing problems when using the software or ports to unsupported platforms or environments. When a newer version of the software is available then you should upgrade first before asking support. Also excluded is custom coding (i.e., writing customer-specific code outside the ATOMIKOS product boundaries).

You are not allowed to disclose any benchmark results for the software without any prior and explicit consent of ATOMIKOS.

Art 6: Communications

Asking Support Questions

All support is remote unless otherwise indicated in the formula you have purchased. Remote problem cases are to be reported by the named dedicated persons as indicated in your support purchase order and emailed to support@atomikos.com where they will be pulled into the Atomikos ticketing system.

You agree to supply the following minimum information for each issue:

The steps to reproduce the issue

The expected behaviour of the software

The observed behaviour of the software

Upon receipt, ATOMIKOS will generate a timestamp and ticket (number) to identify the problem. This ticket should be used by you for all further communications related to the case.

Downloading Fixes

As of release 3.9, you can simply configure and use our MavenRepository settings.

Art 7: Disclaimer

In no event will ATOMIKOS be liable for any damages whatsoever including – but not restricted to – lost revenue or profits or other direct, indirect, special, incidental, cover, or consequential damages, even if advised of the possibility of such damages, except to the extent applicable law, if any, provides otherwise.

Art 8: Completeness

This is the full and final agreement between you and ATOMIKOS, and it supersedes any promises, representations or agreements relating to the subject of this agreement. This agreement may be changed only if you and an ATOMIKOS authorized representative do so in writing. No inconsistent, additional, or pre-printed terms on your purchase order or other business form apply.

Art 9: Refund Policy

Our support fees are paid up-front in order to guarantee availability of our support staff. For this reason, we do not offer refunds.

Appendix A: Release Numbering and Backward Compatibility

In general, we follow the semantic versioning strategy outlined in http://semver.org and with backward compatibility we mean compatibility at the Atomikos API and configuration level.

Release Numbers

Release numbers are of the form x.y.z[Mi]:

x is the major version - a change indicating a big difference in functionality that might break backward compatibility.

y is the minor version - a change indicated a minor difference in functionality that maintains backward compatibility.

z is the maintenance version - a change indicating that one or more bugs have been fixed, without any drastic changes.

Mi is the optional milestone version - indicating an unstable release made available only for experimental purposes.

Snapshot Release

Identified by x.y.z-SNAPSHOT, a snapshot release is meant for internal development purposes only, and definitely not for production use.

Example: 3.7.0-SNAPSHOT means an ongoing development build for what should become release 3.7 at some point in time.

Milestone Release

A milestone release is any release identified by x.y.zMi (i.e., with Mi suffix). Milestone releases are not supported: we do not guarantee that maintenance releases will be published at any time. Rather, milestone releases represent public early access releases (beta releases).

Example: 3.7.0M2 indicates a milestone release for what should become release 3.7 at some point in time.

Stable Release

A release x.y becomes stable as soon as it is no longer made available as a milestone or snapshot release. In general, there will be one or more maintenance releases for each stable release.

Example: 3.5 is a stable release because we have released 3.5.0

Maintenance Release

By maintenance release, we mean any release identified by x.y.z.

Example: 3.5.1 is a maintenance release (usually fixing one or more bugs in the prior release 3.5.0).

Appendix B: Important Dates

The following table summarizes when our current and past releases expire in terms of support; from those dates on it is highly recommended that you upgrade to a newer release.