OPEN SOURCE LEXIKON

  • BSDartige Lizenzen
  • Copyleft
  • Copyright Notice
  • Derivative Work
  • Headerfiles
  • LGPL
  • Lizenzen mit beschränktem Copyleft
  • Lizenzen mit strengem Copyleft
  • Lizenzen ohne Copyleft
  • Open Source
  • Open Source Compliance
  • Permission Notice
  • Pflichtangaben
  • Proprietäre Software
  • Source Code
  • Unterlizenzierung
  • Würzburger Open Source Standard
  • Würzburger Standard
  • Würzburger Taxonomie der Lizenzen
  • Zeaderfiles

Die BSDartigen Lizenzen haben die größte Nähe zu Public Domain Software. Sie gestatten die Nutzung der Software auch ohne dass eigene Source Codes freigegeben werden müssen. Die Zulässigkeit der Benutzung steht jedoch unter der Bedingung, dass bestimmte Pflichtangaben zusammen mit der Software angegeben werden. Diese sind:

- Der Copyrightvermerk

- der Disclaimer und

- der Lizenztext, der in der Regel den Disclaimer enthält.

Die Abkürzung BSD steht für Berkeley Software Distribution. Von der Lizenz werden typischerweise 3 Varianten verwendet, eine mit 2 Klauseln, eine mit 3 Klauseln und eine mit 4 Klauseln.

Weiterlesen

Der Begriff Copyleft beschreibt eine lizenzrechtliche Konstruktion, vor allem bei Lizenzen mit strengem Copyleft, bei dem eine Lizenz unter der auflösenden Bedingung gewährt wird, dass der jeweilige Nutzer seinerseits ein Nutzungsrecht an jedermann einräumt. Mit diesem Effekt soll erreicht werden, dass als Gegenleistung für die quelloffene Zurverfügungstellung von Software Weiterentwicklungen der Community bereit stehen.

Die rechtliche Wirksamkeit des Copyleft Effektes wurde im Ergebnis erfolglos in Frage gestellt. Vor Gericht wurde ein Verstoß gegen Kartellrecht, AGB-Recht oder urheberrechtliche Grundsätze vorgebracht, was bisher jedoch noch kein Gericht überzeugt hat. Die grundsätzliche Wirksamkeit von Open Source Lizenzen mit Copyleft ist in der Rechtsprechung derzeit unbestritten.

Weiterlesen

auch: Copyright-Vermerk oder Urhebervermerk

Werkbezogene Kennzeichnung eines Urhebers oder Rechteinhabers. Die Copyright Notice besteht typischerweise aus dem Copyright-Zeichen (c), dem Rechteinhaber und einer Jahreszahl. Während früher der Copyright-Vermerk für die Entstehung von Urheberrechten zumindest im US-Recht eine Bedeutung hat, ist er heute für die Begründung von Rechten weitgehend bedeutungslos. Gleichwohl wird die Tradition jedoch fortgeführt, die Copyright-Vermerke zu platzieren und deren Anbringung von Lizenznehmern zu fordern. Die meisten Open Source Lizenzen verlangen die Anbringung von Copyright-Vermerken.

Die Copyright Notice weist häufig gerade nicht den tatsächlichen Urheber aus, sondern denjenigen, der die Nutzungsrechte wahrnimmt. Gerade bei urheberrechtlichen Schöpfungen im Unternehmen fallen Urheber und Rechteinhaber auseinander.

Der häufig verwendete Satz "All rights reserved" ist nach dem Würzburger Open Source Standard Teil der Copyright Notice und muss daher mit ausgeliefert werden unabhängig davon ob diese drei Wörter ansonsten eine rechtliche Folge auslösen.

Weiterlesen

Der Begriff Derivative Work ist ein Kernelement der GPLartigen Lizenzen. Vom Vorliegen eines Derivative Work kann es abhängen, ob eine Verpflichtung besteht, eigenen Source Code unter Open Source Lizenz freizugeben oder ob er als closed Source Software vertrieben werden darf. Der Begriff lässt sich zunächst abstrakt oder kasuistisch hinsichtlich der eindeutigen Fallkonstellation erläutern. Große Schwierigkeiten bereitet er jedoch bei den genauen Fragen der Abgrenzung. Beginnen wir daher zunächst mit der allgemeinen Begriffsbestimmung und den eindeutigen Konstellationen.

Derivative Work ist ein Begriff aus dem amerikanischen Copyright Act, allerdings spielt für die Auslegung der GPL häufig auch nationales, insbesondere auch deutsches Urheberrecht, eine Rolle. Eine mögliche Übertragung wäre der Begriff "Bearbeitung" aus dem deutschen Urheberrecht, es wird jedoch sehr schnell klar, dass der deutsche Rechtsbegriff der Bearbeitung aus § 3 UrhG für die Deifinition zu kurz greift. Wir würden den Begriff Derivative Work wie folgt abstrakt definieren:

"Ein Derivative Work ist ein urheberrechtlich schützbares Werk, das entweder durch Bearbeitung oder Verbindung in der Form von einem anderen Werk abgeleitet wurde, dass die beiden Bestandteile in funktionaler Hinsicht eine Einheit bilden."

Bei genauerer Betrachtung dieser Definition muss man feststellen, dass gerade die Frage der funktionalen Einheit im Einzelfall sehr unterschiedlich gesehen werden kann. Bei Software, die in Hardware fest eingebettet ist, besteht immer die Versuchung, das gesamte Gerät als eine Einheit zu betrachten ohne auch nur zwischen Betriebssystem und Anwendungsprogrammen zu unterscheiden, da für den Endanwender eine wertige Unterscheidung ebenfalls kaum sichtbar und nutzbar ist. Das andere Extrem wäre eine Lesart, wonach Derivative Work so lange nicht vorliegt, wie es sich um getrennt ablauffähigen Source Code handelt, der über definierte Schnittstellen Daten mit anderen Programmen austauscht.

Fallgruppen

Veränderter Source Code

Einigkeit besteht, dass immer dann ein derivative Work vorliegt, wenn Source Code erheblich verändert und danach kompiliert wird. Das hier eingefügte Kriterium der Erheblichkeit verursacht wieder neue Abgrenzungsschwierigkeiten. Aus urheberrechtlicher Sicht wäre die Veränderung einzelner Parameter oder Variablennamen noch keine Bearbeitung; selbst die Beseitigung von Fehlern kann nach § 69d UrhG zustimmungsfrei sein, gleichwohl aber ein derivative work auslösen. Wir empfehlen daher bei jeder auch kleinen Bearbeitung die GPL zu beachten.

Statische Verlinkung

Wird eine unter GPL stehende Software statisch verlinkt und dann untrennbar in eine Binärdatei mit anderen Komponenten vermischt, so liegt in der Regel ein derivative work vor. Ausnahmen sind denkbar.

Übernommene Snippets

Häufig werden einzelne Codezeilen aus einem Programm in ein anderes kopiert. Soweit es sich dabei um urheberrechtlich schutzfähige Werke handelt, liegt darin auch ein derivative work.

Dynamische Verlinkung

Die Herausgeber der GPL-Lizenzen sehen in jeder Art der Verlinkung in der Regel auch derivative work. Wir sind der Auffassung, dass es auf die Funktion und die Richtung der Verlinkung ankommt. Zur Vermeidung dieser Streitfragen wurde die LGPL geschaffen, die für bestimmte Verknüpfungsarten ausdrückliche Ausnahmen vorsieht.

Weiterlesen

Headerfiles sind Teile vom Source Code mit der Beschreibung von Funktionen. Headerfiles enthalten in den meisten Fällen keine Programmfunktion, so dass strittig ist, ob Headerfiles dem urheberrechtlichen Schutz überhaupt unterliegen. Diese Frage wird im Open Source Recht vor allem dadurch akut, dass bei Open Source Projekten häufig nur die Headerfiles, nicht aber die übrigen Source Code-Dateien in ein Projekt eingebunden werden. Da die Headerfiles häufig Lizenzvermerke enthalten, entstehen bei Source Code-Scans zunächst Lizenzkonflikte, die sich bei näherer Betrachtung jedoch oft als unbedenklich herausstellen.

Nach dem Würzburger Open Source Standard können Headerfiles frei verwendet werden, solange sie keine Programmierbefehle enthalten, sondern ausschließlich Dateien und Funktionen referenzieren. Headerdateien mit Datentabellen, z. B. zur Konvertierung von Zeichensätzen, unterliegen nach unserer Auffassung den urheberrechtlichen Leistungsschutzrecht des Datenbankherstellers und erfordern daher die Beachtung der ausgewiesenen Lizenz selbst dann, wenn keine Programmierbefehle enthalten sind.

Für die Open Source Software Qt existiert eine eigene LGPL-Exception, die die Verwendung von Headerfiles unter bestimmten Bedingungen ausdrücklich zulässt. Die Existenz dieser Ausnahme kann dahingehend interpretiert werden, dass ohne die Ausnahme die Verwendung rechtswidrig wäre oder in der anderen Richtung, dass mit der Ausnahme nur das klargestellt wird, was ohnehin Intension der LGPL war, nämlich die Zulässigkeit der Einbindung von austauschbaren Librarys, wofür die Einbindung von Headerfiles in der Regel erforderlich ist.

Weiterlesen

Die Lesser General Public License erscheint meistens in den Versionen 2.1 oder 3.0. Die Lizenz ist eine Abwandlung der GPL und gestattet die Verbindung von Open Source Software unter LGPL mit proprietären oder anderweitig lizensierten Source Code auch ohne Freigabe des eigenen Source Codes wenn bestimmte Bedingungen eingehalten sind. Vereinfacht könnte man behaupten, die LGPL Software darf verwendet und weitergegeben werden, wenn sie lediglich dynamisch verlinkt wird. Tatsächlich taucht der Begriff dynamische Verlinkung im Lizenztext nirgendwo auf, sodass die genaue Abgrenzung wann die Ausnahmen zum Copyleft Effekt eingreifen, im Einzelfall schwer fallen.

Übersehen wird häufig, dass selbst bei Vorliegen einer dynamischen Verlinkung die Verpflichtung bestehen bleibt, Lizenztext und unter Umständen auch Source Codes der LGPL Software mitzuliefern. Eine entsprechende Verletzung führte bereits zu einem Urteil gegen einen Softwarehersteller, der eher versehentlich eine LGPL Komponente aus seiner Distributions-CD mitlieferte, ohne dabei jedoch die Lizenzbedingungen vollständig einzuhalten.

Weiterlesen

Unter dieser Kategorie fassen wir Lizenzfamilien zusammen, bei denen der Eintritt des Copyleft Effektes von der Art der Verknüpfung abhängt. Typische Vertreter sind die LGPL, CDDL und MPL. Die jeweiligen Lizenzfamilien in dieser Kategorie sind sehr unterschiedlich, sodass sich die rechtliche Prüfung anders als beispielsweise bei den liberalen Lizenzen nicht nach einem Standardschema richtet.

Weiterlesen

auch: reciprocal License

Unter dieser Kategorie fassen wir Lizenzen zusammen, die einen strengen Copyleft Effekt vorsehen. Typische Vertreter sind die GPLartigen Lizenzen (GPL v2.0, GPL v3.0, AGPL, EPL, CPL). Nicht hierzu gehört die LGPL, die zur Kategorie der Lizenzen mit beschränktem Copyleft gehört.

GPLartige Lizenzen verlangen, dass mit der Open Source Software zugleich auch der Source Code bereitgestellt wird. Die Bereitstellung von Source Code kann je nach Lizenz durch ein schriftliches Angebot, auf einem beigefügten Datenträger oder per Download erfolgen. Der Copyleft Effekt führt dazu, dass GPLartige Software teilweise nur dann mit eigenem Code oder anderer Open Source Software verbunden werden darf, wenn diese Software ebenfalls quelloffen bereitgestellt wird oder unter eine kompatiblen Lizenz steht.

Weiterlesen

auch liberale Lizenz oder permissive License

Unter diesem Begriff fassen wir diejenigen Lizenzfamilien zusammen, die eine Freinutzung von Open Source Software ohne jeglichen Copyleft Effekt vorsehen und nicht die Weitergabe von Source Codes verlangen. Typische Lizenzfamilien innerhalb der Kategorie der liberalen Lizenzen sind die BSDartigen Lizenzen oder die Lizenzarten Apache, Boost oder MIT.

Typische Verpflichtungen bei liberalen Lizenzen sind die nachfolgenden Pflichten:

- Beifügung eines Copyrightvermerks

- Beifügung eines Disclaimers

- Beifügung des Lizenztextes.

Eine besondere Herausforderung besteht darin, dass die vorgenannten Pflichtangaben zusammen mit der Software mitgegeben werden müssen. Wird die Software im Source Code bereitgestellt, befinden sich diese Texte meistens in den Source Codes oder in beigefügten Textdateien. Bei einer binären Weitergabe muss entweder ein Datenträger mitgegeben werden oder die Lizenz vom Programm selbst wiedergegeben werden.

Weiterlesen

Mit Open Source bezeichnet man im engeren Wortsinn Software, die quellenoffen und kostenlos für jedermann zugänglich ist. Tatsächlich wird Open Source Software jedoch häufig auch ohne die Source Codes und in binärer Form weitergegeben, was bei liberalen Lizenzen auch zulässig ist. Nach der Würzburger Taxnomie wird Open Source Software je nach Copyleft-Effekt in drei Unterkategorien unterteilt. Abzugrenzen ist Open Source Software von freier Software, wie z.B. Freeware und kommerzieller Software.

Weiterlesen

Unter dem Begriff Open Source Compliance verstehen wir den unternehmensinternen Vorgang, Softwareentwicklung und Softwarebeschaffung so zu gestalten, dass Verstöße gegen Open Source Lizenzbedingungen vermieden werden. Eine besondere Herausforderung besteht darin, dass für Open Source Compliance sowohl technische Kenntnisse, als auch im überschaubaren Umfang juristische Spezialkenntnisse erforderlich sind. Unternehmen sind daher häufig zumindest in der Anfangsphase oder bei der Etablierung von Prozessen auf externe Hilfe angewiesen.

Unterstützung bei Open Source Compliance bieten dabei sowohl IT-Unternehmen, als auch IT-Fachanwälte. Ansatz und Grenzen sind dabei meistens unterschiedlich.

Unternehmen, die sich auf Open Source Compliance spezialisiert haben, bieten häufig Software zur Verwaltung von Open Source Projekten oder zum scannen von Software an, ziehen sich jedoch zurück, wenn es um rechtliche Beurteilungsfragen geht. Anwälte können zwar die Rechtsfragen beantworten und haben das dafür notwendige technische Verständnis, entwickeln in den meisten Fällen jedoch keine eigenen Tools und manche Anwälte sind unerfahren bei prozessorientierter Unternehmensberatung.

Weiterlesen

Die Permission Notice enthält Angaben darüber, welche Nutzungsrechte ein Nutzer hat. Zur Permission Notice gehört auch der Hinweis, welche Lizenz Anwendung findet.

Praktisch stellt sich die Frage, welcher Text wiedergegeben werden muss, wenn ein Lizenztext die Anbringung von Copyright Notice und Permission Notice verlangt. Bei kurzen Lizenzen ist der Lizenztext und die Permission Notice kaum voneinander zu unterscheiden, wie z.B. bei der MIT License. Hier ist die Permission Notice mit dem Lizenztext identisch. Der Disclaimer, dessen Veröffentlichung z.B. bei der BSD License eigens Erwähnung findet, ist dagegen eigentlich nicht Teil der Permission Notice, wohl aber Teil des Lizenztextes.
 Im Zweifel empfehlen wir sämtliche vorhandenen Angaben mitzuführen.

The MIT License (MIT)

Copyright (c) <year> <copyright holders>

Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in
all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
THE SOFTWARE.

Weiterlesen

Unter Pflichtangaben verstehen wir diejenigen Angaben, die gemäß Lizenztext einer Open Source Lizenz mit der Software mitgeliefert werden müssen. Bestandteile könne je nach Lizenz dabei sein:

  • Copyright Notice
  • Permission Notice
  • Disclaimer
  • Lizenztext

Nicht zu den Pflichtangaben gehört der Source Code.

Weiterlesen

auch: kommerzielle Software

Alles was nicht Freie Software oder Open Source Software ist, fällt unter die Kategorie der proprietären/ kommerziellen Software. Dabei kommt es nicht darauf an, dass mit der Software eine Gewinnerzielungsabsicht verfolgt wird. Bei proprietärer Software ist typischerweise ein (nicht notwendig entgeltlicher) Lizenzerwerb vom Rechteinhaber erforderlich. Kommerzielle Software kann auch kostenlos verbreitet werden etwa in Form von Demo-Versionen oder Shareware.

Weiterlesen

auch: Quellcode

Umfasst dabei gelegentlich auch Textdateien, die nicht Programmcode enthalten, wie beispielsweise mitgelieferte Lizenz-Texte, Dokumentationen oder Kompilierungsanweisungen. Source Code wird abgegrenzt zum Objekt Code (auch Binärcode). Die Verfügbarkeit von Source Code ist in der Regel technische Voraussetzung für die Bearbeitung und Überprüfung von Software. Durch Dekompilierung ist es mit Einschränkungen möglich, aus einem Binärcode Source Code zu gewinnen.

Weiterlesen

Die meisten Open Source Lizenzen sehen keine Unterlizenzierung vor. Das ist eine wesentliche Abweichung zwischen proprietären Lizenzen, die meistens eine Kette von Unterlizenzen vorsehen, und der Lizenzierung von Open Source Software. Bei Open Source erhält der jeweilige Nutzer seine Lizenz immer direkt vom Rechteinhaber. Es existiert keine Lizenzkette, so dass Fehler innerhalb dieser Kette auch nicht zum Erlöschen der Lizenz führen können.

Weiterlesen

Der Würzburger Open Source Standard ist eine Methode zur Überprüfung von Open Source Projekten auf rechtliche Sicherheit. Der Standard besteht aus zwei Abschnitten:

  1. Beschreibung eines standardisierten Verfahrens zum Prüfungsablauf
  2. Inhaltliche Vorgaben zur Entscheidung von Streitfragen im Bereich von Open Source

Prüfungsablauf

Der technische Teil der Prüfung basiert dabei auf einer automatisierten Prüfung, wie sie beispielsweise von Black Duck durchgeführt wird. Die technischen Prüfungsergebnisse werden bei relevanten Lizenzen ergänzt durch Angaben zur Veränderung, Weitergabe und Verlinkung. Hierauf folgt eine vollständige juristische Analyse mit detaillierter Aufdeckung etwaiger Rechtsrisiken. Dazu werden die Open Source Komponenten nach der zugehörigen Lizenz in das Schema der Würzburger Taxonomie klassifiziert.

Materieller Teil

Der inhaltliche Teil trifft Annahmen zu typischen Streitfragen, die gerade bei den komplizierteren Lizenzen mit Copyleft auftreten und bisher uneinheitlich entschieden werden. Der Würzburger Open Source Standard verfolgt dabei eine ausgewogene Rechtsposition, die weder Rechteinhaber noch Entwickler über Gebühr benachteiligt. Der Standard eignet sich daher auch als Grundlage für Ausschreibungen und Beauftragungen.

Anwendungsbereich

Der Würzburger Open Source Standard bietet sich an als Vertragsgrundlage bei der Beschaffung von Open Source Software. Die Parteien ersparen sich dadurch das detallierte Ausverhandeln und Definieren von rechtlichen und technischen Eigenschaften, die zu Beginn des Beschaffungsprozess noch gar nicht als Problem erkannt wurden. Der Standard ermöglicht auch einen klar vorgegebenen Prüfungsablauf und vermeidet Streit und Zeitverzug.

s. auch: Reichen meine Einkaufsbedingungen nicht aus?

Herkunft

Der Würzburger Standard wurde von der IT-Rechts-Kanzlei Jun Rechtsanwälte entwickelt. Er basiert auf den Erfahrungen und herausgebildeten Leitlinien, die bei über 600 Open Source Fallprüfungen angesetzt wurden. Die Wertungen werden bisher schon in der Automobilbranche auf Herstellerseite zur Überprüfung der zugelieferten Software eingesetzt.

Weiterlesen

Kurzform für Würzburger Open Source Standard.

Weiterlesen

Die Würzburger Taxonomie ist ein Gliederungsschema für Softwarelizenzen. Ziel der Einteilung ist dabei die Zusammenfassung von Open Source Lizenzarten in Gattungen, Familien und Klassen, um je nach Gemeinsamkeiten einheitliche rechtliche Überprüfungen zu ermöglichen. Gerade bei computergestützer Rechtsprüfung ist es erforderlich,

  • die Komplexität von Lizenzen auf die wesentlichen für die Prüfung relevanten Punkte zu reduzieren und
  • die Vielfalt von Lizenzen durch Gruppierungen zu reduzieren
  • ohne Genauigkeit und Zuverlässigkeit einzubüßen.

Wichtigstes Unterscheidungsmerkmal ist dabei die Copyleft-Wirkung. Hier geht es um die Frage, wie hoch die Anforderungen der Lizenz an den Benutzer sind, um eine Veröffentlichung ohne eigene Codefreigabe zu gestatten. Hier teilen sich die Open Source Lizenzen in drei Klassen ein:

  • starkes Copyleft
  • beschränktes Copyleft
  • ohne Copyleft.

Lizenzen mit starkem Copyleft wie etwa die GNU GPLv2.0 verlangen etwa dass sämtliche Beabeitungen oder abgeleiteten Werke (derivative work) ebenfalls unter eine kompatible Lizenz gestellt werden, während die Lizenzen ohne Copyleft, wie etwa die BSD License, jede Bearbeitung und Weitergabe unter kommerzieller Lizenz gestattet.

Weiterlesen

Headerfiles sind Teile vom Source Code mit der Beschreibung von Funktionen. Headerfiles enthalten in den meisten Fällen keine Programmfunktion, so dass strittig ist, ob Headerfiles dem urheberrechtlichen Schutz überhaupt unterliegen. Diese Frage wird im Open Source Recht vor allem dadurch akut, dass bei Open Source Projekten häufig nur die Headerfiles, nicht aber die übrigen Source Code-Dateien in ein Projekt eingebunden werden. Da die Headerfiles häufig Lizenzvermerke enthalten, entstehen bei Source Code-Scans zunächst Lizenzkonflikte, die sich bei näherer Betrachtung jedoch oft als unbedenklich herausstellen.

Nach dem Würzburger Open Source Standard können Headerfiles frei verwendet werden, solange sie keine Programmierbefehle enthalten, sondern ausschließlich Dateien und Funktionen referenzieren. Headerdateien mit Datentabellen, z. B. zur Konvertierung von Zeichensätzen, unterliegen nach unserer Auffassung den urheberrechtlichen Leistungsschutzrecht des Datenbankherstellers und erfordern daher die Beachtung der ausgewiesenen Lizenz selbst dann, wenn keine Programmierbefehle enthalten sind.

Für die Open Source Software Qt existiert eine eigene LGPL-Exception, die die Verwendung von Headerfiles unter bestimmten Bedingungen ausdrücklich zulässt. Die Existenz dieser Ausnahme kann dahingehend interpretiert werden, dass ohne die Ausnahme die Verwendung rechtswidrig wäre oder in der anderen Richtung, dass mit der Ausnahme nur das klargestellt wird, was ohnehin Intension der LGPL war, nämlich die Zulässigkeit der Einbindung von austauschbaren Librarys, wofür die Einbindung von Headerfiles in der Regel erforderlich ist.

Weiterlesen


SITEMAP

  • KONTAKT

    JunIT | Kanzlei für IT- und Wirtschaftsrecht

    Salvatorstr. 21, DE-97074 Würzburg

    +49 931.6639.232

    +49 931.52235

    info@kanzlei-jun.de

    Mo-Do: 08.00 - 18.00 | Fr: 08.00 - 16.30