Management von Open-Source-Lizenzen in einem großen Software-Haus. Linuxtag Helene Tamer, T-Systems International GmbH

Transkript

1 Management von Open-Source-Lizenzen in einem großen Linuxtag Helene Tamer, T-Systems International GmbH 1

2 Warum Open Source? Solution Design Reuse / Standards / State-ofthe-Art Technologie-Treiber frei wie in Redefreiheit (3) Kosten-Optimierung Keine oder minimale Kosten frei wie in Freibier (3) Nutzung durch Lizenzen geregelt Kommerzielle Nutzung erlaubt? Was ist zu beachten? 2

3 Wo ist das Problem? Energie Gesundheit Vernetztes Auto Mediendistribution Die Ziele Effizienz / Produktivität und - für uns ganz wichtig - Compliance Wir arbeiten im Kundenauftrag Uneingeschränkte Nutzungsrechte Sicherer und betreuter Betrieb Unterschiedliche Lösungsszenarien müssen von vielen einzelnen Mitarbeitern umgesetzt werden Wer soll alle Lizenzen kennen? 3

4 Wie schaffen wir das? Prinzip: Hilfe zur Selbsthilfe Information / Schulung Prozesse und Regeln: Wann muss ich was wie tun? Templates und Hilfsmittel Ergänzt durch Support Beratung für Spezialfälle durch: Open Source Competence Center Legal Support 4

5 Was heißt das für unsere Kundenbeziehung? Unsere Verantwortung Transparenz schaffen: Information über alle eingesetzten Komponenten Vorgaben der Kunden beachten, soweit vorhanden Mediendistribution Energie Unser Angebot Unterstützung beim Einsatz von Open Source durch Betreuungs- und Wartungsverträge Anpassungen an die Anforderungen der Kunden Beratung beim Einsatz von Open Gesundheit Vernetztes Auto 5

6 Navigationshilfen Einteilung der Lizenzen in Klassen Ohne Einschränkung nutzbar Nicht verwenden Einzelfallprüfung Risikobewertung nach Szenarien Nur intern Stand-Alone Als Teil unserer Software Risiko low high Detail-Informationen zu Lizenzen Eigene Übersichten Oslic(2) Bitkom SPDX / 6

7 Komponenten-Datenbank Tool-Unterstützung Datenbank + Web-Zugriff zur Zeit: MySQL und Java Datenbank Struktur und Content - und einfaches User- Interface sollen als Open Source zur Verfügung gestellt werden. Komponenten- Lizenzen Projekte Systeme Applikationen Datenbank und Web- Zugriff Demo. Komponenten- Einsatz 7

8 Fragen? 8

9 Vielen Dank! 9

10 Backup 10

11 Klassifizierung von Lizenzen. Klassifizierung Permissive Lizenzen Beispiele Klassifizierung Apache BSD MIT Charakteristik: Kommerziell ohne Einschränkung nutzbar Formalitäten bei Weitergabe zu beachten. Copyleft Lizenzen MPL CDDL EPL CPL GPL AGPL (Mozilla) (SUN) (Eclipse) (IBM) (GNU) (GNU) Kommerzielle Software, die derived von diesen Komponenten ist, darf nur unter der gleichen OSS Lizenz weiter gegeben werden. Zu bewerten (Einzelfall): Ist Anwendung ein derivative work? Welche Nutzungsrechte gelten? Welche sonstigen Regelungen gelten? Andere Lizenzen Einzelfall-Betrachtung Helene Tamer, T-Systems International GmbH / Linuxtag Lizensiert unter CC BY-NC-ND

12 Einsatzbereiche von OSS. Interner Einsatz (innerhalb einer Legal-Einheit) z.b. IDE, Monitoring-Tool im Betriebsumfeld) Im Allgemeinen unkritisch Lieferung zur Stand-Alone-Nutzung an Kunden/andere Legaleinheit z.b. Middleware, Client-Tools wie z.b. Office-Pakete Lizenzbedingungen müssen eingehalten werden Anforderungen des Kunden müssen eingehalten werden Teilkomponente integriert in unsere Software Unterscheide: Verändert/Unverändert Genaue Prüfung erforderlich, ob und unter welchen Bedingungen die Integration erlaubt ist ( Derived Work ist möglicherweise kritisch!) Lizenzbedingungen müssen eingehalten werden Anforderungen des Kunden müssen eingehalten werden R I S I K O Helene Tamer, T-Systems International GmbH / Linuxtag Lizensiert unter CC BY-NC-ND

13 Open Source Prüfung im Software-Entwicklungs-Prozess. 1 Angebot Entwicklungs-Projekt Betrieb / Wartung 1 Trigger 1: Auswahl Komponente 2 Trigger 2: Integration Komponente 3 Trigger 3: Weitergabe Komponente 13

14 ToDos bei Trigger 1: Auswahl Komponente. Kriterien zur Prüfung einer Komponente Lizenzrechtlich Vor allem: Dürfen die Komponenten kommerziell eingesetzt und weiter gegeben werden? Welche Einschränkungen sind zu beachten? Kundenanforderungen: Erlaubt der Kunde im Rahmenvertrag oder den Ausschreibungsunterlagen den Einsatz von OSS? Sachliches Risiko Performance, Stabilität der Komponente, Weiterpflege des Codes, Kritikalität der Anwendung etc. (z.b. ist Einsatz in Embedded Systems eingehend zu prüfen) Verwende Make or Buy Template Regelungen im Angebot / Einzelvertrag erforderlich, z.b. Information über Einsatz von Komponenten Nutzungsrechte: nur eingeschränktes Nutzungsrecht Ggfs. Regelung von Haftung, Gewährleistung, Supportleistungen (mit Auswirkungen auf die Kalkulation) Helene Tamer, T-Systems International GmbH / Linuxtag Lizensiert unter CC BY-NC-ND

15 ToDos bei Trigger 2: Integration Komponente. Bei Integration von Komponenten im SE-Prozess Lizenzbedingungen einhalten: Integration von OSS-Komponenten in kommerzielle Software wird durch viele Lizenzen verboten oder eingeschränkt! Z.B.: GPL (GNU General Public License): Auch dynamisches Linken einer Komponente verlangt, dass unsere Anwendung wieder unter die GPL gestellt wird. MPL (Mozilla Public License) / CDDL (Common Development and Distribution License): Diese Komponenten dürfen nur in unsere Anwendung integriert werden, wenn eine strikte Trennung der Dateien erfolgt. LGPL (GNU Lesser General Public License): prüfen, ob durch die Art der Einbindung in unsere Applikation die Freigabe unserer Applikation zum Reengineering. erforderlich macht. Apache Lizenzen: Bei Integration ohne Einschränkung zu verwenden. Weitergabe von geänderten OSS-Komponenten: Fast immer nur unter der gleichen Lizenz erlaubt! Freigabe erforderlich! Empfehlung: ie Applikation so unabhängig wie möglich von einzelnen Komponenten gestalten (z.b. durch Verwendung von Software Design Patterns wie Encapsulation und Loose Coupling). Helene Tamer, T-Systems International GmbH / Linuxtag Lizensiert unter CC BY-NC-ND

16 ToDos bei Trigger 3: Weitergabe Komponente. Dies gilt für jede Weitergabe an andere Legaleinheiten (Kunde, Unterauftragnehmer, andere Telekom-Legaleinheiten) Vor jeder Weitergabe prüfen, ob die Lizenzbedingungen dies erlauben. Alle Lizenzbedingungen sind einzuhalten. Sicher stellen, dass alle Freigaben durch den Kunden vorliegen, falls erforderlich. Dokumentation aller OSS Komponenten, die weiter gegeben werden, mit Angabe der Lizenzen (in der Dokumentation der Applikation und im Lieferschein). Mitgabe aller Lizenzdateien, copyright notices usw. (Diese sind bei Java Komponenten oft in den entsprechenden *.jar files enthalten dies muss aber überprüft werden.) Mitgabe des Source Codes, soweit dies die Lizenz verlangt. Helene Tamer, T-Systems International GmbH / Linuxtag Lizensiert unter CC BY-NC-ND

17 T-Systems als Open Source Anbieter. Sinnvoll Für Frameworks / Tools Zum Beispiel: MDA-Generator dromdary: Nicht für Kundenlösungen (Kunden erwarten exklusive Nutzungsrechte) Aber: Support und Beratung der Kunden beim Einsatz und Betrieb von Open Source Definition von Open Source Product Stacks für definierte Szenarien Im Einzelfall zu prüfen: Haftungsrisiko für Schäden durch Komponente Verträglichkeit mit existierenden Kundenverträgen Kompatibilität mit Lizenzen enthaltener/verwendeter Open Source Software Verträglichkeit mit Patentrecht. Auswahl einer geeigneten Lizenz. 17

18 Links und Kontaktdaten. (1) Lizensiert unter: Creative Commons CC BY-NC-ND 3.0 (2) OSLiC: (3) Freie-Software-Definition: Kontakt: Helene Tamer, T-Systems International GmbH, 18