THE SLAng SLA LANGUAGE

Frequently asked questions

UCL Logo
Disclaimer: None of the information provided on this page should be construed as legal advice. SLAng is under development and should not yet be used for real SLAs.

    SLAs in general

  1. What is an SLA?
  2. Why isn't this legal advice?
  3. What is the difference between an SLA and a contract?
  4. Why do we need a language for SLAs?
  5. What are the requirements for an SLA?
  6. What are the requirements for an SLA language?

    ASP in general

  7. What is Application Service Provision (ASP)?
  8. What are the advantages of the ASP business model?
  9. What are the risks with the ASP business model?
  10. How can SLAs mitigate the risks with the ASP business model?

    SLAng

  11. What is SLAng?
  12. How can SLAng be used?
  13. Why should I not use SLAng for real SLAs yet?
  14. Who has been involved in the development of SLAng, and why?

    SLAng in practice

  15. What parties need to be involved in an ASP SLA?
  16. What requirements must my service meet for me to use SLAng to offer SLAs?
  17. What software infrastructure is needed to use SLAng?
  18. I am a service client. How can I get an SLA from a provider?
  19. I am an application-service provider. How can I offer SLAs to my clients?
  20. I am a network service provider. What do I need to know about ASP SLAs?
  21. What happens when parties disagree about an SLA?
  22. SLAng is only monitorable. How can I force another party to pay a penalty if they are in violation of a SLAng SLA?
  23. I can't express what I need to in SLAng. What now?

    SLAng in research

  24. How can I reuse the theory underpinning SLAng
  25. How can I extend SLAng?
  26. How can I implement SLA languages for other domains?

    The SLAng open-source project

  27. How is SLAng licensed?
  28. What software is distributed for SLAng?
  29. How is the software for SLAng licensed?
  30. What software is planned for SLAng?
  31. How can I get involved with the development of SLAng?
  32. How can I support the SLAng project?

SLAs in general

1. What is an SLA?
The term SLA is much abused. We interpret the term strictly to mean the contract or part of a contract made between a service provider and client that assigns penalties to undesirable behaviour on the part of either party, or the service.

Historically, SLAs usually constrain properties of a service, such as latency or reliability, that may informally be grouped as Quality-of-Service (QoS) properties. Therefore there is a tendency to call any specification of QoS for a service an SLA. However, these should properly be called Service-Level Specifications (SLSs).

The term SLA implies that an agreement exists between parties. Agreements are only useful if they have an economic effect, and the obvious use for SLAs is to mitigate the risk to the client that the service does not perform in the way that they anticipate when they chose to start using it. The economic importance of SLAs implies strong requirements on the content of such agreements.

The principle benefit of using SLAs is that mitigating the risks in a service provision scenario makes it possible for clients to more fully realise the benefits of outsourcing, which potentially include reduced costs and increased QoS. SLAs also allow discrimination between services on the basis of quality and cost.

top

2. Why isn't this legal advice?
None of the information offered on this website should be considered to be legal advice. This is because the authors of this information are not qualified or insured to offer legal advice, and in many cases it would therefore be illegal for us to do so (as far as we know).

Since this is the case, SLAng concrete SLAs should not be trusted as the sole basis for any contractual agreement without also seeking qualified legal advice. SLAng provides a means to represent concrete SLAs, and we have attempted to provide vocabulary supporting likely combinations of financial and technical arrangements. However, additional legal considerations may apply before these can be considered legitimate contracts.

top

3. What is the difference between an SLA and a contract?
A contract is a legal instrument, and hence we are unqualified to advise you on this matter. See the answer to Q2 for a further explanation of this. However, we make a distinction between legitimate SLAs, which may be contracts, or form part of contracts, and concrete SLAs that are merely a representation of some SLA terms that may or may not be legitimate. SLAng provides the capacity to represent concrete SLAs without in any way guaranteeing that they will also be legitimate.

top

4. Why do we need a language for SLAs?
Trivially, we need a language for expressing SLAs because although we could make informal verbal agreements as to the behaviour of services, we will probably need to also record the details of any SLAs entered into, in case a disagreement later arises that is pertinent to the SLA.

We make a distinction between concrete SLAs, and legitimate SLAs. A concrete SLA is merely a representation of some SLA terms, whereas a legitimate SLA reflects a genuine agreement between the parties, and satisifies all additional legal requirements to form part of a contract. Because we can not offer legal advice, we can not comment on the legal aspects of legitimate SLAs. Instead, the focus of our work is on providing support for expressing concrete SLAs, which may or may not ever form the basis for legitimate SLAs.

Why should we use a formal language, rather than a natural language for expressing SLAs? As mentioned in the answer to Q1, the fact that SLAs have financial components implies strong requirements for the content of SLAs. The contents must be precise, not open to exploitation, and only refer to events that are mutually monitorable by the client and provider. Meeting these requirements may be difficult, raising the cost of preparing an SLA. By using a formal language, some of the burden of expressing the SLA is passed to the definition of the language. The language need only be defined once, in such a way that all SLAs expressed in the language have some desirable properties, and may then be reused for multiple SLAs, reducing the cost of their preparation.

SLAs are also potentially relevant information for systems architecture, where they can be used to guide adaption and deployment activities. Therefore a machine-readable language for SLAs is desirable.

top

5. What are the requirements for an SLA?
SLAs have numerous requirements. Here we comment on the practical requirements for SLAs if they are to be effective in mitigating the risk for a client in entering a service-provision scenario. Legal requirements may also apply if an SLA it to be legitimate. We may not comment on these and you should possibly seek professional legal advice before entering into any SLA. Most fundamentally SLAs must describe the behaviours of the system or the parties that cause one party to have to pay a penalty to another, and they must describe the penalty. However, in so doing an SLA should try to meet a number of other requirements that increase the likelihood of it being an effective basis for conflict resolution in the event of a disagreement between the parties.

We call the capacity of an SLA to ensure that any relevant dispute is resolved according to the original intent of the agreement the protectability of the agreement.

A number of important requirements stem from the need for SLAs to be protectable. For example, SLAs should also be precise and understandable, so that disagreements concerning their original meaning are made more difficult.

SLAs should also preferably be monitorable, in that they should only constrain events that are intrinsically visible to both parties, or events that the parties can have monitored for them by parties that they trust. Note that because SLAs have a financial component, parties may have a disincentive to honestly report events relevant to penalties that they may have to pay. Independently monitoring these events reduces the risk of dishonest reporting, increasing the likelihood that a dispute will be resolved according to the initial intent of the agreement.

A number of other requirements govern the practicality of using SLAs. SLAs should also be as cheap to prepare as possible, and certainly cheap relative to the value of the agreement being specified. Otherwise SLAs will not be effective for risk management, as the cost of preparation could obviate the benefit of receiving penalties.

SLAs should be non-exploitable, meaning that one party cannot by their actions cause another party to have to pay a penalty unless the second party is in breach of their obligations with respect to the agreement. Clearly if an SLA is exploitable there will be a disincentive for some party to enter it, rendering it ineffective for risk management.

top

6. What are the requirements for an SLA language?
The ideal SLA language would only permit the expression of SLAs meeting all the requirements for SLAs in any scenario in which an SLA was desired. Such a language may be impossible, due a conflict between the need for a high level of expressiveness to accomodate all possible scenarios of interest, and the need to verify properties of SLAs such as non-exploitability and monitorability. Therefore, a number of specialised SLA languages for different domains may be required.

In addition to the requirement that SLA languages must be able to express a set of SLAs with good characteristics, a number of requirements may be defined for the language itself. For example, if SLAs are to be processed in any way automatically, it is desirable to have a language definition prepared in such a way as to be useful in the engineering of SLA tools.

Because SLA languages assume part of the burden of expressing the meaning of an SLA, the language definitions also inherit the requirements for precision and understandability from the SLAs.

top

ASP in general

7. What is Application Service Provision (ASP)?
We use the term Application Service Provision to refer to the provision of an electronic service across a network, by one organisation to another, often in return for payment. A large number of middleware technologies provide support for the communication that occurs between the parties during service provisioning. These include Remote-Procedure Calls (RPC), Enterprise JavaBeans, DCOM and .Net.

top

8. What are the advantages of the ASP business model?
Sometimes it is essential for companies to do business with other companies, and ASP can be an efficient way to do it.

It is also certainly the case that the development and operation of large-scale distributed systems is a complicated and costly affair. Advocates of service-orientation suggest that outsourcing parts of these systems to external providers allows organisations to concentrate on improving those parts that remain. This specialisation argument also applies to the parties providing the outsourced services, potentially allowing them to improve the quality of the services they offer and reduce the price. Finally, a competitive market in services may also be a driver of service quality.

top

9. What are the risks with the ASP business model?
Set against the benefits that outsourcing a service may provide are two substantial risks.

When a client considers integrating an outsourced service into their infrastructure, they must make two bets. The first concerns how well the service will operate when it is operating at all. The service presumably has some value to the client. If the service does not operate correctly, with reference to the specification advertised to the client, then the client could suffer financially. The second concerns the reliability of the service and the lifetime of the service provision agreement. The client will frequently need to make an investment to integrate a new service into their infrastructure. Since the service presumably provides them with some value when it operates, the client will expect to be able to recuperate this expense over the lifetime of the service provision agreement. However, if the service fails to operate, or the agreement is prematurely cut short, this opportunity may be lost.

top

10. How can SLAs mitigate the risks with the ASP business model?
SLAs are highly appropriate to the ASP scenario, since they can effectively mitigate the risks involved.

By associating penalties with poor performance, SLAs can mitigate the financial risk to the client that the service will not perform as expected.

An SLA can also be used to associate penalties with the reliability of the service, or the early termination of the service provision agreement. In the event of catastrophic termination of the service, the client could essentially become a creditor of the provider. Although in many cases this will occur due to the bankruptcy of the service provider, a small measure of protection is still provided for the client.

top

SLAng

11. What is SLAng?
SLAng is a language for concrete service-level agreements currently providing support for ASP SLAs. See an introduction to SLAng for more details.

SLAng is defined using an EMOF metamodel, with embedded OCL constraints and natural-language documentation in English. This makes it extremely precise as well as being understandable.

SLAng is designed so that all SLAs expressed in the language are monitorable. It includes semantics for administration, which is the process whereby the parties to the SLA agree what penalties are to be paid. It expresses constraints on the accuracy of reports used in administration that are approximately monitorable.

SLAng can express a number of different types of constraints including: reliability, timeliness, availability, data currency, data recovery constraints and constraints on the lifetime of the agreement. The application of these constraints can be varied according to schedules, the state of the service or the state of an external system that is also monitorable by the parties.

top

12. How can SLAng be used?
Ultimately, the intent is that SLAng be used to express the SLA parts of service-provision agreements and contracts for service provision. Such contracts will state, amongst other things, that the payment of penalties should be in a manner consistent with the SLA interpreted according to the semantics of the SLAng language.

Note that to be legitimate, such contracts will also need to meet legal requirements upon which we are unqualified to comment. Please see Q2 for a further discussion of this.

However, SLAng has not yet been extensively validated, either theoretically or in practice. Therefore we do not recommend that it be used in real SLAs with actual financial significance. The risk is that in the event of a disagreement, the semantics of SLAng may be found to be ambiguous, or the formal parts of SLAng, which are definitive of the language, may be found not to match the informal parts that describe the design intent for the language, and may have been the basis for deciding how to write the SLA. Therefore the SLA will have failed to have captured the original intent of the parties with respect to service provision and can therefore not be described as protectable.

Validation of the SLAng language is the subject of ongoing research and development at UCL.

In the meantime, it may be appropriate to use SLAng to prototype SLAs that may be required in the future. The innovative design of SLAng, incorporating novel research results such as semantics for monitorability, administration and the control of measurement error also make it a useful basis for future research, and the development of SLA languages for other domains.

top

13. Why should I not use SLAng for real SLAs yet?
SLAng has not yet been extensively validated, either theoretically or in practice. Therefore we do not recommend that it be used in real SLAs with actual financial significance. The risk is that in the event of a disagreement, the semantics of SLAng may be found to be ambiguous, or the formal parts of SLAng, which are definitive of the language, may be found not to match the informal parts that describe the design intent for the language, and may have been the basis for deciding how to write the SLA. Therefore the SLA will have failed to have captured the original intent of the parties with respect to service provision and can therefore not be described as protectable.

top

14. Who has been involved in the development of SLAng, and why?
The original version of SLAng was developed by Davide Lamanna as part of the IST project TAPAS. The goals of TAPAS were to produce trusted and QoS-aware middleware for application-service provision.

When Davide quit the project, his work was taken over by James Skene, who is now the principle developer of SLAng. During the remaining lifetime of the TAPAS project and subsequently, James has developed SLAng as the principle topic of his PhD, and the language has undergone very extensive revision, retaining little but its original scope. James is, and Davide was, under the supervision of Wolfgang Emmerich.

The TAPAS project involved a number of partner organisations who also contributed to the development of SLAng. These include Addesso Gmbh., Newcastle University and Bologna University.

top

SLAng in practice

15. What parties need to be involved in an ASP SLA?
SLAng SLAs are mutually monitorable. This means that both the client and provider of the service should be able to observe all events over which constraints are placed or have them observed on their behalf by a party that they trust. The benefit of monitorability is that no party can misrepresent the behaviour of the service to the other without the other knowing.

SLAng achieves mutual monitorability be assuming that the parties are technically adjacent to each other - in other words, separated only by an interface which is reliable and over which messages take a negligable amount of time to pass. At first glance this seems like a problematic assumption, as application services will more usually be delivered across a network operated by one or more internet-service providers, the delay of which is certainly not negligible, and which may not be 100% reliable.

These factors may be reconciled by realising that network-service providers may potentially offer ASP SLAs to the client themselves. In a three-party scenario (client, provider and ISP) a safe system of SLAs, in which parties must only pay penalties as a result of violations of their own responsibilities, is possible to guarantee round-trip time and all other SLAng constraints, using two SLAs, one offered by the ISP to the client, and the other offered by the service provider to the ISP. In fact, an analysis of all possible systems of SLAs in the ASP scenario reveals that this is the only way to insure end-to-end QoS guarantees using SLAs that are at minimum mutually monitorable. If more than one ISP administers the network a chain of SLAs can be used.

This result will probably be a brake on the widespread adoption of SLAng in the future, as ISPs are not currently used to offering ASP SLAs. However, it is our opinion that SLAs that are anything less than mutually monitorable do not adequately mitigate the risks in service provision.

Therefore, the parties that must be involved in an SLA are always a technically adjacent client and service provider. However, the network service provider will perform the role of the ASP service provider in an SLA defined for the client's interface, and the role of the client in an SLA defined at the service provider's interface.

top

16. What requirements must my service meet for me to use SLAng to offer SLAs?
The requirements that a service must meet depend on the constraints that are included in a SLAng SLA.

If reliability constraints are included then the service must benefit from a technical specification of adequate precision and understandability that the parties can agree for any service usage whether it has been successful.

If data-currency constraints are used or reliability constraints are used for a stateful service then the service must implement transactions and define a timeout for all operations. This allows the parties to distinguish between overdue requests that are assumed to have modified the state and those that should have left the state unchanged. This then allows reliability and data-currency assessments on the results of subsequent requests.

top

17. What software infrastructure is needed to use SLAng?
SLAng SLAs do not explicity require any additional software infrastructure to that required to operate the service constrained by the SLA. However, during the administration of the SLA, both the client and the provider are required to produce logs of the behaviour of the service. These logs are reconciled and the reconciled log is used as the basis for the calculation of violations and hence penalty payments. Clearly the production of these logs will require monitoring infrastructure.

When reliability constraints are used, for reasons of practicality, the monitoring infrastructure may also require the ability to recognise service responses not conforming to the specification of the service.

top

18. I am a service client. How can I get an SLA from a provider?
The negotiation of an SLA should be part of the negotiation of a broader Service-Provision Agreement (SPA) or contract which will also include details such as regular fees for the provision of the service and other financial arrangements.

Note that if you receive a service for free then there will be no incentive for the service-provider to provide you with an SLA. Moreover, if the service-provider holds a monopoly on the service being provided, they may also require that no SLA is made, or be able to negotiate much weaker constraints.

Note that if you pay for a service but do not have an SLA, there are other ways to mitigate your risk than the use of an SLA. You may require that your provider submits to due-diligence inspections or other management oversight. Alternatively you may feel that your risk is reduced by your own financial might relative to the service provider, by market forces, or by the provider's regard for their own reputation.

If an SLA is a possibility you should carefully consider what guarantees it offers and how these will be recorded in a concrete SLA that forms a record of the agreement.

In our opinion, the basic purpose of an SLA is to mitigate the financial risk to you the client in the service provision agreement. Therefore, an SLA should describe not only what quality-of-service will be provided to you, but the consequences in terms of penalties for the provider if it is not. Otherwise the SLA offers no value to you the client. If you expect to incur significant integration costs, or assume additional financial risks over the lifetime of the service-provision agreement, should should also consider whether the SLA offers you compensation in the event of the early termination of the agreement by the provider, or as a result of an intolerable deterioration in the provided quality-of-service.

You should also take care to ensure that the guarantees that are being offered are the ones that you want. You will be concerned with the quality-of-service as you experience it at your interface to the network. If an application-service provider is offering you guarantees at their interface to the network, these will not necessarily be useful to you as you will also have to accomodate the performance of the network. Also, you may not be able to monitor these guarantees, meaning that in the event of a disagreement over the delivered quality-of-service, you may find it hard to prove that the SLA has been violated. To obtain monitorable SLAs you may need to deal with the network service provider, who can in theory act as a reseller of the application service at your network interface, and is thus capable of guaranteeing quality-of-service for the complete round-trip.

In considering how the SLA is recorded, you should take care that the agreement is captured in a precise and understandable manner, so that in the event of a disagreement, the original agreement can be interpreted and will state unambiguously what should occur. SLAng aims to support these requirements, and is also suitable for expressing SLAs that are monitorable (as part of the agreement, you agree that the events under discussion are monitorable; this is of course only valid if they really are monitorable). However, SLAng is still undergoing validation, so we do not recommend that you use it for real SLAs. Also, you may need to obtain legal advice from a qualified source before entering an SLA.

top

19. I am an application-service provider. How can I offer SLAs to my clients?
The negotiation of an SLA should be part of the negotiation of a broader Service-Provision Agreement (SPA) or contract which will also include details such as regular fees for the provision of the service and other financial arrangements. As a service provider you may wish to define commodity SLAs that can be offered to different classes of customer. Note that at present we do not recommend that you use SLAng to define your SLAs, since the language has not yet adequately been validated. Also, you may need to obtain legal advice from a qualified source before entering into an SLA.

As a service provider, you should understand that your clients are going to require end-to-end QoS guarantees. If you control the network over which your service is delivered to the client, it will be possible for you to safely undertake to pay penalties if these are not met. Otherwise, it will probably be necessary for you to partner with a ISP, who will resell your service to the client, in the course of which insuring the performance of the network.

As a service provider you have the opportunity either to provide pre-defined commodity SLAs to your clients, or to negotiate these individually. In either case you may have to involve an ISP reseller of your service in the negotiations.

top

20. I am a network service provider. What do I need to know about ASP SLAs?
On the face of it, network service providers, or ISPs, provide services at a lower level of abstraction than application-services layer. However, our theoretical results indicate that the only way in which end-to-end QoS guarantees may be provided to the client of an application service in a manner that is both safe and monitorable is by the ISP reselling services.

Therefore, ISPs should be prepared to act as service marketplaces. You, the ISP will offer SLAs to clients on the edges of your network. In turn, you will enter into SLAs guaranteeing that service providers connected to your network will provide you with adequate QoS to service your clients. This may be done on a bulk basis, or using SLAs paired with your client SLAs.

You will wish to monitor the performance of the services provided to you, and the behaviour of clients, in order to monitor your SLAs. You will therefore have to consider how monitoring technologies can be embedded in the edges of your network.

Where services must be delivered across multiple networks, you will need to enter into SLAs with the networks with which you connect.

top

21. What happens when parties disagree about an SLA?
Parties can attempt to disagree about an SLA in a number of ways.

Parties may disagree about the original meaning of the SLA. If this occurs, and the SLA was expressed using SLAng, you should refer to the original definition of SLAng, which should precisely and unambiguously document the meaning of the SLA.

Parties may disagree about what happened that is relevant to the SLA. Since SLAng SLAs are monitorable, parties cannot misrepresent what happened without their partner being aware of it (if they have been paying attention). Therefore the likelihood of this happening is reduced.

In any case, the parties may be able to resolve their differences by referring to the original SLA document, by exchanging evidence, or through negotiation.

Note that in the event of an irreconcilable disagreement, the parties will have to achieve satisfaction through some mechanism, perhaps legal (although we cannot advise on legal matters), external to the SLA.

top

22. SLAng is only monitorable. How can I force another party to pay a penalty if they are in violation of a SLAng SLA?
First, it is a mistake to think that an SLA compels anybody to do anything. If the SLA is a contract, or part of a contract, then the law may apply pressure to a party as a result, although we are not qualified to advise on this.

What SLAs do do is capture an agreement in a precise way. SLAng insists that the things you agree on in a SLAng SLA are monitorable, so you can see whether the other party is meeting the agreement. However, they are only monitorable by you, as a party to the SLA, and not necessarily by anyone else. If you therefore seek to prove that your account of events is true and that account of your peer in the agreement is false, then the only assistance you will get from the agreement is the ability to assert that you were capable of gathering such evidence, not that you have necessarily done so faithfully.

SLAng SLAs are therefore not inherently arbitratable. However, they do allow you to detect cheating partners, and hence make cheating less desirable. Also, if you can provide access to your monitoring infrastructure to a third party in a manner that they trust, they will be able to back your claims in the event that your partner in the agreement tries to cheat.

top

23. I can't express what I need to in SLAng. What now?
Although ASP services all look very similar according to our definition, SLAs for such services can still be very various. This is because the requirements that the client has for a service may vary according to conditions that are external to the service. Enabling the description of all of these conditions would require a general-purpose modelling language, such as the combination of EMOF, OCL and English that is used to define SLAng. This would greatly increase the complexity of the language specification, so we have so far avoided providing these facilities.

Therefore, you should consider either extending SLAng or implementing a new language. See the answers to Q25. How can I extend SLAng? and Q26. How can I implement languages for other domains?

top

SLAng in research

24. How can I reuse the theory underpinning SLAng
Read the academic papers related to SLAng and use citations in the normal way. We would suggest that the most significant contributions of this work are:
  • The identification of risk mitigation for the client as the principle purpose of an SLA.
  • The elaboration of an explicit set of requirements for SLAs.
  • The adoption of a precise yet understandable meta-modelling formalism for the definition of the language.
  • The identification of monitorability as an important requirement for SLAs, the provision of a method for the analysis of monitorability in systems of SLAs for any given situation, and the identification of the most monitorable system of SLAs for the three-party ASP scenario.
  • An extension of the theory of monitorabilty to accomodate measurement error, resulting in the notion of approximate monitorability.
  • The definition in SLAng of a set of constraints that are monitorable.

top

25. How can I extend SLAng?
SLAng is defined using a combination of three languages, EMOF, OCL and English. Under the Creative-Commons Attribution 2.5 license you may produce derivative works from the SLAng language specification provided you acknowledge UCL as the author of the original work.

You may wish to extend SLAng for two main reasons. SLAng may not be able to express variations in constraints according to some external conditions which you will need to model. Alternatively, you may wish to express SLAs over different kinds of services.

This level of expressiveness is available at the meta-level, due to the languages chosen to define SLAng. Therefore, if you require more expressivity then we suggest you define an extension to the language. In principle, this should be no harder than defining the conditions that you required in SLAng, if SLAng were totally general purpose. You will be obliged to define your requirements initially in terms of types of objects and events in the language extension, and then in terms of particular objects and events in an actual SLA. However, taking a more general approach will also allow you to reuse your extension across multiple SLAs, if this is beneficial.

Further discussion of the approach taken to define SLAng is available in the introduction to SLAng. You should also review the academic literature on the subject.

If you are extending SLAng for ASP constraints, you should consider how the extension will effect the protectability of any agreements expressed in the extended language. Will the agreements still be monitorable, and how will measurement error be handled? Also, you should be careful to model the semantics of any changes that you make to the syntax of SLAng, or the meaning of these elements could be brought into question in the event of a disagreement over an SLA.

top

26. How can I implement SLA languages for other domains?
Languages for SLAs for other domains may be implemented in a number of ways:
  • You may choose to extend SLAng.
  • You may choose to use the same approach used to define SLAng, but create a completely new language.
  • You may choose to use some other approach to defining the language.

The advantages to extending SLAng include the possibility of reusing some generic parts of the specification, such as the general handling of measurement error and the semantics for SLA administration, which are likely to be relevant to all SLAs that are at best monitorable, but not inherently arbitratable, as is the case for ASP SLAs. You will also accrue benefits due to the approach used to define SLAng.

The advantages to adopting the same approach used to define SLAng are a good deal of precision in the definition whilst still retaining a tolerable level of understandability. Any language specification produced in this way will also be machine readable and a potentially useful artefact in the generation of software, for example, using the code-generation capabilities of the UCL MDA tools.

The advantages to using a different approach will be the opportunity to avoid some mistakes that we may have made. We don't know what these are however, so this is not guaranteed, and you will also have the opportunity to make new mistakes of your own.

top

The SLAng open-source project

27. How is SLAng licensed?
The SLAng language specification is licensed under a Creative Commons Attribution 2.5 license. The copyright holder is UCL. This means that you may use the specification commercially, and you may also prepare derivative works provided that you acknowledge UCL as the author of the original work.

Clearly any extended or refactored language for SLAs derived from the specification will be a derived work. It is not clear whether SLAs expressed using the language should be considered to be derivative works. However:

  • You are not required to make derivative works public.
  • In order to be unambiguous, SLAs should reference the specification of the language in which they are written (otherwise after making the agreement, the parties could disagree about how the agreement should be interpreted). If this specification is derived from SLAng it must acknowledge UCL as the authors of the original work. We therefore consider the reference to the specification in the SLAs to be adequate acknowledgement of the authorship of the original language if the SLAs are considered to be derivative works. If such a reference is not included then the language of the SLA is either not derived from SLAng or you are writing a bad SLA which should be not be associated with SLAng.
  • The exception to the previous point is: if you include parts of the SLAng language specification in an SLA, the SLA is clearly a derivative work.

top

28. What software is distributed for SLAng?
At the time of writing, we make available two versions of an editor for SLAng SLAs. Both versions are automatically generated from the SLAng language specification using the UCL MDA tools. One version provides a user-interface using the Java Swing library. The other version is a plugin for the Eclipse IDE.

top

29. How is the software for SLAng licensed?
The SLAng software is licensed under the Mozilla Public License (MPL), with an option to relicense to GPL or LGPL. The copyright for the software is owned by UCL. Under the MPL you may incorporate the software into new applications, providing that you acknowledge UCL as the author of the original software. On a per-file basis, you must also make publicly available any modifications that you make to the program source code, although you do not have to make public code that you integrate with the software except where otherwise required to do so.

We do not regard programs designed to operate with the SLAng language as works derived from the SLAng language specification for the purposes of interpreting the Creative Commons license. The exception to this is any translation of the specification which is then used as a definitive source for the interpretation of an SLA, even if that language may be considered to be a programming language. This means that you may write software that is not derived from our software, but is designed to work with SLAng SLAs, without any licensing restrictions, provided that software does not supercede the role of the SLAng language specification.

top

30. What software is planned for SLAng?
In the future we may look at developing monitoring software that is compatible with the constraints in SLAng SLAs. If you are interested in this, please contact us.

top

31. How can I get involved with the development of SLAng?
Please contact us.

top

32. How can I support the SLAng project?
SLAng is currently supported by research project funds. Consequently its emphasis is on academic research. If you are interested in cooperating with UCL to extend this work, possibly within the framework of future research projects, then we will be pleased to hear from you.

At present the SLAng open-source project does not support full-time developers. If you are interested in commercialising SLAng technology within the framework of the open-source project, then we will also be pleased to hear from you.

The SLAng project does not require piecemeal donations at present.

top