| Home | https://cusy.io |
| GitHub | https://github.com/cusyio |
| https://www.linkedin.com/company/cusy-gmbh | |
| Meetup | https://www.meetup.com/Cusy-Meetup/ |
Open-Source-Lizenzen sind für Software gedacht. Für Dokumente, Bilder, Audio/Video, Schriftarten und Hardware gibt es eigene, passgenau zugeschnittene Lizenzen. Wir verbinden häufig freie Lizenzen lediglich mit Open-Source-Software. Mit der zunehmenden Popularität freier Software übertrug sich diese Idee jedoch auch auf andere Bereiche. FOSS-Lizenzen eignen sich jedoch nur bedingt, um Dokumente, Bilder, Audio, Video, Schriftarten oder Hardware zu lizenzieren. Daher entstanden schnell spezialisierte Lizenzen für jeden dieser Bereiche. Dieser Artikel ist der vorletzte Teil unserer fünfteiligen Serie über freie Lizenzen. In den vorherigen [1] drei Artikeln [2] bezogen wir uns auf Software [3]. Nun sehen wir uns an, welche Lizenzangaben für Nicht-Software relevant sind und welche passenden freien Lizenzen es dafür gibt. Der Fokus liegt dabei auf dem Umgang mit Dokumenten, Bildern, Audio und Video, Schriftarten und Hardware. Im nächsten Teil betrachten wir dann Daten, Datenbanken und Datenmodelle. Nicht-Software-Lizenzen Tabelle „Verfügbare Lizenzen für Nicht-Software“ gibt einen Überblick über verschiedene freie Nicht-Software-Lizenzen. Haben wir zu einer Lizenz lediglich Creative Commons (CC [4]) genannt oder endet eine standardisierte Lizenzangabe [5] mittels SPDX [6] in der dritten Spalte der Tabelle mit einem Stern, heißt das, dass mehrere Varianten bestehen und der Lizenzgeber eine weitere, genauere Auswahl innerhalb der Kategorie zu treffen hat. Die Tabelle gibt nur einen ersten Überblick. Im Folgenden gehen wir noch genauer darauf ein, wie Sie Lizenzangaben in den unterschiedlichen Dateiformaten einbinden. Zunächst besprechen wir die Art und Weise der Kennzeichnung und Hinterlegung zum Werk. Danach sehen wir uns die zur jeweiligen Kategorie passenden Lizenzen genauer an. Lizenz SPDX-Angabe Dokumente Creative Commons CC0, CC-* GNU Free Documentation License GFDL-1.* FreeBSD Documentation License FreeBSD-DOC Open Publication License, Version 1.0 (OPL) OPUBL-1.0 Bilder Creative Commons CC0, CC-* Design Science License (DSL) nicht vorhanden Free Art License 1.3 LAL-1.3 Video- und Audiodaten Creative Commons CC0, CC-* Schriftarten SIL Open Font License OFL-1.* Lizenz zu LaTeX EC Fonts nicht vorhanden Arphic Public License Arphic-1999 IPA Font License IPA Hardware TAPR Open Hardware License TAPR-OHL-1.0 CERN Open Hardware License v2 CERN-OHL-P-2.0, CERN-OHL-W-2.0, CERN-OHL-S-2.0 Solderpad Hardware License SHL-0.5* Formate Informationen zu Autor, Lizenz und Verweisen zum Lizenzdokument lassen sich entweder in den Metainformationen der Datei unterbringen oder in einem separaten, mit dem Lizenzgegenstand ausgelieferten Dokument. Bei Bildern, PDF-Dateien sowie Audio- und Videodateien können Sie die Lizenzinformationen direkt in den Metadaten hinterlegen. Dabei helfen die beiden Standards EXIF [7] und XMP [8]. Das Exchangeable Image File Format EXIF stellt mehrere passende Felder [9] bereit, darunter »Exif.Image.Artist« für den Ersteller oder Fotograf und »Exif.Image.Copyright« für die Informationen zum Urheberrecht. Zur Verarbeitung dienen Werkzeuge wie Exiftool [10], Exif2 und Gimp. Das Kürzel XMP steht für Extensible Metadata Platform. Hier stehen ebenfalls Felder für den Ersteller (»Author«) und für Informationen zum Urheberrecht (»Copyright«) bereit. Zusätzlich gibt es »CreationDate« für den Erstellzeitpunkt und »Creator« für die Software, mit der die Datei erstellt wurde. In XML-Dokumenten lassen sich die Lizenzangaben direkt in der Datei speichern (Listing 1). SPDX-konform ist eine zusätzliche »*-license«-Datei zum Projekt oder Werk. Abbildung 1 zeigt das für eine PNG-Datei aus dem Tutorial Python4DataScience [11]. Die resultierende Maschinenlesbarkeit sorgt dafür, dass sich mögliche Lizenzkonflikte automatisiert erkennen lassen. Für Quellcode funktioniert der SPDX-Mechanismus bestens, bei anderen Werkarten gestaltet sich
Protomaps ist ein Open-Source-Ökosystem zum Erstellen, Speichern und Ausliefern maßgeschneiderter digitaler Karten, dessen Fähigkeiten deutlich über die der teuren kommerziellen Konkurrenz hinausgehen. Den Markt für digitale Kartendienste dominieren bislang proprietäre Anbieter wie Mapbox – mit hohen Lizenzgebühren, eingeschränkter Kontrolle über die Daten und einem starken Vendor-Lock-in. Doch mit Protomaps (Abbildung 1) gibt es längst eine leistungsfähige Open-Source-Alternative, die zahlreiche Anwendungsfälle abdeckt. Im Folgenden führen wir Sie kurz in das Dateiformat Protomaps [1] sowie die wichtigsten Unterschiede zu herkömmlichen Raster- oder proprietären Tile-Diensten ein. Anschließend sehen wir uns den kompletten Tool-Stack von Protomaps näher an. Das reicht von den Open-Source-Datensätzen von OpenStreetMap [2] über das Erstellen effizienter Tiles bis hin zu der Bereitstellung und der Integration in gängige Frontend-Bibliotheken wie MapLibre [3] und Leaflet [4]. Anhand praktischer Beispiele demonstrieren wir, wie Sie eigene Tiles generieren und selbst hosten können. Außerdem stellen wir Ihnen sinnvolle Anwendungsfälle für Protomaps vor, die die wichtigsten Vorteile gegenüber Mapbox verdeutlichen: Kostenfreiheit, Datenkontrolle und Offline-Fähigkeit. Außerdem nennen wir Alternativen für Anwendungsfälle, die keine großen, webbasierten Karten erfordern. Abschließend bieten wir einen kurzen Ausblick auf weitere Entwicklungen im Ökosystem der Open-Source-Karten. Was ist Protomaps? Protomaps ist ein Open-Source-Ökosystem zum Erstellen, Speichern und Ausliefern von Vector Tiles, dem modernen Standard für digitale Karten. Während herkömmliche Kartendienste wie Mapbox [5] ihre Daten als proprietären Service vermarkten, liefert Protomaps eine komplette Lösung, um Karten selbst bereitzustellen. Die Rohdaten werden aus OpenStreetMap (OSM [6]) eingelesen, in das effiziente PMTiles-Format transformiert und die Resultate über einen leichtgewichtigen HTTP/2-Server an Endgeräte verteilt. Das Protomaps-Projekt wurde von Brandon Liu (@bdon [7]) ins Leben gerufen, der auch weiterhin die Hauptverantwortung für die Pflege trägt. Die Finanzierung des Projekts übernahm der NGI0 Core Fund [8]. Heute trägt Github Sponsors die Kosten für die Infrastruktur, wie den Betrieb der API und des Cloud-Speichers. Ein Protomaps-Service besteht aus drei Hauptkomponenten, die das Generieren, Speichern und Ausliefern des Kartenmaterials übernehmen (siehe Tabelle „Hauptkomponenten eines Protomaps-Service“). Dabei setzt Protomaps das Unix-Paradigma „Mache nur eine Sache und mache sie gut“ um. Als zentrales Element dient das PMTiles-Format, für Speicher und Webserver kommen andere bekannte Technologien zum Einsatz. Komponente Zweck PMTiles erstellen Einlesen von Geodaten und Generieren der Tiles, beispielsweise in einer CI/CD-Pipeline. PMTiles Store Persistente Speicherung der »*.pmtiles«-Dateien etwa auf einer S3-kompatiblen Speicherplattform, die HTTP Range Requests [48] und Cross-Origin Resource Sharing (CORS [49]) unterstützt. PMTiles-Server HTTP/2-basierter Webserver, der Caching und Range Requests unterstützt, beispielsweise Caddy oder Nginx. Datengrundlage PMTiles ist ein Einzeldatei-Archivformat für Pyramiden aus gekachelten Daten. Bei den gekachelten Daten, die sich über Z/X/Y-Koordinaten adressieren lassen, kann es sich um kartografische Basiskarten, Fernerkundungsdaten, JPEG-Bilder oder anderes handeln. PMTiles arrangiert die Kacheln und Verzeichnisse so, dass das Verschieben und Zoomen mit minimalem Aufwand gelingt. Da es sich jedoch um ein schreibgeschütztes Format handelt, ist es nicht möglich, ein Archiv zu aktualisieren, ohne die gesamte Datei neu zu schreiben. Die bereitgestellten Basiskarten [9] verwenden Daten von OSM und Natural Earth [10] zum Generieren der »*.pmtiles«-Dateien. Das Format enthält jedoch nicht alle Daten und Tags aus OSM. Es versucht, für eine Verwendung als allgemeine Karte ein Gleichgewicht zwischen Kachelgröße und Vollständigkeit herzustellen. Werkzeuge Mit Protomaps Basemaps [11]
Agentische LLM-Systeme stellen besondere Herausforderungen an die Sicherheit. Insbesondere besteht das Risiko, dass ein Angriff über versteckte Anweisungen erfolgt und das LLM dadurch sensible Daten weitergibt. Es gilt, dieses Risiko durch explizite Maßnahmen zu mindern. Agentische Large Language Models (LLMs) bieten eine radikal neue Möglichkeit zur Entwicklung von Software, indem sie ein ganzes Ökosystem von Agenten über eine ungenaue Konversation koordinieren. Das ist eine gänzlich neue Arbeitsweise, die jedoch auch erhebliche Sicherheitsrisiken mit sich bringt, insbesondere durch manipulierte Prompts. Ein Blogpost [1] des renommierten Sicherheitsspezialisten Bruce Schneier verdeutlicht die Probleme: „Wir wissen einfach nicht, wie wir uns gegen diese Angriffe verteidigen sollen. Wir haben keine agentenbasierten KI-Systeme, die vor solchen Angriffen sicher sind. Jede KI, die in einer feindlichen Umgebung arbeitet – die also auf nicht vertrauenswürdige Trainingsdaten oder Eingaben stoßen kann –, ist anfällig für Prompt-Injection. Es handelt sich um ein existenzielles Problem, das, soweit ich das beurteilen kann, die meisten Entwickler dieser Technologien einfach ignorieren.“ Um diese Risiken im Blick zu behalten, durchforsten die Autoren Forschungsartikel, die mit einem tiefen Verständnis für moderne LLM-basierte Tools verfasst wurden und eine realistische Sicht auf die Risiken bieten, und fassen ihre Erkenntnisse regelmäßig in einem Blog [2] zusammen. Es ist das Ziel, einen leicht verständlichen praktischen Überblick über Sicherheitsprobleme und Abhilfemaßnahmen im Zusammenhang mit agentenbasierten LLMs zu geben. Dieser Artikel soll die entsprechenden Überlegungen einem breiteren Publikum zugänglich machen. Der Inhalt stützt sich unter anderem auf umfangreiche Forschungsergebnisse von Experten wie Simon Willison [3] und Bruce Schneier [4]. Rund um agentische LLMs gibt es viele Risiken, und die Technologie befindet sich in einem raschen Wandel. Daher gilt es, die Risiken zu verstehen und herauszufinden, wie man sie wo immer möglich mindern kann. Agentische LLMs – eine Begriffsklärung Die künstliche Intelligenz befindet sich im raschen Wandel, sodass Begriffe schwer zu fassen sind. Insbesondere der Begriff „KI“ wird überstrapaziert, um alles von maschinellem Lernen [5] über große Sprachmodelle [6] bis hin zu Artificial General Intelligence [7] zu fassen. Bei agentischer KI sprechen wir hier im Wesentlichen von LLM-basierten Anwendungen, die autonom agieren können, die also das grundlegende LLM-Modell um interne Logik, Schleifen, Tool-Aufrufe, Hintergrundprozesse und Sub-Agenten erweitern. Anfangs handelte es sich dabei hauptsächlich um Programmierassistenten wie Claude [8], Cline [9] und Cursor [10], inzwischen betrifft das fast jede LLM-basierte Anwendung. Es ist hilfreich, die Architektur und die Funktionsweise solcher Applikationen zu verdeutlichen. Ein agentisches LLM liest aus sehr vielen Datenquellen und kann Aktivitäten mit Seiteneffekten auslösen (Abbildung 1). Einige der Agenten werden explizit vom Benutzer ausgelöst, viele sind jedoch integriert. Beispielsweise lesen Programmieranwendungen in der Regel den Quellcode eines Projekts und die Konfiguration, ohne den Anwender darüber zu informieren. Je intelligenter die Anwendungen werden, desto mehr Agenten agieren im Hintergrund. Model Context Protocol – API für LLMs Ein MCP-Server ist eigentlich eine Art API, die speziell für die Verwendung mit LLMs entwickelt wurde. Beim Model Context Protocol (MCP [11]) handelt es sich um ein standardisiertes Protokoll für diese APIs, sodass ein LLM versteht, wie eine Quelle abgerufen wird und welche Tools und Ressourcen sie anbietet. Die API kann eine Vielzahl von Funktionen bereitstellen. Sie kann
RE: https://mastodon.social/@hugovk/115333348041057866
Thanks @hugovk! I haven’t been this excited about a #Python release in a long time. I’m curious to see how some of our projects will fare with free-threaded Python: https://cusy.io/en/blog/free-threaded-python-hit-or-miss.html
cusy GmbH
Veit Schiele
Cusy Design System