Scope

This page collects Frequently Asked Questions (FAQ) and related answers with respect to the legal text of the ESA Software Community License (ESCL) as long as the regional constraint of the ESCL is neither modified nor removed. It should be noted that, due to its regional constraint, the ESCL is NOT an Open Source license as it limits use of the software to the Territory of ESA Member States (compare 1.13, 2.1, 2.2, 3.1, 3.4). 

Questions and Answers

1. General Questions

Q1.1 - There is no provision on delivery of the software. When and how will the delivery take place?

There is no provision on delivery of the software, since there is no obligation to distribute the software under the license. Delivery terms (when, how), additional warranties and even maintenance obligations and service levels (cf. Sec. 6 ESCL) can be agreed on in separate contracts. It is recommended not to amend or modify the license text itself, but to provide such clauses in additional and separate contracts.

Q1.2 - Must the Delivery include the Source Code and Object Code of the software together with the corresponding documentation?

Initially it is possible to only distribute the software in Object Code form. However, according to Sec. 3.3 ESCL the Source Code must be provided to each recipient in addition or made freely accessible. There is no obligation to distribute a documentation.

Q1.3 - When does the license start? Is there a need to sign the license?

Generally speaking the license becomes effective upon receipt of the Software. Once you exercise a right under the license, e.g. by using, modifying, distributing the Software, you implicitly agree to the license. That is not specific to the ESCL, but a general feature of Open Source licenses. There is no need to provide clauses for a specific effective date.

If Delivery terms (e.g. “software and source code have to be delivered on 1.1.2013”) are important to the parties, they can be agreed on in separate contracts. It is not recommended to amend or modify the license text itself for this purpose.

Q1.4 - Can we combine code coming under Mozilla Public License 1.1 with ESA-owned code and license the result under any of the ESCL types?

Combination with…

ESCL No Copyleft: yes

ESCL Weak Copyleft: yes, provided (*) is implemented

ESCL Strong Copyleft: no

(*) Both the Mozilla MPL v1.1 and the ESCL Weak Copyleft require that the source codes remain separated in different files. Relicensing of the result under the applicable ESCL is permitted, provided that the MPL-covered code remains licensed under the MPL and the formal requirement of the MPL (e.g. notification) are observed.

Q1.5 - How do you implement compatibility between ESCL and other Open Source licence types?

Since the ESCL is not an Open Source license (due to its regional constraint), you have to check whether you could combine your Open Source component with “commercial” software.

Q1.6 - Is ESCL protecting against source code obfuscation? It is not uncommon in Java commercial software to use automated obfuscation tools to transform the source code. While still usable and compilable, the source code is no longer understandable / modifiable by a human. While unethical, it appears to be legal. Should the ESCL be modified to protect against it?

Sec. 1.9 defines the “Source Code” as the “usually human readable form of the Software […] in which modifications are made”. It can be argued that obfuscated code is neither human readable nor the form in which the modifications are made – actually, the obfuscation is sort of an additional compilation step after the modifications were made. The wording in Sec. 1.9 ESCL is similar to the wording of the GPL and the common understanding is that obfuscated code is not GPL compliant. So from this point of view the ESCL already protects against obfuscation. Further clarifications are harder to draft, since it is unclear to define “obfuscated” code more precisely (e.g. what about PERL code….). 

Q1.7 - Must the ESA Transfer Board (ATB) approve the distribution of the software outside ESA Member States countries before being able to license this software to a company of an ESA member state?

Yes. The ESA Convention gave the obligation to establish rules under which Technology can be transferred outside the Member States, always bearing in mind the “peaceful purposes” of the Agency. Technology Transfer outside the Member States of ESA, meaning licensing Software under a “non-controllable” (as in territory) Open Source License therefore always has to be authorised or recommended by the Agency Technology Transfer Board (ATB). You can find further information on this topic and the rules of the ATB in the ESA Rules on Information, Data and Intellectual Property, Chapter IV, No. 2. Note: This rule is applicable to all Software which shall be licensed under an Open Source License, including an ESA Public License.

2. Questions regarding specific clauses

Q2.1 - Sec. 1.1 Definitions - Is the “Contributor” also the licensor?

“Licensor” is anyone that distributes the software to a third party (to the licensee). A “Contributor” is anyone that creates or modifies the software. A Contributor can also be a Licensor, and vice versa. See also Sec. 1.1.1 of the ESA License Commentary.

Q2.2 - Sec. 1.5 Definitions - Is ESA always the Licensor?

Not necessarily. “Licensor” is anyone that distributes the software to a third party. If you receive the software from ESA, ESA is the Licensor. If you subsequently distribute the software to a third party – which is permitted under Sec. 2.1, 3, since Open Source Software can be freely distributed –, you are the Licensor.

Q2.3 - Sec. 1.9 Definitions - Why „and/or“? Why is this not only„and“?

“Software” means the software Distributed under this License by the Licensor, in Source Code and/or Object Code form. Software may (initially) only be distributed in Object Code form, see in Sec. 3.3.

Q2.4 - Sec. 2.2 Patents - What is the practical meaning of this clause?

If a company releases software under the ESCL, Sec. 2.2 assures that the company automatically grants a license to all of the company’s patents to the users - to the extent that such patent license grant is necessary for the users to exercise their rights under the ESCL.

Likewise, any user of ESCL licensed software can be sure that no contributor to the software requires him to enter into additional patent license agreements or pay additional patent license fees. For example, a company cannot release software under the ESCL and then claim for additional patent license fees for the use of such software.

For a more detailed discussion of Sec. 2.2, see the ESCL license commentary.

Q2.5 - Sec. 2.2: Patents - Who grants the patent license and for which duration?

The license grant is perpetual. The license is granted by all Contributors to the Software. As a result, the Software might still infringe third party patents (i.e. patents of parties not involved in the development of the Software).

Q2.6 - Sec. 2.3: Trademarks - There is a restriction on the use of ESA trademarks. This seems to be deemed a limitation of liability. Furthermore, this may raise some issues as the concept is subjective.

Sec. 2.3 is not intended as a limitation of liability. The provision is merely a clarification that no trademark licenses whatsoever are granted. The concept of “trademark infringements” is subjective, as there is no objective way to define an infringing use of a trademark, but this is rather a consequence of statutory trademark law and not due to the wording of Sec. 2.3. For example, you should clearly not advertise the Software or your products using the Software with the ESA logo.

Q2.7 - Sec. 3.2.3 External Modules - Can External Modules only be considered as such if they are not run from separate address spaces? What is meant by "separate address spaces"?

“Running in separate address spaces” are separate programs or processes only loosely related to each other. For example the Apache Web Server and the MySQL database usually run in different address spaces as separate processes, but are of course interfacing with each other. Such combination would fall under the “External Modules” exception of Sec. 3.2.3. However, a dynamically or statically linked library usually runs in the same address space as the target software, thereby not falling under the “External Module” exception.

Please note that Sec. 3.2.3 is found in all versions of the ESCL, even in the Strong Copyleft version. Sec. 3.2.3 clarifies that two separate programs interfacing with each other (e.g. applications interfacing with an external database server) do not trigger the Copyleft effect. We felt such clarification was necessary, since this is a disputed issue e.g. under the GPL.

Please note that the Weak Copyleft version of the ESCL (Sec. 3.2.4) permits many more forms of combinations and library usage without triggering a Copyleft effect. For example, the Weak Copyleft version permits static and dynamic linking and even source code integration of third party modules and libraries without triggering a Copyleft effect.

If you are looking for a possibility to relax the requirements for linking external libraries or modules, the Weak Copyleft version of the ESCL is recommended.

Q2.8 - 3.2.4e Relinking Option - Does this option bring the Weak Copyleft licence closer to Strong Copyleft?

The relinking option is a clause that makes it a bit harder to combine or link ESCL covered libraries or modules with proprietary software. A similar clause is found in the LGPL.

The purpose of this clause is as follows:

The Weak Copyleft version of the ESCL permits the linking of ESCL licensed libraries with proprietary software. The result can be a “black box” product, with the ESCL library incorporated, but no possibility for the user to modify or exchange the incorporated ESCL library.

The relinking option tries to give the user more freedom in such scenario. The proprietary software must provide some kind of mechanism (“relinking possibility”) that allows the user to run the proprietary software with a different or modified version of the ESCL library (however, such exchange of the library being solely at the user’s risk). This is usually not an issue if the if the ESCL library is dynamically linked – then the user can simply exchange the library file. If the library is statically linked, the software must provide some other possibility for the user to exchange the library.

If the “relinking option” is necessary, relevant or even desirable for ESA should be decided by the Contracts Officers and Technical Officers on a case-by-case basis. Generally, the relinking option is only relevant if ESA provides libraries that are intended to be used as components of other software under the ESCL.

Q2.9 - Sec. 3.3a Communication of the Source Code - Does recipient mean a sublicensee?

The “recipient” is the same as the licensee (i.e. the person that the Software is Distributed to), meaning anyone who receives a copy of the software.

Q2.10 - Sec. 3.4 Service Provision - What does Service Provision mean?

Service Provision means that someone provides a service e.g. over the web, as SaaS (software-as-a-service) or as ASP (application service providing). In these cases the software is not physically distributed, but the users can usually take advantage of the functionality of the software by remote access, i.e. over the web or other networks. As there is no distribution of the binary or the source code of the software, the obligations requiring a “distribution” of the Software (e.g. to grant a license or to provide the source code) do not apply. This method has become known as a “service provision loophole” and is found in most Open Source licenses, including the GPL. By inserting the Service Provision Clause into the license, the loophole is closed and it is made sure that the Source Code and modified versions become available also where the Software is only used for service provision.

Q2.11 - Sec. 3.5 Dual Licensing - What does Dual Licensing mean?

“Dual Licensing” means that software is released under one or more different licenses at the same time. For example, software can be released under OSS and proprietary license terms or under multiple OSS license terms at the same time – e.g. under both the GPL and MPL licenses.

The original author of a work, such as software, owns all rights in his work. In the event of a non-exclusive license grant (e.g. under the GPL) he retains his rights – and is therefore free to grant additional and/or different rights and licenses. This is of course only applicable to the author’s own original developments. He cannot grant additional rights to other authors’ contributions (without consent of all contributors). Furthermore, the author cannot “revoke” rights already granted e.g. under the GPL. He is merely allowed to license the same software again under different license terms, e.g. in addition to the GPL-licensed version. Dual licensing might result in “fragmentation” of the software. Since the software is released under multiple licenses, modifications and changes contributed to one version of the software (under license X) might not be incorporated or available for legal or practical reasons in the other version of the software (under license Y), thus resulting in different “branches”.

Permission for Dual Licensing must be given by the relevant copyright holders / authors.

Q2.12 - Sec. 5.3: Warranty - Sec. 5.3 excludes any liability. Would this kind of provision be valid under e.g. German law?

Validity of the limitation of liability and limitation of warranty clauses are always questionable. However, since the software is provided free of charge, the clause is valid under German statutory limitations (BGB). This might be treated different though in any other national law, esp. non-European legal provisions.

Q2.13 - Sec. 7 Infringements - Why is this clause not reciprocal?

This clause has not been written in a reciprocal way as there is no legal need for reciprocity. There are two main reasons for that: first, every Licensor/Contributor is also a licensee (“You”) and therefore obliged to give notification under Sec. 7 (with the possible exception of the original creator of the Software). Second, ESA or any other licensor, who distributes the Software always has to find a solution to stop the infringement. This means that automatically also the “first” distributor of the software has to inform the recipients of the License if he becomes aware of infringements insofar as this is possible. But the “first” distributor cannot give the information of an infringement to any user before himself, he must (and therefore only has the obligation to) cease any infringement by his distribution according to statutory law.