Grundlagen des Open-Source-Lizenzrechts

Ein kompakter Überblick über die rechtlichen Aspekte von Open-Source-Software. Neben den rechtlichen Grundlagen werden die wesentlichen Eigenschaften von Open-Source-Lizenzen vorgestellt. Außerdem werden einige verbreitete Lizenzen detaillierter erläutert.

Transcript

1. Grundlagen des Open-Source-Lizenzrechts Andreas Schreiber Deutsches Zentrum für Luft- und Raumfahrt e.V. PyCon DE 2012, Leipzig, 30. Oktober 2012 PyCon DE 2012 > Grundlagen des Open-Source-Lizenzrechts > A. Schreiber > 30.10.2012 www.DLR.de • Folie 1
2. Übersicht - Rechtliche Grundlagen - Urheberrecht - Vertragsrecht - Open-Source-Software - Lizenzarten von Software - Definition Open-Source-Software - Open-Source-Lizenzmodelle - Ausgewählte Open-Source-Lizenzen - Praktische Nutzung von Open-Source PyCon DE 2012 > Grundlagen des Open-Source-Lizenzrechts > A. Schreiber > 30.10.2012 www.DLR.de • Folie 2
3. Rechtliche Grundlagen • Urheberrecht • Vertragsrecht PyCon DE 2012 > Grundlagen des Open-Source-Lizenzrechts > A. Schreiber > 30.10.2012 www.DLR.de • Folie 3
4. Urheberrecht - Urheberrechtsfähig sind Werke der Literatur, Wissenschaft und Kunst - Werke sind persönliche geistige Schöpfungen auf den Gebieten - Sprachwerke (einschl. Computerprogramme) - Musik - Pantomime - Bildende Kunst - Lichtbildwerke - Filmwerke - Darstellungen wissenschaftlicher oder technischer Art PyCon DE 2012 > Grundlagen des Open-Source-Lizenzrechts > A. Schreiber > 30.10.2012 www.DLR.de • Folie 4
5. Urheberrecht Urheberrechtlicher Schutz von Software (§§ 69a ff. UrhG) Gegenstand des Schutzes (§ 69a UrhG) - Computerprogramme sind in jeder Form geschützt (sowohl Source- als auch Objektcode) - einschließlich des Entwurfsmaterials - Ideen und Grundsätze des Programms sind nicht geschützt - Computerprogramme sind dann geschützt, wenn sie das Ergebnis einer eigenen geistigen Schöpfung des Urhebers sind - qualitative oder ästhetische Kriterien sind dabei unerheblich PyCon DE 2012 > Grundlagen des Open-Source-Lizenzrechts > A. Schreiber > 30.10.2012 www.DLR.de • Folie 5 UrhG: Gesetz über Urheberrecht und verwandte Schutzrechte (Urheberrechtsgesetz): http://www.gesetze-im-internet.de/urhg
6. Urheberrecht Urheberrechtlicher Schutz von Software (§§ 69a ff. UrhG) Zustimmungsbedürftige Handlungen (§ 69c UrhG) - dauerhafte oder vorübergehende Vervielfältigung (Vervielfältigung ist auch das Laden in den Arbeitsspeicher  schon das Benutzen der Software erfordert eine Lizenz) - Übersetzung, Bearbeitung oder andere Umarbeitung - Verbreitung - öffentliche Wiedergabe PyCon DE 2012 > Grundlagen des Open-Source-Lizenzrechts > A. Schreiber > 30.10.2012 www.DLR.de • Folie 6
7. Vertragsrecht - „Der Unternehmer hat dem Besteller das Werk frei von Sach- und Rechtsmängeln zu verschaffen“ (§ 633 Abs. 1 BGB) - „Das Werk ist frei von Rechtsmängeln, wenn Dritte in Bezug auf das Werk keine oder nur die in Vertrag übernommenen Rechte gegen den Besteller geltend machen können“ (§ 633 Abs. 2 BGB) - Kaufrecht (§§ 433 ff BGB) enthält eine identische Regelung (§ 435 BGB) - Rechtsmängel sind z.B. entgegenstehende Urheberrechte Dritter PyCon DE 2012 > Grundlagen des Open-Source-Lizenzrechts > A. Schreiber > 30.10.2012 www.DLR.de • Folie 7 BGB: Bürgerliches Gesetzbuch: http://www.gesetze-im-internet.de/bgb
8. Vertragsrecht Juristische Folgen bei Rechtsmängeln Besteller kann 1. Nacherfüllung verlangen (§ 635 BGB)  Hersteller („Unternehmer“) muss Mangel beseitigen oder ein neues Werk herstellen 2. den Mangel selbst beseitigen und Ersatz der Aufwendungen verlangen 3. vom Vertrag zurücktreten oder die Vergütung mindern 4. Schadensersatz oder Ersatz vergeblicher Aufwendungen verlangen PyCon DE 2012 > Grundlagen des Open-Source-Lizenzrechts > A. Schreiber > 30.10.2012 www.DLR.de • Folie 8
9. Rechtewegfall Manche Lizenzbedingungen normieren explizit einen sog. Rechtewegfall, wenn die Lizenzbedingungen nicht eingehalten werden Beispiele: GPLv2, GPLv3, LGPLv2, LGPLv3, CPL Konsequenz: Keine Lizenz mehr mit der Folge, dass 1. urheberrechtliche Unterlassungs- und Schadensersatzansprüche geltend gemacht werden können 2. ein Auftraggeber Ansprüche wegen Rechtsmängelhaftung geltend machen kann (siehe oben) - Wenn kein Rechtewegfall, dann nur Vertragsverletzung gegenüber dem Lizenzgeber (Schadensersatz) PyCon DE 2012 > Grundlagen des Open-Source-Lizenzrechts > A. Schreiber > 30.10.2012 www.DLR.de • Folie 9
10. Rechtsfolgen bei Urheberrechtsverletzung Zivilrecht - Vernichtung von Vervielfältigungsstücken, § 69f UrhG - Ansprüche auf Unterlassung und Schadensersatz, § 97 UrhG - Abmahnung, § 97a UrhG - Anspruch auf Vernichtung, Rückruf, Überlassung, § 98 UrhG - Entschädigungsanspruch, § 100 UrhG - Auskunftsanspruch, §101 UrhG - Anspruch auf Vorlage und Besichtigung, § 101a UrhG - Vorlage von Bank-, Finanz- und Handelsunterlagen, § 101b UrhG Strafrecht - Unerlaubte Verwertung urheberrechtlich geschützter Werke, § 106 UrhG - Unzulässiges Anbringen der Urheberrechtsbezeichnung, §107 UrhG - … PyCon DE 2012 > Grundlagen des Open-Source-Lizenzrechts > A. Schreiber > 30.10.2012 www.DLR.de • Folie 10
11. Open-Source-Software • Lizenzarten von Software • Definition Open-Source-Software • Open-Source-Lizenzmodelle PyCon DE 2012 > Grundlagen des Open-Source-Lizenzrechts > A. Schreiber > 30.10.2012 www.DLR.de • Folie 11
12. Lizenzarten von Software - Kommerzielle Software - Shareware - Public-Domain-Software - Freie Software - Open-Source-Software - Freeware - Donationware - Peaceware PyCon DE 2012 > Grundlagen des Open-Source-Lizenzrechts > A. Schreiber > 30.10.2012 www.DLR.de • Folie 12
13. Kommerzielle Software und Shareware Kommerzielle Software - Man erwirbt i.d.R. nur ein Nutzungsrecht an der Software - Vor der Nutzung ist der Kauf einer Lizenz erforderlich, der Autor behält in jedem Fall das Copyright Shareware - Verbreitung einer oft eingeschränkt nutzbaren Version - Meist erst nach Bezahlung unbeschränkt nutzbar - „Test kostenlos“, danach wie kommerzielle Software In beiden Varianten wird i.d.R. kein Quelltext mitgeliefert PyCon DE 2012 > Grundlagen des Open-Source-Lizenzrechts > A. Schreiber > 30.10.2012 www.DLR.de • Folie 13
14. Kostenlose Software Ohne Quelltext Freeware - Software, die vom Urheber zur kostenlosen Nutzung zur Verfügung gestellt wird Donationware - Freeware, bei der eine eventuelle Bezahlung dem Benutzer freigestellt bleibt Bei diesen Lizenzmodellen bezieht sich „Free“ (frei) nur auf die Kosten PyCon DE 2012 > Grundlagen des Open-Source-Lizenzrechts > A. Schreiber > 30.10.2012 www.DLR.de • Folie 14
15. Kostenlose, freie Software Mit Quelltext Public Domain („gemeinfrei“) - Völliger Verzicht des Urhebers auf seine Rechte - In Deutschland ist ein Totalverzicht auf das Urheberrecht – etwa zugunsten der Allgemeinheit – nicht möglich Freie Software - Erlaubt den Benutzern neben einer freien Weitergabe des Programms auch seinen Quelltext einzusehen und zu verändern sowie Modifikationen weiter zu verbreiten - Diese Software darf zu einen beliebigen Preis verkauft werden Open Source - Ist in den meisten Fällen auch freie Software - Es existieren mehr als 70 Open-Source-Lizenzen mit vielen Sonderregelungen PyCon DE 2012 > Grundlagen des Open-Source-Lizenzrechts > A. Schreiber > 30.10.2012 www.DLR.de • Folie 15
16. Lizenzarten von Software PyCon DE 2012 > Grundlagen des Open-Source-Lizenzrechts > A. Schreiber > 30.10.2012 www.DLR.de • Folie 16 Quelle: http://www.oss.bund.de/node/123
17. Definition Open-Source-Software Free Software Foundation (FSF) Free software is a matter of the user´s freedom to run, copy, distribute, study, change and improve the software. PyCon DE 2012 > Grundlagen des Open-Source-Lizenzrechts > A. Schreiber > 30.10.2012 www.DLR.de • Folie 17 „Free as in ‘freedom’, not as in ‘free beer’“ Richard Stallmann
18. Definition Open-Source-Software Open Source Initiative (OSI) (1/4) 1. Freie Weitergabe („Free Redistribution“) Die Lizenz soll die Weitergabe der Software als Teil einer Gesamtsoftware oder Software-Distribution nicht einschränken. 2. Quellcode („Source Code“) Das Programm darf als Quellcode oder in kompilierter Form verteilt werden. Aber der Quellcode muss zugänglich sein. 3. Abgeleitete Software („Derived Works“) Die Lizenz muss Modifikationen und abgeleitete Werke erlauben. Verteilung unter der gleichen Lizenz muss möglich sein. PyCon DE 2012 > Grundlagen des Open-Source-Lizenzrechts > A. Schreiber > 30.10.2012 www.DLR.de • Folie 18
19. Definition Open-Source-Software Open Source Initiative (OSI) (2/4) 4. Unversehrtheit des Quellcodes des Autors („Integrity of The Author's Source Code“) Die Lizenz darf die Verteilung modifizierter Programme nur einschränken, falls „Patches“ zum Kompilierzeitpunkt erlaubt sind. Die Lizenz darf verlangen dass abgeleitete Versionen einen anderen Namen haben müssen. 5. Keine Diskriminierung von Personen oder Gruppen („No Discrimination Against Persons or Groups“) Die Lizenz darf keine Personen oder Personengruppen ausschließen oder benachteiligen. PyCon DE 2012 > Grundlagen des Open-Source-Lizenzrechts > A. Schreiber > 30.10.2012 www.DLR.de • Folie 19
20. Definition Open-Source-Software Open Source Initiative (OSI) (3/4) 6. Keine Einschränkungen bezüglich des Einsatzfeldes („No Discrimination Against Fields of Endeavor “) Die Lizenz darf Bereiche oder Geschäftsfelder nicht ausschließen. 7. Weitergabe der Lizenz („Distribution of License“) Die Lizenz des Programms muss für alle gelten, denen das Programm weiter gegeben wird. 8. Die Lizenz darf nicht auf ein bestimmtes Produktpaket beschränkt sein („License Must Not Be Specific to a Product”) Die Rechte am Programm dürfen sich nicht ändern, wenn es als Teil einer Gesamtsoftware oder Distribution verteilt wird. PyCon DE 2012 > Grundlagen des Open-Source-Lizenzrechts > A. Schreiber > 30.10.2012 www.DLR.de • Folie 20
21. Definition Open-Source-Software Open Source Initiative (OSI) (4/4) 9. Die Lizenz darf die Weitergabe zusammen mit anderer Software nicht einschränken („License Must Not Restrict Other Software“) Die Lizenz darf andere Software, mit der zusammen sie als Gesamtsoftware oder Distribution verteilt wird, nicht einschränken. 10.Lizenz muss technologieneutral sein („License Must Be Technology-Neutral“) Die Lizenz darf nicht auf eine bestimmte (Software-)Technologie oder Schnittstelle eingeschränkt werden. PyCon DE 2012 > Grundlagen des Open-Source-Lizenzrechts > A. Schreiber > 30.10.2012 www.DLR.de • Folie 21
22. Open-Source-Lizenzen Definition von Open-Source unter http://opensource.org/docs/osd  Liste mit >70 Open-Source-Lizenzen Licenses that are popular and widely used or with strong communities - Apache License, 2.0 - New and Simplified BSD licenses - GNU General Public License (GPL) - GNU Library or "Lesser" General Public License (LGPL) - MIT license - Mozilla Public License 1.1 (MPL) - Common Development and Distribution License - Common Public License 1.0 - Eclipse Public License PyCon DE 2012 > Grundlagen des Open-Source-Lizenzrechts > A. Schreiber > 30.10.2012 www.DLR.de • Folie 22
23. Open-Source-Lizenzmodelle „Copyleft“ vs. „Non-Copyleft“ Copyleft heißt: Weiterentwicklungen der Software müssen unter den gleichen Lizenzbedingungen freigegeben werden wie die Software selbst - strenges Copyleft: keine Ausnahme! - beschränktes Copyleft: Ausnahmen sind möglich Non-Copyleft heißt: Weiterentwicklungen der Software können unter anderen Lizenzbedingungen freigegeben werden als die Software selbst PyCon DE 2012 > Grundlagen des Open-Source-Lizenzrechts > A. Schreiber > 30.10.2012 www.DLR.de • Folie 23
24. Open-Source-Lizenzmodelle Fünf Lizenztypen 1. Lizenzen mit strengem Copyleft (z.B. GPL, AGPL, CPL, EPL) ( alle Bearbeitungen müssen der Ursprungslizenz unterstellt werden) 2. Lizenzen mit beschränktem Copyleft (z.B. MPL, LGPL) ( Ausnahmen vom strengen Copyleft sind zugelassen) 3. Lizenzen ohne Copyleft (z.B. BSD, Apache, PSFL) ( keine Pflichten für die Lizenzierung von neuem oder geändertem Code) 4. Lizenzen mit Wahlmöglichkeit (z.B. Artistic) ( Der Bearbeiter einer Software darf zwischen verschiedenen Möglichkeiten zur Lizenzierung seiner Bearbeitung wählen) 5. Lizenzen mit Sonderrechten (z.B. NPL, QPL, APSL) ( Der Bearbeiter einer Software muss dem Inhaber der Ursprungssoftware Sonderrechte einräumen) PyCon DE 2012 > Grundlagen des Open-Source-Lizenzrechts > A. Schreiber > 30.10.2012 www.DLR.de • Folie 24
25. Verbreitung von Open-Source-Lizenzen PyCon DE 2012 > Grundlagen des Open-Source-Lizenzrechts > A. Schreiber > 30.10.2012 www.DLR.de • Folie 25 GPLv2 46% Artistic License 9% LGPL 8% MIT License 7% GPLv3 6% BSD License 6% Apache License 2 5% Sonstige 13% Quelle: Black Duck Open Source Resource Center (2011), total rund 230000 Open Source Projekte analysiert
26. Ausgewählte Open-Source-Lizenzen • GNU General Public License (GPL) • Eclipse Public License • GNU Lesser General Public License (LGPL) • BSD License • Python Software Foundation License (PSFL) • Apache License PyCon DE 2012 > Grundlagen des Open-Source-Lizenzrechts > A. Schreiber > 30.10.2012 www.DLR.de • Folie 26
27. GNU General Public License (GPLv2) (Strenges Copyleft) Rechte des Lizenznehmers: - Software benutzen, vervielfältigen, verbreiten, öffentlich zugänglich machen, bearbeiten PyCon DE 2012 > Grundlagen des Open-Source-Lizenzrechts > A. Schreiber > 30.10.2012 www.DLR.de • Folie 27
28. GNU General Public License (GPLv2) (Strenges Copyleft) Pflichten des Lizenznehmers - bei der Weitergabe unveränderter Software - Mitlieferung des Lizenztextes - Zugänglichmachung des Source Codes - Urheberrechtsvermerk - Haftungsausschluß („Disclaimer“) - Lizenzgebührenverbot - Verbot von Beschränkungen, die über die GPL hinaus gehen - bei der Weitergabe veränderter Software zusätzlich - Änderungsvermerk - Anzeige interaktiver Kommandos - Copyleft PyCon DE 2012 > Grundlagen des Open-Source-Lizenzrechts > A. Schreiber > 30.10.2012 www.DLR.de • Folie 28
29. GNU General Public License (GPLv2) (Strenges Copyleft) Wann gilt das Copyleft? (1) - Alles, was nicht als „derivative work“ anzusehen ist, kann beliebig weitergegeben werden (sog. „separate works“) - Programme oder Softwarebestandteile, die nicht voneinander abgeleitet sind, können unter verschiedenen Lizenzen vertrieben werden, auch auf einem Datenträger - Programme oder Softwarebestandteile, die nicht voneinander abgeleitet sind, müssen aber dann insgesamt unter der GPL verbreitet werden, wenn sie ein Ganzes bilden („part of the whole“) - Programme oder Softwarebestandteile, die voneinander abgeleitet sind, müssen stets insgesamt unter der GPL verbreitet werden PyCon DE 2012 > Grundlagen des Open-Source-Lizenzrechts > A. Schreiber > 30.10.2012 www.DLR.de • Folie 29
30. GNU General Public License (GPLv2) (Strenges Copyleft) Wann gilt das Copyleft? (2) - Wann ist von einen „part of the whole“ auszugehen? Zweck der Regelung: Vermeiden, dass GPL-Software so mit anderer Software verbunden wird, das es dem Nutzer unmöglich wird, die GPL- Bestandteile als eigenständige Werke zu erkennen und zu nutzen - Drei Aspekte: 1. technische Eigenständigkeit 2. inhaltlich-funktionale Eigenständigkeit 3. selbständiger Vertrieb möglich PyCon DE 2012 > Grundlagen des Open-Source-Lizenzrechts > A. Schreiber > 30.10.2012 www.DLR.de • Folie 30
31. GNU General Public License (GPLv2) (Strenges Copyleft) Wann gilt das Copyleft? (3) Einzelaspekte: - Codeänderungen und -ergänzungen  Copyleft - Kernelmodule  abhängig von der Eigenständigkeit - Verlinkung (insbesondere auf GPL/LGPL-Bibliotheken)  ein Executable = Copyleft  statische Verlinkung = i.d.R. Copyleft  dynamische Verlinkung = abhängig von Eigenständigkeit - Nutzung von GPL-Softwaretools (z.B. Emacs, GNU C Compiler, Editoren)  erzeugtes Programm = i.d.R. kein Copyleft PyCon DE 2012 > Grundlagen des Open-Source-Lizenzrechts > A. Schreiber > 30.10.2012 www.DLR.de • Folie 31
32. GNU General Public License (GPLv3) (Strenges Copyleft) Rechte des Lizenznehmers: - Wesentliche Unterschiede zu GPLv2, sind folgende neue Formulierungen - „Propagate“: sämtliche Nutzungen, für die eine urheberrechtliche Gestattung notwendig ist - „Convey“: Dritte in die Lage versetzen, Programmkopien zu erhalten oder zu erstellen PyCon DE 2012 > Grundlagen des Open-Source-Lizenzrechts > A. Schreiber > 30.10.2012 www.DLR.de • Folie 32
33. GNU General Public License (GPLv3) (Strenges Copyleft) Pflichten des Lizenznehmers - Wesentliche Unterschiede zu GPLv2: - Source Code kann per Download zugänglich gemacht werden - Zusätzliche Lizenzbedingungen sind in bestimmten Umfang zulässig (Additional Permissions“ - „non-permissive additional terms“) - Digital Rights Management - Patentlizenzierung PyCon DE 2012 > Grundlagen des Open-Source-Lizenzrechts > A. Schreiber > 30.10.2012 www.DLR.de • Folie 33
34. Common Public License (CPL) / Eclipse Public License (EPL) (Strenges Copyleft) Ähnlich wie GPL, aber mit einigen Variationen, z.B.: - Möglichkeit zur Unterlizenzierung - Patentlizenz - Sonderregelungen für kommerzielle Distributoren Bei Eclipse Unterscheidung zwischen: - Verwendung als Entwicklungswerkzeug  kein Copyleft, solange kein Eclipse-Code in das Programm kopiert wird - Nutzung von Eclipse-Komponenten zur Laufzeit  wenn Bearbeitung von Eclipse, dann Copyleft  wenn nur Werkverbindung, dann kein Copyleft (z.B. Eclipse Plugins) PyCon DE 2012 > Grundlagen des Open-Source-Lizenzrechts > A. Schreiber > 30.10.2012 www.DLR.de • Folie 34
35. GNU Lesser General Public License (LGPLv2) (Beschränktes Copyleft) Hauptanwendungsfall: Libraries (speziell GNU C-Library) Pflichten bei Weitergabe unveränderter Software - Mitlieferung einer Kopie des Lizenztextes - Herausgabe Source Code - Copyrightvermerk - Gewährleistungs- und Haftungsausschluß - Beibehaltung bestehender Lizenzhinweise/Haftungs- und Gewährleistungsausschlüsse - Keine Lizenzgebühren Pflichten bei Weitergabe veränderter Software - Veränderte Software muß der LGPL unterstellt werden - Urheberrechtsvermerke dürfen nicht geändert werden - Veränderungen der Software müssen gekennzeichnet sein PyCon DE 2012 > Grundlagen des Open-Source-Lizenzrechts > A. Schreiber > 30.10.2012 www.DLR.de • Folie 35
36. GNU Lesser General Public License (LGPLv2) (Beschränktes Copyleft) Pflichten bei Weitergabe veränderter Software (1) Veränderung der Bibliothek selbst (work based on the Library): - Strenges Copyleft, aber: - es können Funktionseinheiten einer LGPL-Bibliothek mit Funktionseinheiten einer nicht-LGPL-Bibliothek (proprietär) in eine gemeinsame Bibliothek verbunden werden, wenn - die getrennte Verbreitung dieser beiden Bestandteile gestattet ist - deutlicher Hinweis auf LGPL-Bestandteile erfolgt - deutlicher Hinweis, wo LGPL-Bestandteile gefunden werden können - LGPL-Bestandteile in isolierter Form unter den Lizenzbedingungen der LGPL mitgeliefert werden PyCon DE 2012 > Grundlagen des Open-Source-Lizenzrechts > A. Schreiber > 30.10.2012 www.DLR.de • Folie 36
37. GNU Lesser General Public License (LGPLv2) (Beschränktes Copyleft) Pflichten bei Weitergabe veränderter Software (2) Kombination der Bibliothek mit einem Programm (work that uses the Library): - Programme, die die Library nur benutzen („in isolation“ zugreifen) werden von der LGPL nicht erfasst  alle Anwendungsprogramme auf Basis von Linux können ohne Restriktion der LGPL in isolierter Form vertrieben werden, auch wenn sie auf LGPL- Bibliotheken zugreifen - aber: Wenn Programm und Library zu einem Programm zusammenkompiliert werden, gilt die LGPL für das ganze Programm - Sonderregelung für Makros und Inline-Funktionen - aber Sonderregelungen beachten…… PyCon DE 2012 > Grundlagen des Open-Source-Lizenzrechts > A. Schreiber > 30.10.2012 www.DLR.de • Folie 37
38. GNU Lesser General Public License (LGPLv2) (Beschränktes Copyleft) Pflichten bei Weitergabe veränderter Software (3) Sonderregelungen für Zugriff eines Programmes auf eine LGPL- Bibliothek (work that uses the Library) - Das Programm, das auf eine LGPL-Bibliothek zugreift, darf beliebigen Lizenzbedingungen unterstellt werden, aber - Kunden muß die Veränderung des zugreifenden Programms gestattet werden (incl. Reverse Engineering zur Fehlerbehebung) - Hinweis, dass eine LGPL-Bibliothek verwendet wird - Mitlieferung Lizenztext LGPL - Bei Urheberrechtsvermerk muß auch ein Urheberrechtsvermerk zur LGPL-Bibliothek erfolgen PyCon DE 2012 > Grundlagen des Open-Source-Lizenzrechts > A. Schreiber > 30.10.2012 www.DLR.de • Folie 38
39. GNU Lesser General Public License (LGPLv2) (Beschränktes Copyleft) Pflichten bei Weitergabe veränderter Software (4) Sonderregelungen für Zugriff eines Programmes auf eine LGPL- Bibliothek (work that uses the Library) Wahlweise eine der folgenden Bedingungen 1. Lieferung des Source Codes der Bibliothek in einer Weise, dass die Bibliothek verändert und mit dem Programm neu verlinkt werden kann 2. Drei Jahre gültiges Angebot zur Lieferung der v.g. Materialien 3. Verwendung von Shared Libraries PyCon DE 2012 > Grundlagen des Open-Source-Lizenzrechts > A. Schreiber > 30.10.2012 www.DLR.de • Folie 39
40. BSD License – Berkeley Software Distribution (kein Copyleft) Rechte des Lizenznehmers: - Einfaches, unbeschränktes Nutzungsrecht an jedermann, die Software zu benutzen, zu vervielfältigen, zu verbreiten, öffentlich zugänglich machen, zu bearbeiten PyCon DE 2012 > Grundlagen des Open-Source-Lizenzrechts > A. Schreiber > 30.10.2012 www.DLR.de • Folie 40
41. BSD License – Berkeley Software Distribution (kein Copyleft) Pflichten des Lizenznehmers - bei der Weitergabe unveränderter Software im Source- oder Objektcode - Urheberrechtsvermerk weitergeben - Lizenzbestimmungen weitergeben - Haftungs- und Gewährleistungsausschluß weitergeben - Werbeklausel (in der modified BSD license gestrichen) - bei der Weitergabe veränderter Software im Source- oder Objektcode - entfallen diese Pflichten! Fazit: Bearbeiteter Code kann in proprietäre Software überführt oder unter einer anderen Open-Source-Lizenz lizenziert werden PyCon DE 2012 > Grundlagen des Open-Source-Lizenzrechts > A. Schreiber > 30.10.2012 www.DLR.de • Folie 41
42. Python Software Foundation License (PSFL) (kein Copyleft) - BSD-artige Lizenz - Anwendungsfall: Für Änderungen an Python selbst Rechte des Lizenznehmers:  wie BSD-Lizenz Pflichten des Lizenznehmers - Es darf keine Werbung im Namen der PSF für die Software gemacht werden. - In veränderter Software muss der ursprüngliche Copyright-Vermerkt enthalten bleiben (z.B. “Copyright © 2001-2012 Python Software Foundation; All Rights Reserved”) PyCon DE 2012 > Grundlagen des Open-Source-Lizenzrechts > A. Schreiber > 30.10.2012 www.DLR.de • Folie 42
43. Apache Software License (kein Copyleft) Rechte des Lizenznehmers: - Einfaches, unbeschränktes Nutzungsrecht an jedermann, die Software zu benutzen, zu vervielfältigen, zu verbreiten, zu bearbeiten (V1.0 und 1.1) - zusätzlich öffentlich zugänglich machen und Unterlizenzierung, Patentlizenz (V 2.0) PyCon DE 2012 > Grundlagen des Open-Source-Lizenzrechts > A. Schreiber > 30.10.2012 www.DLR.de • Folie 43
44. Apache Software License (kein Copyleft) Pflichten des Lizenznehmers (V 1) - bei Weitergabe der Software im Source- oder Objektcode - Urheberrechtsvermerk im Original beibehalten - Lizenzbestimmungen mitliefern - Hinweis auf Haftungs- und Gewährleistungsausschluß - Veränderte Versionen dürfen nicht unter dem Begriff „Apache“ vertrieben werden - Pflichthinweis auf apache.org – auch in Werbematerialien - Pflicht zur Weitergabe des Source Code besteht nicht PyCon DE 2012 > Grundlagen des Open-Source-Lizenzrechts > A. Schreiber > 30.10.2012 www.DLR.de • Folie 44
45. Apache Software License (kein Copyleft) Pflichten des Lizenznehmers (V 1.1) - bei Weitergabe der Software im Source- oder Objektcode - Urheberrechtsvermerk im Original beibehalten - Lizenzbestimmungen mitliefern - Hinweis auf Haftungs- und Gewährleistungsausschluß - Veränderte Versionen dürfen nur mit Zustimmung von Apache unter dem Begriff „Apache“ vertrieben werden - Pflichthinweis auf apache.org – in Werbematerialien: nein - Pflicht zur Weitergabe des Source Code besteht nicht PyCon DE 2012 > Grundlagen des Open-Source-Lizenzrechts > A. Schreiber > 30.10.2012 www.DLR.de • Folie 45
46. Apache Software License (kein Copyleft) Pflichten des Lizenznehmers (V 2.0) - bei Weitergabe der Software im Source- oder Objektcode - Bei Änderungen  Änderungshinweise - Bei Vertrieb im Source Code dürfen keine Urheber-, Patent- oder Markenrechtshinweise gelöscht werden - Textdatei „Notice“ weitergeben - Lizenzbestimmungen mitliefern - Hinweis auf Haftungs- und Gewährleistungsausschluß - Veränderte Versionen dürfen nur mit Zustimmung von Apache unter dem Begriff „Apache“ vertrieben werden - Pflicht zur Weitergabe des Source Code besteht nicht - Eigene Änderungen dürfen explizit unter abweichenden Bedingungen weitergegeben werden, soweit sie der Apache- Lizenz nicht widersprechen PyCon DE 2012 > Grundlagen des Open-Source-Lizenzrechts > A. Schreiber > 30.10.2012 www.DLR.de • Folie 46
47. Artistic Software License (Perl) (Lizenz mit Wahlmöglichkeit) Rechte des Lizenznehmers: - Recht zur Vervielfältigung, Verbreitung, öffentliche Zugänglichmachung in unveränderter Form - Recht zur Veränderung sowie Vertrieb der veränderten Version - Verbreitung im Objektcode erlaubt PyCon DE 2012 > Grundlagen des Open-Source-Lizenzrechts > A. Schreiber > 30.10.2012 www.DLR.de • Folie 47
48. Artistic Software License (Perl) (Lizenz mit Wahlmöglichkeit) Pflichten des Lizenznehmers - bei Weitergabe der Software im Source- oder Objektcode - Urheberrechtsvermerk - Weitergabe Haftungsausschluß - Bei Änderungen des Gesamtpaketes: Einhaltung einer der folgenden vier Bedingungen: 1. Modifizierungen als kostenlose Public Domain 2. Nutzung nur für den internen Gebrauch 3. proprietäre Nutzung unter anderem Namen (unter zusätzlichen Auflagen) 4. Lizenzvertrag mit dem Urheber der Ursprungsversion PyCon DE 2012 > Grundlagen des Open-Source-Lizenzrechts > A. Schreiber > 30.10.2012 www.DLR.de • Folie 48
49. Nutzung von Open-Source-Software • Nutzungsformen von Software • Integration von Open-Source-Software in eigene Entwicklungen • Rechtsfolgen bei Lizenzverletzung PyCon DE 2012 > Grundlagen des Open-Source-Lizenzrechts > A. Schreiber > 30.10.2012 www.DLR.de • Folie 49
50. Warum Open Source Software nutzen? - Unabhängigkeit von einem bestimmten Hersteller - Erweiterungen oder Fehlerbeseitigung können selbst durchgeführt (oder beauftragt) werden - Unterschied zu proprietärer Software - Keine oder wenige Bedingungen - Nutzung durch beliebige Nutzerzahlen - Keine Lizenzkosten bei Vervielfältigung - Einblick in den Quellcode ist möglich - Analyse der Softwarequalität - Prüfung auf schädliche Funktionen (Backdoors, Spionagefunktionen) PyCon DE 2012 > Grundlagen des Open-Source-Lizenzrechts > A. Schreiber > 30.10.2012 www.DLR.de • Folie 50
51. Nutzungsformen von Software Eigenständigkeit von Software - Eigenständige Programme mit unterschiedlichen Lizenzbedingungen werden zusammen benutzt und vertrieben - Frage der Lizenzkompatibilität stellt sich nicht. - Nutzung von Software über Schnittstellen - Programmierschnittstellen (APIs) und Systemaufrufe - Bei Systemaufrufen meist Eigenständigkeit - Eigenständigkeit bei API nicht eindeutig - Kommunikationsschnittstellen (Inter-process communication, …) - Kommunikation zwischen unabhängigen Programmen, daher i.d.R. Eigenständigkeit - Komponentenschnittstellen (Plugins, Kernelmodule, …) - Eigenständigkeit ist nicht eindeutig PyCon DE 2012 > Grundlagen des Open-Source-Lizenzrechts > A. Schreiber > 30.10.2012 www.DLR.de • Folie 51
52. Integration von Open-Source-Software in eigene Entwicklungen - Werden Softwaremodule verwendet, die unterschiedlichen Lizenzbedingungen unterliegen:  rechtzeitig prüfen, ob die Lizenzbedingungen miteinander kompatibel sind! PyCon DE 2012 > Grundlagen des Open-Source-Lizenzrechts > A. Schreiber > 30.10.2012 www.DLR.de • Folie 52 Wichtig: Lizenzkompatibilität prüfen!
53. Verteilung der Software Software, die Open Source mit „kritischer“ Lizenz enthält: - Bei Inkompatibilität der Lizenzbedingungen durch entsprechende Programmierung dafür sorgen, dass insoweit nicht derivative, sondern separate work entsteht - Bei der Weitergabe der Software durch technische Maßnahmen (z.B. separate Ordnerstruktur) dafür sorgen, dass die Software nicht als part of the whole erscheint PyCon DE 2012 > Grundlagen des Open-Source-Lizenzrechts > A. Schreiber > 30.10.2012 www.DLR.de • Folie 53 Vorsicht bei Kopieren von Quellcodeausschnitten in eigene Dateien!
54. Lizenzkompatibilität Ausgangsfall: - Es werden Software-Komponenten miteinander kombiniert, die unterschiedlichen Lizenzbedingungen unterliegen Problem: - Je nach Konstellation sind die unterschiedlichen Lizenzbedingungen zueinander nicht kompatibel, d.h. man kann entweder nur die eine oder die andere Lizenzbedingung erfüllen, aber nicht alle gleichzeitig - Das Problem tritt bei Copyleft-Bedingungen auf, wenn Open-Source- Programme so miteinander verbunden werden, dass die Programme nicht mehr eigenständig sind (Grund: Veränderungsverbot der Lizenzbedingungen) - Programmkomponenten ohne Copyleft können i.d.R. beliebig miteinander kombiniert werden, ohne daß dies zu Inkompatibilität führt PyCon DE 2012 > Grundlagen des Open-Source-Lizenzrechts > A. Schreiber > 30.10.2012 www.DLR.de • Folie 54
55. Lizenzkompatibilität Drei Fragen: 1. Bilden zwei oder mehr Softwarebestandteile voneinander abgeleitete Werke? 2. Unterliegt auch nur eines dieser Werke einer Copyleft- Lizenzbestimmung? 3. Enthalten die beteiligten Non-Copyleft-Bedingungen Regelungen, die mit dieser Copyleft-Bestimmung nicht vereinbar sind? (Kompatibilitätsklauseln (z.B. der LGPL) greifen nicht?) PyCon DE 2012 > Grundlagen des Open-Source-Lizenzrechts > A. Schreiber > 30.10.2012 www.DLR.de • Folie 55
56. Lizenzkompatibilität Beispiele Apache 2.0 Mod. BSD CPL/EPL GPL v2    GPL v3    LGPL v2    LGPL v3    PyCon DE 2012 > Grundlagen des Open-Source-Lizenzrechts > A. Schreiber > 30.10.2012 www.DLR.de • Folie 56
57. Weitere Beispiele finden sich bei Wikipedia… PyCon DE 2012 > Grundlagen des Open-Source-Lizenzrechts > A. Schreiber > 30.10.2012 www.DLR.de • Folie 57 License Author Latest version Publication date Link with code using a different license Release changes under a different license Common Development and Distribution License Sun Microsystems 1.0 December 1, 2004 Yes Yes Artistic License Larry Wall 2.0 2000 Yes With restrictions Apple Public Source License Apple Computer 2.0 August 6, 2003 Yes No Cryptix General License Cryptix Foundation ? 1995 Yes Yes Eclipse Public License Eclipse Foundation 1.0 February 2004 Yes No Educational Community License ? 1.0 ? Yes Yes Common Public License IBM 1.0 May 2001 Yes No Code Project Open License The Code Project 1.0 2007 Yes No Fair Licence ? N/A 2004 Yes Yes EUPL European Commission 1.1 January 2009 Yes With an explicit compatibility list Eiffel Forum License NICE 2 2002 Yes Yes http://en.wikipedia.org/wiki/Comparison_of_free_software_licenses
58. Lizenzkompatibilität Lizenzkompatibilität innerhalb der GPL Problem Wahlrecht: - Der Lizenzgeber kann wählen, ob der Lizenznehmer die GPL in der Version „only“ oder in der Version „any version later“ anzuwenden hat  GPLv2 und GPLv3 sind nicht miteinander kompatibel, wenn die GPLv2 in der Version only verwendet wird (z.B. bei Linux).  GPLv2 und GPLv3 sind jedoch dann kompatibel, wenn für die GPLv2 die Version any gilt. Im Übrigen siehe Kompatibilitätslisten unter www.gnu.org/licenses/license-list.html PyCon DE 2012 > Grundlagen des Open-Source-Lizenzrechts > A. Schreiber > 30.10.2012 www.DLR.de • Folie 58
59. Veröffentlichung eigener Software unter einer Open-Source-Lizenz • Auswahl der richtigen Open-Source-Lizenz • Bereitstellung von Open-Source-Software PyCon DE 2012 > Grundlagen des Open-Source-Lizenzrechts > A. Schreiber > 30.10.2012 www.DLR.de • Folie 59
60. Gründe zur Veröffentlichung als Open Source Was will man erreichen? - Hohe Verbreitung der Software - Sichtbarkeit in Communities - Höhere Chancen auf Projektbeteiligungen - Steigerung der Attraktivität als Arbeitgeber PyCon DE 2012 > Grundlagen des Open-Source-Lizenzrechts > A. Schreiber > 30.10.2012 www.DLR.de • Folie 60 Wunsch nach Veröffentlichung als Open Source mit Begründung durch die Verantwortlichen
61. Randbedingungen Grundlage für die Entscheidung - Kommerzielle Interessen - Geheimhaltung / Exportkontrolle - Bestehende Communities - Apache Software Foundation - Eclipse Foundation - Forschungsinitiativen - Anforderungen der Geldgeber - Aufträge und Projekte PyCon DE 2012 > Grundlagen des Open-Source-Lizenzrechts > A. Schreiber > 30.10.2012 www.DLR.de • Folie 61 Entscheidung durch Leitung nach Abwägung der Randbedingungen
62. Verwendung von Open Source Software in öffentlichen Förderprojekten - Bereits im Angebot / Förderantrag klar offenlegen, dass im Projekt Open- Source-Software verwendet wird - Möglichst bereits im Angebot / Förderantrag offenlegen, welche Lizenzbedingungen diese Software haben wird PyCon DE 2012 > Grundlagen des Open-Source-Lizenzrechts > A. Schreiber > 30.10.2012 www.DLR.de • Folie 62
63. Auswahl der richtigen Open-Source-Lizenz Das Ziel klären Fragen: - Welche Lizenz soll die zu erstellende Software haben? - Wie soll die Software verteilt werden? - Teil einer Community mit vorgegebenen Lizenzen? - Auf welchen Softwaremodule basiert die neue Software? PyCon DE 2012 > Grundlagen des Open-Source-Lizenzrechts > A. Schreiber > 30.10.2012 www.DLR.de • Folie 63 Veröffentlichung als Open Source: Lizenzauswahl Wichtig: In jedem Fall Lizenzkompatibilität mit den verwendeten Softwaremodulen prüfen!
64. Auswahl der richtigen Lizenz PyCon DE 2012 > Grundlagen des Open-Source-Lizenzrechts > A. Schreiber > 30.10.2012 www.DLR.de • Folie 64 Randbedingungen für die Lizenz klären Keine eigene Lizenz erstellen, wenn es sich vermeiden lässt! Möglichst eine Lizenz wählen, die der Open-Source-Definition der OSI genügt.
65. Bereitstellung von Open-Source-Software Möglichkeiten der Verteilung - Software wird nicht angeboten (In-House-Nutzung) - Software wird als Binärpaket zum Download angeboten - Software wird mit Source Code zum Download angeboten - Software liegt komplett auf einer öffentlichen Hosting-Plattform - SourceForge.net - code.google.com - eclipse.org - github.com - ... PyCon DE 2012 > Grundlagen des Open-Source-Lizenzrechts > A. Schreiber > 30.10.2012 www.DLR.de • Folie 65 Veröffentlichung als Open Source: Bereitstellung der Software
66. Credits Credits Rainer Tritz-Floßdorf ( D L R Te c h n o l o g i e m a r k e t i n g )
67. PyCon DE 2012 > Grundlagen des Open-Source-Lizenzrechts > A. Schreiber > 30.10.2012 www.DLR.de • Chart 67 Fragen? Kontakt Twitter: @onyame Andreas.Schreiber@dlr.de