Hallo zusammen, kennt jemand eine Übersicht, wie ich bei der Verwendung von Quelltexten aus unterschiedlichen Quellen und evtl. mit unterschiedlichen Open-Source-Lizenzen vorgehen muß, wenn ich mein Projekt selbst als Open Source veröffentlichen will? Wichtig wäre mir insbesondere das Vorgehen, a) bei Fremd-Anteilen, die auf Dateiebene unverändert bleiben und problemlos in einem eigenen Verzeichnis gehalten werden können (z.B. ARM CMSIS), b) bei Fremd-Libraries, die leicht verändert werden, aber auch noch separat gehalten werden können (z.B. Standard Peripheral Libaries) und c) bei Fremd-Quelltext, der zur Anpassung an die eigenen Bedürfnisse komplett auf links gedreht und mit eigenem Header etc. vermengt wurde. Das Ganze suche ich natürlich unter der Berücksichtigung der gängigen Open-Source Lizenzen und dann auch noch so gut (deutsch oder englisch) erklärt, daß der nicht-Jurist nicht nach der ersten Stunde lesen frustriert aufgibt und beschließt, nie wieder Open Source zu machen. Keine einfache Sache. Kennt jemand eine Quelle? Viele Grüße W.T. P.S.: Muss nicht kostenlos und darf auch ruhig auf totem Papier sein. Nur für den Nicht-Juristen lesbar ist eine harte Anforderung.
Mit einer Quelle kann ich nicht dienen, aber ich weiß aus eigener Erfahrung wie mühsam das sein kann. Natürlich hängt es sehr stark davon ab, welche fremden Lizenzen du hast, und unter welcher Lizenz du selbst veröffentlichen willst. ich hatte vor ~15 Jahren mit LCD4Linux das Problem, dass ich eine fremde Quelle verwenden wollte, in deren Header folgendes zu finden war:
1 | ** You are free to incorporate this code into your own works, even if it ** |
2 | ** is a commercial application. However, you may not charge anyone else ** |
3 | ** for the use of this code! If you intend to distribute your code, ** |
4 | ** I'd appreciate it if you left this message intact. I'd like to ** |
5 | ** receive credit wherever it is appropriate. Thanks! ** |
das unscheinbare *you may not charge...* ist zur GPL (die ich verwendet habe) inkompatibel, den (mir bekannten) Autor habe ich nicht erreicht bzw. er hat nicht geantwortet, also blieb mir nichts anderes übrig als den Code rauszuwerfen, und selbst eine "clean room implementation" zu machen. Was habe ich daraus gelernt: die Lizenzbedingungen von fremdem Code genau lesen, und wenns nach Problemen riecht, lieber weglassen.
Hallo Michsel, Michael R. schrieb: > und unter welcher Lizenz du selbst veröffentlichen willst. Der Punkt ist bei mir noch ungeklärt. Im Moment will ich noch abstecken, ob ich überhaupt Energie hineinstecken will, das Ganze Open-Source-fähig zu machen. Dabei ist der lizenzrechtliche Teil nur ein Teilaspekt. Stichwort "lieber weglassen"/"clean room implementation": Kann das eine Einzelperson überhaupt leisten? Wenn ich den Wikipedia-Artikel richtig verstanden habe, bedeutet das: Eine Gruppe erarbeitet aus dem Quelltext/Produkt eine Spezifikation. Eine Gruppe erarbeitet aus der Spezifikation neuen Quelltext. Die Gruppen dürfen keine Überschneidung haben.
Walter T. schrieb: > Stichwort "lieber weglassen"/"clean room implementation": Kann das eine > Einzelperson überhaupt leisten? Wenn ich den Wikipedia-Artikel richtig > verstanden habe, bedeutet das: Eine Gruppe erarbeitet aus dem > Quelltext/Produkt eine Spezifikation. Eine Gruppe erarbeitet aus der > Spezifikation neuen Quelltext. Die Gruppen dürfen keine Überschneidung > haben. Vielleicht ist "clean room" in meinem Fall auch der (juristisch) falsche Ausdruck. ich wusste was ich brauche (einen "expression evaluator") hatte einen gefunden, diesen verworfen und selbst neu (ohne Anlehnung an den anderen Code) implementiert.
Im Detail ist das alles immer kompliziert, aber eins ist sicher: du hast viel weniger Probleme damit, was du wie verwenden darfst, wenn du am Schluss den Quelltext veröffentlichst. Klar, die blöden GPL-Kompatiblitätsprobleme etc. hast du immer noch ...
Sven B. schrieb: > du hast > viel weniger Probleme damit, was du wie verwenden darfst, wenn du am > Schluss den Quelltext veröffentlichst Nö. Solange ich nichts verkaufen will, habe ich die wenigsten Probleme, wenn ich meine Sachen für mich behalte und niemandem einen Einblick in die Funktionsweise gebe. Alles andere ergibt Mehraufwand und eventuell Ärger. Wie groß Mehraufwand und Ärger sind - das gilt es vorab festzustellen.
Deswegen ist es im Enterprise Umfeld gängige Praxis, Anwenderspezifische Software zu entwickeln und im selben Haus zu betreiben (beim Anwender oder beim Entwickler).
Walter T. schrieb: > Wichtig wäre mir insbesondere das Vorgehen, > a) bei Fremd-Anteilen, die auf Dateiebene unverändert bleiben und > problemlos in einem eigenen Verzeichnis gehalten werden können (z.B. ARM > CMSIS), > > b) bei Fremd-Libraries, die leicht verändert werden, aber auch noch > separat gehalten werden können (z.B. Standard Peripheral Libaries) und > > c) bei Fremd-Quelltext, der zur Anpassung an die eigenen Bedürfnisse > komplett auf links gedreht und mit eigenem Header etc. vermengt wurde. Ich glaube, bei den meisten Lizenzen gibt es keine Unterscheidung für diese drei Fälle.
Hallo, erstmal musst du alle verwendeten Lizenzen zusammensuchen und ihre grundsätzliche Kompatiblität zueinander feststellen. Für die üblichen Verdächtigen gibt es da Tabellen. Dazu gehört auch die Lizenz des Ergebnisses, denn die ergibt sich meist von selbst. > Wichtig wäre mir insbesondere das Vorgehen, > a) bei Fremd-Anteilen, die auf Dateiebene unverändert bleiben und > problemlos in einem eigenen Verzeichnis gehalten werden können (z.B. ARM > CMSIS), Entweder in diesem Verzeichnis oder im Stammverzeichnis des Projektes findet sich eine LICENCES.TXT oder sowas, wo die einzelnen Bedingungen der Teilprojekte festgehalten sind. > b) bei Fremd-Libraries, die leicht verändert werden, aber auch noch > separat gehalten werden können (z.B. Standard Peripheral Libaries) und Bei uns ist das übliche Vorgehen, den Lizenzheader zu erweitern (im Sinne von "(c) 1998 Originalautor; changes (c) 2002 wir". Bei Dual-Lizenzierung des Originals (z.B. BSD/GPL) legst du außerdem fest, welche Lizenz des Originals greifen soll. Das kommt ebenfalls in die LICENCES.TXT. > c) bei Fremd-Quelltext, der zur Anpassung an die eigenen Bedürfnisse > komplett auf links gedreht und mit eigenem Header etc. vermengt wurde. Da wird's schwierig, hab ich keine Erfahrung mit. > Das Ganze suche ich natürlich unter der Berücksichtigung der gängigen > Open-Source Lizenzen und dann auch noch so gut (deutsch oder englisch) > erklärt, daß der nicht-Jurist nicht nach der ersten Stunde lesen > frustriert aufgibt und beschließt, nie wieder Open Source zu machen. Gibt's da von der FSF oder ähnlichen Organisationen nichts zu? Das ist doch in deren Interesse, sowas verständlich zu machen... Walter T. schrieb: > Nö. Solange ich nichts verkaufen will, habe ich die wenigsten Probleme, > wenn ich meine Sachen für mich behalte und niemandem einen Einblick in > die Funktionsweise gebe. Was übrigens auch ein Grund ist, Dienste in die Cloud zu verlegen.
Rolf M. schrieb: > Ich glaube, bei den meisten Lizenzen gibt es keine Unterscheidung für > diese drei Fälle. Ich finde zumindest keine Infos. Aber es klingt unlogisch. Beispiel: Ich nehme eine Quelltext-Library, 2-clause BSD: Copyright 2012 by Werner Meier, no warranty etc.: Ich darf also mit dem Quelltext grob erst einmal alles machen, was ich will, wenn ich die Lizenz-Information unverändert weitergebe. Jetzt bastele ich am Quelltext herum. Passe es so an, daß es besser zu meinem Rest-Projekt paßt. Baue frische Fehler hinein. Mache alles unlesbar und häßlich. Bin halt nicht der tolle Programmierer. Dann kopiere ich oben in den Quelltext wieder den ursprünglichen Lizenztext. Also weiß jeder Leser: Werner Meier hat 2012 diesen Mist verzapft und lehnt jede Verantwortung ab. Ist das so gemeint?
Walter T. schrieb: > Werner Meier hat 2012 diesen Mist verzapft und > lehnt jede Verantwortung ab. > > Ist das so gemeint? Ja. Freescale zum Beispiel hat das Problem erkannt und geht bei ihrem CMSIS noch einen Schritt weiter indem sie noch eine weitere Klausel zur normalen unveränderten BSD hinzugefügt haben. Jetzt steht dort im Wesentlichen: * [BSD] Du mußt dazuschreiben daß unser [Freecale] Code enthalten ist * [FSL] Du darfst auf keinen Fall unseren Namen nennen. Man sollte meinen so ein Konzern hätte wenigstens einen Teilzeit-Anwalt der beim Aufsetzen von rechtlichen Dokumenten aushilft.
Verschoben in "Offtopic"? Ich hätte behauptet daß die Frage, wie ich mein Embedded Projekt für Open Source vorbereite, ins Kernthema gehört und eigentlich von jedem Hobby-Entwickler berücksichtigt werden sollte. Sicher: Für AVR ist das banal. Da kann ich oft auf das schön geschnürte Paket des AVR-GCCs zurückgreifen und einfach meinen eigenen Quelltext, ohne Fremd-Header veröffentlichen. Aber den Luxus habe ich hier nicht mehr.
Walter T. schrieb: > Sven B. schrieb: >> du hast >> viel weniger Probleme damit, was du wie verwenden darfst, wenn du am >> Schluss den Quelltext veröffentlichst > > Nö. Solange ich nichts verkaufen will, habe ich die wenigsten Probleme, > wenn ich meine Sachen für mich behalte und niemandem einen Einblick in > die Funktionsweise gebe. > > Alles andere ergibt Mehraufwand und eventuell Ärger. Wie groß > Mehraufwand und Ärger sind - das gilt es vorab festzustellen. Ja ach ne. Wenn du es niemandem geben willst, kannst du immer machen was du willst. Ich habe angenommen, dass das Programm danach entweder verkauft oder sonstwie verteilt werden soll.
Er wird vermutlich einfacher wenn Du die Frage nicht so allgemein stellst, denn allgemein sind beliebige Kombinationen möglich (oder rechtlich unmöglich) sondern stattdessen konkret auflistest welche Lizenzen alle in das konkrete Produkt mit reingelinkt werden sollen so daß man das konkret betrachten kann.
Bernd K. schrieb: > Er wird vermutlich einfacher wenn Du die Frage nicht so allgemein > stellst, Das Problem ist: Ich suche die Infos allgemein. Als Übersicht. Am besten ein Buch "Was ich bei Open Source Lizenzen beachten muß für Dummies auf 500 Seiten." Ich will wissen, welchen Aufwand ist als Hobbyprogrammierer in die Open-Source-Veröffentlichung stecken müßte, um eine informierte Entscheidung zu treffen, ob es das Wert ist, ins Detail zu gehen.
Walter T. schrieb: > Ich will wissen, welchen Aufwand ist als Hobbyprogrammierer in die > Open-Source-Veröffentlichung stecken müßte, um eine informierte > Entscheidung zu treffen, ob es das Wert ist, ins Detail zu gehen. Im allgemeinen Fall setzt das mindestens ein spezifisches Jurastudium pro Land voraus, in dem die Veröffentlichung erreichbar sein soll, sowie Kenntnis der existierenden Rechtsprechung, soweit vorhanden. Damit lautet die Antwort grundsätzlich und immer "nein, den Aufwand ist es nicht wert". In der Realität triffst du aber nur auf vereinfachte Fälle: - du bist der alleinige Rechteinhaber; - du hast die Erlaubnis aller anderen Rechteinhaber; - du mischst nur übliche Lizenzen; - du machst nichts kommerzielles damit; - etc.pp. Walter T. schrieb: > Ich hätte behauptet daß die Frage, wie ich mein Embedded Projekt für > Open Source vorbereite, ins Kernthema gehört und eigentlich von jedem > Hobby-Entwickler berücksichtigt werden sollte. Im einfachsten Fall kupferst du von vorhandenen Embedded-Projekten für deine Plattform ab. Irgendwie sehe ich da jetzt kein riesiges Problem, wenn du nicht gerade 5 verschiedene Lizenzen mischst und noch zusätzliche, unspezifische Anforderungen hast. Walter T. schrieb: > Am besten ein Buch "Was ich bei Open Source Lizenzen beachten muß > für Dummies auf 500 Seiten." Eine 500 Seiten lange Checkliste, von denen viele Punkte weder von mir noch vom derzeitigen Entwickler geprüft werden können, geschweige denn von einem Fachanwalt, fände ich jetzt auch nicht besonders nützlich... Der ehemalige Maintainer von Busybox hatte da schon genug Spaß dran, und machte nicht ohne Grund Toybox, was für Android inzwischen Standard ist. Überhaupt geht Android von der GPL weg, weil sie Probleme hat (GPLv3 ist dort übrigens schlicht verboten).
Walter T. schrieb: > Bernd K. schrieb: >> Er wird vermutlich einfacher wenn Du die Frage nicht so allgemein >> stellst, > > Das Problem ist: Ich suche die Infos allgemein. Als Übersicht. Am besten > ein Buch "Was ich bei Open Source Lizenzen beachten muß für Dummies auf > 500 Seiten." > > Ich will wissen, welchen Aufwand ist als Hobbyprogrammierer in die > Open-Source-Veröffentlichung stecken müßte, um eine informierte > Entscheidung zu treffen, ob es das Wert ist, ins Detail zu gehen. Ich finde, du gehst hier falsch vor. Du versuchst hier zuerst, für sämtliche theoretisch möglichen Konstellationen aus Lizenzen zu überlegen, wie man damit umgeht, um danach dann die Entscheidung zu treffen, ob du überhaupt jemals ein OpenSource-Programm veröffentlichen möchtest oder der Aufwand für die Lizenzen zu hoch ist. Bis du mal soweit bist, hast du schon mindestens zehn mal soviel Aufwand in diese ganzen Überlegungen gesteckt, wie der durchschnittliche OpenSource-Entwickler. Wenn du ein konkretes Projekt hast (bzw. planst), schaue dir an, welche Lizenzen vorkommen, und dann überlege dir, wie man damit umgehen kann. Alles andere bringt dich nicht weiter.
Walter T. schrieb: > Ich will wissen, welchen Aufwand ist als Hobbyprogrammierer in die > Open-Source-Veröffentlichung stecken müßte, um eine informierte > Entscheidung zu treffen, ob es das Wert ist, ins Detail zu gehen. Das wird so einfach nicht funktionieren, dafür gibt es zu viele Lizenzen. Hilfreich wäre eine Liste der bestehenden Lizenzen von wiederverwendeten Komponenten, und eine grobe Zielrichtung welche Lizenz du für dein Projekt anstrebst. Nichtsdestotrotz finde ich es gut dass du dich damit beschäftigst. Sensibilität für Lizenzen halte ich für wichtig, ich finde aber dass das speziell hier zu wenig Beachtung findet. Schönes Beispiel ist die (wunderbare) Entprell-Routine von Peter D. wo die Lizenzfrage komplett ungeklärt ist.
Rolf M. schrieb: > Du versuchst hier zuerst, für > sämtliche theoretisch möglichen Konstellationen aus Lizenzen zu > überlegen, wie man damit umgeht, um danach dann die Entscheidung zu > treffen, ob du überhaupt jemals ein OpenSource-Programm veröffentlichen > möchtest oder der Aufwand für die Lizenzen zu hoch ist. Nein. Ich versuche mir eine Übersicht am Anfang zu schaffen. S. R. schrieb: > Im einfachsten Fall kupferst du von vorhandenen Embedded-Projekten für > deine Plattform ab. Woher will ich, ohne die nötige Übersicht, wissen, ob die anderen das sinnvoll gemacht haben?
Walter T. schrieb: > Woher will ich, ohne die nötige Übersicht, wissen, ob die anderen das > sinnvoll gemacht haben? Was ist "sinnvoll"? Wenn ich Code schreibe und oben "BSD-lizenziert" ranpappe, dann ist das meine eigene Entscheidung. Wenn ich Fremdcode einbinde, dann muss ich aufpassen, dass ich dessen Lizenz nicht verletze. Im Normalfall ist das ein sehr übersichtlicher Prozess, und es gibt Tabellen, ob sowas grundsätzlich zulässig ist. Wenn es dir um einen absoluten Spezialfall geht, also z.B. eine Mischung aus 5 verschiedenen (mehr oder weniger) Opensource-Lizenzen, vielleicht noch einem proprietärem Buildtool und besonderer Hardware, dann lass das gerichtlich klären. Das ist eine juristische Frage, da ist nichtmal ein Richterspruch wasserdicht. Nachtrag: Hier geht's los: https://en.wikipedia.org/wiki/License_compatibility
S. R. schrieb: > Hier geht's los: https://en.wikipedia.org/wiki/License_compatibility Danke! Das ist ein Anfang.
Bernd K. schrieb: > Freescale zum Beispiel hat das Problem erkannt und geht bei ihrem CMSIS > noch einen Schritt weiter indem sie noch eine weitere Klausel zur > normalen unveränderten BSD hinzugefügt haben. Jetzt steht dort im > Wesentlichen: > > * [BSD] Du mußt dazuschreiben daß unser [Freecale] Code enthalten ist > * [FSL] Du darfst auf keinen Fall unseren Namen nennen. > > Man sollte meinen so ein Konzern hätte wenigstens einen Teilzeit-Anwalt > der beim Aufsetzen von rechtlichen Dokumenten aushilft. Wo genau steht die Lizenz von Freescale? Interessiere mich dafür, konnte aber die Quelle noch nicht finden. Wäre Dir über einen Link/Hinweis dankbar. Grüße
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.