1 General Questions

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 ESA PL) 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.

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 ESA PL the Source Code must be provided to each recipient in addition or made freely accessible. There is no obligation to distribute a documentation.

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

Generally speaking the license becomes effective upon Distribution of the Software to a third party. 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.

4. Can we combine code coming under Mozilla 1.1 with ESA-owned code and licence the result under any of the ESA-PL types?

Combination with…

ESA-PL No Copyleft: yes

ESA-PL Weak Copyleft: yes

ESA-PL Strong Copyleft: no

Both the Mozilla MPL v1.1 and the ESA-PL Weak Copyleft require that the source codes remain separated in different files. Relicensing of the result under the applicable ESA-PL 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.

5. How do you implement compatibility between ESA-PL and other Open Source licence types using Appendix A? What must be kept in mind when doing so?

You need to add an Appendix A to the ESA-PL explicitly naming the licenses that should be compatible. The licenses should be named as precisely as possible, including version numbers (e.g. “GPLv3 and any later version”, “GPL (all versions) and any later version”, “GPLv3 only”).

Please keep in mind that license compatibility allows a change of license terms and that such change is a one-way track. For example, if you provide compatibility with the GPL, a contributor can “switch” the software from ESA-PL to GPL license terms. Once the software has been “switched” to GPL, all later modifications and enhancements stay licensed under the GPL. Since the GPL is not compatible with the ESA-PL, the license switch cannot be reversed.

Compatibility should only be provided with similar or more restrictive licenses. For example, if the ESA-PL Strong Copyleft were compatible with the MPL, the software would effectively be subject to a weak Copyleft license (since any user could “switch” from ESA-PL Strong Copyleft to MPL). However, this is probably not the intention of the original author, who put the software initially under a strong Copyleft license.

Note: Appendix A with the list of compatible licenses should be decided upon by the competent ESA committee – and not on a case by case basis by the TO.

6. Is ESA-PL 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 ESA-PL 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 ESA-PL 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 ESA-PL 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….).

7. Must the ESA Transfer Board (ATB) approve the distribution of the software to all world countries before being able to license this software under ESA-PL 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, not only to the ESA-PL.

2 Questions regarding specific clauses

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.

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.

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.

4. Sec. 2.2 Patents

What is the practical meaning of this clause?

If a company releases software under the ESA-PL, 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 ESA-PL.

Likewise, any user of ESA-PL 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 ESA-PL 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 ESA-PL license commentary.

5. Sec. 2.2: Patents

Who grants the patent license and for which duration?

The license grant is perpetual.

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.

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 ESA-PL, 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 ESA-PL (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 ESA-PL is recommended.

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 ESA-PL 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 ESA-PL permits the linking of ESA-PL licensed libraries with proprietary software. The result can be a “black box” product, with the ESA-PL library incorporated, but no possibility for the user to modify or exchange the incorporated ESA-PL 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 ESA-PL library (however, such exchange of the library being solely at the user’s risk). This is usually not an issue if the if the ESA-PL 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 ESA-PL.

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.

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.

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.

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.

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 can not 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.