Open-Source-Vorschriften stellen ungewöhnliche Erfolgsvoraussetzungen. Erfahren Sie, wie Open-Source-Anwälte ihren Arbeitgebern helfen können, einen gangbaren Weg nach vorne zu finden.
Wie ich im ersten Teil dieser zweiteiligen Serie berichtet habe, bin ich Open-Source-Anwalt bei Red Hat. Ein wichtiger Teil meiner Arbeit besteht darin, anderen Unternehmen, einschließlich ihrer internen Berater, Informationen darüber zur Verfügung zu stellen, wie Red Hat ein vollständig Open-Source-Entwicklungsmodell einführt, um Produkte für Unternehmen zu entwickeln, und ihre allgemeinen Fragen zur Open-Source-Lizenzierung zu beantworten. Nachdem ich von den Erfolgen von Red Hat gehört habe, dreht sich das Gespräch, das diese Anwälte mit mir führen, oft darum, wie sich ihre Organisationen zu Open-Source-bewussteren und leistungsfähigeren Organisationen entwickeln können, und sie fragen mich oft, wie sie ihre Praktiken verbessern können, um kompetentere Open-Source-Lösungen zu erhalten Rechtsberatung für Mitarbeiter seiner Organisationen. In diesen beiden Artikeln werde ich mitteilen, was ich internen Rechtsberatern normalerweise zu diesen Themen sage.
Finden Sie immer einen machbaren Weg
Mein Arbeitgeber, Red Hat, ist einzigartig in der Verwendung von Open-Source-Software, da unser Entwicklungsmodell mit einer Open-Source-Community mit Tausenden von Mitwirkenden beginnt und zu einem Endprodukt führt, das erprobt, getestet und vertrauenswürdig ist. Genauer gesagt beginnen wir durch unser einzigartiges Entwicklungsmodell mit von der Community erstellter Open-Source-Software und arbeiten an jedem Projekt, um die Sicherheit zu stärken, Fehler zu beheben, Schwachstellen zu schließen und neue Funktionen hinzuzufügen. Diese Verbesserungen tragen wir dann in jedes Projekt ein, sodass sie der gesamten Open-Source-Community zugute kommen. Die Vorteile dieses Ansatzes sind wichtig und umfassen:
- Nutzen Sie externe Innovationen durch die Zusammenarbeit zwischen internen Teams und anderen außerhalb der Organisation;
- Wenn eine bestehende oder potenzielle Community an demselben Problem wie Sie arbeitet und zusammenarbeiten kann, vermeiden Sie die Kosten und Ineffizienzen, die mit der Entwicklung und Wartung einer Open-Source-Lösung selbst verbunden wären.
- Durch die produktive Zusammenarbeit mit Partnern und der vorgelagerten Projektgemeinschaft kann die kostspielige Wartung nachgelagerter Zweige des Hauptprojekts vermieden werden.
- Für einige Unternehmen ist es verlockend, nicht öffentliche Zweige des Upstream-Codes zu erstellen, weil dies eine schnelle Möglichkeit ist, einen bestimmten Anwendungsfall zu lösen, oder weil sie nicht bereit sind, in der Community zusammenzuarbeiten. Der langfristige Wartungsaufwand einer solchen Zweigstelle kann jedoch aufgrund erhöhter Entwicklungskosten, Verlust der Interoperabilität und anderen Gründen unerschwinglich sein. Im Gegensatz dazu werden durch die Zentralisierung der Entwicklung innerhalb der ursprünglichen Upstream-Community die Entwicklungskosten auf alle Teilnehmer verteilt.
Mit wenigen Ausnahmen (z. B. Red Hat) verfügen die meisten Unternehmen, die Open-Source-Software verwenden, wahrscheinlich über ein proprietäres Softwarelizenzierungsmodell (oder das SaaS-Äquivalent) und lizenzieren proprietäre Software als Teil ihres Geschäfts. Diese Organisationen glauben, dass sie über Softwarekomponenten verfügen, die einen gewissen Wettbewerbsvorteil bieten, und möchten nicht, dass diese Komponenten anderen unter Open-Source-Bedingungen zur Verfügung gestellt werden. Das ist verständlich. Allerdings möchte ich jeden Open-Source-Anwalt, der sich mit solchen Themen befasst, dazu ermutigen, seine Mandanten dazu zu drängen, ein Open-Source-Entwicklungsmodell zu übernehmen, insbesondere für alle Software, die undifferenziert und verbreitet ist.
Wenn Ihr Unternehmen beispielsweise eine Anwendung für Mobiltelefone entwickelt und Sie ein Softwaremodul zum Lesen und Schreiben von PNG-Bilddateien benötigen, ist die Verwendung eines der beliebten Open-Source-PNG-Softwaremodule auf GitHub deutlich günstiger. Das Kodieren und Dekodieren von PNG-Bildern ist für Ihr Unternehmen möglicherweise nicht zu unterscheiden. Warum sollten Sie also wertvolle Entwicklungszeit damit verbringen, Ihre eigene Version zu schreiben? Darüber hinaus kann das Schreiben eines eigenen Moduls für diese Funktionalität auch zu Kompatibilitätsproblemen mit anderer Software führen, die allgemein verfügbare Open-Source-Module verwendet. Warum ist das? Obwohl Ihre Module und Open-Source-Module möglicherweise zum Kodieren und Dekodieren der veröffentlichten PNG-Spezifikation geschrieben wurden, kann die Spezifikation manchmal anders interpretiert werden und es können Implementierungsfehler auftreten. Jeder, der dasselbe Modul zur Ausführung dieser Funktionalität verwendet, stellt die Kompatibilität für die Mehrheit der Benutzer sicher und reduziert die Entwicklungs- und Wartungskosten.
Es ist auch wichtig, sich darüber im Klaren zu sein, dass manche Software möglicherweise proprietär bleiben muss und nicht den Open-Source-Bedingungen unterliegt. Abhängig von der Softwarearchitektur Ihres Systems und der verwendeten Open-Source-Lizenz kann Softwarecode, der proprietär bleiben soll, den Bedingungen der Open-Source-Lizenz unterliegen, sofern nicht bestimmte Maßnahmen (über den Rahmen dieses Artikels hinaus) ergriffen werden. Hier wäre es sinnvoll, den Kunden einige Beratungsleistungen hinsichtlich der Lizenzauswahl und -architektur anzubieten.
Finden Sie flexible Lösungen
Organisationen, die bisher vor allem proprietäre Software lizenziert haben, nutzen nach und nach zunehmend Open-Source-Software, aber die Anforderungen an die Prüfung und Genehmigung werden wahrscheinlich steigen (meiner Erfahrung nach sogar exponentiell). Solche Organisationen können aufgrund von Ressourcenbeschränkungen Schwierigkeiten haben. Hier sind einige flexible Lösungen, die Sie übernehmen können.
Autorisieren und delegieren Sie an andere
Anwälte können und sollten keine Gatekeeper sein. Das ist ineffizient und führt definitiv zu Engpässen bei den Entwicklungs- und Veröffentlichungszeiten, was zu Frustration und Umsatzeinbußen führt. Stattdessen sollte die Genehmigungsbefugnis kompetenten Personen im Produkt- oder Projektmanagement und im Engineering übertragen werden. Dies ermöglicht es Organisationen, effektiv flexibel zu bleiben. Um dies erfolgreich zu erreichen, ist die Aufklärung Ihrer Kunden (siehe nächster Abschnitt) von entscheidender Bedeutung.
Ein Ansatz, den ich verfolge, besteht darin, der gesamten technischen Organisation Open-Source-Schulungen anzubieten, damit diese grundlegende Entscheidungen zu Lizenzmodellen und Architekturen treffen können, und gleichzeitig Softwareentwicklern speziellere Schulungen anzubieten, damit sie komplexere Anleitungen und Entscheidungen geben können. Berücksichtigen Sie auch klare Beschränkungen der Berechtigungen auf jeder Ebene, einschließlich der Art von Problemen und Entscheidungen, die an Sie als ihren Open-Source-Anwalt weitergeleitet werden müssen. Die spezifische Autorisierungsstufe Ihrer Organisation hängt von der Erfahrung Ihres Teams mit Open Source und der Sensibilität für bestimmte Open Source-Probleme ab.
Informieren Sie Ihre Kunden
Ich habe festgestellt, dass Schulungen eines der effektivsten Instrumente für die Migration Ihrer Organisation zu einer stärker auf Open Source ausgerichteten Organisation sind. Die Schulung Ihrer Softwareentwickler und Produktmanager ist von entscheidender Bedeutung. Lassen Sie mich näher darauf eingehen.
Auch wenn Ihre Software-Ingenieure auf dem neuesten Stand sind und im Allgemeinen sehr gut mit Open-Source-Themen und Softwarelizenzierung vertraut sind, ist es dennoch wichtig, sie entsprechend den spezifischen Anforderungen Ihres Unternehmens zu schulen. Beispielsweise erlaubt Ihr Unternehmen möglicherweise nur die Verwendung freizügiger Open-Source-Lizenzen und stellt möglicherweise bestimmte Anforderungen an den Urheberrechtshinweis und die Verfügbarkeit des Quellcodes. Um Probleme in der Entwicklung zu vermeiden, die anschließend behoben werden müssen (eine kostspielige und zeitaufwändige Praxis), ist es am besten, Ingenieure darin zu schulen, die Möglichkeit unangemessenen Verhaltens zu minimieren, insbesondere zu Beginn eines Entwicklungsprozesses (siehe nächster Abschnitt).
Auch Produktmanager müssen geschult werden. In vielen Unternehmen sind Produktmanager für die klassischen vier Aspekte des Marketings (Produkt, Preis, Positionierung und Werbung) verantwortlich und für den gesamten Lebenszyklus eines Produkts von der Wiege bis zur Bahre verantwortlich. Jeder Aspekt der Arbeit eines Produktmanagers kann durch den Einsatz von Open-Source-Software beeinflusst werden. Aus den oben genannten Gründen ist es für sie hilfreich, die Anforderungen für die Verwendung von Open-Source-Software zu verstehen. Darüber hinaus und was noch wichtiger ist: Der erhebliche Einfluss von Produktmanagern innerhalb einer Organisation bedeutet, dass sie oft in der Lage sind, notwendige Änderungen an Prozessen und Richtlinien vorzunehmen. Produktmanager können einer Ihrer stärksten Befürworter von Prozessänderungen für Offenheit sein.
Früherkennung
Die Lösung von Open-Source-Lizenzproblemen gegen Ende des Entwicklungsprozesses ist schwierig und teuer. Wenn das Veröffentlichungsdatum der Software näher rückt, werden die Architektur und die Open-Source-Softwaremodule ausgewählt und sind nur schwer zu ändern. Wenn ein Problem festgestellt wird, beispielsweise „Copyleft“-Software, die in ein proprietäres Softwaremodul eingebettet ist (wenn dieses proprietäre Modul nicht den Open-Source-Bedingungen unterliegen soll), kann eine Änderung der Architektur oder des Moduls in dieser Entwicklungsphase schwierig und kostspielig sein teuer. Stattdessen sollte der Prozess der Architekturanalyse und der Auswahl von Open-Source-Modulen früh im Entwicklungsprozess erfolgen, damit kostengünstigere und effektivere Korrekturen vorgenommen werden können.
Die „Belohnungen“ von Open-Source-Regulierungen
Die Ausübung der Open-Source-Regulierung ist eine lohnende Karriere, da die Fähigkeit, eine Organisation in eine „offene“ Richtung zu beeinflussen, große Vorteile mit sich bringt. Der Erfolg hängt von Ihrer Fähigkeit ab, Lösungen zu finden, die machbar und flexibel sind, während Ihr Unternehmen wächst und reifer wird.
Über den Autor: Jeffrey R. Kaufman ist leitender Wirtschaftsrechtsberater im Open-Source-Rechtsteam von Red Hat, dem weltweit führenden Anbieter von Open-Source-Softwarelösungen. Er ist außerdem außerordentlicher Rechtsprofessor an der University of North Carolina. Bevor er zu Red Hat kam, war Jeffrey als Patent- und Open-Source-Berater für Qualcomm tätig.
Übersetzerprofil: Xue Liang, Leiter der Internet-Geschäftsabteilung der Jihuizhijia Intellectual Property Consulting Company, ist gut in Patentanalyse, Patentlayout, Wettbewerbsverfolgung, FTO-Analyse und Open-Source-Software-Risikoanalyse für geistiges Eigentum. Er engagiert sich für die Bereitstellung von Internetunternehmen und High-Tech-Unternehmen mit Beratungsdiensten im Bereich geistiges Eigentum.
