European Space Agency Public License (ESA-PL) Commentary – v2.3

European Space Agency Public License (ESA-PL) Commentary – v2.3 

There are three versions of the ESA-PL licenses, each with a different Copyleft scope, but otherwise identical provisions: 
    • European Space Agency Public License (ESA-PL) – Strong Copyleft (“ESA-PL Strong”)
    • European Space Agency Public License (ESA-PL) – Weak Copyleft (“ESA-PL Weak”)
    • European Space Agency Public License (ESA-PL) – Permissive (“ESA-PL Permissive”)
The licenses only differ in Sec. 3 where the wording is adapted to the Copyleft scope of the respective license. 
Generally the ESA-PL Strong is comparable to the GPL/AGPL license, the ESA-PL Weak is comparable to the MPL license and the ESA-PL Permissive is comparable to the BSD license.
Several clauses are found in similar form in existing Open Source licenses. We tried to disclose such similarities as far as possible in this document to help clarifying the intention and the scope of the respective clauses.

1.1 Definitions (Sec. 1)
1.1.1 “Licensor”, “Contributor”, “You”

The License distinguishes between the “Licensor” and the “Contributor”. 
“Licensor” is anyone who distributes Software under the License to “You”, the licensee. E.g. a Licensor is someone who gives You a copy of the Software or makes the Software available to You for download. In a legal sense, the License agreement is therefore concluded between You and the Licensor.
“Contributor” is anyone who initially creates or later modifies the Software. The Licensor can be a Contributor (e.g. someone distributing a modified version), but he must not necessarily be a Contributor. The Licensor is not a Contributor if he distributes an unmodified version.

1.1.2 “Distribution”
Distribution is a key term in any Open Source license, in particular since the Copyleft obligations are tied to the act of Distribution. “Distribution” is broadly speaking any act of conveying, transmitting or spreading copies of the Software, as Source Code or Object Code. The provision of software-as-a-service – i.e. granting access or making available functionality without conveying copies – is not to be seen as “Distribution”, as no copy of the software as such is distributed. Sec. 3.4 ESA-PL Strong explicitly deals with service provision.

1.1.3 “Software”, “Modification”, “Contributor Version”
“Software” means the specific version of the software as distributed by the Licensor to You. 
“Modification” means any work based on the Software or modifications (e.g. changes) of the Software.
”Contributor Version” means the specific version of the software on which the Contributor’s modifications are based. 

1.1.4 “Source Code”, “Object Code”
These definitions correspond with the MPL 2.0 and GPLv3. The “Source Code” includes the associated documentation and comments. “Object Code” is any form of distribution other than Source Code. 
We chose the term “Object Code” instead of “executable” as the more accurate term, since not every kind of object code is an executable in the technical sense (e.g. a compiled library is object code, but not an executable).
“Source Code” refers to the “preferred form in which modifications are made”. For example, if you use a “meta language” such as IDL or WSDL which itself will be compiled into another language’s source code, the “preferred form for modifications” would generally be the IDL or WSDL code, not the generated code. Likewise, if a C source code is compiled to assembly language, the assembly language source code would not be the “preferred form for modifications".

1.2 Grant of Rights (Sec. 2)
1.2.1 Copyright (Sec. 2.1)
Sec. 2.1 provides the license grant under Copyright. In accordance with European Copyright principles, we have set out the specific rights granted by the License in more detail than it is done in US-based licenses.
The rights granted through the license are granted by the Licensor and in addition by each Contributor in respect of its modifications or contributions. The Licensor is able to “pass through” the rights granted by each Contributor since the rights are sub-licensable. This redundant grant of rights aims to minimize the risk of “missing links” in the license chain.
The license entitles the licensee to use the Software for any and all purposes. Any usage restriction, e.g. to peaceful purposes only, would not be OSI compliant.
The license grant is perpetual and irrevocable. However, termination pursuant to the termination clause (e.g. in case of breach with the terms of this License) in Sec. 8 results in a termination of the copyright license as well.

1.2.2 Patents (Sec. 2.2)
The patent license is granted by each Contributor in respect of the Contributor’s Modifications and the Contributor Version – i.e. the version of the software created by the Contributor (the “Patent Licensed Version”). 
Corresponding to the GPLv3, the patent license therefore comprises the whole software - including the contributions of the licensor, but not limited to the contributions of the licensor. 
For example, a Contributor adds a steering module which implements a patented algorithm (the “Contributor’s Modifications”) to an existing satellite OS software (the “Contributor Version”), resulting in a new version of the software (the so-called “Patent Licensed Version”). The License requires the Contributor to grant two different patent licenses: one license is granted to his patents implemented by the steering module (i.e. patents pertaining to the Contributor’s Modifications) and, in addition, the License requires the Contributor to grant another license to his patents – if any – that would be infringed by the pre-existing satellite OS software (i.e. patents relevant to the entire Contributor Version). This is the intended result: if the patent license grant would be restricted to the Contributor’s Modifications only (i.e. a patent license only in respect of the added module), the Contributor could – regardless of his contribution and distribution of the software – claim that recipients would be infringing his patent rights pertaining to the rest of the software.
The license grant includes patents held by the Contributor at the time he Distributes his contribution and additionally it also includes all subsequently acquired patents pertaining to his Contribution (cf. definition of “Patent Claims”: “[…] any patent claim(s), owned at the time of the Distribution or subsequently acquired […]”). As a result, a Contributor cannot “re-appropriate” his contributions, once distributed under the ESA license, by later applying for patents pertaining to his contribution. He is deemed to grant a license to such subsequently acquired patents as well.
The scope of the patent license is limited to the version of the Software created by the Contributor (the “Patent Licensed Version”). The patent license grant does not necessarily cover later modifications of the version made by the Contributor. The license scope is restricted to the then-current state and functionality. This has practical consequences: it can result in a restriction of modifying or creating works based on the software which results in a restriction of the rights granted under Copyright in Sec. 2.1. Such restriction is common in Open Source licenses (in fact, no existing OSS license requires a broader grant of patent rights) and, regardless of the limiting effect, OSI compliant.
However, patent licensing results in uncertainties for users of the Software. In particular, modifications and further development of the Software might require additional patent licenses, since the scope of the patent license grant is restricted to the original state and functionality. Generally speaking, once patents are involved, careful legal due diligence is necessary and highly recommended when modifying and distributing modified software. 
To make the users aware of patent issue, the License requires disclosure of any patents involved (Sec. 4.5).
Sec. 2.2 tries to clarify the patent license scope by explicitly mentioning some use cases NOT covered by the patent license grant:
    • Not covered are infringements resulting “only as a consequence of further modifications”. As a result, modifications extending the scope or functionality of the software beyond the initial state could result in patent infringements, depending on the scope of the patent and the modifications in question. Unfortunately there is no easy way to determine if a modification extends beyond the scope of the patent license grant.
 
    • A combination of the software with other software or hardware usually extends the scope or functionality. However, if such combinations were “intended” by the Patent Licensed Version, the patent license scope covers such combinations. For example, if a Contributor creates a general purpose library, such library can be seen as intended to be combined with other software. Nevertheless  it can be problematic to determine whether a specific combination was intended which can lead to uncertainty of the extension of the patent license.

    • A re-implementation of a patented algorithm – i.e. not based on the Contributor’s source code – is not covered by the patent license (“a Modification under Patent Claims in the absence of the Contributor’s Modifications”).

    • Use of the patented code in other software not related to the original Patent Licensed Version is not covered by the patent license (“by a combination of the Contributor’s Modifications with software other than the Patent Licensed Version or Modifications thereof”).

The wording of Sec. 2.2 and the exceptions basically correspond with the MPL 2.0 patent clause.

1.2.3 Trademarks (Sec. 2.3)
The trademark license grant corresponds to Sec. 6 of the Apache license. Trademarks of a Licensor may be used only to the extent reasonably necessary for exercising rights under the License and describing the origin of the Software (i.e. naming the Licensor as the Licensor). 
In particular, if someone creates Modifications of the Software, he must not use ESA’s (or any other Licensor’s) names or trademarks to state or imply that the Modification is endorsed or created by ESA.

1.3 Distribution
1.3.1 Copyleft / Permissive (Sec. 3.1)
There are three versions of the ESA-PL licenses, each with a different Copyleft scope:
    • Strong Copyleft (GPL/AGPL-style)
    • Weak Copyleft (MPL-style)
    • Permissive / Non-Copyleft (BSD-style)
The difference between the licenses is the distribution and Copyleft clause in Sec. 3.1: 
    • either a “strong” Copyleft clause in the ESA-PL Strong or a limited Copyleft clause in the ESA-PL Weak 
    • or a permissive, non-Copyleft clause in the ESA-PL Permissive. 

1.3.1.1 Copyleft and compatibility clause (ESA-PL Strong and ESA-PL Weak)
Sec. 3.1 sets out the general Copyleft principle in the ESA-PL Strong and ESA-PL Weak. Generally, all Distribution of the Software (including Modifications) has to be under the terms of the License. 
Distribution can be under the current or any later version of the License, provided the later version is an “official” version released by ESA as the license steward (Sec. 10.1). However, a Contributor may decide to prohibit Distribution under later versions of the License (for example, the MySQL project explicitly chose not to distribute code under the GPLv3 but only under GPLv2). 
Sec. 3.1 ESA-PL Weak also includes a compatibility clause. Distribution may be under the terms of the ESA-PL Weak, but also under the terms of a compatible license, as named in Appendix A to the ESA-PL Weak. Compatible licenses are currently the GNU General Public License (GPL) version 2 and any subsequent version and the CeCILL version 2 and any subsequent version.

1.3.1.2 No Copyleft (ESA-PL Permisive)
Under the ESA-PL Permissive, further Distribution of the Software (including Modifications) can be under any license terms (i.e. no Copyleft). 
However, a notice obligation must be observed by the Distributor: Notice must be given of the use of the (original) Software and the applicability of the ESA-PL Permissive to the original Software. As a result, a company can e.g. use the Software as a basis for its own developments, but needs to notify its customers that ESA-PL Permissive-licensed Software was used.
The Distributor must make best efforts to ensure that the aforementioned notification obligation is passed through to its licensees and recipients. This obligation corresponds to Sec. 5.3.2 CeCILL-B. Note that due to this obligation the license is not a true „free“ license, since further license agreements are restricted (although only to a very limited extent) – the license agreement concluded by the Distributor needs to address the notification obligation related to the Software. However, this is a very lightweight restriction on the part of the Distributor and should not discourage the use of the Software.

1.3.2 Copyleft Exceptions (Sec. 3.2 ESA-PL Strong and ESA-PL Weak)
Sec. 3.2 provides certain explicit exceptions to the Copyleft as set out in Sec. 3.1 of the ESA-PL Strong and the ESA-PL Weak, thereby clarifying and limiting the Copyleft effect. 
In particular, Sec. 3.2.4 ESA-PL Weak results in a “weak” Copyleft comparable to the MPL. 

1.3.2.1 Compilations (Sec. 3.2.1 ESA-PL Strong and ESA-PL Weak)
This is a clarification of the Copyleft scope suitable for both “strong” and “weak” Copyleft schemes. Sec. 3.2.1 clarifies that mere compilations (e.g. placing the Software on a medium like a CD or DVD along with other software for the purpose of distribution – for example the Debian or Ubuntu Linux distribution) are not subject to the Copyleft effect. Other software distributed on the same medium as the Licensed Software will not be “infected” by the License terms. The wording corresponds to Sec. 5 GPLv3.

1.3.2.2 System Libraries (Sec. 3.2.2 ESA-PL Strong and ESA-PL Weak)
In software development it is necessary to utilize standard libraries and components provided by e.g. the compiler (like the C stdlib), the operating system or the runtime environment / object code interpreter (e.g. the Phyton or PHP runtime environment). In particular if such components are statically linked to the software, they would in principle be subject to the Copyleft effect. For example, if the C stdlib is linked to the Software, Copyleft requires the resulting combination, including the C stdlib, to be licensed under the License.
This is neither necessary nor intended by the License. Therefore Sec. 3.2.2 provides an explicit “System Library” exception. Operating System and Compiler components are excluded from the Copyleft scope. The wording basically corresponds to Sec. 3 GPLv2 / Sec. 1 GPLv3.

1.3.2.3 External Modules (Sec. 3.2.3 ESA-PL Strong and ESA-PL Weak)
This Copyleft exception for interfacing with external modules is based on Sec. 5.3.3 CeCILL and aims to clarify ambiguities posed by strong Copyleft licenses, in particular the GPL, regarding the question of “mere aggregates” – i.e. whether a combination of software by means of mere interfacing results in a Copyleft-relevant “combination” or merely results in “separate and independent works”.
Sec. 3.2.3 clarifies that the interfacing of Software with external modules – defined as modules running in separate address spaces – does not trigger the Copyleft effect. Such external modules can be distributed under different license terms. 
The definition of “external modules” in Sec. 3.2.3 is highly technical. “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. However, a dynamically or statically linked module usually runs in the same address space as the target software, thereby not falling under the “External Module” exception.

1.3.2.4 Weak Copyleft / Combinations (Sec. 3.2.4 ESA-PL Weak)
Sec. 3.2.4 ESA-PL Weak further reduces the Copyleft scope, resulting in a “weak” Copyleft comparable to e.g. the MPL license.
Generally, Sec. 3.2.4 allows a combination of ESA-PL Weak-licensed software with other software to be distributed under any license terms, provided that the ESA-PL Weak remains applicable to the original software. Changes to the original software have to remain licensed under the ESA-PL. 
The ESA-PL Weak-licensed software or code is called the “Covered Code”. This Covered Code can be combined or linked with additional software or code, called the “External Code”. The result of such combination is called the “Combination”.
There are different requirements for the Distribution of such “Combination” as Object Code and Source Code:
    • If the resulting “Combination” is distributed as Source Code, the Covered Code remains licensed under the ESA-PL Weak, while the Source Code of the External Code may be licensed under different terms. As a result, with regards to the original Software (the Covered Code) the Copyleft remains applicable.
    • If the resulting “Combination” is distributed as Object Code, such distribution may be under any license terms. Since the Object Code is usually one single executable, Covered Code and External Code cannot be distinguished and the resulting, combined Object Code cannot be subject to multiple license terms. However, any Distribution in Object Code form requires additional disclosure of the Source Code of the ESA-PL Weak-licensed Covered Code pursuant to Sec. 3.3.
The wording “combining or linking […] with additional code or software” aims to clarify that modifications of the original Software in themselves (other than adding additional, separated code or software) are not subject to the exception of Sec. 3.2.4 and remain subject to the Copyleft effect. For example:
    • If the ESA-licensed Software is a library or component, linking the library with other software is subject to Sec. 3.2.4: the resulting Combination can be distributed under different license terms. However, changes to the library itself, not being an “addition” of external code to the library (or, vice versa, an “addition” of the library to external code), remain subject to the Copyleft effect and must be distributed under the ESA License.
    • If the ESA-licensed Software is extended by a proprietary component, the resulting Combination may be distributed under ESA license terms in respect of the original Software and the proprietary terms in respect of the component. This allows an integration of components similar to the MPL. For example, the ESA-licensed software can be linked to an MPL-licensed library.
Sec. 3.2.4 imposes some additional restrictions:
    • The new license terms must not restrict the rights in the original Software used for the Combination.
    • Notice has to be given that ESA-licensed software is used in the Combination. Even if the Combination is licensed under proprietary terms, the user shall be informed of the use of ESA licensed software.  For example, a company may use an ESA-licensed library in its proprietary software but must inform its users that the library was used.
There are no further requirements regarding the notice, e.g. where and how it shall be given. For example, the notice can be shown within the application (in an “About” window), the corresponding documentation or in a “NOTICE” file within the distribution.
    • The Source Code of the original Software (Covered Code) and the extension (External Code) must be clearly separated. Usually such separation is achieved by putting the External Code in different files. This is necessary because the recipient needs to be able to distinguish the External Code from the Covered Code in order to comply with the different license terms. Furthermore this condition results in an MPL-like clarification of the Copyleft scope: code in different files may be subject to different license terms while changes to an ESA-licensed file are Modifications not subject to the Sec. 3.2.4 exception.
    • In the event of an Object Code distribution of the Combination, the Source Code of the Covered Code must be made available to recipients in accordance with Sec. 3.3. For example a company can use an ESA-licensed library, but must make the library source code available for its users upon request.

1.3.3 Communication of the Source Code (Sec. 3.3 ESA-PL Strong and ESA-PL Weak)
The License permits a binary-only distribution of the software. In that event, it must be ensured that the corresponding Source Code is available to recipients. 
Sec. 3.3(b) states that the Source Code must be made available “freely accessible by reasonable means” – e.g. available for download. This obligation is effective during the Distribution of the software and for a minimum term of three years starting with the last act of Distribution.
The recipient must be notified how and where the Source Code can be obtained. At a minimum, such notice needs to be included in the “NOTICE” file, which must be part of the binary distribution.
1.3.4 Service Provision (Sec. 3.4 ESA-PL Strong)
This clause is intended to close the Software-as-a-Service loophole. 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 provide the source code) do not apply. This is known as a “service provision loophole”. The provision of software “as a service” is not an act of Distribution under the License, since no copies of the software are spread or transmitted. 
As a result, a company could build upon ESA licensed software and use the software to provide services to third parties, either by granting remote access to a server-based installation or by merely rendering services using the software. Because such service provision is no Distribution, the company would not be required to disclose their modifications to the ESA licensed software. 
Sec. 3.4 requires disclosure of the Source Code of the software provided “as a service”, if access to the software or its functionality is granted to third parties. This provision is similar to the AGPL and covers the provision of software “as a service”.
Mere internal use of the software for service provisions is not within the scope of the clause. For example, if a company receives data from its customers, processes it with the software and sends the results back to the customer, such use would not be covered by the clause.

1.3.5 Dual Licensing (Sec. 3.5)
Sec. 3.5 corresponds to Sec. 5c GPL v3 and clarifies the permission of dual / multiple licensing models. The clause is not necessary for the viability of dual licensing, but merely clarifies the possibility.
 “Dual Licensing” means that software is released under one or more different licenses. For example, software can be released under Open Source and proprietary license terms or under multiple Open Source license terms at the same time – e.g. under both the GPL and MPL licenses.
1.4 Notices (Sec. 4)
The obligations related to notices apply in the event of any Distribution of the Software or Modifications thereof, regardless of a Source Code or Object Code Distribution.

1.4.1 License and Notices (Sec. 4.1)
Sec. 4.1 requires all Distributions to include a copy of the License and all notices further mentioned in Sec. 4 – i.e. the CHANGELOG file, NOTICE file and display (if any), and the LEGAL file.

1.4.2 No changes to notifications unless permitted (Sec. 4.2)
Sec. 4.2 states that existing notices must not be changed, unless changes are required or allowed by the License. Furthermore, notices may be adapted to Modifications – for example, if the NOTICE file or the LEGAL file refers to code or functionality that was removed or replaced by a Contributor, the Contributor may change the notices correspondingly. However, in particular changes to the LEGAL file should only be undertaken upon careful due diligence by the Contributor.

1.4.3 CHANGELOG (Sec. 4.3)
Sec. 4.3 requires all Contributors to identify themselves and their modifications in a CHANGELOG file.

1.4.4 General NOTICE (Sec. 4.4)
Sec. 4.4 provides for a general NOTICE file that may include any kind of notices by Contributors (e.g. attribution notices, general remarks).

1.4.5 Patent Notice (Sec. 4.5)
Each Contributor must identify its relevant Patent Claims in a “LEGAL” file by providing the patent number and contact information. This is necessary to allow licensees to undertake patent due diligences and – if necessary – contact the Contributor for clarifications or further license grants.

1.5 Warranty and Liability (Sec. 5)
The current warranty and liability provisions are drafted under German law.
Pursuant to Sec. 5.1, each Contributor warrants that he is able to grant the necessary rights to his Modifications. For example, a Contributor copying third party source code without authorization and integrating such source code into the Software would be in violation of such warranty. 
There is no need under German law to provide a disclaimer for warranty and liability in an Open Source license. General consensus is that under German law, an Open Source license grant is deemed to be a “gift”. Statutory law (provides for a limitation of warranty and liability, restricting warranty and liability of the “donor” (Licensor) to cases of fraudulent misrepresentation, gross negligence and wilful misconduct.
Nevertheless the licenses include a warranty and liability disclaimer in Sec. 5.2 and 5.3, primarily to clarify the responsibilities in the event German law is not applicable (cf. Sec. 9).

1.6 Additional Agreements (Sec. 6)
Sec. 6 clarifies that any Licensor can conclude additional, accompanying agreements with recipients regarding e.g. maintenance or development of the Software or providing additional warranties regarding the Software. However, additional agreements must not restrict or alter the License terms or restrict the recipient’s rights under the License. Furthermore, the clause clarifies that additional agreements must not create any liability for other Licensors or Contributors. The wording corresponds to Sec. 3.5 MPLv2.

1.7 Infringements (Sec. 7)
If any Distributor knows of third party rights that are infringed by the Software, the Distributor must take reasonable steps to inform the community and ESA of the infringement.
This notification obligation corresponds to Sec. 3.4(a) MPLv1.1. However, the MPL clause was restricted to a Contributor and the Contributor’s Modifications. Nevertheless, any Distributor should be obliged to inform the community of any third party claims he knows of. 
Furthermore, to avoid liability risks, any licensee should cease infringing uses until the infringement is cured, either by the acquisition of the necessary rights or licenses or by a modification of the Software to the effect that the Modification is non-infringing. This is usually in the licensee’s own interest.

1.8 Termination (Sec. 8)
1.8.1 Termination for breach (Sec. 8.1)
All rights granted under the License automatically terminate if a licensee is in breach with the License terms and does not cure such breach within 30 days of becoming aware of it. Therefore compliance with the License terms is a condition for the exercise of rights (and benefits) granted by the License. Similar termination provisions are found in most OSS Licenses.

1.8.2 Patent retaliation (Sec. 8.2)
Sec. 8.2 provides a so-called “patent retaliation” termination provision. If a licensee institutes patent litigation alleging that the Software infringes his patent, all of his rights under the License terminate. As a result, the litigating party must cease to use and distribute the Software. This provision is intended to discourage patent litigation. Similar clauses are found e.g. in the GPL, MPL and Eclipse license. 
Sec. 8.2 requires patent litigation related to the Software, i.e. the allegation that the Software infringes one or more patents. Litigation covers cross-claims and counterclaims, i.e. there is no exception for defensive action – any patent related litigation results in a termination. Upon termination, all rights granted under Patent and Copyright to the Software terminate.

1.8.3 Survival of license grants (Sec. 8.3)
Sec. 8.3 clarifies that regardless of a termination, all licenses (validly and in accordance with the License) granted prior to termination remain valid and survive the termination. Further recipients and licensees of the Software are not affected by a breach of a distributor higher up in the license chain.

1.9 Applicable Law, Arbitration and Compliance (Sec. 9)
1.9.1 Law and Arbitration (Sec. 9.1, 9.2)
The licenses are subject to the laws of the ESA Member State (Art. 1 of the ESA Convention) where the Licensor resides or has his registered office. If a dispute arises with the ESA as the Licensor or if the Licensor has no residence or registered office inside a Member State, German law applies.
The arbitration clause corresponds to Annex I, Art. 25 of the ESA Convention and Chapter III, Clause 13 of the ESA GCC.

1.9.2 Legal compliance (Sec. 9.3, 9.4)
Sec. 9.3 clarifies that any licensee is solely responsible for compliance with the applicable law. In particular, a licensee could be subject to export control law. In that event, it is the licensee’s sole responsibility to comply with such export control law. The License neither requires nor prevents a licensee from compliance with statutory law.
If statutory law, regulations or judicial decisions prevent a licensee from compliance with one or more terms and conditions of the License, any relevant limitations need to be described in the LEGAL notice. For example, if a judicial decision imposes a licensee to collect license fees from recipients upon distribution due to the infringement of third party rights, such restriction and the alleged infringement must be described in the LEGAL notice. 
Sec. 9.4 corresponds to Sec. 4 MPLv1.1. Please note that the License does not follow the GPL’s “all or nothing” approach: if a court or statutory law attempts to limit or contradict the GPL license terms, the license for all practical purposes ceases to exist (comparable to an automatic termination, cf. Sec. 12 GPLv3). The ESA Licenses merely require the user to comply with the License to the extent possible and notify other licensee of limitations. 

8 August 2017
Authors:
Carsten Gerlach, cgerlach@tcilaw.de
Victoria Böhm, vboehm@tcilaw.de