michael wrote:
Thorsten Behrens schrieb:
André Schnabel wrote:
Abgesehen davon, dass es aus den im FAQ genannten und anderen Gründen
praktisch ist, wenn eine juristische Person das gesamte Copyright
innehat, braucht SUN das SCA (bzw. JCA) bekanntermaßen zur Distribution
von StarOffice unter der von SUN bestimmten Lizenz.
Das möchte ich bezweifeln. Für die Distribution von StarOffice sollte die
LGPL genauso hinreichend sein, wie sie das für RedOffice, Lotus Symphony,
NeoOffice, Oxygen Office .... ist.
Martin Hollmichel best"atigt dies:
Das ist in der tat so. Fuer StarOffice werden sogar die identischen
libraries wie fuer OpenOffice.org benutzt, [...]
Michael folgerte vorher:
Und SUN hat - aus mir nachvollziehbaren und respektablen Gründen -
erklärt, das SCA stehe nicht zur Disposition.
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?
Ich zitiere mal - weil allgemein verständlich die Wikipedia:
"Die LGPL setzt ähnlich wie die GPL die Idee des Copyleft ein, um die
Freiheit der lizenzierten Software zu schützen. ... Veränderte Versionen
müssen dabei ebenfalls unter der LGPL (oder wahlweise der GPL)
lizenziert werden. Grundsätzlich darf eine unter LGPL lizenzierte
Software nur zusammen mit ihrem Quelltext vertrieben werden.
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.
etwas technischer formuliert: sobald LGPL code statisch in eine andere
Applikation eingebunden wird, muss diese Applikation auf unter einer
LGPL kompatiblen Lizenz stehen. Das Merkmal der LGPL ist aber gerade,
wenn die Libraries unverandert benutzt werden, duerfen die Applikation
mit einen kommerziellen Lizenz ausgestattet werden.
Martin
André Schnabel wrote:
Nun kann der andere "Vertragspartner" die Zusammenarbeit aufkündigen und
beispielsweise OOo forken und den Fork unter eine Lizenz stellen, nach
der garantiert kein Code mehr nach OOo (und StarOffice) zurückfließen
kann (wie in der Vergangenheit schon leider geschehen). Dies ist sein
gutes Recht aufgrund der von SUN für OOo gewählten Lizenz.
Nur kann mir keiner erklären, dass ein solches Verhalten Freier Software
im Allgemeinen und OOo im Speziellen nützt und dass er damit der
OOo-Community oder den Office-Suite-Nutzern etwas Gutes tut.
Da stimme ich dir vollkommen zu. Diese verhalten nützt kaum jemandem was
- insbesondere aber nicht dem OOo-Projekt. Ich glaube, Thorsten könnte da
anderer Ansicht sein - von Michael Meeks weiss ich, dass er es definitiv
ist ;)
Tja, Forking. Ein ganz interessanter Text dazu:
http://producingoss.com/en/social-infrastructure.html#forkability
http://producingoss.com/en/forks.html
Obige Links entsprechen nahezu 100% meiner Ansicht zu diesem Thema.
Insofern ist es an allen Beteiligten, einen Fork nach M"oglichkeit
zu vermeiden - oder eben nicht (um Missverst"andnissen vorzubeugen:
ich stimme ebenfalls mit Andrés obiger Aussage "uberein, zumindest
kurz- bis mittelfristig).
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.
Gruß
Michael
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@de.openoffice.org
For additional commands, e-mail: dev-h...@de.openoffice.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@de.openoffice.org
For additional commands, e-mail: dev-h...@de.openoffice.org
