Thorsten Behrens schrieb: > michael wrote: >>> Hm. Also ich fasse mal zusammen: das Copyright in einer Hand zu >>> haben, ist hilfreich f"ur die Verfolgung von Verst"ossen, und wenn >>> man, wie geschehen, z.B. auf LGPL v3 re-lizensieren will. Das kann >>> aber genauso gut eine existierende oder noch zu gr"undende >>> Non-Profit-Organisation leisten. F"ur die Benutzung in beliebigen >>> kommerziellen Produkten ist bei LGPL eben genau *keine* Sonderlizenz >>> n"otig. Ich frage mich daher, was dann noch an "nachvollziehbaren >>> und respektablen Gr"unden" "ubrigbleibt? >> [...] >> >> Im Gegensatz zur GPL dürfen alle Programme, welche die LGPL-lizenzierte >> Software nur extern benutzen, zum Beispiel als DLL-Dateien, ihre eigene >> Lizenz behalten. ... Soll die unter der LGPL lizenzierte Software >> dagegen fest in ein anderes Programm eingebunden werden, muss auch das >> andere Programm unter der LGPL bzw. einer kompatiblen Lizenz stehen." >> >> Meine Kurzfassung: Solange SUN Staroffice unter keiner LGPL-kompatiblen >> Lizenz veröffentlicht, wird das SCA gebraucht, damit SUN Rechteinhaber >> ist, der eine solche "duale" Lizenzierung vornehmen kann. >> > Hi Michael, > > nein, wie Du auch Martins Klarstellung nochmal entnehmen kannst. OOo > & SO bin"ar identische libs -> SO-Spezifika nur in separaten > Komponenten -> nach LGPL gestattet. Insofern steht meine Frage > nachwievor im Raume. >
Nein, wenn ich OOo nähme (und SUN nimmt wesentliche Teile von OOo für StarOffice) dann muss ich meine Distribution, sagen wir einmal beispielsweise FreeOffice, unter die LGPL oder eine kompatible Lizenz stellen, darf also beispielsweise keine 3-Klausel-BSD-Lizenz stellen. Erst recht darf ich keine proprietäre Lizenz wählen. Ich darf Programme schreiben, die auf OOo "aufsetzen", beispielsweise Extentions, und diese unter einer beliebigen Lizenz veröffentlichen. Wenn ich aber Code von OOo nehme muss es LGPL oder kompatibel sein. StarOffice kann daher nur deshalb unter einer nicht LGPL-kompatiblen Lizenz erscheinen, weil SUN die Rechte am Code hat (und zwar bei Nicht-SUN-Angestellten (s. § 69b UrheberGesetz) durch das SCA). Du musst mir das nicht glauben; Du kannst auch Rene fragen ;-). >> Forken ist die eine Sache. Dafür mag es in dem einen oder anderen Fall >> gute Gründe geben. Die andere Sache ist, die Lizenz des Forks so zu wählen, >> dass Codeaustausch nur in einer Richtung (zum Fork hin) stattfinden kann und >> in die andere Richtung (zum ursprünglichen Projekt hin) ausgeschlossen ist. >> > Ich weiss nicht, auf welchen Fork (oder empfundenen Fork) Du > anspielst - ooo-build ist LGPL (NeoOffice z.B. ist GPL, und insofern > eine andere Liga). > Also: LGPL-Code kann nach GPL "fließen", aber nicht umgekehrt, womit Du schon das im Auge befindlich gewesene Beispiel genannt hast. Noch mal Klartext: go-ooo-Code kann bei gleicher Lizenz völlig unproblematisch nach OOo "fließen", aber nicht ohne SCA weiter nach StarOffice, was eine Barriere auch für OOo darstellt, wenn man OOo und StarOffice möglichst "codegleich" halten will. Ich hoffe, nun sind alle Unklarheiten beseitigt. Gruß Michael --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@de.openoffice.org For additional commands, e-mail: dev-h...@de.openoffice.org
