Bei den Entwicklern proprietärer Informationssysteme entsteht im Zusammenhang mit GPL-lizenzierter Software eine erhebliche Unsicherheit. Dabei ist der virale Effekt der GPL auf Linux Kernelmodule (LKM) ein heftig diskutiertes Problem. Unbeachtet bleibt bei dieser Diskussion, dass man zwischen der Rechtslage in Deutschland bzw. Europa und der in den Vereinigten Staaten unterscheiden muss. Dieser Beitrag beleuchtet exemplarisch, welche Konstellationen streng zu trennen sind und wie sich die Rechtslage bei Entwicklung und Vertrieb von LKMs in Deutschland darstellt. Die gewonnenen Erkenntnisse können auf andere Projekte übertragen werden, die GPLlizenzierte Software einbeziehen.

R euse of well-tried components promises costeffective construction of high-quality software systems. With this approach, third-party software components are usually integrated into complex software systems. The risks of using such components of different suppliers are both technical and judicial. Some technical problems were discussed by Peter G. Neumann in the July 2006 “Inside Risks” column. Here, we discuss emergent judicial concerns as they apply in Europe. From the judicial point of view, a risk exists for system vendors to be held liable for malfunctions that are not self-induced, without being able to take recourse to the supplier delivering the faulty component. The resulting problems are evident in the context of German legislation. These problems apply throughout the European Union, due to an EU council directive concerning liability for defective products (No. 85/374/EEC of July 25th, 1985). The reason for the additional liability risks when reusing third-party software components is this: The integrator/vendor of systems composed of several software components from different suppliers is in general liable to his customers as well as to the general public for any malfunction of the whole system. If the product does not function properly, the customer will confront the vendor—for example, to receive a refund or to seek a discount. Even worse, if the system is safety critical, the customer might sue the vendor for damages. The same is true for any injured persons who are not the contractual partner of the vendor. The vendor might have to pay huge sums because of damage to goods or people. The customer and the injured party have the advantage that an exact localization of the fault is not necessary for their claim. They merely have to provide evidence that a malfunction of the product caused the damage. The vendor then has little chance of warding off the claims. In particular, according to the European directive 85/374/EEC, no contractual derogation is permitted as regards the liability of the producer in relation to the injured person; all producers involved in the production process could be made liable, insofar as their finished product, component part, or any raw material supplied by them was defective. After having paid for damages, the system vendor might consider taking recourse to one of his suppliers, or more precisely, the one supplier that delivered the defective component. In contrast to the injured party, the vendor now has the problem that he must localize the fault within his component-based system. He can point his finger to a supplier only if he can prove that this supplier’s software component failed and contains the responsible fault as root cause of the failure. Fault diagnosis and fault localization in complex component-based systems present a real challenge, because they can require the complete reconstruction of the error-propagation process among all components and the identification of the conditions that activated the root cause of the failure. An additional difficulty for software forensics is the transient state, which is usually lost at the time of system failure. The error propagation process within a system composed of software components does usually not create “visible” indications about single component failures. In contrast, error propagation processes in hardware usually create physical indication toward the fault locations. For instance, if a laptop burns, it should be possible to prove that a particular hardware component such as the battery burned first (although this does not necessarily mean that this component was responsible). Component specifications are used to formalize provided services, and may define what is required from the execution environment or by other components in order to provide correct service. These component specifications could be part of requirements specifications and even of formal contracts between system vendor and component suppliers. However, such specifications are often ambiguous, incomplete, and neglecting precise metrics for quality properties. Conversely, failures may be caused by improper protocols governing interactions among multiple components; thus, the system composer may be responsible for failures himself. Here, technical and judicial issues meet. In our interdisciplinary Graduate School TrustSoft (www.trustsoft.org), we integrate research in Computer Science and Law to address these problems.

Basic concepts and terminology for trustworthy software systems are discussed. Our discussion of definitions for terms in the domain of trustworthy software systems is based on former achievements in dependable, trustworthy and survivable systems. We base our discussion on the established literature and on approved standards. These concepts are discussed in the context of our graduate school TrustSoft on trustworthy software systems. In TrustSoft, we consider trustworthiness of software systems as determined by correctness, safety, quality of service (performance, reliability, availability), security, and privacy. Particular means to achieve trustworthiness of component-based software systems - as investigated in TrustSoft - are formal verification, quality prediction and certification; complemented by fault diagnosis and fault tolerance for increased robustness.

Der Verfasser legt den juristischen Streit um die vertragstypologische Einordnung des Downloads von OSS dar und schliest sich der Meinung an, die die Regeln der Schenkung analog anwendet. Darauf folgt eine kurze Darstellung der einschlagigen Haftungsregelungen sowie der Moglichkeiten, diese durch Vertragsgestaltungen zu modifizieren. Dem Beitrag wird dabei als Grundkonstellation der isolierte, unentgeltliche Download von OSS direkt vom Urheber unter Geltung der GNU GPL zu Grunde gelegt.