Hallo, ich möchte gerne zunächst zwei Projekte über Github veröffentlichen und Versionen. Dabei möchte ich meine Sourcen einfach so freigeben "Mach doch was du willst", aber mit einem rechtlichen Schutz "software as is ... no warranty ...". Bei beiden Projekten nutze ich jeweils eine externe Bibliothek. Konkret habe ich mir das so ausgeknobelt, wo ich denke das alles korrekt ist: 1. Eine kleines HTML/PHP/MySQL script/seite für eine Listenanwendung mit einer externen software, welche unter LGPL lizensiert ist. -> Hier würde ich meinen Code unter MIT Lizenzieren und die Bibliothek "wie sie ist" mit LGPL beilegen. 2. Ein kleines Mikrocontroller-Projekt mit Hard- und Software. Hard- sowie Software würde ich wieder gerne unter MIT lizensieren und die externe software ist hier IRMP, also GPL v2. -> Auch hier würde ich wieder mein zeuch unter MIT und die IRMP unter bestehender GPL einstellen. Sind meine Überlegungen so korrekt? Oder muss ich ebenfalls GPL nutzen? (Also wäre jetzt kein Beinbruch GPL zu nehmen, aber MIT hat mehr Freiheitsgrade.) Lässt sich Hardware überhaupt mit MIT lizensieren? Habe sonst nur die Cern Open Hardware Lizenz gefunden. Für weitere Tipps und Hinweise wäre ich sehr dankbar. Vg
Mach doch derbe eigene Lizenz. Es hindert dich keiner daran einen Text zu verfassen, in dem du alle Schuld von die weist und du erlaubst alles mit den Sourcen zu machen. Bei dem Haftungsausschluss kannst du dich ja am Text der anderen Lizenzen orientieren. Nur zur Sicherheit.
Katatafisch schrieb: > Sind meine Überlegungen so korrekt? Oder muss ich ebenfalls GPL nutzen? Mit dem Quellcode kannst du machen, was du willst; der GPL-"Virus" wird erst bei den Binär-Dateien wirksam. > Lässt sich Hardware überhaupt mit MIT lizensieren? Auf Hardware an sich gibt es kein Urheberrecht; du lizensierst allenfalls die Projektdokumentation (Schaltpläne etc.). Für Dokumentation wäre Creative Commons überlegenswert.
Clemens L. schrieb: >> Lässt sich Hardware überhaupt mit MIT lizensieren? > > Auf Hardware an sich gibt es kein Urheberrecht; du lizensierst > allenfalls die Projektdokumentation (Schaltpläne etc.). Für > Dokumentation wäre Creative Commons überlegenswert. Natürlich meinte ich mit Hardware den Schaltplan und Layout. Also etwas was ich bei Github commiten kann. :-) Stimmt, die CC... gibts ja auch noch. Also bei Projekt 2 könnte ich dann machen: - Hardware (Schematic & Layout): CC-BY-SA (oder ganz stumpf CC0) - eigene sourcen: MIT - externe sourcen (irmp): GPL --- Was die externen sourcen angeht, laut GPL darf ich die ja Ändern und Weiterverbreiten unter der ursprünglichen Lizenz, wenn ich das jetzt richtig kapiert habe. Also kann (oder muss) ich doch eigene und fremde sourcen, obwohl sie in einem Projekt zusammengeführt sind, getrennt betrachten, was die Lizenz angeht, oder?
Katatafisch schrieb: > Hier würde ich meinen Code unter MIT Lizenzieren und die Bibliothek > "wie sie ist" mit LGPL beilegen. Das solle in ordnung sein. LGPL erlaubt die Verwendung von damit lizenzierten Libraries von anders lizenzierter Software. Stelle einfach sicher, dass du klar stellst, welche Lizenz zu welchem Softwareteil gehört, und verwende dynamisches linking. Katatafisch schrieb: > Ein kleines Mikrocontroller-Projekt mit Hard- und Software. > Hard- sowie Software würde ich wieder gerne unter MIT lizensieren und > die externe software ist hier IRMP, also GPL v2. > -> Auch hier würde ich wieder mein zeuch unter MIT und die IRMP unter > bestehender GPL einstellen. GPLv2 ist nicht mit der MIT Lizenz kompatibel, wenn du also GPLv2 code in deinem Projekt verwendest, muss dieses ebenfalls GPLv2 sein. Andernfalls kann das Kompilat nicht veröffentlicht werden, ohne gegen eine Lizenz zu verstossen. GPLv3 wäre kompatibel, falls die Lizenznotiz "GPLv2 oder neuer" lautet, könnte man theoretisch die GPLv3 für das Kompilat verwenden, aber das macht niemand.
Katatafisch schrieb: > Also kann (oder muss) ich doch eigene und fremde sourcen, obwohl sie in > einem Projekt zusammengeführt sind, getrennt betrachten, was die Lizenz > angeht, oder? Das ist natürlich möglich, Ich empfehle jedoch, die Sourcen garnicht erst zusammen zu führen. Es gibt diverse andere Möglichkeiten, bei git repositories könnte man Submodule verwenden. Oder man kann die externen Sourcen anderweitig dem Projekt verfügbar machen, und nur mit z.B. automake prüfen, ob diese auf dem buildsystem verfügbar sind, etc.
Daniel A. schrieb: > GPLv2 ist nicht mit der MIT Lizenz kompatibel, wenn du also GPLv2 code > in deinem Projekt verwendest, muss dieses ebenfalls GPLv2 sein. Das ist natürlich nicht pauschal wahr. Eigenen unabhängigen (nicht abgeleiteten) Code, kann man lizenzieren, wie man will. Das Gesamtwerk kann man dann zwar nur unter der restriktiveren Lizenz vertreiben, aber die Einzelteile können trotzdem permissivere Lizenzen haben.
Ich finde sowieso den ganzen Blödsinn und Aufwand mit den Vorschriften und Urheberrechten bei privaten Projekten die man veröffentlichen möchte absolut übertrieben! Deshalb mein Rat, eine Veröffentlichung seiner privaten Projekte einfach sein lassen... die Welt dreht sich auch so noch weiter. ;-)
nicht"Gast" schrieb: > Mach doch derbe eigene Lizenz. Es hindert dich keiner daran einen Text > zu verfassen, in dem du alle Schuld von die weist und du erlaubst alles > mit den Sourcen zu machen. Es gibt genügend existierende Lizenzen, die von Menschen verfasst wurden, die sich mit juristischen Themen auskennen. Und die Vor- und Nachteile der einzelnen Lizenzen sind bekannt. Wozu also selber etwas verfassen, das dann im Fall der Fälle womöglich ungültig ist? Ma W. schrieb: > Daniel A. schrieb: >> GPLv2 ist nicht mit der MIT Lizenz kompatibel, wenn du also GPLv2 code >> in deinem Projekt verwendest, muss dieses ebenfalls GPLv2 sein. > > Das ist natürlich nicht pauschal wahr. > Eigenen unabhängigen (nicht abgeleiteten) Code, kann man lizenzieren, > wie man will. Ja, natürlich kann ich ein Projekt, das überhaupt nichts mit irgendeinem anderen Projekt, das unter GPL steht, zu tun hat, unter einer beliebigen Lizenz veröffentlichen. > Das Gesamtwerk kann man dann zwar nur unter der restriktiveren Lizenz > vertreiben, aber die Einzelteile können trotzdem permissivere Lizenzen > haben. Wenn es "Einzelteile" und ein "Gesamtwerk" gibt, ist der Code offenbar nicht "unabhängig". Wenn ich ein Programm schreibe, das eine Bibliothek unter GPL nutzt, dann ist dieses Programm "derived work", so dass der Code bei Veröffentlichung ebenfalls unter GPL stehen muss. Nur bei sehr loser Kopplung gilt das nicht. Da gibt's dann aber auch gar keine Einschränkungen mehr bezüglich der Lizenz.
Rolf M. schrieb: > Wenn es "Einzelteile" und ein "Gesamtwerk" gibt, ist der Code offenbar > nicht "unabhängig". Wenn ich ein Programm schreibe, das eine Bibliothek > unter GPL nutzt, dann ist dieses Programm "derived work", so dass der > Code bei Veröffentlichung ebenfalls unter GPL stehen muss. Nein, das ist falsch. Dein Code kann z.B. auch unter BSD-Lizenz stehen. Um das Gesamtwerk zu vertreiben gelten die restriktiveren Bedingungen der GPL. Es macht jedoch einen riesigen Unterschied, wenn ich (als dritte Partei) BSD-lizenzierte Codeteile aus dem Gesamtwerk entnehme und anderweitig verwende. Diese Teile sind keineswegs automatisch GPL.
Ma W. schrieb: > Rolf M. schrieb: >> Wenn es "Einzelteile" und ein "Gesamtwerk" gibt, ist der Code offenbar >> nicht "unabhängig". Wenn ich ein Programm schreibe, das eine Bibliothek >> unter GPL nutzt, dann ist dieses Programm "derived work", so dass der >> Code bei Veröffentlichung ebenfalls unter GPL stehen muss. > > Nein, das ist falsch. Dein Code kann z.B. auch unter BSD-Lizenz stehen. > Um das Gesamtwerk zu vertreiben gelten die restriktiveren Bedingungen > der GPL. Wenn man aber wieder das szenario eigener Code = MIT Lizent und fremder code = GPLv2 betrachtet, sind die Lizenzen doch immernoch inkompatibel. Wenn ich das ganze richtig verstehe, würde dass dann doch heissen, dass der Ersteller das "Gesamtwerk", also das fertige Binary, unter GPLv2 lizenziert vertreiben könnte, da er die Lizenz seines Codes nach belieben ändern kann, aber anderen wäre dies doch dann nicht möglich, weil diese den MIT Lizenzierten part nicht mit GPLv2 lizenzieren könnten, weil die GPLv2 nicht mit der MIT Lizenz kompatibel ist, oder? Und würde dass dann nicht die frage aufwerfen, ob andere den ursprünglich unter MIT Lizenzierten Codeteil unter GPLv2 lizenziert vom Ersteller verlangen können, da dieser den Code ja quasi neu lizenziert hat, und man bei der GPL den Code zum binary verlangen kann? So oder so erscheint mir die Möglichkeit bei dieser Lizenzkombination nicht besonders sinnvoll.
> 1. [...] : > -> Hier würde ich meinen Code unter MIT Lizenzieren und die Bibliothek > "wie sie ist" mit LGPL beilegen. > > > 2. [...] : > -> Auch hier würde ich wieder mein zeuch unter MIT und die IRMP unter > bestehender GPL einstellen. > > Sind meine Überlegungen so korrekt? Was Ich bei deinen Überlegungen nicht verstehe ist warum Du Dir die Mühe machst die bereits Quelloffenen Libs miteinzubeziehen. Diese Libs sind ja bereits veröffentlicht! Also verlinke sie einfach... Mit der passenden Buildsteuerung können diese direkt beim ersten Builddurchlauf Online geholt werden (gleich in der passenden Version, muss ja nicht die neueste sein) und lokal gecached bleiben. Du hast die Libs doch nicht etwa geforkt und verbastelt, oder? Du musst Dich also nur um die Lizenz für Deinen Quellcode entschieden.
Hallo erstmal danke für die vielen Infos und Hinweise. Ich wollte mich am Wochenende damit mal auseinandersetzen, aber das war mal wieder so ein Blitzwochenende: Hell, Dunkel, Hell, Dunkel, Montag ... wunderer schrieb: > Ich finde sowieso den ganzen Blödsinn und Aufwand mit den Vorschriften > und Urheberrechten bei privaten Projekten die man veröffentlichen möchte > absolut übertrieben! Deshalb mein Rat, eine Veröffentlichung seiner > privaten Projekte einfach sein lassen... die Welt dreht sich auch so > noch weiter. ;-) Aus dem Grund habe ich bisher keinen Code veröffentlicht. Aber wenn ich durchs web streife und ein interessantes Projekt finde, gucke ich mir gerne die Unterlagen dazu genauer an. Aus diesem Grund möchte ich einfach mit geringem Aufwand die Unterlagen meiner Projekte ins Netz stellen. Iana L. schrieb: >> 1. [...] > : >> -> Hier würde ich meinen Code unter MIT Lizenzieren und die Bibliothek >> "wie sie ist" mit LGPL beilegen. >> >> >> 2. [...] > : >> -> Auch hier würde ich wieder mein zeuch unter MIT und die IRMP unter >> bestehender GPL einstellen. >> >> Sind meine Überlegungen so korrekt? > > Was Ich bei deinen Überlegungen nicht verstehe ist warum Du Dir die Mühe > machst die bereits Quelloffenen Libs miteinzubeziehen. > Diese Libs sind ja bereits veröffentlicht! Also verlinke sie einfach... > Mit der passenden Buildsteuerung können diese direkt beim ersten > Builddurchlauf Online geholt werden (gleich in der passenden Version, > muss ja nicht die neueste sein) und lokal gecached bleiben. > Du hast die Libs doch nicht etwa geforkt und verbastelt, oder? > > Du musst Dich also nur um die Lizenz für Deinen Quellcode entschieden. Im Beispiel 1 kommt der externe Code von sourceforge, ist aber weiter nicht angefasst worden. Im Beispiel 2 musste ich natürlich die irmpconfig.h entsprechend für mein Projekt anpassen. Ich möchte gerne ein Projekt komplett, so wie ich es umgesetzt habe, veröffentlichen. Hintergrund ist einmal ein geringerer Arbeitsaufwand für jemanden der diese Projekt nachbauen möchte und evtl. Inkompatibilitäten bei verschiedenen Versionen des externen Codes. -------------- Also ist der einfachste Weg, meine Sourcen unter einer gleichen oder kompatiblen Lizenz zu stellen. Also bei beiden Beispielen (1. mit LGPL und 2. mit GPL v2) für meinen Code die GPL zu wählen. (Schaltplan und Layout unabhängig davon unter CC...) Und beim zweiten Mikrocontroller-Projekt die Kompilate wegzulassen. Bei Scriptsprachen (Projekt 1 mit php/html) ist das ja eh hinfällig.
Katatafisch schrieb: > Also bei beiden Beispielen (1. mit LGPL und 2. mit GPL v2) für meinen > Code die GPL zu wählen. (Schaltplan und Layout unabhängig davon unter > CC...) Bei der GPL ist dann noch abschnitt 0 zu beachten, man sollte eine Lizenznotiz & Copyrightnotiz in den Sourcecode files hinterlegen, damit klar ist das diese unter der GPL stehen: https://www.gnu.org/licenses/old-licenses/gpl-2.0.en.html#SEC3 Obwohl, es gibt alternativen dazu. Katatafisch schrieb: > Und beim zweiten Mikrocontroller-Projekt die Kompilate wegzulassen. Wenn man für alle source teile sowieso die selbe Lizenz verwendet ist das eigentlich kein Problem.
> Im Beispiel 1 kommt der externe Code von sourceforge, ist aber weiter > nicht angefasst worden. Gut! > Im Beispiel 2 musste ich natürlich die irmpconfig.h entsprechend für > mein Projekt anpassen. Auch gut: aus deiner Feder stammt nur deine "irmpconfig.h" welche jene aus der Lib ersetzt (ev. gar nur einige wenige sed Anweisungen welche die aus der Lib vorhandene Datei minimal anpasst). > Ich möchte gerne ein Projekt komplett, so wie ich es umgesetzt habe, > veröffentlichen. Hintergrund ist einmal ein geringerer Arbeitsaufwand > für jemanden der diese Projekt nachbauen möchte und evtl. > Inkompatibilitäten bei verschiedenen Versionen des externen Codes. pervasive build automation ist erstrebenswert.[1] Also inkl. den Download einer bestimmten Version des ext. Codes, ggfs. inkl. dessen minimale Anpassung. Das passend gewählte Versionierungssystem macht bereits das Meiste für Dich (Stichworte: externals & version pinning ). > Also ist der einfachste Weg, meine Sourcen unter einer gleichen oder > kompatiblen Lizenz zu stellen. DAS. [1] Extremfälle davon laden sich auch schon mal gerne die fürs Projekt benötigte komplette Toolchain runter, nicht bloss Libs. In Source Form und kompilieren sich erstmal die Tools genehm zurecht. dpkg , pkg-man, Gentoo & cie. lassen grüssen. Qualitätssicherung to the Max ...
Iana L. schrieb: > Mit der passenden Buildsteuerung können diese direkt beim ersten > Builddurchlauf Online geholt werden Damit man das eigene Projekt in ein paar Jahren nicht mehr bauen kann, weil irgendeine der Abhängigkeiten entweder gar nicht mehr online verfügbar ist oder woanders? Das Internet ist schnellebig.
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.