Lebenszeichen vom Team OpenOffice.org - [Fwd: [de-users]

[michael]

Hallo,

Thomas Mitzka hat sich auf der users ... gemeldet. Da das auch hier
interessant sein dürfte, habe ich die Nachricht weitergeleitet.

Meine Anmerkung: Gerüchte entstehen oft mangels "handfester" Informationen.

Gruß
Michael

-------- Original-Nachricht --------
Betreff: [de-users] Re: Open Office
Datum: Fri, 21 Oct 2011 13:42:14 +0200
Von: Thomas Mitzka <***@bos-it.de>
Antwort an: ***@de.openoffice.org
An: ***@de.openoffice.org
Referenzen:
<1482742724.197795.1319134566547.JavaMail.open-***@oxltgw05.schlund.de>
<***@Esprimo7935> <***@kirk.de>
<***@Esprimo7935>
<***@kirk.de> <***@openoffice.org>

Hi,
es kursieren doch die interessantesten Informationen und Gerüchte im
Netz um den Fortbestand von OOo.
Vielleicht kann ich hier ein paar Dinge einmal klarziehen und verdeutlichen:

1. Die ASF hat die "Aufsicht" über den OOo-Quellcode und das Copyright
von Oracle überantwortet bekommen.
2. Aktuell versucht man dort den Code von der LGPL Lizenz auf die ASL
Lizenz zu portieren (ein echt großes Projekt)
- ob die ASF jemals eigene Binärpakete, für alle Betriebssysteme, von
OOo erstellen wird ist zur Zeit noch nicht klar.
- wenn denn wann das erste OOo zum Download bereitsteht ist zur Zeit
nicht vorhersagbar
3. Zum 1.Sept. hat Oracle fast alle Mitarbeiter der Business-Unit
"OpenOffice" entlassen.
4. Diese Mitarbeiter haben bis vor kurzem etwa 95% des OOo Codes
produziert und verwaltet und gepflegt.

5. Größte Frage/Unsicherheit aktuell: Was wird aus OOo, wenn die
Entwickler nicht mehr an dem Projekt arbeiten? Wer füllt die Lücken und
wer übernimmt deren Aufgaben?

6. TeamOpenOffice (existiert seit +10 Jahren und hat sich schon immer um
die Finanzen des Projekts gekümmert!) hat sich jetzt "aufgerafft", um
ein paar der Lücken zu füllen und um sicher zustellen, dass es auch in
Zukunft ein freies OOo geben wird.
- Es wurden alle OOo-Entwickler aus Hamburg zusammengerufen und das
TeamOO hat ihnen deutlich gemacht, dass man versuchen möchte Ihre
Arbeitskraft zu erhalten.
- Damit das gelingen kann, wurde eine Spenden/Retter-Kampagne gestartet.
(Erste Artikel hat Ihr sicher schon gelesen) Hier ist übrigens jeder
herzlich eingeladen auf die eine oder andere Art und Weise mit zu helfen
;) (www.teamopenoffice.de) Es gibt einen Kampagnenplan, die Seiten
werden auch noch übersetzt (englisch, etc) und wir versuchen gerade
alles, das Geld aufzutreiben, dass die Entwicklung auch in Zukunft
gesichert ist.
- TeamOO hat sich auf die Fahnen geschrieben, das Release 3.3.1 endlich
fertig zu stellen und man ist auch fleissig dabei.
- TeamOO möchte gerne eine langfristige Entwicklungssicherheit
garantieren können und wieder dafür sorgen, dass OOo für alle zum
Download bereitsteht.
- TeamOO möchte in der Zukunft fleissig zu OOo (ASF) beitragen und würde
auch sehr gerne mit LO eng zusammenarbeiten. Wie das aussehen wird, muss
man mal schauen, aber auch hier gibt es sicher schon Ideen und
Vorstellungen :)

7. Eigentlich wollen wir die Arbeit der Vergangenheit fortführen und
dabei die Community besser und enger einbinden, den direkten Kontakt zu
den Nutzern suchen und viel mehr für die Verbreitung von OOo tun.

Ich hoffe ich habe nichts ausgelassen, aber so stellt sich die aktuelle
Situation dar. OOo ist nicht tot, nein es wird gerade noch etwas
umgearbeitet, so dass im Anschluss alle gut davon haben (wenn man es so
formulieren darf ;) )

Viele Grüße und ein schönes Wochenende

Thomas

Deswegen äußerte ich ja die Erwartung, dass da in absehbarerZukunft
wieder mehr zu sehen sein sollte. Also nochmal zusammengefasst: Die
Neuorganisation hat sicher viele Kräfte gebunden, weswegen währenddessen
nicht so viel veröffentlicht wurde wie zuvor gewohnt; dies solltejetzt
aber erledigt sein, so dass es künftig wieder deutlicher vorwärts geht.
Ein daraus etwa entstandener Eindruck, OOo sei tot oder es würde OOo
nicht mehr geben, ist falsch.

Der Releaseplan für OpenOffice.org sah zuletzt vier Releases pro Jahr
vor, nämlich zwei Releases mit neuen Features und zwei
Bugfixingreleases. Dieser Releaseplan konnte mehr als nur gelegentlich
nicht eingehalten werden. Vor den Featurereleases gab es Beta-Releases
zum öffentlichen Testen. Schließt man diese ein, waren es (planmäßig)
insgesamt sechs Releases pro Jahr. Daneben wurden mehr oder weniger
zahlreiche Milestones und Release Candidates zum Testen veröffentlicht.
als letztes Bugfixing-Release: 3.2.1
als letztes Feature-Release: 3.3
als letztes Beta-Release: 3.4-beta
LibreOffice hat nach eigenen Angaben eine andere Release-Politik, die
mit "release early, release often" gekennzeichnet werden kann. Dies hat
zur Folge, dass dort nur manche Versionen als zum produktiven Einsatz
gedacht deklariert werden.
Apache kann auf OpenOffice.org 3.4-beta aufbauen, hat jedoch noch
notwendigerweise zahlreiche Aufgaben zu bewältigen, bevor ein
"offizielles" Release angekündigt werden. Es jedoch meinem Kenntnisstand
nach bereits "private" Builds aus dem Apache-Repository zum Testen -
allerdings wohl nicht für alle Plattformen.
Es geht also bei OpenOffice.org voran, wenn auch verständlicherweise
z.Zt. sehr viel langsamer als gewohnt.
Gruß
Michael

--
------------- BOS-it GmbH&Co.KG -----------------------------------
You can learn what ever you want, you just
have to try and try and try and try ....

Oracle Approved Education Center - Hamburg und Berlin

Thomas Mitzka
Geschäftsführer / CEO
Mobil: (++49)-(0)173-8534351
Mail: ***@Bos-it.de

BOS-it GmbH&Co.KG
BOS-it Oracle Schulungszentrum
Nagelsweg 55
20097 Hamburg

Tel: 040 - 32901977
Fax: 040 - 32901978

Oracle Office Migrations-Partner
Oracle Silber-Partner
Handelsregister: Hamburg A 110856
VAT: DE265464252
--
-----------------------------------------------------------------
To unsubscribe send email to users-***@de.openoffice.org
For additional commands send email to ***@de.openoffice.org
with Subject: help

[Jörg Schmidt]

Hallo,

Post by michael
Meine Anmerkung: Gerüchte entstehen oft mangels "handfester"
Informationen.

Bloß was ist Gerücht und was Information? Oder stürzt Du Dich in Beliebigkeit auf jede gut _klingende_ Aussage und leitest daraus eine 'gesicherte Zukunft' für OOo ab?


Zur Frage von Informationen und angemessen kritischer Beurteilung der entstandenen Lage verweise ich einmal auf den post von Mathias auf de users-Liste, der mir ausnehmend gut gefällt:
http://article.gmane.org/gmane.comp.openoffice.general.german/102575

(unten auch zusätzlich als 'Volltext' angehängt)

Ich habe auf der users-Liste umfassend geantwortet, möchte meine antwort hier aber verkürzt auch nochmals reinstellen:

Alle Probleme die ich bei Team OOo sehe, und die sich nicht mehr wegdiskutieren lassen, gründen sich überwiegend auf mangelnde Bereitschaft zur Kommunikation mit der (ehrenamtlichen) Community und mit potentiellen (_eher_ beruflich) interessierten Unterstützern.

Die jetzige Kampange von Team OOo erachte ich _leider_ weitgehend als Flop (nicht einmal die Stimmung im 'Unternehmenslager' ist nennenswert positiv) und die Ursache ist für mich überwiegend der Versuch der Eigenbrödlerei, denn hätte man die, ehrenamtliche wie 'kommerzielle', Community mit eingebunden hätte das Ganze ganz anders ausgesehen.

Team OOo hat wohl auch jetzt noch manche Chancen zu /einem/ Motor zu werden (*Mathias beschreibt einen Weg dazu der mir persönlich sehr gefiele*), aber dazu gilt es schnellstens Ernst damit zu machen mit der Community zusammenzuarbeiten und nicht nur davon zu reden das zu tun.


Hierzu möchte ich Team OOo auffordern und ermutigen:
Geht auf die Community zu, hört auch auf ihre Erfahrungen, bringt Eure eigenen Erfahrungen und euer Wissen ein und fühlt euch als Teil der Community.
Seit bereit auch den Weg der kleinen mühevollen Schritte zu gehen und hört auf zu glauben die Zukunft von OOo vom 'grünen Tisch' aus gestalten zu können, sondern mischt euch unters 'Volk', das Volk was nur Spaß daran hat hier in einem freien Projekt etwas mitzutun, genauso wie das 'Volk' das sich auch beruflich mit OOo beschäftigt ohne gleichzeitig ein Welt-Konzern zu sein.

Längst nicht ist dadurch schon die Zukunft von OOo sicher, aber jeder Weg beginnt mit dem ersten Schritt ...



Gruß
Jörg


--

-----Ursprüngliche Nachricht-----
Von: Mathias Bauer [mailto:***@gmx.de]
Gesendet: Freitag, 21. Oktober 2011 22:17
An: ***@de.openoffice.org
Betreff: [de-users] Re: Open Office

Moin Thomas,

ich finde es prima, dass ihr OOo voranbringen wollt, aber ich habe so einige Problem mit der Art, wie ihr es tut. Das Echo, was euer Presse-Statement hervorgerufen hat, war IMHO sehr schlecht für OOo. Mit etwas mehr vorheriger Koordination und Kommunikation wäre das sicherlich vermeidbar gewesen.

Ihr erwecktet den Eindruck, dass OOo am Ende ist (ohne wirklich zu erklären, warum ihr das glaubt). Das wolltet ihr sicher nicht, aber so ist es durch die Presse gegangen (IMHO vorhersehbar). Ich kann mir auch gut vorstellen, dass in LibreHausen die Sektkorken geknallt haben. :-)

Die Fantastischen Vier sind nur mal leider nur ein Comic. In der realen Welt braucht es mehr, um ein solches Projekt zu stemmen, und daher sollte man die verfügbaren Resourcen bündeln. Das erfordert eine gemeinsame Basis und Absprachen, keine Pressemitteilungen aus heiterem Himmel. Davon hatten wir letztes Jahr ungefähr zur gleichen Zeit eigentlich schon eine zuviel.

Post by michael
Hi,
es kursieren doch die interessantesten Informationen und Gerüchte im
Netz um den Fortbestand von OOo.
1. Die ASF hat die "Aufsicht" über den OOo-Quellcode und das Copyright
von Oracle überantwortet bekommen.

Das ist leider falsch, siehe nächsten Absatz.

Post by michael
2. Aktuell versucht man dort den Code von der LGPL Lizenz auf die ASL
Lizenz zu portieren (ein echt großes Projekt)

Man versucht es nicht, man tut es. Und das wird auch passieren. Es sind dabei folgende Dinge zu erledigen:

- Oracle erstellt eine Liste aller Dateien, die es unter die Apache-Lizenz (AL2) stellt; die ASF erhält *nicht* das Copyright (das wollen die gar nicht), der Code wird nur unter die AL2 gestellt, sodass die ASF ihn nutzen kann. Oracle kann das für alle Quelldateien tun, deren Copyright es besitzt (das sind bei weitem die meisten).
- Alle restlichen Quelldateien müssen daraufhin untersucht werden, ob ihre Lizenz "kompatibel" mit der AL2 ist (also z.B. eine BSD-Lizenz, MIT-Lizenz usw.).
- Einige Quelldateien sind klar inkompatibel (LGPL oder MPL) und müssen durch andere ersetzt bzw. neu geschrieben werden. Das ist ein relativ kleiner Teil.
- OOo verwendet eine ganze Reihe von "externen" Libraries, von denen einige unter einer zur AL2 kompatiblen Lizenz stehen, einige nicht.
Momentan muss noch untersucht werden, welche davon z.B. durch Änderung des Build/Release-Prozesses weiterhin verwendet werden können (Hunspell,nss), welche ersetzt werden müssen und welche dann erst einmal in einer 3.4 fehlen werden, zumindest auf einigen Plattformen.

Stand der Dinge ist, dass ich selbst schon vor Wochen mal eine Liste aller Quelldateien erstellt habe, von denen ich annehme, dass sie nicht Oracle gehören, und alle damit verbundenen Lizenzprobleme sind adressiert, zum Teil auch schon gelöst. Des weiteren kennen wir mittlerweile auch fast alle lizenzinkompatbilen 3rdparty-Komponenten von OOo und es wird erörtert, wie damit umgegangen werden kann. Man wird sehen.

Wie lange Oracle noch für die endgültige Dateiliste braucht, weiß in der Tat niemand, aber ich vermute sehr stark, dass die da so viel Tempo wie möglich machen, weil die offensichtlich mit OOo so schnell wie irgend möglich nix mehr zu tun haben wollen. ;-) Und allzu stark wird die endgültige Liste nicht von meiner Liste, die ich mir mal selbst gebastelt hatte (und die als Grundlage für die Liste der "nicht-Oracle-Dateien" diente), abweichen. Diese beiden Arbeiten laufen also quasi parallel nebeneinander.

Post by michael
- ob die ASF jemals eigene Binärpakete, für alle Betriebssysteme, von
OOo erstellen wird ist zur Zeit noch nicht klar.

Das ist so komplett falsch. Es gibt überhaupt keinen Grund, daran zu zweifeln, dass die Entwickler, die unter dem Dach der ASF an OOo arbeiten, ein Release zustande bringen werden. Und dieses wird dann natürlich zumindest Windows, MacOS und Linux bedienen. Solaris scheint sowohl bei LO als auch bei OOo auf dem absteigenden Ast zu sein, solange sich dafür keine aktive Entwickler-Community findet. Wieso verbreitest du solche Angstparolen?

Warum sollte die ASF ein Projekt übernehmen, aber dann keine Releases machen? Wenn es Entwickler gibt, die das wollen, dann wird es auch passieren.

Post by michael
- wenn denn wann das erste OOo zum Download bereitsteht ist zur Zeit
nicht vorhersagbar

Richtig. Das gilt aber für alle Projekte, die keinen zeitgetriebenen Schedule wie LO haben. Das galt z.B. insbesondere für alle bisherigen OOo Releases. ;-)

Post by michael
3. Zum 1.Sept. hat Oracle fast alle Mitarbeiter der Business-Unit
"OpenOffice" entlassen.

Das ist auch nicht richtig. Aber Details sind hier unwichtig und als ehemaliger Oracle-Mitarbeiter respektiere ich den Wunsch meines vorherigen Arbeitgebers, diese Dinge nicht in der Öffentlichkeit zu erörtern.

In der Praxis hat die Masse der OOo-Entwickler von Oracle bereits vor dem 1. September die Arbeit am Produkt eingestellt, wie die Statistiken des Quelltext-Repositories zeigen. Nichtsdestotrotz arbeiten mittlerweile schon wieder eine Reihe von Entwicklern an Apache-OOo und es werden in absehbarer Zeit auch noch mehr Entwickler hinzukomen.
Entsprechende Ankündigungen hat es schon gegeben. Da ich über hier nicht ausbreitbares Hintergrundwissen dazu verfüge, kann ich nur anmerken, dass ich diesbezüglich absolut optimistisch bin.

Post by michael
5. Größte Frage/Unsicherheit aktuell: Was wird aus OOo, wenn die
Entwickler nicht mehr an dem Projekt arbeiten? Wer füllt die Lücken
und wer übernimmt deren Aufgaben?

Vielleicht die Entwickler, die das in Zukunft unter dem Dach der ASF tun?

Post by michael
6. TeamOpenOffice (existiert seit +10 Jahren und hat sich schon immer
um die Finanzen des Projekts gekümmert!) hat sich jetzt "aufgerafft",
um ein paar der Lücken zu füllen und um sicher zustellen, dass es auch
in Zukunft ein freies OOo geben wird.
- Es wurden alle OOo-Entwickler aus Hamburg zusammengerufen und das
TeamOO hat ihnen deutlich gemacht, dass man versuchen möchte Ihre
Arbeitskraft zu erhalten.

Naja, das ist eine heftige Übertreibung. Deine Aussage mag bei Außenstehenden den Eindruck erwecken, dass es nur an fehlendem Geld liegt, dass die alte Mannschaft nicht mehr an OOo arbeitet, aber das stimmt nicht.

Es ist richtig, dass eine Einladung verteilt wurde, aber das sagt ja nichts aus. Die ehemaligen OOo-Entwickler aus Hamburg haben jedenfalls größtenteils alle schon neue Jobs (mich eingeschlossen, bei Apache OOo arbeite ich jetzt als freier Entwickler mit). Wenn ein paar der verbliebenen ehemaligen OOo-Entwickler durch entsprechendes Funding in die Lage versetzt würden, an Apache-OOo mitzuarbeiten, wäre das natürlich wunderbar. Ich fände es klasse, wenn ihr da was erreichen könntet. Aber alleine werden die das nicht wuppen können.

Post by michael
- Damit das gelingen kann, wurde eine Spenden/Retter-Kampagne gestartet.
(Erste Artikel hat Ihr sicher schon gelesen) Hier ist übrigens jeder
herzlich eingeladen auf die eine oder andere Art und Weise mit zu helfen
;) (www.teamopenoffice.de) Es gibt einen Kampagnenplan, die Seiten
werden auch noch übersetzt (englisch, etc) und wir versuchen gerade
alles, das Geld aufzutreiben, dass die Entwicklung auch in Zukunft
gesichert ist.
- TeamOO hat sich auf die Fahnen geschrieben, das Release 3.3.1
endlich fertig zu stellen und man ist auch fleissig dabei.
- TeamOO möchte gerne eine langfristige Entwicklungssicherheit
garantieren können und wieder dafür sorgen, dass OOo für alle zum
Download bereitsteht.

Du solltest eigentlich wissen, dass TeamOOo zwar Software zum Download anbieten kann, aber kein OOo, das kann nach Lage der Dinge nur die ASF.

Post by michael
- TeamOO möchte in der Zukunft fleissig zu OOo (ASF) beitragen und
würde auch sehr gerne mit LO eng zusammenarbeiten. Wie das aussehen
wird, muss man mal schauen, aber auch hier gibt es sicher schon Ideen
und Vorstellungen :)

Wäre nur schön gewesen, ihr hättet das bei eurer Kampagne gleich von vorneherein an prominenter Stelle klargemacht. Erstens, weil das nach einer schlagkräftigeren Bewegung klingt als eure 4-Mann-Kampagne und so dem Ruf von OOo sicherlich mehr geholfen hätte, und zweitens, weil es nun mal nicht ohne die ASF gehen wird. Oder die TDF, wenn ihr diese Richtung beschreiten wollt. Einen zweiten Fork braucht OOo so nötig wie ich ein drittes Bein.

Post by michael
7. Eigentlich wollen wir die Arbeit der Vergangenheit fortführen und
dabei die Community besser und enger einbinden, den direkten Kontakt
zu den Nutzern suchen und viel mehr für die Verbreitung von OOo tun.

Sehr guter Punkt! Mit dem Verständnis, dass ein Projekt wie OOo auch eine Anwender-Komponente als integralen Bestandteil der Projektstruktur braucht, tut sich die ASF schwer, zumindest IMHO. Ihr wäret hier eine perfekte Ergänzung. Wobei ich sowohl professionelle Nutzer, die evtl.
sogar bezahlten Support brauchen, als auch den sprichwörtlichen Otto Normalverbraucher meine.

So wie ich die Leute bei der ASF kennengelernt habe, haben die kein Besitzdenken. Die freuen sich über jeden, der an den Projekten, die sie hosten, mitarbeitet. Wenn dann noch Leute wie TeamOOo auftreten, die in den Bereichen, wo es der ASF einfach an Erfahrung und manchmal auch an Verständnis fehlt, ihr Tätigkeitsfeld sehen, wird das bestimmt positiv wahrgenommen. Es ist nur wichtig, dass das alles öffentlich auf der Mailingliste erfolgt, nicht irgendwo im stillen Kämmerlein und dann mit einem Paukenschlag verkündet.

Post by michael
Ich hoffe ich habe nichts ausgelassen, aber so stellt sich die
aktuelle Situation dar. OOo ist nicht tot, nein es wird gerade noch
etwas umgearbeitet, so dass im Anschluss alle gut davon haben (wenn
man es so formulieren darf ;) )

IMHO liegt die Zukunft von OOo bei der ASF und, und das Beste, was alle an einer Zukunft von OOo Interessierten tun könnten, ist, das dortige Projekt zu unterstützen. Da ist auch Platz für Team OpenOffice.org, ich glaube sogar, dass das eine wundervolle Ergänzung wäre.

Die ASF beschäftigt keine Entwickler, vielmehr sind aus deren Sicht alle Entwickler "Freiwillige". Einige von diesen werden von Firmen wie IBM bezahlt, andere nicht. Da könnte eine Organisation wie TeamOOo, die Donations einsammeln kann, um Entwickler zu bezahlen (was die ASF nicht kann und will), helfen. Ob das nun allgemeine Spenden oder zielgerichtete "Bounties" sind, ist egal.

Aber das ändert nichts daran, dass das ein Apache-OOo bleiben wird, und aufgrund der rechtlichen Situation ist das auch das einzige OOo, das es geben kann, denn die Trademark gehört der ASF. Die einzige Möglichkeit, dass die ASF das Trademark von OOo dauerhaft an jemand anders abtritt, wäre, dass Apache-OOo komplett scheitert. Aber weder glaube ich, dass das eintreten wird, noch glaube ich, dass irgendjemand hier sich das wünscht, denn dann wäre OOo IMHO wirklich am Ende. Also sollten wir davon ausgehen, dass "OpenOffice.org" entweder von der ASF kommt oder gar nicht.

Ihr könntet vielleicht helfen, ein "Zwischenrelease" wie die von dir erwähnte 3.3.1 herauszubringen, z.B. um die aufgekommene Diskussion über Security Fixes zu adressieren. Die ASF kann jetzt noch nichts releasen (aus Lizenzgründen), ihr könnt es ohne weiteres auch nicht, weil ihr das Trademark für OOo nicht habt. Mit etwas Fantasie kann man da vielleicht etwas basteln (ohne Details - IANAL). Würde ich gut finden.

Ciao,
Mathias

[David Paenson]

Hallo,

ich wünsche Apache-OOo allen Erfolg. Zwei Forks sind in der Tat eine
Verzettelung der Kräfte. Die derzeitig im Umlauf befindliche 3.3 ist extrem
gut. Es besteht keine Not, die Sachen übers Knie zu brechen. User in der
Industrie und in Büros oder an Unis brauchen keine so häufigen Releases, sie
wollen vor allem zuverlässige Software. Natürlich freuen sie sich und
brauchen auch eine Weiterentwicklung, sprich neue Features, aber nicht in so
kurzen Abständen.

Ich für meinen Teil habe angefangen, meine Dokumentation für Studenten jetzt
ins Französische zu übersetzen. Die englische und deutsche Version liegen,
so lange sie nicht direkt auf Apache untergebracht werden können, hier:

http://www.fb4.fh-frankfurt.de/tips/openoffice/dokumentation/ooo_for_students.pdf[ENGLISCH]
http://www.fb4.fh-frankfurt.de/tips/openoffice/dokumentation/ooo_fuer_studenten.pdf[DEUTSCH]

Ich werde die Apache-Entwicklung im Rahmen meiner Möglichkeiten
(Dokumentation und Unterricht an meiner Uni) weiterhin unterstützen. Ich
wünsche mir, dass die LO-Programmierer das ebenfalls tun.

Dave

Post by michael
Hallo,

Post by michael
Meine Anmerkung: Gerüchte entstehen oft mangels "handfester" Informationen.

Bloß was ist Gerücht und was Information? Oder stürzt Du Dich in
Beliebigkeit auf jede gut _klingende_ Aussage und leitest daraus eine
'gesicherte Zukunft' für OOo ab?
Zur Frage von Informationen und angemessen kritischer Beurteilung der
entstandenen Lage verweise ich einmal auf den post von Mathias auf de
http://article.gmane.org/gmane.comp.openoffice.general.german/102575
(unten auch zusätzlich als 'Volltext' angehängt)
Ich habe auf der users-Liste umfassend geantwortet, möchte meine antwort
Alle Probleme die ich bei Team OOo sehe, und die sich nicht mehr
wegdiskutieren lassen, gründen sich überwiegend auf mangelnde Bereitschaft
zur Kommunikation mit der (ehrenamtlichen) Community und mit potentiellen
(_eher_ beruflich) interessierten Unterstützern.
Die jetzige Kampange von Team OOo erachte ich _leider_ weitgehend als Flop
(nicht einmal die Stimmung im 'Unternehmenslager' ist nennenswert positiv)
und die Ursache ist für mich überwiegend der Versuch der Eigenbrödlerei,
denn hätte man die, ehrenamtliche wie 'kommerzielle', Community mit
eingebunden hätte das Ganze ganz anders ausgesehen.
Team OOo hat wohl auch jetzt noch manche Chancen zu /einem/ Motor zu werden
(*Mathias beschreibt einen Weg dazu der mir persönlich sehr gefiele*), aber
dazu gilt es schnellstens Ernst damit zu machen mit der Community
zusammenzuarbeiten und nicht nur davon zu reden das zu tun.
Geht auf die Community zu, hört auch auf ihre Erfahrungen, bringt Eure
eigenen Erfahrungen und euer Wissen ein und fühlt euch als Teil der
Community.
Seit bereit auch den Weg der kleinen mühevollen Schritte zu gehen und hört
auf zu glauben die Zukunft von OOo vom 'grünen Tisch' aus gestalten zu
können, sondern mischt euch unters 'Volk', das Volk was nur Spaß daran hat
hier in einem freien Projekt etwas mitzutun, genauso wie das 'Volk' das sich
auch beruflich mit OOo beschäftigt ohne gleichzeitig ein Welt-Konzern zu
sein.
Längst nicht ist dadurch schon die Zukunft von OOo sicher, aber jeder Weg
beginnt mit dem ersten Schritt ...
Gruß
Jörg
--
-----Ursprüngliche Nachricht-----
Gesendet: Freitag, 21. Oktober 2011 22:17
Betreff: [de-users] Re: Open Office
Moin Thomas,
ich finde es prima, dass ihr OOo voranbringen wollt, aber ich habe so
einige Problem mit der Art, wie ihr es tut. Das Echo, was euer
Presse-Statement hervorgerufen hat, war IMHO sehr schlecht für OOo. Mit
etwas mehr vorheriger Koordination und Kommunikation wäre das sicherlich
vermeidbar gewesen.
Ihr erwecktet den Eindruck, dass OOo am Ende ist (ohne wirklich zu
erklären, warum ihr das glaubt). Das wolltet ihr sicher nicht, aber so ist
es durch die Presse gegangen (IMHO vorhersehbar). Ich kann mir auch gut
vorstellen, dass in LibreHausen die Sektkorken geknallt haben. :-)
Die Fantastischen Vier sind nur mal leider nur ein Comic. In der realen
Welt braucht es mehr, um ein solches Projekt zu stemmen, und daher sollte
man die verfügbaren Resourcen bündeln. Das erfordert eine gemeinsame Basis
und Absprachen, keine Pressemitteilungen aus heiterem Himmel. Davon hatten
wir letztes Jahr ungefähr zur gleichen Zeit eigentlich schon eine zuviel.
Damit wir in Zukunft nicht wieder ständig über solche Missverständnisse

Post by michael
Hi,
es kursieren doch die interessantesten Informationen und Gerüchte im
Netz um den Fortbestand von OOo.

In der Tat, und daran wart ihr zuletzt nicht ganz schuldlos (s.o.). Dann

Post by michael
Vielleicht kann ich hier ein paar Dinge einmal klarziehen und
1. Die ASF hat die "Aufsicht" über den OOo-Quellcode und das Copyright
von Oracle überantwortet bekommen.

Das ist leider falsch, siehe nächsten Absatz.

Post by michael
2. Aktuell versucht man dort den Code von der LGPL Lizenz auf die ASL
Lizenz zu portieren (ein echt großes Projekt)

Man versucht es nicht, man tut es. Und das wird auch passieren. Es sind
- Oracle erstellt eine Liste aller Dateien, die es unter die Apache-Lizenz
(AL2) stellt; die ASF erhält *nicht* das Copyright (das wollen die gar
nicht), der Code wird nur unter die AL2 gestellt, sodass die ASF ihn nutzen
kann. Oracle kann das für alle Quelldateien tun, deren Copyright es besitzt
(das sind bei weitem die meisten).
- Alle restlichen Quelldateien müssen daraufhin untersucht werden, ob ihre
Lizenz "kompatibel" mit der AL2 ist (also z.B. eine BSD-Lizenz, MIT-Lizenz
usw.).
- Einige Quelldateien sind klar inkompatibel (LGPL oder MPL) und müssen
durch andere ersetzt bzw. neu geschrieben werden. Das ist ein relativ
kleiner Teil.
- OOo verwendet eine ganze Reihe von "externen" Libraries, von denen einige
unter einer zur AL2 kompatiblen Lizenz stehen, einige nicht.
Momentan muss noch untersucht werden, welche davon z.B. durch Änderung des
Build/Release-Prozesses weiterhin verwendet werden können (Hunspell,nss),
welche ersetzt werden müssen und welche dann erst einmal in einer 3.4 fehlen
werden, zumindest auf einigen Plattformen.
Stand der Dinge ist, dass ich selbst schon vor Wochen mal eine Liste aller
Quelldateien erstellt habe, von denen ich annehme, dass sie nicht Oracle
gehören, und alle damit verbundenen Lizenzprobleme sind adressiert, zum Teil
auch schon gelöst. Des weiteren kennen wir mittlerweile auch fast alle
lizenzinkompatbilen 3rdparty-Komponenten von OOo und es wird erörtert, wie
damit umgegangen werden kann. Man wird sehen.
Wie lange Oracle noch für die endgültige Dateiliste braucht, weiß in der
Tat niemand, aber ich vermute sehr stark, dass die da so viel Tempo wie
möglich machen, weil die offensichtlich mit OOo so schnell wie irgend
möglich nix mehr zu tun haben wollen. ;-) Und allzu stark wird die
endgültige Liste nicht von meiner Liste, die ich mir mal selbst gebastelt
hatte (und die als Grundlage für die Liste der "nicht-Oracle-Dateien"
diente), abweichen. Diese beiden Arbeiten laufen also quasi parallel
nebeneinander.

Post by michael
- ob die ASF jemals eigene Binärpakete, für alle Betriebssysteme, von
OOo erstellen wird ist zur Zeit noch nicht klar.

Das ist so komplett falsch. Es gibt überhaupt keinen Grund, daran zu
zweifeln, dass die Entwickler, die unter dem Dach der ASF an OOo arbeiten,
ein Release zustande bringen werden. Und dieses wird dann natürlich
zumindest Windows, MacOS und Linux bedienen. Solaris scheint sowohl bei LO
als auch bei OOo auf dem absteigenden Ast zu sein, solange sich dafür keine
aktive Entwickler-Community findet. Wieso verbreitest du solche
Angstparolen?
Warum sollte die ASF ein Projekt übernehmen, aber dann keine Releases
machen? Wenn es Entwickler gibt, die das wollen, dann wird es auch
passieren.

Post by michael
- wenn denn wann das erste OOo zum Download bereitsteht ist zur Zeit
nicht vorhersagbar

Richtig. Das gilt aber für alle Projekte, die keinen zeitgetriebenen
Schedule wie LO haben. Das galt z.B. insbesondere für alle bisherigen OOo
Releases. ;-)

Post by michael
3. Zum 1.Sept. hat Oracle fast alle Mitarbeiter der Business-Unit
"OpenOffice" entlassen.

Das ist auch nicht richtig. Aber Details sind hier unwichtig und als
ehemaliger Oracle-Mitarbeiter respektiere ich den Wunsch meines vorherigen
Arbeitgebers, diese Dinge nicht in der Öffentlichkeit zu erörtern.
In der Praxis hat die Masse der OOo-Entwickler von Oracle bereits vor dem
1. September die Arbeit am Produkt eingestellt, wie die Statistiken des
Quelltext-Repositories zeigen. Nichtsdestotrotz arbeiten mittlerweile schon
wieder eine Reihe von Entwicklern an Apache-OOo und es werden in absehbarer
Zeit auch noch mehr Entwickler hinzukomen.
Entsprechende Ankündigungen hat es schon gegeben. Da ich über hier nicht
ausbreitbares Hintergrundwissen dazu verfüge, kann ich nur anmerken, dass
ich diesbezüglich absolut optimistisch bin.

Post by michael
5. Größte Frage/Unsicherheit aktuell: Was wird aus OOo, wenn die
Entwickler nicht mehr an dem Projekt arbeiten? Wer füllt die Lücken
und wer übernimmt deren Aufgaben?

Vielleicht die Entwickler, die das in Zukunft unter dem Dach der ASF tun?

Post by michael
6. TeamOpenOffice (existiert seit +10 Jahren und hat sich schon immer
um die Finanzen des Projekts gekümmert!) hat sich jetzt "aufgerafft",
um ein paar der Lücken zu füllen und um sicher zustellen, dass es auch
in Zukunft ein freies OOo geben wird.
- Es wurden alle OOo-Entwickler aus Hamburg zusammengerufen und das
TeamOO hat ihnen deutlich gemacht, dass man versuchen möchte Ihre
Arbeitskraft zu erhalten.

Naja, das ist eine heftige Übertreibung. Deine Aussage mag bei
Außenstehenden den Eindruck erwecken, dass es nur an fehlendem Geld liegt,
dass die alte Mannschaft nicht mehr an OOo arbeitet, aber das stimmt nicht.
Es ist richtig, dass eine Einladung verteilt wurde, aber das sagt ja nichts
aus. Die ehemaligen OOo-Entwickler aus Hamburg haben jedenfalls größtenteils
alle schon neue Jobs (mich eingeschlossen, bei Apache OOo arbeite ich jetzt
als freier Entwickler mit). Wenn ein paar der verbliebenen ehemaligen
OOo-Entwickler durch entsprechendes Funding in die Lage versetzt würden, an
Apache-OOo mitzuarbeiten, wäre das natürlich wunderbar. Ich fände es klasse,
wenn ihr da was erreichen könntet. Aber alleine werden die das nicht wuppen
können.

Post by michael
- Damit das gelingen kann, wurde eine Spenden/Retter-Kampagne gestartet.
(Erste Artikel hat Ihr sicher schon gelesen) Hier ist übrigens jeder
herzlich eingeladen auf die eine oder andere Art und Weise mit zu helfen
;) (www.teamopenoffice.de) Es gibt einen Kampagnenplan, die Seiten
werden auch noch übersetzt (englisch, etc) und wir versuchen gerade
alles, das Geld aufzutreiben, dass die Entwicklung auch in Zukunft
gesichert ist.
- TeamOO hat sich auf die Fahnen geschrieben, das Release 3.3.1
endlich fertig zu stellen und man ist auch fleissig dabei.
- TeamOO möchte gerne eine langfristige Entwicklungssicherheit
garantieren können und wieder dafür sorgen, dass OOo für alle zum
Download bereitsteht.

Du solltest eigentlich wissen, dass TeamOOo zwar Software zum Download
anbieten kann, aber kein OOo, das kann nach Lage der Dinge nur die ASF.
Wieder das "Informationen" und "Gerüchte" Problem. Wenn ihr also dieses
Versprechen einlösen wollt, solltet ihr das zusammen mit den

Post by michael
- TeamOO möchte in der Zukunft fleissig zu OOo (ASF) beitragen und
würde auch sehr gerne mit LO eng zusammenarbeiten. Wie das aussehen
wird, muss man mal schauen, aber auch hier gibt es sicher schon Ideen
und Vorstellungen :)

Wäre nur schön gewesen, ihr hättet das bei eurer Kampagne gleich von
vorneherein an prominenter Stelle klargemacht. Erstens, weil das nach einer
schlagkräftigeren Bewegung klingt als eure 4-Mann-Kampagne und so dem Ruf
von OOo sicherlich mehr geholfen hätte, und zweitens, weil es nun mal nicht
ohne die ASF gehen wird. Oder die TDF, wenn ihr diese Richtung beschreiten
wollt. Einen zweiten Fork braucht OOo so nötig wie ich ein drittes Bein.

Post by michael
7. Eigentlich wollen wir die Arbeit der Vergangenheit fortführen und
dabei die Community besser und enger einbinden, den direkten Kontakt
zu den Nutzern suchen und viel mehr für die Verbreitung von OOo tun.

Sehr guter Punkt! Mit dem Verständnis, dass ein Projekt wie OOo auch eine
Anwender-Komponente als integralen Bestandteil der Projektstruktur braucht,
tut sich die ASF schwer, zumindest IMHO. Ihr wäret hier eine perfekte
Ergänzung. Wobei ich sowohl professionelle Nutzer, die evtl.
sogar bezahlten Support brauchen, als auch den sprichwörtlichen Otto
Normalverbraucher meine.
So wie ich die Leute bei der ASF kennengelernt habe, haben die kein
Besitzdenken. Die freuen sich über jeden, der an den Projekten, die sie
hosten, mitarbeitet. Wenn dann noch Leute wie TeamOOo auftreten, die in den
Bereichen, wo es der ASF einfach an Erfahrung und manchmal auch an
Verständnis fehlt, ihr Tätigkeitsfeld sehen, wird das bestimmt positiv
wahrgenommen. Es ist nur wichtig, dass das alles öffentlich auf der
Mailingliste erfolgt, nicht irgendwo im stillen Kämmerlein und dann mit
einem Paukenschlag verkündet.

Post by michael
Ich hoffe ich habe nichts ausgelassen, aber so stellt sich die
aktuelle Situation dar. OOo ist nicht tot, nein es wird gerade noch
etwas umgearbeitet, so dass im Anschluss alle gut davon haben (wenn
man es so formulieren darf ;) )

IMHO liegt die Zukunft von OOo bei der ASF und, und das Beste, was alle an
einer Zukunft von OOo Interessierten tun könnten, ist, das dortige Projekt
zu unterstützen. Da ist auch Platz für Team OpenOffice.org, ich glaube
sogar, dass das eine wundervolle Ergänzung wäre.
Die ASF beschäftigt keine Entwickler, vielmehr sind aus deren Sicht alle
Entwickler "Freiwillige". Einige von diesen werden von Firmen wie IBM
bezahlt, andere nicht. Da könnte eine Organisation wie TeamOOo, die
Donations einsammeln kann, um Entwickler zu bezahlen (was die ASF nicht kann
und will), helfen. Ob das nun allgemeine Spenden oder zielgerichtete
"Bounties" sind, ist egal.
Aber das ändert nichts daran, dass das ein Apache-OOo bleiben wird, und
aufgrund der rechtlichen Situation ist das auch das einzige OOo, das es
geben kann, denn die Trademark gehört der ASF. Die einzige Möglichkeit, dass
die ASF das Trademark von OOo dauerhaft an jemand anders abtritt, wäre, dass
Apache-OOo komplett scheitert. Aber weder glaube ich, dass das eintreten
wird, noch glaube ich, dass irgendjemand hier sich das wünscht, denn dann
wäre OOo IMHO wirklich am Ende. Also sollten wir davon ausgehen, dass
"OpenOffice.org" entweder von der ASF kommt oder gar nicht.
Ihr könntet vielleicht helfen, ein "Zwischenrelease" wie die von dir
erwähnte 3.3.1 herauszubringen, z.B. um die aufgekommene Diskussion über
Security Fixes zu adressieren. Die ASF kann jetzt noch nichts releasen (aus
Lizenzgründen), ihr könnt es ohne weiteres auch nicht, weil ihr das
Trademark für OOo nicht habt. Mit etwas Fantasie kann man da vielleicht
etwas basteln (ohne Details - IANAL). Würde ich gut finden.
Ciao,
Mathias
--
-----------------------------------------------------------------
with Subject: help

[Jörg Schmidt]

Hallo,

Zwei Forks sind in der Tat eine Verzettelung der Kräfte.

aber Wettbewerb kann auch belebend sein

Die derzeitig im Umlauf befindliche 3.3 ist extrem gut.
Es besteht keine Not, die Sachen übers Knie zu brechen.
User in der Industrie und in Büros oder an Unis brauchen
keine so häufigen Releases, sie wollen vor allem
zuverlässige Software.

Moment ...

Derzeitig gilt doch wohl für OOo 3.3.0 das dort auch folgender Fehler enthalten
ist:

http://www.heise.de/newsticker/meldung/LibreOffice-anfaellig-fuer-trojanische-Word
-Dateien-1354893.html

Oder irre ich mich da?

In LO ist dieser Fehler inzwischen beseitigt, in OOo hingegen (zumindestens durch
ein offizielles Release) nicht und das ist zumindestens sehr schlechte PR für OOo,
gerade auch für anwender die zuverlässige Software suchen.

"zumindestens" schreibe ich deshalb weil man über die tatsächliche Gefahr die von
dem Problem ausgeht ja noch diskutieren könnte, nur in jetziger Situation
allgemeiner Unsicherheit zur Zukunft von OOo wirkt sowas natürlich besonders
negativ in der öffentlichen Wahrnehmung.

Ich werde die Apache-Entwicklung im Rahmen meiner Möglichkeiten
(Dokumentation und Unterricht an meiner Uni) weiterhin unterstützen.

Prima.

Ich wünsche mir, dass die LO-Programmierer das ebenfalls tun.

Ich denke das wird weitestgehend nicht möglich sein, weil die Lizensierung dagegen
spricht. Zumindest erschiene es mir etwas unlogisch wenn LO-Programmier zusätzlich
unter Apache-Lizenz veröffentlichen würden obwohl ja gerade LO/TDF, auch in
lizenzrechtlichen Fragen, doch wohl so beschaffen ist wie es die Beteiligten
selbst wollen.

Im Übrigen dürfte sich die Frage nach jüngsten Verlautbarungen seitens LO immer
weniger stellen, denn wenn die dortige Feststellung ist das sich LO und OOo von
der Code-Basis immer mehr auseinander entwickeln, dürften Codebeiträge die für
beide Projekte 'kompatibel' sind eher zu Ausnahmen werden.

Und ein Entwickler der sowohl zu LO wie zu OOo dann Code beiträgt wäre eben als
(freier) LO- und OOo-Programmier anzusehen und nicht als ein 'LO-Entwickler' der
Code zu OOo beiträgt.



Gruß
Jörg

[Herbert Dürr]

Post by Jörg Schmidt

Zwei Forks sind in der Tat eine Verzettelung der Kräfte.

aber Wettbewerb kann auch belebend sein
[...]

Ich werde die Apache-Entwicklung im Rahmen meiner Möglichkeiten
(Dokumentation und Unterricht an meiner Uni) weiterhin unterstützen.

Prima.

Ich wünsche mir, dass die LO-Programmierer das ebenfalls tun.

Ich denke das wird weitestgehend nicht möglich sein, weil die Lizensierung dagegen
spricht. Zumindest erschiene es mir etwas unlogisch wenn LO-Programmier zusätzlich
unter Apache-Lizenz veröffentlichen würden obwohl ja gerade LO/TDF, auch in
lizenzrechtlichen Fragen, doch wohl so beschaffen ist wie es die Beteiligten
selbst wollen.

Zur Zeit veröffentlichen sie ihre Änderungen unter der LGPL, weil die
alte OOo Lizenz das so vorgab. Die Änderungen wurden und werden außerdem
noch unter der MPL angeboten.

Wenn man zusätzlich unter der ASL anbieten würde, wäre eine
Wiedervereinigung problemlos möglich. Was wäre der Vorteil der Apache
Lizenz? Die Projekte der Apache Foundation zeigen, daß eine gute
Zusammenarbeit von Entwicklern auch von ansonsten konkurrierenden Firmen
unter dem Dach möglich ist und den zugrunde liegenden Standard (z.B.
HTML) wesentlich voranbringen.

Bei OpenOffice&Co. ist z.B. noch etliches an "Heavy Lifting" zu tun und
das macht man nicht mal eben so. Man konzentriert sich am liebsten auf
die Fun-Projekte, auf die "Scratch my personal Itch" Projekte, die
"maximale Wirkung bei minimalem Einsatz" Änderungen und für die "ich
habe einen Rechtschreibfehler behoben und werde jetzt als Entwickler
gezählt" Änderungen.

Für grundlegend wichtige und große Umbauten müssen die Leute anders
motiviert werden und dabei spielen Firmen, denen offene Dokumenten- und
Austauschformate wichtig sind, eine entscheidende Rolle. Wenn die Firmen
nun die bewährte Zusammenarbeit unter dem Apache Dach nutzen und
gleichzeitig den Rat ihrer Anwälte (nämlich ein Veto gegen jedwede
"virale Lizenzen") befolgen wollen, sind "kleine Wiedervereinigungen",
indem soviele wie möglich ihre Änderungen auch unter die Apache Lizenz
stellen, ein wichtiger Beitrag für die langfristige Vitalität des Projekts.

Post by Jörg Schmidt
Im Übrigen dürfte sich die Frage nach jüngsten Verlautbarungen seitens LO immer
weniger stellen, denn wenn die dortige Feststellung ist das sich LO und OOo von
der Code-Basis immer mehr auseinander entwickeln, dürften Codebeiträge die für
beide Projekte 'kompatibel' sind eher zu Ausnahmen werden.

Als Entwickler sehe ich das nicht so... "cherry picking" ist mit den
aktuellen Versionskontrollsystemen kaum ein Problem.

Herbert

[Thorsten Behrens]

Post by Herbert Dürr
Wenn man zusätzlich unter der ASL anbieten würde, wäre eine
Wiedervereinigung problemlos möglich.

Moin Herbert,

heh, wenn mein Kater quaken würde und schwimmen, wäre er eine Ente.
;)

(der Knackpunkt bei Dir ist, daß es ein *alle* impliziert)

Post by Herbert Dürr
Für grundlegend wichtige und große Umbauten müssen die Leute anders
motiviert werden und dabei spielen Firmen, denen offene Dokumenten-
und Austauschformate wichtig sind, eine entscheidende Rolle.

Ich stimme Dir zu, daß festangestellte Entwickler für ein Projekt
wie LibO/OOo wichtig sind. Deswegen wächst ja z.B. bei LibreOffice
auch der Kreis der bezahlten Entwickler ständig.

Ich stimme nicht mit der von Dir implizierten Behauptung überein,
daß *nur* die festangestellen Experten den Code nach vorne bringen
können. Wir haben viele gute Features und lange schwärende Bugs von
Freiwilligen gefixt bekommen. Manchmal ist frischer Wind & ein
unbelastetes Auge auch hilfreich. ;)

Post by Herbert Dürr
Wenn die Firmen nun die bewährte Zusammenarbeit unter dem Apache
Dach nutzen und gleichzeitig den Rat ihrer Anwälte (nämlich ein
Veto gegen jedwede "virale Lizenzen") befolgen wollen, sind
"kleine Wiedervereinigungen", indem soviele wie möglich ihre
Änderungen auch unter die Apache Lizenz stellen, ein wichtiger
Beitrag für die langfristige Vitalität des Projekts.

Die plötzliche Polemik gegen Copyleft erstaunt mich immer wieder.
Sie wurde seltsamerweise in den vergangenen 11 Jahren mit der LGPL
nie geäußert.

Auch hier in Rede stehende Firmen haben kein Problem, bei
existierenden Projekten unter Weak-Copyleft oder sogar GPL zu
contributen. Es ist natürlich für ein gewinnorientiertes
Unternehmen günstiger, nicht zurück contributen zu _müssen_ - ich
betrachte dieses Schlupfloch aber nicht als wünschenswert.

Post by Herbert Dürr

Post by Jörg Schmidt
Im Übrigen dürfte sich die Frage nach jüngsten Verlautbarungen
seitens LO immer weniger stellen, denn wenn die dortige
Feststellung ist das sich LO und OOo von der Code-Basis immer
mehr auseinander entwickeln, dürften Codebeiträge die für beide
Projekte 'kompatibel' sind eher zu Ausnahmen werden.

Als Entwickler sehe ich das nicht so... "cherry picking" ist mit den
aktuellen Versionskontrollsystemen kaum ein Problem.

Das ist zumindest irreführend. Merging von Fixes/Features wird,
unabhängig vom Versionskontrollsystem, zukünftig zusätzliche Arbeit
machen. Diese Arbeit wird nur dann investiert werden, wenn es das
Feature "wert" ist. Dies gilt natürlich für beide Seiten - wer also
einen Bugfix beispielsweise bei LibreOffice integriert haben möchte,
tut dies am besten 'passend' zur Codebase.

Gruß,

-- Thorsten

[Herbert Dürr]

Moin Thorsten,

Post by Thorsten Behrens

Post by Herbert Dürr
Wenn man zusätzlich unter der ASL anbieten würde, wäre eine
Wiedervereinigung problemlos möglich.

Moin Herbert,
heh, wenn mein Kater quaken würde und schwimmen, wäre er eine Ente.
;)
(der Knackpunkt bei Dir ist, daß es ein *alle* impliziert)

Nein, er impliziert eben nicht *alle*. Wenn DU DEINE Änderungen neben
der LGPL und der MPL auch unter die Apache Lizenz stellen würdest, wäre
das allein schon ein positiver Schritt.

Ich persönlich und beruflich bin bereit zu so einem positiven Schritt.
Meine Änderungen sind unter der Apache Lizenz und Ihr dürft Sie gern und
problemlos einbauen. Bei meinen Kollegen ist das ebenso. Wem der
organisatorisch bedingte Split als eine Zeit- und Kräfteverschwendung
erscheint, der kann das für sich durch die ASL lösen.

Der Schritt mit der ASL ist sehr viel einfacher, sinnvoller und
verbindender, als wenn Du an Deinem Kater rumoperierst ;-) Also tu das
Erstere und laß das Letzere. Er wird es Dir danken und für das Projekt
wäre es auch besser...

Post by Thorsten Behrens

Post by Herbert Dürr
Für grundlegend wichtige und große Umbauten müssen die Leute anders
motiviert werden und dabei spielen Firmen, denen offene Dokumenten-
und Austauschformate wichtig sind, eine entscheidende Rolle.

Ich stimme Dir zu, daß festangestellte Entwickler für ein Projekt
wie LibO/OOo wichtig sind. Deswegen wächst ja z.B. bei LibreOffice
auch der Kreis der bezahlten Entwickler ständig.
Ich stimme nicht mit der von Dir implizierten Behauptung überein,
daß *nur* die festangestellen Experten den Code nach vorne bringen
können.

Das impliziere ich überhaupt nicht. Aber es gibt Bereiche, in denen die
Arbeit schon fast Kopf- oder Bauchschmerzen verursacht und das tut sich
dann kaum jemand freiwillig an.

Post by Thorsten Behrens
Wir haben viele gute Features und lange schwärende Bugs von
Freiwilligen gefixt bekommen. Manchmal ist frischer Wind& ein
unbelastetes Auge auch hilfreich. ;)

Das sehe ich auch so. Es geht mir selbst so, daß ich über mir fremde
Codebereiche sehe. Und wie schon gesagt, werden die Bereiche "Coding for
Fun", "Scratch my personal Itch" und "maximale Wirkung bei minimalem
Einsatz" durch Freiwillige gut abgedeckt.

Wenn ich selbst in meiner Freizeit noch Appetit auf Coden haben,
vermeide ich jedenfalls Themen, die mir diesen Appetit vermiesen
könnten. Im professionellen Umfeld ist meine Schmerzschwelle dagegen
schon deutlich höher. Ich denke, das geht nicht nur mir so, oder?

Post by Thorsten Behrens

Post by Herbert Dürr
Wenn die Firmen nun die bewährte Zusammenarbeit unter dem Apache
Dach nutzen und gleichzeitig den Rat ihrer Anwälte (nämlich ein
Veto gegen jedwede "virale Lizenzen") befolgen wollen, sind
"kleine Wiedervereinigungen", indem soviele wie möglich ihre
Änderungen auch unter die Apache Lizenz stellen, ein wichtiger
Beitrag für die langfristige Vitalität des Projekts.

Die plötzliche Polemik gegen Copyleft erstaunt mich immer wieder.
Sie wurde seltsamerweise in den vergangenen 11 Jahren mit der LGPL
nie geäußert.

Es gibt ein sehr großes Interesse an offenen Dokumenten- und
Austauschformaten und ich verstehe inzwischen deutlich besser, warum
sich potentielle Mitspieler selbst bei diesem großen Interesse kaum am
Projekt beteiligen konnten: das CopyLeft hätte einen wesentlichen
Mehraufwand bedeutet.

Post by Thorsten Behrens
Auch hier in Rede stehende Firmen haben kein Problem, bei
existierenden Projekten unter Weak-Copyleft oder sogar GPL zu
contributen.

Gehe mal davon aus, daß bei solchen Code-Beiträgen die Anwälte der
betroffenen Unternehmen erstmal Überstunden machen müssen und sich das
Verhältnis von Nutzen zu Kosten dadurch drastisch verschlechtert.

Post by Thorsten Behrens
Es ist natürlich für ein gewinnorientiertes
Unternehmen günstiger, nicht zurück contributen zu _müssen_ - ich
betrachte dieses Schlupfloch aber nicht als wünschenswert.

An der Geschichte der letzten Jahre kann man klar lernen, daß man mit
dem Produkt selbst kein Geld machen kann. Hat außer ein paar
Download-Spammern jemand mit dem OOo Binary mehr Geld mehr eingenommen
als ausgegeben? Wichtig an der ganzen Geschichte ist doch das offene
Dokumenten- und Austausch-Format.

Post by Thorsten Behrens

Post by Herbert Dürr

Post by Jörg Schmidt
Im Übrigen dürfte sich die Frage nach jüngsten Verlautbarungen
seitens LO immer weniger stellen, denn wenn die dortige
Feststellung ist das sich LO und OOo von der Code-Basis immer
mehr auseinander entwickeln, dürften Codebeiträge die für beide
Projekte 'kompatibel' sind eher zu Ausnahmen werden.

Als Entwickler sehe ich das nicht so... "cherry picking" ist mit den
aktuellen Versionskontrollsystemen kaum ein Problem.

Das ist zumindest irreführend. Merging von Fixes/Features wird,
unabhängig vom Versionskontrollsystem, zukünftig zusätzliche Arbeit
machen. Diese Arbeit wird nur dann investiert werden, wenn es das
Feature "wert" ist. Dies gilt natürlich für beide Seiten - wer also
einen Bugfix beispielsweise bei LibreOffice integriert haben möchte,
tut dies am besten 'passend' zur Codebase.

Das ist klar und immer noch kein besonderes Problem. Wichtig ist nur,
daß die Lizenz paßt. Heißer Tipp: Die Apache Lizenz paßt auf alle
Projekte...

Viele Grüße,
Herbert

[Thorsten Behrens]

Moin Herbert,

ich beziehe mich unten auf das "problemlos" -

Post by Herbert Dürr

Post by Herbert Dürr
Wenn man zusätzlich unter der ASL anbieten würde, wäre eine
Wiedervereinigung problemlos möglich.

[snip]

Post by Herbert Dürr
Nein, er impliziert eben nicht *alle*. Wenn DU DEINE Änderungen
neben der LGPL und der MPL auch unter die Apache Lizenz stellen
würdest, wäre das allein schon ein positiver Schritt.

Ich glaube nicht, daß eine Wiedervereinigung "problemlos" ist, wenn
nicht alle zustimmen. Insofern ist das *alle* für mich impliziert,
ansonsten macht Dein Statement keinen Sinn.

Post by Herbert Dürr
Der Schritt mit der ASL ist sehr viel einfacher, sinnvoller und
verbindender, als wenn Du an Deinem Kater rumoperierst ;-)

Ich denke nicht, daß man die philosophischen Implikationen der AL
als einfachen Schritt abtun sollte. Sowohl privat als auch als Firma
würde ich es mir jedenfalls gut überlegen, meine Zeit und Arbeit
unter eine Lizenz zu stellen, die es einer großen Firma ermöglicht,
diese ohne jede Gegenleistung kommerziell zu verwerten.

Post by Herbert Dürr
Wenn ich selbst in meiner Freizeit noch Appetit auf Coden haben,
vermeide ich jedenfalls Themen, die mir diesen Appetit vermiesen
könnten. Im professionellen Umfeld ist meine Schmerzschwelle
dagegen schon deutlich höher. Ich denke, das geht nicht nur mir
so, oder?

Kommt drauf an. Im Zweifel wird halt Code auch mal neu geschrieben,
was früher im Firmensetup immer an einem "wieso, läuft doch"
scheiterte. Nochmals, ich empfinde daher die Beiträge der
Freiwilligen als bereichernd, und der Zukunftsfähigkeit des Codes
sehr zuträglich.

Post by Herbert Dürr
Es gibt ein sehr großes Interesse an offenen Dokumenten- und
Austauschformaten und ich verstehe inzwischen deutlich besser,
warum sich potentielle Mitspieler selbst bei diesem großen
Interesse kaum am Projekt beteiligen konnten: das CopyLeft hätte
einen wesentlichen Mehraufwand bedeutet.

Kannst Du das näher ausführen? Was, im Vergleich zum SCA/JCA,
verlangt ein LGPL-Projekt an Mehraufwand beim Legal Review?

Post by Herbert Dürr
Gehe mal davon aus, daß bei solchen Code-Beiträgen die Anwälte der
betroffenen Unternehmen erstmal Überstunden machen müssen und sich
das Verhältnis von Nutzen zu Kosten dadurch drastisch
verschlechtert.

Das sollte ja genau einmal notwendig sein, pro Firma & Lizenz, oder
nicht? D.h. für die in Rede stehende Firma sollten diese Mehrkosten
bereits angefallen und anderweitig verbucht sein?

Post by Herbert Dürr
An der Geschichte der letzten Jahre kann man klar lernen, daß man
mit dem Produkt selbst kein Geld machen kann.

Schließt Du da nicht vom Einzelfall auf die Allgemeinheit? Ich kann
das beim besten Willen nicht bestätigen.

Post by Herbert Dürr
Heißer Tipp: Die Apache Lizenz paßt auf alle Projekte...

Im Prinzip ja - sobald die MPL2 gilt. MPL1.1 ist nicht
AL2-kompatibel. Aber das war hier auch eigentlich nie strittig.

Viele Grüße,

-- Thorsten

[Jörg Schmidt]

Hallo,

Post by Thorsten Behrens
Sowohl privat als
auch als Firma würde ich es mir jedenfalls gut überlegen,
meine Zeit und Arbeit unter eine Lizenz zu stellen, die es
einer großen Firma ermöglicht, diese ohne jede Gegenleistung
kommerziell zu verwerten.

DANKE für diesen Satz denn er entlarvt worum es den Verfechtern eines strikten
Copylefts in Abwägung von propritär/kommerziell in Praxis häufig zuerst geht,
nämlich um das schlechte eigene Bauchgefühl das andere mit dem Code wirtschaftlich
erfolgreicher sein könnten als man selbst.

DAS jedoch hat mit Freiheitsdenken jedoch wenig zu tun sondern ist Ausdruck
monetären Denkens.

Freiheit hat nämlich nichts damit zu tun ob ich arm oder reich bin oder andere arm
oder reich sind sondern ist ein Wert ansich.



Gruß
Jörg

[Herbert Duerr]

Moin Thorsten,

Post by Thorsten Behrens
ich beziehe mich unten auf das "problemlos" -
[...]

Post by Herbert Dürr
Nein, er impliziert eben nicht *alle*. Wenn DU DEINE Änderungen
neben der LGPL und der MPL auch unter die Apache Lizenz stellen
würdest, wäre das allein schon ein positiver Schritt.

Ich glaube nicht, daß eine Wiedervereinigung "problemlos" ist, wenn
nicht alle zustimmen. Insofern ist das *alle* für mich impliziert,
ansonsten macht Dein Statement keinen Sinn.

Es ist schon wahr, daß mathematisch gesehen die Wiedervereinigung erst
mit 100% abgeschlossen wäre. Ich bin für so Sachen aber vielleicht etwas
zu pragmatisch veranlagt und würde selbst bei weniger als 95% schon von
Wiedervereinigung reden.

Post by Thorsten Behrens

Post by Herbert Dürr
Der Schritt mit der ASL ist sehr viel einfacher, sinnvoller und
verbindender, als wenn Du an Deinem Kater rumoperierst ;-)

Ich denke nicht, daß man die philosophischen Implikationen der AL
als einfachen Schritt abtun sollte. Sowohl privat als auch als Firma
würde ich es mir jedenfalls gut überlegen, meine Zeit und Arbeit
unter eine Lizenz zu stellen, die es einer großen Firma ermöglicht,
diese ohne jede Gegenleistung kommerziell zu verwerten.

Bei Apache funktioniert genau damit hervoragend. Z.B. der Webserver gilt
als DIE Referenzapplikation für die zugrundeliegenden Standards und alle
profitieren vom starken Standard, dem daraus resultierenden gesunden
Umfeld und einer mächtigen Infrastruktur. Es beteiligen sich ansonsten
konkurriende Firmen, weil ihnen der Standard und die Referenzplattform
wichtig ist.

Post by Thorsten Behrens

Post by Herbert Dürr
Wenn ich selbst in meiner Freizeit noch Appetit auf Coden haben,
vermeide ich jedenfalls Themen, die mir diesen Appetit vermiesen
könnten. Im professionellen Umfeld ist meine Schmerzschwelle
dagegen schon deutlich höher. Ich denke, das geht nicht nur mir
so, oder?

Kommt drauf an. Im Zweifel wird halt Code auch mal neu geschrieben,
was früher im Firmensetup immer an einem "wieso, läuft doch"
scheiterte. Nochmals, ich empfinde daher die Beiträge der
Freiwilligen als bereichernd, und der Zukunftsfähigkeit des Codes
sehr zuträglich.

Je mehr kompetente Mitspieler an der langfristigen Fortenwicklung
interessiert sind, desto weniger ist ein "wieso, läuft doch" ein
dauerhaftes Problem. Da sind wir uns mal wieder völlig einig.

Bei Apache Projekten funktioniert genau diese Zusammenarbeit
hervoragend, und es bringen sich Firmen ein, die sonst einen großen
Bogen um CopyLeft Lizenzen machen.

Post by Thorsten Behrens

Post by Herbert Dürr
Es gibt ein sehr großes Interesse an offenen Dokumenten- und
Austauschformaten und ich verstehe inzwischen deutlich besser,
warum sich potentielle Mitspieler selbst bei diesem großen
Interesse kaum am Projekt beteiligen konnten: das CopyLeft hätte
einen wesentlichen Mehraufwand bedeutet.

Kannst Du das näher ausführen? Was, im Vergleich zum SCA/JCA,
verlangt ein LGPL-Projekt an Mehraufwand beim Legal Review?

Ich bin kein Anwalt und will auch keiner werden. Ich vertraue da mal den
sehr kompetenten Kollegen. Z.B. war die bekannte Kontribution des
ReadCopyUpdate Mechanismus zum Linux-Kernel deutlich mehr als ein "ich
committe das mal eben".

Da Du das SCA/JCA ansprichst: Ich weiß genau, daß Firmen, die das nicht
unterzeichnen wollten und konnten auch mit der LGPL Schwierigkeiten
haben. Mir fallen sogar einige bekannte Leute aus der LO-Fraktion ein,
die genau gegen das SCA/JCA gewettert haben.

Post by Thorsten Behrens

Post by Herbert Dürr
Gehe mal davon aus, daß bei solchen Code-Beiträgen die Anwälte der
betroffenen Unternehmen erstmal Überstunden machen müssen und sich
das Verhältnis von Nutzen zu Kosten dadurch drastisch
verschlechtert.

Das sollte ja genau einmal notwendig sein, pro Firma& Lizenz, oder
nicht? D.h. für die in Rede stehende Firma sollten diese Mehrkosten
bereits angefallen und anderweitig verbucht sein?

Soweit ich weiß, war und ist das nicht so (z.B. RCU).

Post by Thorsten Behrens

Post by Herbert Dürr
An der Geschichte der letzten Jahre kann man klar lernen, daß man
mit dem Produkt selbst kein Geld machen kann.

Schließt Du da nicht vom Einzelfall auf die Allgemeinheit? Ich kann
das beim besten Willen nicht bestätigen.

Wer hat denn mit dem OpenOffice Binary selbst Geld gemacht? Die besten
Köpfe bei meinem früheren Arbeitgeber haben es jedenfalls nicht
geschafft, aus dem Binary Profit zu schlagen, obwohl sie als
SCA/JCA-"Profiteure" eine bessere Ausgangslage hatten als alle Konkurrenten.

Post by Thorsten Behrens

Post by Herbert Dürr
Heißer Tipp: Die Apache Lizenz paßt auf alle Projekte...

Im Prinzip ja - sobald die MPL2 gilt. MPL1.1 ist nicht
AL2-kompatibel. Aber das war hier auch eigentlich nie strittig.

Das heißt, das Ihr Änderungen, die unter der AL2 Lizenz gemacht werden,
nicht in LibreOffice integrieren könnt? Das glaube ich nicht. Aber wie
gesagt, ich bin kein Anwalt.

Ich würde es schön finden, wenn Du den Schritt machst, Deine Änderungen
auch unter der AL2 bereitzustellen. Oder als SC-Mitglied zumindest
garantierst, daß diejenigen nicht ausgegrenzt werden, die den Weg der
individuellen Wiedervereinigung per AL als sinnvoll erachten: Ein
LO-Entwickler, dessen Code auch in OOo einfließen darf, sollte auch
weiterhin LO-Entwickler bleiben dürfen.

Viele Grüße,
Herbert

BTW: Ich bin bis Ende der Woche auf Dienstreise und habe da ein volles
Programm. Bis dahin kann ich die Diskussion nicht selbst weiterführen.

[Thorsten Behrens]

Moin Herbert,

Post by Herbert Duerr

Post by Thorsten Behrens

... und ich verstehe inzwischen deutlich besser, warum sich
potentielle Mitspieler selbst bei diesem großen Interesse kaum
am Projekt beteiligen konnten: das CopyLeft hätte einen
wesentlichen Mehraufwand bedeutet.

Kannst Du das näher ausführen? Was, im Vergleich zum SCA/JCA,
verlangt ein LGPL-Projekt an Mehraufwand beim Legal Review?

Ich bin kein Anwalt und will auch keiner werden. Ich vertraue da mal
den sehr kompetenten Kollegen. Z.B. war die bekannte Kontribution
des ReadCopyUpdate Mechanismus zum Linux-Kernel deutlich mehr als
ein "ich committe das mal eben".
Da Du das SCA/JCA ansprichst: Ich weiß genau, daß Firmen, die das
nicht unterzeichnen wollten und konnten auch mit der LGPL
Schwierigkeiten haben. Mir fallen sogar einige bekannte Leute aus
der LO-Fraktion ein, die genau gegen das SCA/JCA gewettert haben.

Meine Frage war: was ist der Mehraufwand, nachdem man das SCA/JCA eh
hat reviewen müssen? Das war doch Deine These, daß die LGPL das
Haupthindernis war?

Post by Herbert Duerr

Post by Thorsten Behrens

Gehe mal davon aus, daß bei solchen Code-Beiträgen die Anwälte der
betroffenen Unternehmen erstmal Überstunden machen müssen und sich
das Verhältnis von Nutzen zu Kosten dadurch drastisch
verschlechtert.

Das sollte ja genau einmal notwendig sein, pro Firma& Lizenz, oder
nicht? D.h. für die in Rede stehende Firma sollten diese Mehrkosten
bereits angefallen und anderweitig verbucht sein?

Soweit ich weiß, war und ist das nicht so (z.B. RCU).

Klingt nicht plausibel. Dann würde jede Code-Submission unter AL2
vermutlich ähnlichen Aufwand generieren - schließlich müßte man ja
alle Verträge und Patentlizenzen auf etwaige Konflikte abklopfen.

Post by Herbert Duerr
Wer hat denn mit dem OpenOffice Binary selbst Geld gemacht?

Wer es vermochte, mittels Wartungsverträgen und gebündelten
Angeboten sein Engineering zu refinanzieren.

Post by Herbert Duerr
Oder als SC-Mitglied zumindest garantierst

Nitpick: Ich kann als Einzelperson nichts garantieren.

Post by Herbert Duerr
daß diejenigen nicht ausgegrenzt werden, die den Weg der
individuellen Wiedervereinigung per AL als sinnvoll erachten.

Du hast mich bisher nicht als jemanden kennengelernt, der andere
ausgrenzt, und daran wird sich auch in Zukunft nix ändern.

Viele Grüße,

-- Thorsten

[Thorsten Behrens]

Moin Herbert,

Post by Herbert Duerr

Post by Thorsten Behrens

... und ich verstehe inzwischen deutlich besser, warum sich
potentielle Mitspieler selbst bei diesem großen Interesse kaum
am Projekt beteiligen konnten: das CopyLeft hätte einen
wesentlichen Mehraufwand bedeutet.

Kannst Du das näher ausführen? Was, im Vergleich zum SCA/JCA,
verlangt ein LGPL-Projekt an Mehraufwand beim Legal Review?

Ich bin kein Anwalt und will auch keiner werden. Ich vertraue da mal
den sehr kompetenten Kollegen. Z.B. war die bekannte Kontribution
des ReadCopyUpdate Mechanismus zum Linux-Kernel deutlich mehr als
ein "ich committe das mal eben".
Da Du das SCA/JCA ansprichst: Ich weiß genau, daß Firmen, die das
nicht unterzeichnen wollten und konnten auch mit der LGPL
Schwierigkeiten haben. Mir fallen sogar einige bekannte Leute aus
der LO-Fraktion ein, die genau gegen das SCA/JCA gewettert haben.

Meine Frage war: was ist der Mehraufwand, nachdem man das SCA/JCA eh
hat reviewen müssen? Das war doch Deine These, daß die LGPL das
Haupthindernis war?

Post by Herbert Duerr

Post by Thorsten Behrens

Gehe mal davon aus, daß bei solchen Code-Beiträgen die Anwälte der
betroffenen Unternehmen erstmal Überstunden machen müssen und sich
das Verhältnis von Nutzen zu Kosten dadurch drastisch
verschlechtert.

Das sollte ja genau einmal notwendig sein, pro Firma& Lizenz, oder
nicht? D.h. für die in Rede stehende Firma sollten diese Mehrkosten
bereits angefallen und anderweitig verbucht sein?

Soweit ich weiß, war und ist das nicht so (z.B. RCU).

Klingt nicht plausibel. Dann würde jede Code-Submission unter AL2
vermutlich ähnlichen Aufwand generieren - schließlich müßte man ja
alle Verträge und Patentlizenzen auf etwaige Konflikte abklopfen.

Post by Herbert Duerr
Wer hat denn mit dem OpenOffice Binary selbst Geld gemacht?

Wer es vermochte, mittels Wartungsverträgen und gebündelten
Angeboten sein Engineering zu refinanzieren.

Post by Herbert Duerr
Oder als SC-Mitglied zumindest garantierst

Nitpick: Ich kann als Einzelperson nichts garantieren.

Post by Herbert Duerr
daß diejenigen nicht ausgegrenzt werden, die den Weg der
individuellen Wiedervereinigung per AL als sinnvoll erachten.

Du hast mich bisher nicht als jemanden kennengelernt, der andere
ausgrenzt, und daran wird sich auch in Zukunft nix ändern.

Viele Grüße,

-- Thorsten

[David Paenson]

Hallo,

je mehr ich mich als Nichtprogrammierer in die Sache vertiefe, desto mehr
wächst meine Unterstützung für die Apache-Lösung. Wenn ich was Positives
beitrage, und eine Firma macht damit Geld, bin ich dennoch glücklicher, als
wenn ich gar keinen Beitrag gemacht hätte oder dieser wäre vollkommen
verschollen. Wenn man es kritisieren will, dass Firmen mit den Ideen anderer
Geld machen, muss man konsequenterweise überhaupt gegen ein System kämpfen,
das aus allem Geld machen will. Diesen Kampf wird niemand mit einer
CopyLeft- oder sonstiger Lizenz gewinnen. Der muss auf der Straße und in den
Betrieben gewonnen werden. In der Zwischenzeit sollten wir kleinere Brötchen
backen und dem Apache-Fork zum Erfolg verhelfen. Der aggressive Ton vieler
LO-Beiträge hier bestärkt mich in meinem Eindruck, dass LO nicht was
Besseres produzieren will, sondern nur OOo unter dem Begriff "Konkurrenz
belebt das Geschäft" den Garaus machen will. Nicht Konkurrenz, sondern
Kooperation war und ist die Grundlage menschlicher Entwicklung.

Solidarische Grüße
Dave

Post by Herbert Dürr
Moin Thorsten,

Post by Thorsten Behrens

Post by Herbert Dürr
Wenn man zusätzlich unter der ASL anbieten würde, wäre eine
Wiedervereinigung problemlos möglich.
Moin Herbert,

heh, wenn mein Kater quaken würde und schwimmen, wäre er eine Ente.
;)
(der Knackpunkt bei Dir ist, daß es ein *alle* impliziert)

Nein, er impliziert eben nicht *alle*. Wenn DU DEINE Änderungen neben der
LGPL und der MPL auch unter die Apache Lizenz stellen würdest, wäre das
allein schon ein positiver Schritt.
Ich persönlich und beruflich bin bereit zu so einem positiven Schritt.
Meine Änderungen sind unter der Apache Lizenz und Ihr dürft Sie gern und
problemlos einbauen. Bei meinen Kollegen ist das ebenso. Wem der
organisatorisch bedingte Split als eine Zeit- und Kräfteverschwendung
erscheint, der kann das für sich durch die ASL lösen.
Der Schritt mit der ASL ist sehr viel einfacher, sinnvoller und
verbindender, als wenn Du an Deinem Kater rumoperierst ;-) Also tu das
Erstere und laß das Letzere. Er wird es Dir danken und für das Projekt wäre
es auch besser...
Für grundlegend wichtige und große Umbauten müssen die Leute anders

Post by Thorsten Behrens

Post by Herbert Dürr
motiviert werden und dabei spielen Firmen, denen offene Dokumenten-
und Austauschformate wichtig sind, eine entscheidende Rolle.
Ich stimme Dir zu, daß festangestellte Entwickler für ein Projekt

wie LibO/OOo wichtig sind. Deswegen wächst ja z.B. bei LibreOffice
auch der Kreis der bezahlten Entwickler ständig.
Ich stimme nicht mit der von Dir implizierten Behauptung überein,
daß *nur* die festangestellen Experten den Code nach vorne bringen
können.

Das impliziere ich überhaupt nicht. Aber es gibt Bereiche, in denen die
Arbeit schon fast Kopf- oder Bauchschmerzen verursacht und das tut sich dann
kaum jemand freiwillig an.
Wir haben viele gute Features und lange schwärende Bugs von

Post by Thorsten Behrens
Freiwilligen gefixt bekommen. Manchmal ist frischer Wind& ein
unbelastetes Auge auch hilfreich. ;)

Das sehe ich auch so. Es geht mir selbst so, daß ich über mir fremde
Codebereiche sehe. Und wie schon gesagt, werden die Bereiche "Coding for
Fun", "Scratch my personal Itch" und "maximale Wirkung bei minimalem
Einsatz" durch Freiwillige gut abgedeckt.
Wenn ich selbst in meiner Freizeit noch Appetit auf Coden haben, vermeide
ich jedenfalls Themen, die mir diesen Appetit vermiesen könnten. Im
professionellen Umfeld ist meine Schmerzschwelle dagegen schon deutlich
höher. Ich denke, das geht nicht nur mir so, oder?
Wenn die Firmen nun die bewährte Zusammenarbeit unter dem Apache

Post by Thorsten Behrens

Post by Herbert Dürr
Dach nutzen und gleichzeitig den Rat ihrer Anwälte (nämlich ein
Veto gegen jedwede "virale Lizenzen") befolgen wollen, sind
"kleine Wiedervereinigungen", indem soviele wie möglich ihre
Änderungen auch unter die Apache Lizenz stellen, ein wichtiger
Beitrag für die langfristige Vitalität des Projekts.
Die plötzliche Polemik gegen Copyleft erstaunt mich immer wieder.

Sie wurde seltsamerweise in den vergangenen 11 Jahren mit der LGPL
nie geäußert.

Es gibt ein sehr großes Interesse an offenen Dokumenten- und
Austauschformaten und ich verstehe inzwischen deutlich besser, warum sich
potentielle Mitspieler selbst bei diesem großen Interesse kaum am Projekt
beteiligen konnten: das CopyLeft hätte einen wesentlichen Mehraufwand
bedeutet.
Auch hier in Rede stehende Firmen haben kein Problem, bei

Post by Thorsten Behrens
existierenden Projekten unter Weak-Copyleft oder sogar GPL zu
contributen.

Gehe mal davon aus, daß bei solchen Code-Beiträgen die Anwälte der
betroffenen Unternehmen erstmal Überstunden machen müssen und sich das
Verhältnis von Nutzen zu Kosten dadurch drastisch verschlechtert.
Es ist natürlich für ein gewinnorientiertes

Post by Thorsten Behrens
Unternehmen günstiger, nicht zurück contributen zu _müssen_ - ich
betrachte dieses Schlupfloch aber nicht als wünschenswert.

An der Geschichte der letzten Jahre kann man klar lernen, daß man mit dem
Produkt selbst kein Geld machen kann. Hat außer ein paar Download-Spammern
jemand mit dem OOo Binary mehr Geld mehr eingenommen als ausgegeben? Wichtig
an der ganzen Geschichte ist doch das offene Dokumenten- und
Austausch-Format.
Im Übrigen dürfte sich die Frage nach jüngsten Verlautbarungen

Post by Thorsten Behrens

Post by Herbert Dürr

Post by Jörg Schmidt
seitens LO immer weniger stellen, denn wenn die dortige
Feststellung ist das sich LO und OOo von der Code-Basis immer
mehr auseinander entwickeln, dürften Codebeiträge die für beide
Projekte 'kompatibel' sind eher zu Ausnahmen werden.

Als Entwickler sehe ich das nicht so... "cherry picking" ist mit den
aktuellen Versionskontrollsystemen kaum ein Problem.
Das ist zumindest irreführend. Merging von Fixes/Features wird,

unabhängig vom Versionskontrollsystem, zukünftig zusätzliche Arbeit
machen. Diese Arbeit wird nur dann investiert werden, wenn es das
Feature "wert" ist. Dies gilt natürlich für beide Seiten - wer also
einen Bugfix beispielsweise bei LibreOffice integriert haben möchte,
tut dies am besten 'passend' zur Codebase.

Das ist klar und immer noch kein besonderes Problem. Wichtig ist nur, daß
die Lizenz paßt. Heißer Tipp: Die Apache Lizenz paßt auf alle Projekte...
Viele Grüße,
Herbert
--
------------------------------**------------------------------**-----
with Subject: help

[Christian Lohmaier]

Hallo *,

Post by David Paenson
je mehr ich mich als Nichtprogrammierer in die Sache vertiefe, desto mehr
wächst meine Unterstützung für die Apache-Lösung. Wenn ich was Positives
beitrage, und eine Firma macht damit Geld, bin ich dennoch glücklicher, als
wenn ich gar keinen Beitrag gemacht hätte oder dieser wäre vollkommen
verschollen.

Der Satz gibt schonmal keinen Sinn (wo nix ist, kann auch nix
verschollen gehen), aber egal, denn was Du untern schreibst ist eine
Fehlinterpretation von Jörg, die Du einfach blind übernimmst.

Post by David Paenson
Wenn man es kritisieren will, dass Firmen mit den Ideen anderer
Geld machen, muss man konsequenterweise überhaupt gegen ein System kämpfen,

Das ist nicht der Fall. Auch mit LGPL basierter Software kann man Geld
machen. StarOffice RedOffice, NeoOffice (sogar unter GPL), alles kein
Problem.

Post by David Paenson
Der aggressive Ton vieler
LO-Beiträge hier bestärkt mich in meinem Eindruck, dass LO nicht was
Besseres produzieren will,

ich kann hier nur den Kopf schütteln, aber wenn das wirklch Deine
Einschätzung ist, dann bedenke, daß nicht jeder, der "LibreOffice"
schreibt auch aus dem LO-Lager kommt.

Post by David Paenson
sondern nur OOo unter dem Begriff "Konkurrenz
belebt das Geschäft" den Garaus machen will. Nicht Konkurrenz, sondern
Kooperation war und ist die Grundlage menschlicher Entwicklung.

Ja, und hier sind wir beim Knackpunkt. Kooperation. Das impliziert,
daß derjenige, der etwas nimmt, auch etwas zurückgibt.

Und das ist bei Apache schlicht in keinster Form gegeben.

Und da kommt es die Apache-Contributer gar nicht an. Es geht auch um
die, die weder bei TDF, noch bei Apache mitmischen, sondern nur darauf
warten schmarotzen zu können.

ciao
Christian

[Raphael Bircher]

Post by Christian Lohmaier
Hallo *,

Post by David Paenson
sondern nur OOo unter dem Begriff "Konkurrenz
belebt das Geschäft" den Garaus machen will. Nicht Konkurrenz, sondern
Kooperation war und ist die Grundlage menschlicher Entwicklung.

Ja, und hier sind wir beim Knackpunkt. Kooperation. Das impliziert,
daß derjenige, der etwas nimmt, auch etwas zurückgibt.
Und das ist bei Apache schlicht in keinster Form gegeben.

Das mit dem Zurückgeben ist bei der LGPL und GPL genauso wenig gegeben.
Oder existiert da irgendeine Klausel dass Software Anwender oder
Dienstleister was zurückgeben müssen? Weisst du wie viele kleinere
Firmen OOo nur deshalb haben um Lizenzkosten zu sparen. OOo und LO geht
dabei zu weit über 90 Prozent leer, oder mit einem lächerlichen Sackgeld
aus. Von personellen Ressourcen reden wir schon gar nicht. Wie viele
Millionen werden Jährlich nur mit Dienstleistungen gemacht... und
wieviele dieser Dienstleister beteiligen sich am Projekt? Wenn, dann vor
allem im Marketing, und das sehe ich eher als gut kalkulierte
Investition für die Dienstleister. Wenn man schon unbedingt will, dass
was zurückkommt müsste man die sache fair verteilen.

Sag mir einen Grund warum sich ein Code contributor verpflichten sollte
etwas zurückzugeben, wenn es alle anderen auch nicht müssen? Zudem wirst
du keine Grossfirma dazu zwingen können, sondern sie lässt dann das
Projekt einfach kalt im Regen stehen. Die Copyleft Lizenzen sind eine
Gegenreaktion, und stammen aus einer Zeit in der es viele
Softwareunternehmen einfach zu bunt getrieben haben.

Klar war die ASL2 der Wunsch von IBM, aber die Jungs geben auch etwas
zurück. Übrigens, ich bin auch kein IBM Fan, devinitiv nicht. Aber für
das was sie so tun dürfen sie meinetwegen das bischen Freiheit mehr haben.

Post by Christian Lohmaier
Und da kommt es die Apache-Contributer gar nicht an. Es geht auch um
die, die weder bei TDF, noch bei Apache mitmischen, sondern nur darauf
warten schmarotzen zu können.

Und wie bitte stellst du dir das vor? Firma XY braucht OOo als Grundlage
für zum Beispiel ein kommerzielles Kassensystem. Glaubst du in vollem
Ernst die würden dass ohne Hilfe der Community schaffen? Wohl nicht. Und
was passiert mit Leuten die ständig nur Saugen? Man ignoriert sie
einfach. Die Wahrscheinlichkeit ist aber wesentlich grösser dass die
dann plötzlich den Sinn hinter einer Community sehen. Sie stossen
vielleicht auf ungefixte Fehler, die für ihre Version sehr wichtig sind.
Der Weg zu einer Contribution ist dann nicht mehr weit. Und schon hat
man einen neuen Contributoren gefunden!

Aber ja, man kann natürlich auch hinter jedem potentiellen Contributor
einen Schmarotzer sehen ;-)

Gruss Raphael

[Jörg Schmidt]

Hallo,

Post by Raphael Bircher
Das mit dem Zurückgeben ist bei der LGPL und GPL genauso
wenig gegeben.

Jein.

Die Argumentation ist ja (_im Zweifel_ nur bei GPL) das Nutzer den Code nicht
'umlizensiert' nutzen können und so zwangläufig bestehenden Code um ihre
Codebeiträge, zu gleicher Lizenz, erweitern müssen, oder aber den Code nicht in
eigenen Projekten einbinden können.

Eine solche forderung der GPL halte iocvh auch weder für falsch noch schlecht,
sondern nur für eine normale Forderung.

Falsch und ideologisch wird's erst dann wenn die GPL-Jünger beginnen ihre
'Zwangsbeglückung' damit zu begründen das Code unfrei würde ohne ein striktes
Copyleft und das stimmt ganz offensichtlich nicht den man kann von jedem Code
beliebig viel Kopien ziehenund wenn ggf. Kopien des Codes unfrei werden sind das
Kopien die nur zusätzlich zu vielen freien Kopien existieren und den freien Kopien
nichts 'wegnehmen'.

Zu wollen das andere den eigenen Code, _zu gleichen_ Lizenzbedingungen, verbessern
ist auch keine insich falsche Forderung, nur es ist eine Forderung und kein
Automatismus oder Naturgesetz.

Post by Raphael Bircher
Sag mir einen Grund warum sich ein Code contributor
verpflichten sollte etwas zurückzugeben, wenn es alle anderen
auch nicht müssen?

Dafür gibt es durchaus viele gute Gründe (falls hier "andere" die
nicht-kommerziellen Nutzer sein sollen), im Wesentlichen alles Gründe die dazu
betragen das eigentliche Projekt (zusätzlich) voranzubringen.

Ich persönlich verstehe _und teile_ deshalb das Anliegen von Christian, allein
teile ich es in keinster Weise mit der im Raum stehenden Begründung das die
Nutzung von Möglichkeiten die eine Lizenz bietet "schmarotzen" sein könnte, denn
die Nutzung aller Möglichkeiten einer Lizenz ist einfach nur die bestimmungsgemäße
Nutzung.


Man könnte in diesen Fragen des "Schmarotzes" auch sehr schnell eine Lösung finden
wenn diejenigen die hier immer wieder versuchen freie Software umzudefinieren
einfach einsehen würden das freie Software klar definiert ist und es im
Eigentlichen darum geht entweder freie Software doch neu/anders zu definieren oder
eine zusätzliche 'Art' von Software jenseits von freier Software zu definieren, im
Sinne 'moralisch korrekter' Software.

Ich hätte überhaupt garkein Problem mit einer Lizenz die mir sagt wennn ich
kommerzielle Vorteile aus der Software ziehe muß ich dafür die Community
finanziell, verbindlich und nicht nur freiwillig, beteiligen.
Nur solange es eine _solche_ Lizenzforderung nicht gibt ist es falsch so zu tun
als wenn es sie gäbe und, nach meiner allgemeinen Auffassung, moralisch
verwerflich andere damit unter Druck setzen zu wollen.


Und was ich hier als "allgemeine Auffassung" bezeichne ist meine Grundüberzeugung
das es mir persönlich immer noch ein wenig wichtiger ist die Rechte der Anderen zu
verteidigen als eigene Rechte wahrzunehmen.

Z.B. würde ich auch dann das Recht auf freie Rede eines jeden verteidigen, wenn
andere dieses Recht dazu nutzen Reden zu führen die mir persönlich schaden. Und
gleichzeitig käme ich nie auf die Idee es sei Mißbrauch (oder schmarotzen) wenn
eben andere ihr Recht _auch *gegen* mich_ nutzen egal ob es das Recht freier Rede
oder das Recht lizenzgemäßer Nutzung einer Software ist.


Gruß
Jörg

[Christian Lohmaier]

Hallo Jörg,

Post by Jörg Schmidt
[...]
Ich persönlich verstehe _und teile_ deshalb das Anliegen von Christian, allein
teile ich es in keinster Weise mit der im Raum stehenden Begründung das die
Nutzung von Möglichkeiten die eine Lizenz bietet "schmarotzen" sein könnte, denn
die Nutzung aller Möglichkeiten einer Lizenz ist einfach nur die bestimmungsgemäße
Nutzung.
[...]
[...] Eigentlichen darum geht entweder freie Software doch neu/anders zu definieren oder
eine zusätzliche 'Art' von Software jenseits von freier Software zu definieren, im
Sinne 'moralisch korrekter' Software.

Jörg - klar ist es bestimmungsgemäße Nutzung wenn jemand Apache code
nimmt und ihn in welcher Forma auch immer in sein eigenes Projekt
einbaut und vertreibt, auch ohne etwas zurückzugeben. Ist ja auch das
erklärte Ziel diverser Apache-Projekte allgegenwärtig zu sein.

Aber der Punkt, warum man sich für Apache oder TDF/Copyleft
entscheidet ist doch gerade eben eine moralische, eine Frage der
eigenen Prinzipien. Also kann man diesen Teil nicht als "unwichtig"
abtun. Es ist ja gerade die mögliche, lizenzgemäße Verwertung die als
"Schmarotzen" empfunden wird und aus diesem Grund abgelehnt wird.

Wem es schnurz piep egal ist, der kann bei beiden Projekten mitmischen
(und das tun ja auch ein paar wenige).

Post by Jörg Schmidt
[...]
Nur solange es eine _solche_ Lizenzforderung nicht gibt ist es falsch so zu tun
als wenn es sie gäbe und, nach meiner allgemeinen Auffassung, moralisch
verwerflich andere damit unter Druck setzen zu wollen.

mit bloßen Feststellungen wird keiner unter Druck gesetzt. Es ist wohl
eher so, daß sich viele gar nicht erst mit den Lizenzen
auseinandergesetzt haben oder die Liste der Contributoren als
abgeschlossene Einheit betrachtet wird, und die möglichen
"Schmarotzer" schlicht ausgeblendet wurden.

ciao
Christian

[Jörg Schmidt]

Hallo,

Post by Christian Lohmaier
Jörg - klar ist es bestimmungsgemäße Nutzung wenn jemand
Apache code nimmt und ihn in welcher Forma auch immer in sein
eigenes Projekt einbaut und vertreibt, auch ohne etwas
zurückzugeben. Ist ja auch das erklärte Ziel diverser
Apache-Projekte allgegenwärtig zu sein.
Aber der Punkt, warum man sich für Apache oder TDF/Copyleft
entscheidet ist doch gerade eben eine moralische, eine Frage
der eigenen Prinzipien.

ja, sicher

Post by Christian Lohmaier
Also kann man diesen Teil nicht als
"unwichtig"
abtun.

Ich tue diesen Teil nicht als "unwichtig" ab sondern halte ihn für sehr wichtig.
Hierbei respektiere ich das andere, denen die Dinge genauso wichtig sind,
lediglich für sich andere Antworten finden.

WIE wichtig (auch) mir solche 'moralischen', nichttechnischen Fragen sind siehst
Du beispielsweise daran das ich persönlich mich entschieden habe nicht bei LO
mitzuarbeiten solange der Kurs der TDF in einigen mir wichtigen Dingen mir nicht
gefällt, denn meine Kritik betrifft nirgens technische Fragen der LO-Software,
denn im Technischen ist LO derzeitig m.E. überlegen und ich werde nichts anderes
behaupten.

Das aber, nur um hier nicht mißverstanden zu werden, ist nur meine Entscheidung
und ich respektiere genausogut Entscheidungen anderer Pro TDF, einzig
argumentiere, ich natürlich, so wie jeder andere auch für seine Sicht der Dinge,
ich werde also nicht zu allem Schweigen sondern auch Kritik üben an Dingen an
denen ich nicht direkt beteiligt bin, genausogut wie das andere auch (in
umgekehrter Weise) tun.

Post by Christian Lohmaier
Es ist ja gerade die mögliche, lizenzgemäße Verwertung
die als "Schmarotzen" empfunden wird und aus diesem Grund
abgelehnt wird.

Tja, da gibt es dann aktuell keinen Ausweg. Ich verstehe eben nur sehr schwer
warum (so zumindest mein Eindruck) meist die Gleichen bestimmte Arten der
Verwertung als "schmarotzen" empfinden, aber gleichzeitig die Lizenzen loben die
das ermöglichen.

Es ist keine konkrete Lösung für bestehende Software, nur es wäre eine Lösung für
zukünftige, neue Software wenn z.B. die FSF neue Lizenzen herausbringen würde die
ein Schmarotzen unterbinden, _falls_ das von Vielen gewünscht wäre, denn obwohl
heutige Lizenzen soi sind um der Definition freier Software zu entsprechen kann
man doch diese Definition auch ändern wenn die Mehrheit sie _so_ nicht mehr will.

Post by Christian Lohmaier
mit bloßen Feststellungen wird keiner unter Druck gesetzt.

_Ich_ will diesbezüglich auch niemanden unter Druck setzen, denn ich finde es in
Ordnung wenn Dritte Geld verdienen.

Post by Christian Lohmaier
Es
ist wohl eher so, daß sich viele gar nicht erst mit den
Lizenzen auseinandergesetzt haben oder die Liste der
Contributoren als abgeschlossene Einheit betrachtet wird, und
die möglichen "Schmarotzer" schlicht ausgeblendet wurden.

Das stimmt wahrscheinlich zu fast 100% - ja, so ist im allgemeinen die Wahrnehmung
einer Mehrzahl.


Gruß
Jörg

[Christian Lohmaier]

Hallo Raphael,

Post by Christian Lohmaier

Post by David Paenson
sondern nur OOo unter dem Begriff "Konkurrenz
belebt das Geschäft" den Garaus machen will. Nicht Konkurrenz, sondern
Kooperation war und ist die Grundlage menschlicher Entwicklung.

Ja, und hier sind wir beim Knackpunkt. Kooperation. Das impliziert,
daß derjenige, der etwas nimmt, auch etwas zurückgibt.
Und das ist bei Apache schlicht in keinster Form gegeben.

Das mit dem Zurückgeben ist bei der LGPL und GPL genauso wenig gegeben. Oder
existiert da irgendeine Klausel dass Software Anwender oder Dienstleister
was zurückgeben müssen?

Klar, steht ja in der Lizenz. Wenn Du GPL software modifizierst und
verbreitest, mußt Du auch den Code verfügbar machen. Die LGPL ist eine
Erweiterung der GPL, aber der "Grundgedanke" bleibt erhalten, wenn
auch nicht ganz so streng.

Weisst du wie viele kleinere Firmen OOo nur deshalb
haben um Lizenzkosten zu sparen. OOo und LO geht dabei zu weit über 90
Prozent leer, oder mit einem lächerlichen Sackgeld aus.

Wenn Du nicht ganz so rigoros gequotet hättest, wäre der Part

#> Wenn man es kritisieren will, dass Firmen mit den Ideen anderer
#> Geld machen, muss man konsequenterweise überhaupt gegen ein System kämpfen,
#
#
# Das ist nicht der Fall. Auch mit LGPL basierter Software kann man Geld
# machen. StarOffice RedOffice, NeoOffice (sogar unter GPL), alles kein
# Problem.

erhalten geblieben. Nochmals kurz: Es geht nicht um das Geld, das mit
dem Code möglicherweise verdient wird, das ist nur ein Teilaspekt.
Und wie Du selbst schreibts: Mit der Software an sich verdient man nicht viel.

Sag mir einen Grund warum sich ein Code contributor verpflichten sollte
etwas zurückzugeben, wenn es alle anderen auch nicht müssen?

Das zurückgeben bezog sich auf den Code - und das zurückgeben ist bei
copyleft Lizenzen nunmal stärker vertreten als bei der Apache-Lizenz,
in der das überhaupt nicht "vorgesehen" ist.

Zudem wirst du
keine Grossfirma dazu zwingen können, sondern sie lässt dann das Projekt
einfach kalt im Regen stehen. Die Copyleft Lizenzen sind eine Gegenreaktion,
und stammen aus einer Zeit in der es viele Softwareunternehmen einfach zu
bunt getrieben haben.

GPL, LGPL, etc. als "Gegenreaktion" zu bezeichnen oder implizit als
veraltet ("stammen aus einer Zeit"....) ist schon sehr weit hergeholt.

Klar war die ASL2 der Wunsch von IBM, aber die Jungs geben auch etwas
zurück.

Haben sie gesagt. Aber das haben sie auch schon in der Vergangenheit.
Diesmal wird IBM was tun, alleine schon um nicht noch das letzte
Bisschen Glaubwürdigkeit zu verlieren. Aber ob IBM's Beitrag mehr als
nur ein einmaliger Codedump wird bleibt abzuwarten.

Post by Christian Lohmaier
Und da kommt es die Apache-Contributer gar nicht an. Es geht auch um
die, die weder bei TDF, noch bei Apache mitmischen, sondern nur darauf
warten schmarotzen zu können.

Und wie bitte stellst du dir das vor? Firma XY braucht OOo als Grundlage für
zum Beispiel ein kommerzielles Kassensystem. Glaubst du in vollem Ernst die
würden dass ohne Hilfe der Community schaffen?

Wenn sie das nicht ohne Hilfe schaffen, dann spielen sie für diese
Betrachtung keine Rolle. Wer sein Zeug nicht vertreibt, darf mit dem
Code machen was er will - sowohl bei (L)GPL als auch bei Apache.

Wohl nicht. Und was passiert
mit Leuten die ständig nur Saugen? Man ignoriert sie einfach.

Auch das ist ein Unterschied. Die Konsumenten verändern nix - also
haben die auch gar nix was in diesem Kontext zurückfließen könnte.

Es wurde ja schon oft genug Betont, daß das "Drumherum", der reine
Community-Teil sich bei den Projekten ja kaum unterscheidet - es gibt
Freiwillige die Support leisten, etc.
Der Unterschied zwischen OOo und LO ist die "Dachorganisation".
* TDF auf der einen (die nebenbei bemerkt auch zuerst da war, schon
funktioniert hat) und die die bisherige Lizenz weiterführt (OOo war ja
auch LGPL), und einen Großteil der Code beitragenden OOo-Community
überzeugt hatte
* Apache, das nachträglich zur "Heimat" wurde, weil Oracle (oder IBM)
es so wollte. Die verbleibende Community wurde nicht gefragt, wurde
noch nicht mal informiert. Es wurde von oben herab entschieden. Die
Lizenz ist eine komplett andere, die auch zur Folge hat, daß viele
externe Komponenten gestrichen werden müssen bzw. durch minderwertige
Gegenstücke ersetzt werden (hunspell vs myspell z.B.) oder komplett
neu geschrieben/durch komplett andere Drittkomponente ersetzt werden
müssen.

Aber ja, man kann natürlich auch hinter jedem potentiellen Contributor einen
Schmarotzer sehen ;-)

Du bist ein Träumer - die Schmarotzer, die hier gemeint waren werden
nicht zu Samaritern.
Aber auch wenn:
Was ist wahrscheinlicher: Daß sie das Apache-ICLA unterschreiben,
darauf warten, daß sie akzeptiert werden und dann ihren Patch posten,
oder daß sie einfach auf die Mailingliste schreiben: Hier, mein Code,
nehmt ihn unter der LGPL/MPL (+).

ciao
Christian

[Martin Hollmichel]

Hi Christian,

Post by Christian Lohmaier
Das zurückgeben bezog sich auf den Code - und das zurückgeben ist bei
copyleft Lizenzen nunmal stärker vertreten als bei der Apache-Lizenz,
in der das überhaupt nicht "vorgesehen" ist.

ich glaub Deine Formulierung ist missverständlich, Du meinst sicherlich,
dass kein Zwang zum Zurückgeben vorgesehen ist.

Ich glaube eher, dass gerade im Fall von OpenOffice die Gefahr des
Schmarotzens eher gering, bzw. von kurzer Dauer ist. Die Erfahrung der
vergangenen Jahre hat gezeigt, dass spätestens nach ca. zwei minor
relases, also ca. 1 - 1 1/2 Jahren die Schmerzen des Auseinaderlaufens,
sprich des Lösens von Konflikten im Source code so gross werden
(aufgewendete Arbeitszeit als auch die resultierende Qualität des
Produktes), dass kommerzielle Derivate immer versuchen werden,
veränderten Source code in den Problembereichen zurückzucontributen.
Wichtig hierbei ist natürlich, dass es ein Gegengewicht zu einem solchen
potentiellen "Schmarotzer" gibt, sprich die meiste Entwicklung nicht von
nur einer Company gemacht wird, sondern auf mehrere voneinander
unabhängigen Schultern verteilt wird.

Martin

[Mathias Bauer]

Moin,

ich will mich aus der eigentlichen Diskussion raushalten, da ist
eigentlich alles gesagt. Nur ein paar Dinge würde ich gerne richtig
stellen bzw. klarer herausarbeiten.

Post by Christian Lohmaier
Das zurückgeben bezog sich auf den Code - und das zurückgeben ist bei
copyleft Lizenzen nunmal stärker vertreten als bei der Apache-Lizenz,
in der das überhaupt nicht "vorgesehen" ist.

Ähm, ich glaube nicht, dass du das so meinst, wie du es geschrieben
hast. Natürlich ist sowas "vorgesehen", es wird nur nicht erzwungen.

Post by Christian Lohmaier

Post by Raphael Bircher
Klar war die ASL2 der Wunsch von IBM, aber die Jungs geben auch etwas
zurück.

Haben sie gesagt. Aber das haben sie auch schon in der Vergangenheit.
Diesmal wird IBM was tun, alleine schon um nicht noch das letzte
Bisschen Glaubwürdigkeit zu verlieren. Aber ob IBM's Beitrag mehr als
nur ein einmaliger Codedump wird bleibt abzuwarten.

Meinst du, die stellen extra 5 Entwickler aus der alten OOo-Mannschaft
ein, nur um Code zu dumpen? Kann ich mir nicht vorstellen.

Post by Christian Lohmaier
Was ist wahrscheinlicher: Daß sie das Apache-ICLA unterschreiben,
darauf warten, daß sie akzeptiert werden und dann ihren Patch posten,
oder daß sie einfach auf die Mailingliste schreiben: Hier, mein Code,
nehmt ihn unter der LGPL/MPL (+).

Das ist eine arg einseitige Sichtweise. Selbstverständlich nehmen
ASF-Projekte auch Patches entgegen, ohne dass der Entwickler ein ICLA
unterschrieben hat, sofern es sich um kleinere Contributions handelt.
Und das hat es bei AOOo auch schon gegeben. Vermutlich ist der Punkt, wo
man eine Contribution als "groß" betrachtet, bei AOOo schneller erreicht
als bei LO. Und bei häufigeren Beiträgen eines Entwicklers ist ein ICAL
IMHO sogar praktischer als das ständige Anhängen einer Erklärung zu den
Lizenzen. Und juristisch auch sauberer.

Ciao,
Mathias
(der zwar versteht, warum Leute kein SCA unterschreiben wollten, aber
bist heute nicht kapiert, warum Leute, die regelmäßig(!) zu einem
Projekt beitragen, kein ICLA einsenden wollen)

[Thorsten Behrens]

Post by Mathias Bauer
(der zwar versteht, warum Leute kein SCA unterschreiben wollten, aber
bist heute nicht kapiert, warum Leute, die regelmäßig(!) zu einem
Projekt beitragen, kein ICLA einsenden wollen)

Weil sie es bei anderen Projekten auch nicht müssen. Ich vermute,
bei den meisten sind die Gründe philosophischer und psychologischer
Natur - vielleicht findet sich ja mal ein Sozialwissenschaftler, der
das untersucht. Bis dahin würde ich sowas eher über einem Bier
diskutieren wollen, es ist ein eher weitschweifiges Thema ...

Viele Grüße,

-- Thorsten

[michael]

Post by Thorsten Behrens

Post by Mathias Bauer
(der zwar versteht, warum Leute kein SCA unterschreiben wollten, aber
bist heute nicht kapiert, warum Leute, die regelmäßig(!) zu einem
Projekt beitragen, kein ICLA einsenden wollen)

Weil sie es bei anderen Projekten auch nicht müssen. Ich vermute,
bei den meisten sind die Gründe philosophischer und psychologischer
Natur - vielleicht findet sich ja mal ein Sozialwissenschaftler, der
das untersucht. Bis dahin würde ich sowas eher über einem Bier
diskutieren wollen, es ist ein eher weitschweifiges Thema ...

Um noch einmal auf mein Thema zurückzukommen - eine solche Diskussion
könnte ja auch bei dem von mir in den Raum gestellten Treffen
stattfinden (abends beim Bier oder als Punkt: Akzeptanz für das icla
schaffen) - wenn sich denn genügend Leute finden, die sich treffen wollen.

Gruß
Michael

[Jörg Schmidt]

Hallo,

Post by Christian Lohmaier
Der Satz gibt schonmal keinen Sinn (wo nix ist, kann auch nix
verschollen gehen), aber egal, denn was Du untern schreibst
ist eine Fehlinterpretation von Jörg, die Du einfach blind übernimmst.

Ich glaube Du mißverstehst hier "verschollen", lass mich deshalb die eigentliche
Aussage nochmals erklären.

Wenn ein Stück Code unter freier Lizenz existiert, so kann potentiell jeder es
weiterentwickeln ob jedoch diese potentielle Möglichkeit genutzt wird ist Frage
des Einzelfalls und der Rahmenbedingungen.

Wenn ich nun Bedingungen in der Lizenz so setze das ich bestimmte potentielle
Weiterentwickler abschrecke ist das zunächst von Nachteil ohne aber das es
generell in Summe ein Nachteil sein muß. Und es ist eben keine Fehlinterpretation
sondern nur eine Andersbewertung der 'Summe' wenn man Lizenzen mit schwächerem
Copyleft bevozugt.

Wenn ich ein Stück freie Software (A) habe, so gibt es prinzipiell zumindest 3
Fälle was passieren kann:

1. niemand entwickelt A weiter
2. jemand ergänzt A um Code B zu gleichen Lizenzbedingungen und erzeugt AB
3. jemand ergänzt A um Code unter anderer Lizenz C und ändert dabei ggf. auch die
Gesamtlizensierung' und erzeugt AC

Fall 1. ist hierbei im Übrigen der Fall der als 'verschollen' bezeichnet wurde,
korrekter müßte der nicht-weiterentwickelt heißen.

Ergebnis dieser Fälle ist dann das existieren (jeweils mindestens 1 Kopie):

1. nur A
2. A und AB
3. A und AC

und die einzige Frage ist wie man die eigentlichen Ergebnisse bewertet.

Technisch ist das keine Frage denn jede Erweiterung ist potentiell eine
Verbesserung, also sind AB und AC Verbesserungen.

Lediglich politisch/ideologisch ist es eben eine Frage des Standpunkts, denn
Befürworter eines schwachen Copylefts werden sowohl AB und AC anerkennen,
wohingegen Befürworter eines starken Copylefts sagen werden das AC wegen der
Lizenz wertlos wäre.

Und Beides ist keine Fehlinterpretation sondern lediglich Ausdruck anderer
Bewertung, nämlich der das Befürworter den eines schwachen Copylefts sagen das
Fall 3. immer noch besser ist als Fall 1, Befürworter eines starken Copylefts
jedoch sagen werden dass Fall 3. nicht besser als Fall 1. ist.

Und "politisch/ideologisch" ist es ganz einfach deswegen weil wir zu Kenntnius
nehmen müssen das auch propritäre Software prinzipiell zunächst funktioniert,
selbst wenn wir sie aus bestimmten Gründen für schlechter halten.

Post by Christian Lohmaier

sondern nur OOo unter dem Begriff "Konkurrenz belebt das

Geschäft" den

Garaus machen will. Nicht Konkurrenz, sondern Kooperation

war und ist

die Grundlage menschlicher Entwicklung.

Ja, und hier sind wir beim Knackpunkt. Kooperation. Das
impliziert, daß derjenige, der etwas nimmt, auch etwas zurückgibt.
Und das ist bei Apache schlicht in keinster Form gegeben.

Was wohl Apache selbst darüber denken mag?

Aber lassen wir das einmal dahingestellt und beschränken wir uns hier auf die
Praxis und da stellen wir fest das das Apache-Modell wunderbar funktioniert, wo
also ist da ein Problem.

Was ich auch nie verstehen werde ist die Rummäkelei an Apache seitdem Apache OOo
übernommen hat, denn ich kann mich garnicht erinnern das früher Apache hier
kritisiert worden wäre.

Post by Christian Lohmaier
Und da kommt es die Apache-Contributer gar nicht an. Es geht
auch um die, die weder bei TDF, noch bei Apache mitmischen,
sondern nur darauf warten schmarotzen zu können.

Und genau hier liegt die Fehlinterpretation, denn jeder der Code schreibt und
unter freie Lizenz stellt tut das freiwillig und muß gleichzeitig wissen das sein
Code dadurch auch durch Dritte kommerziell genutzt werden kann.
Diese Nutzung IST lizenzkonform und kann kein "schmarotzen" sein, denn der Urheber
hat ja die Lizenz bewußt und gewollt verwendet.

Wenn der Urheber es als "schmarotzen" sähe kann er eine andere Lizenz verwenden,
und es gäbe kein Problem des "Schmarotzens".

Übrigens tun Letzteres Viele, denn jede Freeware-Lizenz ist beispielsweise
geeignet das was Du hier als "schmarotzen" bezeichnest zu beseitigen.

Alleine Eines geht nicht nämlich bei einer freien Lizenz kommerzielle Nutzung
auszuschließen, denn es ist essentiell für eine freie Lizenz keine Art der Nutzung
zu diskriminieren. In dieser Frage ist auch die FSF, trotz anderer Kritik die ich
an ihr habe, ganz klar wenn sie schreibt:

"Wenn wir die Freiheit des Anwenders verteidigen, lassen wir uns nicht von solchen
Nebensächlichkeiten ablenken, wie etwa wieviel Geld man für den Vertrieb verlangt.
Freiheit ist der Kernpunkt, der gesamte Kernpunkt, und der einzige Kernpunkt."

siehe: http://www.gnu.org/philosophy/selling.de.html


Gruß
Jörg

[Christian Lohmaier]

Hallo Jörg,

Post by Jörg Schmidt

Post by Christian Lohmaier
[...]
Ja, und hier sind wir beim Knackpunkt. Kooperation. Das
impliziert, daß derjenige, der etwas nimmt, auch etwas zurückgibt.
Und das ist bei Apache schlicht in keinster Form gegeben.

Was wohl Apache selbst darüber denken mag?

Der ist es ja gerade eben egal. Deshalb gibt es ja die Apache-Lizenz überhaupt.

Und nochmals: Es bezieht sich hier nicht auf Mitglieder der
Community/des Projektes, die arbeiten natürlich miteinander. Es geht
um die "lizenzgemäße Verwertung" durch Dritte, die sich im Projekt
nicht sehen lassen.

Post by Jörg Schmidt
Was ich auch nie verstehen werde ist die Rummäkelei an Apache seitdem Apache OOo
übernommen hat, denn ich kann mich garnicht erinnern das früher  Apache hier
kritisiert worden wäre.

Es wird nicht Apache als solches kritisiert, sondern Apache als Heimat
für OOo - vor dem Hintergrund, daß es bereits eine Alternative gab,
auf die Oracle als auch IBM Einfluß hätten nehmen können um sie so zu
formen, daß es auch für sie paßt.
Das Apache Projekt hat gegenüber der Apache-Lizenz ja noch zusätzliche
Einschränkungen:
Es wird keine andere Lizenz geduldet. Sprich die bisherigen
Drittkomponenten müssen ersetzt werden. Das verzögert ein OOo-Release
erheblich, sieht man ja.
Es wird ein ICLA gefordert. Einfach mal reinschauen und einen Patch
schicken ist nicht. Man muß erst einen Wisch unterschreiben.
Projekt-spezifische Infrastruktur → ist nicht. Bzw. wird jetzt für OOo
das erste mal eine "Ausnahme" gemacht. Aber viele Sachen fallen erst
mal weg/müssen wieder aufgebaut werden.
Projekt-spezifische Spenden/Gelder → ist nicht. Sieht man ja auch im
aktuellen Konflikt.
Daß OOo zurück zu subversion ist (zumindest vorübergehend) ist auch
nicht so prickelnd.

Post by Jörg Schmidt

Post by Christian Lohmaier
Und da kommt es die Apache-Contributer gar nicht an. Es geht
auch um die, die weder bei TDF, noch bei Apache mitmischen,
sondern nur darauf warten schmarotzen zu können.

Und genau hier liegt die Fehlinterpretation, denn jeder der Code schreibt und
unter freie Lizenz stellt tut das freiwillig

Nein. Eben nicht. Die Lizenz gibt vor, ob der geschriebene Code unter
eine freie Lizenz gestellt werden *muß* oder nicht.

Post by Jörg Schmidt
und muß gleichzeitig wissen das sein
Code dadurch auch durch Dritte kommerziell genutzt werden kann.

Ja, aber jeder der es freiwillig tut, ist kein Dritter um den es hier geht.

Post by Jörg Schmidt
Diese Nutzung IST lizenzkonform und kann kein "schmarotzen" sein, denn der Urheber
hat ja die Lizenz bewußt und gewollt verwendet.

Du hast wieder mal deine irrwitzige Argumentationskette bemüht, bei
der Du von "Ich halte einen Apfel in der Hand" zu "ich liebe Ponies"
kommst.

Post by Jörg Schmidt
Wenn der Urheber es als "schmarotzen" sähe kann er eine andere Lizenz verwenden,
und es gäbe kein Problem des "Schmarotzens".

Nein. Er kann eben *NICHT* einfach eine andere Lizenz verwenden. Die
Lizenz wird duch das Projekt bereits vorgegeben. Apache auf der einen,
LGPL/MPL auf der anderen. Und ja, wenn er Apache nimmt kann er
schmarotzen so viel er will, es bleibt lizenzgemäß.
Aber ob gemäß Lizenz oder nicht ist egal. Es ist das Empfinden dieser
Verwertung als "Schmarotzen" was für die persönliche Entscheidung
ausschlaggebend ist.

Post by Jörg Schmidt
Übrigens tun Letzteres Viele, denn jede Freeware-Lizenz ist beispielsweise
geeignet das was Du hier als "schmarotzen" bezeichnest zu beseitigen.

Ja, eben. Deshalb nimmt TDF ja auch nicht die Apache-Lizenz (ganz
abgesehen davon, daß sie es damals noch gar nicht konnte)

Post by Jörg Schmidt
Alleine Eines geht nicht nämlich bei einer freien Lizenz kommerzielle Nutzung
auszuschließen,

Auch das wurde schon mehrmals geschrieben und auch nie abgestritten.
Das ist wiegesagt auch nicht der Punkt.

ciao
Christian

[Jörg Schmidt]

Hallo Christian,

Post by Christian Lohmaier

Post by Jörg Schmidt
Und genau hier liegt die Fehlinterpretation, denn jeder der Code
schreibt und unter freie Lizenz stellt tut das freiwillig

Nein. Eben nicht. Die Lizenz gibt vor, ob der geschriebene
Code unter eine freie Lizenz gestellt werden *muß* oder nicht.

Darum ging es mir doch garnicht in meiner Argumentation sondern um den ursprünglichen Urheber, nicht um diejenigen Programmierer die dann den Code weiterentwickeln. Und der ursprüngliche Urheber ist frei in seiner Lizenz-Entscheidung von propritär bis GPL.

Post by Christian Lohmaier

Post by Jörg Schmidt
und muß gleichzeitig wissen das sein
Code dadurch auch durch Dritte kommerziell genutzt werden kann.

Ja, aber jeder der es freiwillig tut, ist kein Dritter um den
es hier geht.

Post by Jörg Schmidt
Diese Nutzung IST lizenzkonform und kann kein "schmarotzen"

sein, denn

Post by Jörg Schmidt
der Urheber hat ja die Lizenz bewußt und gewollt verwendet.

Du hast wieder mal deine irrwitzige Argumentationskette
bemüht, bei der Du von "Ich halte einen Apfel in der Hand" zu
"ich liebe Ponies"
kommst.

Meine Argumentation ist ganz einfach das wenn ich als Urheber eine Software unter freie Lizenz stelle das ich dann wissen muß was ich tue.

Z.B. waren 2 frei lizensierte Makros von mir schon auf der CD der C't und die hat mir dafür natürlich nichts gegeben:
http://www.heise.de/software/download/mottco/63530
http://www.heise.de/software/download/uref/41933

nur bin ich deswegen nicht sauer, denn das Recht dazu habe ich ja ausdrücklich durch die Lizenzen eingeräumt und war mir dessen bewußt.
(ach doch, mottco war auch bereits in der niederländischen Ausgabe der C't und dafür habe ich damals ein Gratisemplar bekommen ;.))

Post by Christian Lohmaier
Und ja, wenn er Apache nimmt kann er schmarotzen so viel er
will, es bleibt lizenzgemäß.
Aber ob gemäß Lizenz oder nicht ist egal. Es ist das
Empfinden dieser Verwertung als "Schmarotzen" was für die
persönliche Entscheidung ausschlaggebend ist.

Und in diesem Empfinden habe ich Dir ja in meiner Antwort auf Raphaels Mail beigepflichtet, denn ich halte dieses Empfinden für verständlich nur ich teile es persönlich nicht und ich finde die Wortwahl "schmarotzen" dann nicht gut wenn etwas lizenzkonform genutzt wird und auch nicht gut weil es viele davon abhält sich bei OSS einzubringen, indem es nämlich immer Mißverständnisse entstehen in Vermischung von moralischem Empfinden und Rechtsgegebenheiten.

Ich sehe hier auch keinen Grund zum Streit, denn man kann über diese Dinge schlecht streiten, insofern beweisen kann was 'besser' ist.
Ich persönlich habe vor ca. 7 Jahren angefangen mich mit FOSS zu beschäftigen und fand das alles ganz toll ohne wirklich was zu Lizenzen zu wissen. Dann habe ich begonnen mich für Lizenzen zu interessieren und im Laufe der Zeit bin ich für mich zu der Entscheidung gelangt, das die LGPL die 'maximalste' Lizenz ist die ich mir vorstellen kann selbst zu verwenden (und ich tue das ja auch praktisch), GPL hingegen würde ich nur verwenden wenn ich es muß.
Mein persönliches Empfinden geht aber immer stärker dahin 'BSD-artige' Lizenzen zu bevorzugen, weil ich diese als freier emfinde.

Ich kann Dir auch nur sagen das ich einfach nicht empfinde das ich mißbraucht werde bzw. Schmarotzer nähre, wenn andere, ohne selbst zurückzugeben, mit meinem Code Geld verdienen. Das ist _meine Empfindung_ und kein Beweis für irgendwas.



Gruß
Jörg

[Christian Lohmaier]

Hi Jörg, *,

Post by Jörg Schmidt
Hallo Christian,

Post by Christian Lohmaier

Post by Jörg Schmidt
Und genau hier liegt die Fehlinterpretation, denn jeder der Code
schreibt und unter freie Lizenz stellt tut das freiwillig

Nein. Eben nicht. Die Lizenz gibt vor, ob der geschriebene
Code unter eine freie Lizenz gestellt werden *muß* oder nicht.

Darum ging es mir doch garnicht in meiner Argumentation sondern um den ursprünglichen Urheber, nicht um diejenigen Programmierer die dann den Code weiterentwickeln. Und der ursprüngliche Urheber ist frei in seiner Lizenz-Entscheidung von propritär bis GPL.

Genau das meine ich. Du schweifst wieder in ganz andere Gefilde ab.
Hier kann es nur um die Beteiligung an bereits bestehenden Projekten
gehen. Um die bei Apache OOo und die bei TDF/LibreOffice.

Was andere Projekte machen, oder was ein anderer Entwickler mit seiner
eigenen software macht, hat doch mit dem hier diskutierten überhaupt
nix zu tun. Damit machst Du nur einen Nebenschauplatz auf der den
Thread nur wieder in die Länge zieht. Dabei geht dann das eigentliche
Thema unter.

Post by Jörg Schmidt
[...]
Ich kann Dir auch nur sagen das ich einfach nicht empfinde das ich mißbraucht werde
bzw. Schmarotzer nähre, wenn andere, ohne selbst zurückzugeben, mit meinem Code
Geld verdienen. Das ist _meine Empfindung_ und kein Beweis für irgendwas.

Nochmals: Es geht nicht darum, daß andere damit Geld verdienen.
Es geht darum, daß die Masse nicht von *Verbesserungen* und
*Erweiterungen* profieren kann weil sie schlicht zurückgehalten
werden.

Und ob "Schmarotzer" nun ein passendes Wort ist oder nicht - darüber
kann man denken was man will. Für sich allein stehend würde ich es
nicht verwenden. Es war klar dazu gedacht, um den Gegensatz zwischen
Copyleft und Apache zu illustrieren. Und die Unterschiede werden halt
am deutlichsten, wenn man klar Position bezieht, es von einer
Perspektive heraus aufzeigt.

Aus Apache-Sicht is LibreOffice/TDF natürlich "böse", weil die den
Apache-Code nehmen dürfen (und in Teilen bestimmt auch werden, man
denke an das versprochene IA2), aber andererseits Apache nicht einfach
den Code von LO verwenden darf.

Und bezüglich "Nutznießer-Projekte haben ein Interesse miteinander zu
arbeiten, alleine weil ansonsten der Merge-Aufwand zu hoch wird":
http://www.antelink.com/blog/libreoffice-vs-openoffice-anatomical-study-fork.html
Durch die Stagnation bei OOo ist es bereits jetzt schon nicht mehr
trivial hin-und her zu mergen, dazu hat sich bei LibreOffice schon zu
viel getan.
Und dadurch, daß Oracle eine "Einbahnstraße" bzgl. der Lizenzen
geschaffen hat, wird sich daran auch so schnell nichts ändern.

ciao
Christian

[Uwe Altmann]

Hi

Post by Jörg Schmidt
Hallo Christian,
...
Ich kann Dir auch nur sagen das ich einfach nicht empfinde das ich
mißbraucht werde bzw. Schmarotzer nähre, wenn andere, ohne selbst
zurückzugeben, mit meinem Code Geld verdienen. Das ist _meine
Empfindung_ und kein Beweis für irgendwas.

Und das genau ist der Punkt: Mit welchem Lizenz- und
Einstiegsbedingungen motiviere ich /den nächsten konkreten/ Entwickler
oder sonstigen Aktiven (PR, Doku, helpdesk usw.) zur Mitarbeit an
"meinem" Projekt bzw. treffe eben sein Empfindungen, was
bestimmungsgemäßer Gebrauch seiner Beiträge ist und was nicht mehr. Und
da hätten wir grob vereinfacht gesagt derzeit zwei Modelle:

LGPL vs. Apache als Lizenz und
Patch einwerfen vs. erst Papierkram erledigen als Eintrittshürde.

Uns wie es im Moment aussieht, findet das Modell "LGPL/MPL und den Code
einfach einwerfen" zumindest derzeit deutlich mehr Zulauf. Wundert ja
auch nicht, das wurde ja von den Entwicklern gegründet und die habe
sich's natürlich so eingerichtet, wie sie das für sich richtig hielten
und halten.

Das kann man jetzt aussitzen bis einem der beiden Zweige die Ressourcen
ausgehen oder man versucht zumindest, das einigermaßen beisammen zu
halten - und das war der ehrenwerte Vorschlag Michaels in einem
parallelen Thread.
Wie sieht's denn damit so aus?

P.S.: Ich könnte am Samstag zum Linux-Info-Tag in Landau noch
Verstärkung aus welchem Lager auch immer gebrauchen - Manfred Reiter
kann nicht mitkommen.
Die Pfalz (die Toscana Deutschlands) ist gerade im Herbst eine wirklich
sehr schöne Gegend zum Kurzurlaub machen - Übernachtungsmöglichkeit kann
ich gerne anbieten ;-)
P.P.S: Eric - wie wär's mit einem Besuch zu Hause?

[Jörg Schmidt]

Hallo Uwe, *,

Post by Uwe Altmann
Und das genau ist der Punkt: Mit welchem Lizenz- und
Einstiegsbedingungen motiviere ich /den nächsten konkreten/
Entwickler oder sonstigen Aktiven (PR, Doku, helpdesk usw.)
zur Mitarbeit an "meinem" Projekt bzw. treffe eben sein
Empfindungen, was bestimmungsgemäßer Gebrauch seiner Beiträge
ist und was nicht mehr. Und da hätten wir grob vereinfacht
LGPL vs. Apache als Lizenz und
Patch einwerfen vs. erst Papierkram erledigen als Eintrittshürde.
Uns wie es im Moment aussieht, findet das Modell "LGPL/MPL
und den Code einfach einwerfen" zumindest derzeit deutlich
mehr Zulauf. Wundert ja auch nicht, das wurde ja von den
Entwicklern gegründet und die habe sich's natürlich so
eingerichtet, wie sie das für sich richtig hielten und halten.

Stimmt genau, aber das hilft denjenigen nichts denen dieses Modell nicht gefällt, denn es gilt, auch gerade bei LO aber bei Apache ebenfalls, das sich irgendwer einer Mehrheit unterordnen müßte, sondern es gilt Meritokratie, wer 'macht' bestimmt also die Richtung und wer, zu bestimmte Bedingungen nicht will, 'macht' nicht.

Und lass mich hier etwas Persönliches sagen:
ich bin offfen und ehrlich in diesen Dingen, denn ich sage öffentlich was ich denke und warum ich Manches tue. Große Teile derer die sich entweder gegen LO/TDF oder OOo/Apache entscheiden, tun das ohne öffentliche Begründung, was ja auch ihr Recht ist.
Man kann nur so oder so nichts daran deuteln das für jeden Einzelnen, wenn er mitarbeiten soll, die Bedingungen passen müssen, sonst arbeitet er nicht mit, egal ob öffentlich begründet oder nur stillschweigend.

Post by Uwe Altmann
Das kann man jetzt aussitzen bis einem der beiden Zweige die
Ressourcen ausgehen

Warum so pessimistisch? Zumindest für LO wird man doch, sofern die Eigenaussagen stimmmen, bereits jetzt konstatieren können es gibt mehr Entwickler als OOo (alt) jemals hatte.

Für OOo/Apache sieht es derzeitig viel schlechter aus und ich hoffe da auch nicht auf Wunder sondern höchstens auf hinreichende Verbesserung, wenn das nicht klappt (und die Chance erachte ich als hoch) klappt es nicht. Jedoch besteht selbst dann kein Automatismus das die Entwickler zu LO wechseln werden.

Das ist doch das was ich immer betone, es reicht nicht von OOo enttäuscht zu sein um bei LO/TDF mitzuarbeiten, sondern man muß von den Rahmenbedingungen bei LO/TDF überzeugt sein um dort mitzuarbeiten.
Wäre ich ein Computer, und würde keine persönlichen Vorlieben und Motivationen kennen und würde nur trockene technische Fakten der Software bewerten, wäre ich längst bei LO, denn LO ist unumstritten das _rein technisch_ betrachtet dezeit weit führende Projekt, nur bin ich eben, wie jeder hier, ein Mensch mit Vorlieben und ganz persönlichen Motivationen.

Ansonsten rennst Du bei mir offene Türen ein, nur ich habe nun einmal keinerlei Möglichkeit den Entwicklern zu sagen was sie tun sollen, denn die müssen auf niemandedn verbindlich hören und tun das auch nicht, in einen freien Projekt ist das ihr gutes Recht.

Wäre ich hingegen eine große Firma und hätte dadurch dazu die Macht, und hätte zusätzlich Interesse, würde ich das tun dessen sich SUN über die Jahre verweigert hat, nämlich die Rechte am Code zentral und verbindlich in einer gemeinnützigen Stiftung verwalten. Das wäre bei richtiger Ausgestaltung nämlich der Garant immer, im Falle des Falles, auch umlizensieren zu können wenn sich das als gewünscht für das Vorankommen erweist und in der Art und Weise umzulizensieren wie es dann gewollt und nützlich wäre.
Ich habe nur für solche Dinge nicht die Macht.

Post by Uwe Altmann
oder man versucht zumindest, das
einigermaßen beisammen zu halten - und das war der ehrenwerte
Vorschlag Michaels in einem parallelen Thread.
Wie sieht's denn damit so aus?

Ich glaube hier hat M.Meek recht, wie auch M. Hollmichel, es gibt bezüglich des Codes technische Grenzen und irgendwann wird der Aufwand, bzw. der Teil des Aufwands der nur betrieben wird um die Codebasis zusammenzuhalten, zu hoch.

Faktisch können das aber nur die Entwickler entscheiden, denn die sind es die dort agieren und die können viel oder wenig Code schreiben und können letztlich auch entscheiden wieviel Zusdatzaufwand sie zu treiben bereit sind um die Codebasios zusammenzuhalten.
Ich sehe schlichtweg keine andere Möglichkeit, denn gerade diejenige wo eine Mehrzahl im Projekt abstimmen würde was die Entwickler tun müssen, fällt ja weg da Meritikratie und jeder Entwickler frei ist sich zu entscheiden.



Gruß
Jörg

[Martin Hollmichel]

Post by Jörg Schmidt
Faktisch können das aber nur die Entwickler entscheiden, denn die sind es die dort agieren und die können viel oder wenig Code schreiben und können letztlich auch entscheiden wieviel Zusdatzaufwand sie zu treiben bereit sind um die Codebasios zusammenzuhalten.

teilweise richtig, in vielen Fällen jedoch wird eine Firma, die die
Entwickler beschäftigt, im Interesse der Firma den Entwickler anweisen,
an welchem der Projekte mitzuarbeiten ist, Ich weiss nicht, wie hoch der
Anteil dieser so beauftragten Entwickler sowohl bei der ASF als bei der
TDF ist, ich vermute aber, dass dieser Anteil bei "core" Kontributoren
doch deutlich höher als 50% sind. Insofern haben faktisch nicht nur
Entwickler, sondern die entsprechenden Geldgeber Einfluss bei der
Entscheidung. Das läßt aber auch den Schluss zu, dass bei entsprechenden
fundraising ein grösserer Einfluss der community durchaus möglich ist.

Martin

[Jörg Schmidt]

Hallo Martin, *,

Post by Jörg Schmidt

Post by Jörg Schmidt
Faktisch können das aber nur die Entwickler entscheiden,

denn die sind es die dort agieren und die können viel oder
wenig Code schreiben und können letztlich auch entscheiden
wieviel Zusdatzaufwand sie zu treiben bereit sind um die
Codebasios zusammenzuhalten.
teilweise richtig, in vielen Fällen jedoch wird eine Firma,
die die Entwickler beschäftigt, im Interesse der Firma den
Entwickler anweisen, an welchem der Projekte mitzuarbeiten
ist,

Ja, richtig.

Ich wollte auch diesen Fall nicht auschliessen, gerade weil ich das für EINEN NORMALfall halte, sondern hielts nur für bequem und verständlich von 'Entwicklern' zu sprechen.
Hätte ich im Übrigen nur die Nicht-Firmenentwickler gemeint hätte ich von 'freien Entwicklern' gesprochen.

Korrekt müßte es wohl 'Code-Beiträger' heißen oder nenne mir einen besseren Begriff, denn einzig wollte ich kennzeichnen es geht um diejenigen aus der Community die tatsächlich Code zu OOo beitragen denn das tun nicht Alle, nicht einmal die Mehrzahl (denn die Mehrzahl trägt z.B. Dokus bei oder steht auf Messen oder Ähnliches).


Also .... alles nur Begriffsfragen und ich bin hier gerne bereit andere Begriffe zu nutzen wenn mir jemand Bessere nennt.


Und evtl. noch fürs Protokoll (hier auf der Liste wissen das fast Ale die mich kennen, aber Du (Martin) weißt das vielleicht nicht):

für mich schließt z.B. der Begriff "Community" immer alle Beteiligten ein, es gab für mich also im Eigentlichen nie sowas wie die OOo-Community und Sun, sondern Sun war Bestandteil davon. (einzig ist es manchmal sinnvoll zu unterscheiden, aber das sind Ausnahmen)
Und obwohl ich das so sehe gestehe ich freimütig das ich persönlich ohnehin dem 'Unternehmensflügel' der Community näher stehe, weil ich persönlich damit mehr Schnittmengen bei bestimmten Vorgehensweisen oder Interpretation von Sachthemen habe, als mit /Teilen/ der 'Nicht-Unternehmens-Community'.

Post by Jörg Schmidt
Insofern
haben faktisch nicht nur Entwickler, sondern die
entsprechenden Geldgeber Einfluss bei der Entscheidung. Das
läßt aber auch den Schluss zu, dass bei entsprechenden
fundraising ein grösserer Einfluss der community durchaus möglich ist.

Ich sehe hier bei strenger Betrachtung nicht einmal einen Unterschied, denn egal was oder warum Unternehmen etwas geben sie tun es nur weil sie wollen, genauso wie Nicht-Firmen-Community-Mitglieder.
Nicht-Firmen (also hier überwiegend natürliche Personen) unterscheiden sich da garnicht wesentlich, denn auch die müssen sich ihre Projekt-Teilnahme 'leisten' können müssen also über Zeit- und/oder Geldressourcen verfügen die sie nicht notwendig für ihr 'Normalleben' brauchen sondern bereit sind in das Projekt zu stecken.

Eigentlich fände ich es gut wenn sich Alle dem bewußt wären und man nicht immer wieder Diskussionen führen muß um den gewähnten Dissens zwischen Firemen und Nicht-Firmen zu entspannen bzw. um klarzumachen das Firmenengagement nichts Negatives ist.



Gruß
Jörg

[Jörg Schmidt]

Hallo,

Post by Herbert Dürr

Post by Herbert Dürr
Wenn die Firmen nun die bewährte Zusammenarbeit unter dem

Apache Dach

Post by Herbert Dürr
nutzen und gleichzeitig den Rat ihrer Anwälte (nämlich ein

Veto gegen

Post by Herbert Dürr
jedwede "virale Lizenzen") befolgen wollen, sind "kleine
Wiedervereinigungen", indem soviele wie möglich ihre

Änderungen auch

Post by Herbert Dürr
unter die Apache Lizenz stellen, ein wichtiger Beitrag für die
langfristige Vitalität des Projekts.

Die plötzliche Polemik gegen Copyleft erstaunt mich immer wieder.
Sie wurde seltsamerweise in den vergangenen 11 Jahren mit der
LGPL nie geäußert.

Wer fängt denn mit sowas an, doch wohl die 'Freunde' der FSF, oder lese ich da was
falsch:
http://www.heise.de/open/meldung/Free-Software-Foundation-raet-zu-LibreOffice-1259
195.html

Aber demnächst macht Richard Stallman wohl den Laden alleine, wenn er eigene
Verbündete durch seinen idiotischen Extremismus weiterhin vertreibt:
http://larrythefreesoftwareguy.wordpress.com/2011/10/07/time-to-fork-the-fsf/

Post by Herbert Dürr
ich betrachte dieses Schlupfloch aber nicht als wünschenswert.

Naja, und das haben wir ja dann wieder einmal klargestellt, Freiheit ist für den
Einen die erzwungene Freiheit eines überzogenen Copylefts und für andere die
Freiheit die auch das Recht der anderen Seite anerkennt mit einer *Kopie* des
Codes das zu machen was man will, ggf. also auch ihn in propritäre Projekte
einzubinden.
Das ist für mich im übrigen keine Frage das ich besonderen Wert darauf lege das
Code, i.d. Sinne, beliebig verwendet werden darf, es ist nur die Frage was einem
wichtiger ist, die Freiheit des Anderen oder die Möglichkeit auszuleben anderen
seine Vorstellungen von Freiheit aufzuzwingen.

Post by Herbert Dürr
Das ist zumindest irreführend. Merging von Fixes/Features
wird, unabhängig vom Versionskontrollsystem, zukünftig
zusätzliche Arbeit machen. Diese Arbeit wird nur dann
investiert werden, wenn es das Feature "wert" ist. Dies gilt
natürlich für beide Seiten - wer also einen Bugfix
beispielsweise bei LibreOffice integriert haben möchte, tut
dies am besten 'passend' zur Codebase.

An der Stelle gebe ich Dir völlig Recht, das ist das was ich meinte und was
M.Meeks vor einiger Zeit so ähnlich gesagt hat.
Das ist für mich auch alles OK, insofern es sich ja weitgehend um technische
Zweckmäßigkeiten handelt.


Gruß
Jörg

[Martin Hollmichel]

Hi Thorsten,

Post by Thorsten Behrens
Die plötzliche Polemik gegen Copyleft erstaunt mich immer wieder.
Sie wurde seltsamerweise in den vergangenen 11 Jahren mit der LGPL
nie geäußert.
Auch hier in Rede stehende Firmen haben kein Problem, bei
existierenden Projekten unter Weak-Copyleft oder sogar GPL zu
contributen. Es ist natürlich für ein gewinnorientiertes
Unternehmen günstiger, nicht zurück contributen zu_müssen_ - ich
betrachte dieses Schlupfloch aber nicht als wünschenswert.

grundsätzlich gebe ich Deinen Ausführungen recht, formuliere das aber
ein wenig anders: Ein Unternehmen, insbesondere konservative
Unternehmen, gehen nur ungern Verplichtungen ein. Selbst wenn
grundsätzlich die Bereitschaft da wäre, die eigenen Änderungen
zurückzugeben, besteht ja immer ein Risiko, dass ich das bei einigen
Änderungen (absichtlich oder unabsichtlich) nicht tue. Das mögen
Trivalitäten sein, Anwälte können das aber schlimmste Szenarien draus
konstruieren, Weisst Du z.B. wieviele modifizierte OpenOffice Versionen
es gibt, wo Leute die Unternehmen bei einer OOo Migration geholfen haben
und letztendlich gegen die Lizenz verstossen. In den meisten fällen wohl
Trivalitäten, one-offs die man so im allgemeinen OOo gar nicht als patch
akzeptieren würde, sondern letzlich eine Anpassung an eine
Kundeninstallation sind. Ich sehe das auch nicht tatsächlich als
relevant an, aber andere tun es halt.


Die OpenOffice Situation ist aber auch eine besondere, die gewissen
Aspekten besondere Bedeutung verleiht. Wir setzen hier mit ODF und der
OOo API standards, von denen wir wollen, dass sie auch genutzt werden,
auch von "konservativen Angsthasen", von daher mag eine nicht
restriktive Lizenz günstiger erscheinen.Das widerum erscheint aber auch
nicht so gewichtig, wenn einem das Produkt mehr als die Standards am
Herzen liegen. Und auch ein gegenseitiges dual licensing von patches
(Apache/LGPL) mag zwar die einfache und pragmatische Lösung sein, auf
der anderen Seite ist dies aber in letzter Konsequenz auch
gleichbedeutend mit der Verwässerung der LGPL, d.h. zwar technisch eine
Lösung aber es kann natürlich keine politische Lösung für die
Fürsprecher der LGPL sein.

Es scheint also, als wäre nach der Trennung der Community nun auch die
Trennung der codebasis unvermeidlich. Dies manifestiert dann zum einen
das Ende des bisherigen OOo projektes und birgt das Risko des Scheiterns
für eines oder gar beider Nachfolgeprojekte.

Wir sollten versuchen eine Lösung zu finden, auch wenn die Situation
aussichtslos erscheint oder gar ist. Es ist zu befürchten, dass
demnaechst die alten OOo mailing listen nicht mehr zur Verfügung stehen,
wir sollten trotzdem Wege finden, den Dialog fortzuführen.

Martin

[Jörg Schmidt]

Hallo,

Post by Herbert Dürr
Zur Zeit veröffentlichen sie ihre Änderungen unter der LGPL,
weil die alte OOo Lizenz das so vorgab. Die Änderungen wurden
und werden außerdem noch unter der MPL angeboten.
Wenn man zusätzlich unter der ASL anbieten würde, wäre eine
Wiedervereinigung problemlos möglich.

Ja "wenn", nur genau das wird IMHO nicht passieren, denn damit würde man zuviel
aufgeben insofern dann auch eine Wiedervereinigung unter Apache möglich wäre, man
strebt jedoch wenn dann nach einer Wiedervereinigung unter Regie der TDF.

Post by Herbert Dürr
Was wäre der Vorteil der Apache Lizenz? [...]

Da rennst Du bei mir offene Türen ein, nur bei LO/TDF dürften das Viele anders
sehen.

Post by Herbert Dürr

Post by Jörg Schmidt
Im Übrigen dürfte sich die Frage nach jüngsten

Verlautbarungen seitens

Post by Jörg Schmidt
LO immer weniger stellen, denn wenn die dortige

Feststellung ist das

Post by Jörg Schmidt
sich LO und OOo von der Code-Basis immer mehr auseinander

entwickeln,

Post by Jörg Schmidt
dürften Codebeiträge die für beide Projekte 'kompatibel'

sind eher zu Ausnahmen werden.
Als Entwickler sehe ich das nicht so... "cherry picking" ist
mit den aktuellen Versionskontrollsystemen kaum ein Problem.

Verstehe ich nicht so ganz.

Wenn LO ein Feature B hat, welches auf Feature A aufsetzt, OOo hingegen Feature A
garnicht beinhaltet wird OOo Feature B nicht einfach übernehmen können und
umgekehrt.
Je kleiner hier die 'Sprünge' sind desto eher kann man vielleicht
Alternativimplementierungen für A finden, nur die 'Kette' geht ja weiter und ist
irgendwann A-B-C-D-E und was ist wenn ein Projekt, gewollt, A bis D nicht
implementiert hat, aber E nun trotzdem will? Man muß dann entweder A bis D
nachträglich übernehmen oder dafür eine eigene Alternativ-Implementierung machen.
(naja, das ist sehr verkürzt weil die Zusammenhänge nicht so 'linear' sind, aber
ich habe nur versucht das Ganze in ein fassbares Bild zu kleiden)

Das ist, meines Erachtens, das was M.Meeks, aus Sicht von LO bereits sagte, man
wird sich nicht generell weiter an OOo 'hängen', aber im Einzelfall den _daraus_
resultierenden Aufwand nicht scheuen und gute neue Features übernehmen, auch wenn
das zusätzlichen Aufwand bedeutet, weil eben die 'Basis' nicht mehr gleich ist.

Ich kann für C++-Code nicht abschätzen wie es dort in Praxis aussieht, nur
tendenziell ist doch offensichtlich, je kleiner die Abschnitte A, B, ... werden,
desto weniger dürfte sich die Übernahme lohnen, da ein bisschen Anpassung immer
notwendig ist (wenn man keine identische Code-Basis annimmt) und man dann bei
kleineren Features besser gleich überlegt diese komplett neu zu schreiben, weil
die Übernahme keinen Aufwand spart.



Gruß
Jörg

[Tobias Voigt]

David Paenson <davepolit <at> googlemail.com> writes:
<http://www.fb4.fh-frankfurt.de/tips/openoffice/dokumentation/ooo_fuer_studenten.pdf>

Post by David Paenson
Ich werde die Apache-Entwicklung im Rahmen meiner Möglichkeiten
(Dokumentation und Unterricht an meiner Uni) weiterhin unterstützen.

Meinst du damit diesen Abschnitt aus dem Impressum:

"von David Paenson, B. A. Hons.
Oktober 2011"

"Diese Anleitung basiert auf Version 3.3 von OpenOffice.org.
Für Linux-Anwender empfehle ich die Distribution »Easy
Peasy 1.6«, downloadbar unter http://www.fb4.fh-frankfurt.de/tips/system/."

"Diese Version enthält OpenOffice.org 3.2."
[1] "Nach der Installation empfehle ich
keine automatischen Updates zuzulassen,
[2] denn diese würden OpenOffice.org durch LibreOffice ersetzen,
die meiner Erfahrung nach noch nicht ausgereift ist. "

Da du das im Oktober 20011 schreibst,
wirst du aktuelle Versionen 3.3.4 und 3.4.3 meinen.
Dabei legst nicht einmal dar, was du mit "nicht ausgereift" meinst.

[1] = Empfehlung genannte Linux-Distribution niemals zu aktualisieren.
[2] = Bashing gegen LO

Sei versichert, dass Apache [1] und [2] nicht verstehen wird
als "Apache-Entwicklung unterstützen".

Apache ist von diesem Niveau weit entfernt
bzw. solches Denken ist bei Apache völlig undenkbar.

Tobias

[michael]

Post by michael
Hallo,

Post by michael
Meine Anmerkung: Gerüchte entstehen oft mangels "handfester"
Informationen.

Bloß was ist Gerücht und was Information? Oder stürzt Du Dich in Beliebigkeit auf jede gut _klingende_ Aussage und leitest daraus eine 'gesicherte Zukunft' für OOo ab?

Hallo Jörg,

Thomas M. schrieb einleitend:

"es kursieren doch die interessantesten Informationen und Gerüchte im
Netz um den Fortbestand von OOo."

Ich habe mir daraufhin den mehr oder minder dezenten Hinweis erlaubt,
dass man "Gerüchten" am Besten durch "handfeste" Informationen begegnen
kann.

Diese tuen - und da, denke ich, sind wir uns einig - bei OpenOffice.org not.

Ich jedenfalls vermisse sie.

Gruß
Michael