Hallo,
ich hatte heute nach langer Zeit mal wieder mit einem Menschen zu tun, der sich noch überhaupt gar nicht mit dem Thema Freie Software beschäftigt hat und bemerkt, dass ich keine Referenzwebseite kenne auf die ich verweisen kann. Die Vorteile aus Benutzersicht waren sofort einleuchtend, aber die Frage, warum man auch als Entwickler seine Software frei stellen sollte und wie man trotzdem leben könne konnten wir nicht abschließend klären.
Kennt jemand ein paar Standarttexte, -videos oder -podcasts?
Ich glaube der folgende Links fasst schon vieles zusammen: http://guide.conecta.it/index.php/6._FLOSS-based_business_models
Vielen Dank,
Thomas Koch, http://www.koch.ro
Mein persönlicher liebling (vor allem auch weil auf deutsch) ist [http://www.deshalbfrei.org] insbesondere [http://www.deshalbfrei.org/freiheit/argumente]
lg gerhard
Am 2010-10-12 15:47, schrieb Thomas Koch:
Hallo,
ich hatte heute nach langer Zeit mal wieder mit einem Menschen zu tun, der sich noch überhaupt gar nicht mit dem Thema Freie Software beschäftigt hat und bemerkt, dass ich keine Referenzwebseite kenne auf die ich verweisen kann. Die Vorteile aus Benutzersicht waren sofort einleuchtend, aber die Frage, warum man auch als Entwickler seine Software frei stellen sollte und wie man trotzdem leben könne konnten wir nicht abschließend klären.
Kennt jemand ein paar Standarttexte, -videos oder -podcasts?
Ich glaube der folgende Links fasst schon vieles zusammen: http://guide.conecta.it/index.php/6._FLOSS-based_business_models
Vielen Dank,
Thomas Koch, http://www.koch.ro _______________________________________________ fsfe-de mailing list fsfe-de@fsfeurope.org https://mail.fsfeurope.org/mailman/listinfo/fsfe-de
Hallo Thomas,
ich habe hier noch ein paar Links zum Thema. Vielleicht kennst du sie ja bereits. Sollten aber trotzdem nützlich sein.
- Open Source - Eine Einführung (Galileo Computing- Verlag): http://www.galileocomputing.de/artikel/gp/artikelID-221
- Die Definition Freier Software von GNU.org (mehrsprachig) http://www.gnu.org/philosophy/free-sw.de.html
Die Vorteile aus Benutzersicht waren sofort einleuchtend, aber die
Frage,
warum man auch als Entwickler seine Software frei stellen sollte und
wie man
trotzdem leben könne konnten wir nicht abschließend klären.
Soweit ich mich erinnere haben einige Firmen ehemalig proprietäre Software unter eine freie Lizenz gestellt, um von gewissen damit verbundenen Vorteilen zu profitieren (z.B. neue Nutzer und größere Verbreitung ihrer Produkte). Anschließend boten sie allerhand kommerzielle Dienstleistungen rund um ihre Projekte an und bauten sich eine aktive Community auf, von der sie wiederum auch selbst profitierten.
Viele Linux- Distributoren bieten ebenfalls reichhaltige, teilweise kommerzielle, Zusatznutzen wie z.B. professionellen Support. Allerdings tragen sie zu den zugrunde liegenden Projekten i.d.R. in großem Umfang selbst bei.
Im Gegensatz zum Lizenzgeschäft bei proprietärer Software, schafft die Freiheit von Open-Source-Software neben den eigentlichen Geschäft noch eine ganze Reihe weiterer Vorteile für Anbieter sowie Nutzer und andere. Außerdem belebt es den Markt.
So, ich hoffe das ich dir ein wenig helfen konnte. Norman
Am Dienstag, den 12.10.2010, 15:47 +0200 schrieb Thomas Koch:
Hallo,
ich hatte heute nach langer Zeit mal wieder mit einem Menschen zu tun, der sich noch überhaupt gar nicht mit dem Thema Freie Software beschäftigt hat und bemerkt, dass ich keine Referenzwebseite kenne auf die ich verweisen kann. Die Vorteile aus Benutzersicht waren sofort einleuchtend, aber die Frage, warum man auch als Entwickler seine Software frei stellen sollte und wie man trotzdem leben könne konnten wir nicht abschließend klären.
Kennt jemand ein paar Standarttexte, -videos oder -podcasts?
Ich glaube der folgende Links fasst schon vieles zusammen: http://guide.conecta.it/index.php/6._FLOSS-based_business_models
Vielen Dank,
Thomas Koch, http://www.koch.ro _______________________________________________ fsfe-de mailing list fsfe-de@fsfeurope.org https://mail.fsfeurope.org/mailman/listinfo/fsfe-de
Hallo,
On Tue, Oct 12, 2010 at 03:47:40PM +0200, Thomas Koch wrote:
Die Vorteile aus Benutzersicht waren sofort einleuchtend, aber die Frage, warum man auch als Entwickler seine Software frei stellen sollte
Die Standard-Antwort ist ganz einfach: Weil WIR den Kunden erklären, dass sie nur noch freie Software einsetzen sollten :-)
und wie man trotzdem leben könne
Dazu gibt es einiges an Material im Netz, von sehr unterschiedlicher Qualität.
Sehr fundiert finde ich zum Beispiel die Analysen von Carlo Daffara. Der von Dir selbst verlinkte Artikel stammt übrigens auch von ihm -- im Wesentlichen sind es Auszüge aus diversen Artikeln in seinem Blog. (Der erste Teil ist allerdings von Georg Greve übernommen...) Sein Vortrag auf dem letzten LinuxTag bot wie ich finde eine sehr erhellende Zusammenfassung.
Am interessantesten finde ich den Aspekt, der hier beschrieben wird:
http://carlodaffara.conecta.it/?p=463
Geschäftsmodelle können grundsätzlich auf Eigentumsrechten, oder auf Effizienz basieren (oder einer Mischung aus Beidem). Während proprietäre und halb-freie Anbieter ihr Geschäft zum Teil auf Eigentum aufbauen, setzen komplett freie Anbieter ausschließlich auf Effizienz. Die Entwickler behalten sich in dem Fall keinerlei Eigentumsrechte an dem produzierten Code vor -- aber als Enwickler kennen sie den Code besser als Andere, und sind deshalb in einer besseren Position, um diverse Dienstleistungen anzubieten: Anpassungen, Weiterentwicklung, Schulungen, Einrichtung, Gesammtlösungen, Support, Beratung... Das Verzichten auf Eigentumsrechte fördert dabei die Verbreitung, wodurch Bedarf an Dienstleistungen geschaffen wird -- und kann somit den Umsatz effektiv durchaus steigern.
(Außer der Anbieter ist Quasi-Monopolist, und sieht seine Dominanz kurzfristig auch nicht gefährdet. Es hat schon Gründe, wieso Anbieter wie Microsoft oder Adobe mit aller Macht am proprietären Modell festhalten... Die allermeisten Anbieter sind aber nun mal nicht dominant, sondern müssen sich Marktanteile mühsam erkämpfen -- und dann ist freie Software durchaus ein Geschäftsvorteil.)
Eine interessante Zwischenform sind Anbieter wie RedHat, die sich keine Eigentumsrechte am Code selbst vorbehalten; aber über den geschützten Markennamen trotzdem die freie Verbreitung ihrer Produkte erschweren... Bin mir nicht ganz schlüssig, was ich von solchen Modellen halten soll.
-antrik-
* olafBuddenhagen@gmx.net olafBuddenhagen@gmx.net [2010-10-15 11:31:09 +0200]:
Die Vorteile aus Benutzersicht waren sofort einleuchtend, aber die Frage, warum man auch als Entwickler seine Software frei stellen sollte
Die Standard-Antwort ist ganz einfach: Weil WIR den Kunden erklären, dass sie nur noch freie Software einsetzen sollten :-)
Das ist auch meist meine erste Antwort.
Viele Grüße Matthias
On Monday 18 October 2010 10:56:52 Matthias Kirschner wrote:
- olafBuddenhagen@gmx.net olafBuddenhagen@gmx.net [2010-10-15 11:31:09
+0200]:
Die Vorteile aus Benutzersicht waren sofort einleuchtend, aber die Frage, warum man auch als Entwickler seine Software frei stellen sollte
Die Standard-Antwort ist ganz einfach: Weil WIR den Kunden erklären, dass sie nur noch freie Software einsetzen sollten :-)
Das ist auch meist meine erste Antwort.
Klar, das ist das Argument: Der Kunde möchte es so. Leider wollen viele Kunden es noch nicht so, also ist die Frage: Warum sollte ich meinen Kunden überzeugen das zu verlangen. Teilweise müssen manche Kunden hier sogar teuer aus einer Sackgasse erst wieder herausfahren.
Ein entscheidendes Argument ist: Freie Software senkt im Allgemeinen die gesamten Betriebskosten einer Software-Lösung. Meine Faustregel ist: Um 30%. Von diesem Effizienzgewinn nimmt der Anbieter 10% und gibt den Rest an den Kunden weiter.
Der Hauptgrund für diese höhere Ausbeute ist die geringere Abhängigkeit von einzelnen Anbietern und die damit verbundenen Vorteile. Interessanterweise dreht sich hier auch die Situation um: Freie Software hat viel mehr Eigenschaften einer Software, welche mir selbst gehört, also proprietäre Software, die fühlt sich eigentlich eher nur gemietet an.
Abschnitt 5 hat dazu ein paar wenige Worte und Verweise: http://intevation.de/~bernhard/publications/200408-hmd/200408- wandel_der_it_20j_fs.html
Gruß, Bernhard
Bernhard Reiter reiter@fsfeurope.org schrieb:
Ein entscheidendes Argument ist: Freie Software senkt im Allgemeinen die gesamten Betriebskosten einer Software-Lösung. Meine Faustregel ist: Um 30%. Von diesem Effizienzgewinn nimmt der Anbieter 10% und gibt den Rest an den Kunden weiter.
Mal eine Frage am Rande: Ist das wirklich überzeugend? Ich meine, klar, die Leute lieben konkrete Zahlen, vorallem Prozentzahlen. Aber genauso abschreckend können diese Angaben sein, wenn man Leute überzeugen möchte, die eine Grundausbildung Statistik hinter sich haben.
Gruß Volker
Am Dienstag, 19. Oktober 2010 23:21:31 schrieb Volker Grabsch:
Bernhard Reiter reiter@fsfeurope.org schrieb:
Ein entscheidendes Argument ist: Freie Software senkt im Allgemeinen die gesamten Betriebskosten einer Software-Lösung. Meine Faustregel ist: Um 30%. Von diesem Effizienzgewinn nimmt der Anbieter 10% und gibt den Rest an den Kunden weiter.
Mal eine Frage am Rande: Ist das wirklich überzeugend? Ich meine, klar, die Leute lieben konkrete Zahlen, vorallem Prozentzahlen. Aber genauso abschreckend können diese Angaben sein, wenn man Leute überzeugen möchte, die eine Grundausbildung Statistik hinter sich haben.
Es gibt zwei Teile in dem Argument: 1) Wenn es einen Effizienzgewinn gibt, dann können Kunde und Anbieter davon profitieren. Das scheint mir sehr überzeugend zu sein. Also geht es noch um den zweiten Punkt: 2) Gibt es einen signifikanten Effizientgewinn durch den Einsatz von Freier Software (bei der Entwicklung und überall). Die Statistik sagt ja: http://www.dwheeler.com/oss_fs_why.html#tco und es gibt auch gute Ideen, warum dem so ist.
Wenn ich als Anbieter (Entwickler) das nicht mache, dann macht es mein Kunde mit der Konkurrenz.
Was daran ist denn nicht überzeugend?
Bernhard Reiter reiter@fsfeurope.org schrieb:
Am Dienstag, 19. Oktober 2010 23:21:31 schrieb Volker Grabsch:
Bernhard Reiter reiter@fsfeurope.org schrieb:
Ein entscheidendes Argument ist: Freie Software senkt im Allgemeinen die gesamten Betriebskosten einer Software-Lösung. Meine Faustregel ist: Um 30%. Von diesem Effizienzgewinn nimmt der Anbieter 10% und gibt den Rest an den Kunden weiter.
Mal eine Frage am Rande: Ist das wirklich überzeugend? Ich meine, klar, die Leute lieben konkrete Zahlen, vorallem Prozentzahlen. Aber genauso abschreckend können diese Angaben sein, wenn man Leute überzeugen möchte, die eine Grundausbildung Statistik hinter sich haben.
Es gibt zwei Teile in dem Argument: [...] 2) Gibt es einen signifikanten Effizientgewinn durch den Einsatz von Freier Software (bei der Entwicklung und überall).
Ich fürchte, du hast mich missverstanden. Ich zweifle nicht daran, dass ein Effizienzgewinn vorhanden ist.
Ich zweifle daran, dass die obigen konkreten Worte überzeugend sind, insbesondere der konkrete "Schätzwert" (um es mal nett zu umschreiben) von 30%. Solche (um es jetzt mal fies zu formulieren) "erfundenen" Zahlen können ernste Zweifel an der Seriosität des Argumentierenden wecken - und zwar zu Recht!
Aber wie ich gerade sehe, spielst du damit auf konkrete Studien an, deren Ergebnisse - je nach Jahr und konkreter Software - auf Einsparungen zwischen 19% und 50% kommen:
Die Statistik sagt ja: http://www.dwheeler.com/oss_fs_why.html#tco
Das ging aus der Begriffswahl "Faustregel" nicht so klar hervor. Will sagen, wenn man mit Zahlen jongliert, sollte man vorsichtig sein. Beim Ottonormalverbraucher kommen Aussagen wie "20% besser" und "50% weißer" wohl ganz gut an. Gegenüber Firmen-Chefs und Managern würde ich mir das aber lieber verkneifen, es sei denn, ich kann konkrete Studien und ihre korrekten Zahlenbereiche nennen.
Gruß Volker
Am Mittwoch, 20. Oktober 2010 16:01:46 schrieb Volker Grabsch:
Ich fürchte, du hast mich missverstanden. Ich zweifle nicht daran, dass ein Effizienzgewinn vorhanden ist.
Ich zweifle daran, dass die obigen konkreten Worte überzeugend sind, insbesondere der konkrete "Schätzwert" (um es mal nett zu umschreiben) von 30%. Solche (um es jetzt mal fies zu formulieren) "erfundenen" Zahlen können ernste Zweifel an der Seriosität des Argumentierenden wecken - und zwar zu Recht!
Aber wie ich gerade sehe, spielst du damit auf konkrete Studien an, deren Ergebnisse - je nach Jahr und konkreter Software - auf Einsparungen
zwischen 19% und 50% kommen:
Die Statistik sagt ja: http://www.dwheeler.com/oss_fs_why.html#tco
Das ging aus der Begriffswahl "Faustregel" nicht so klar hervor. Will sagen, wenn man mit Zahlen jongliert, sollte man vorsichtig sein. Beim Ottonormalverbraucher kommen Aussagen wie "20% besser" und "50% weißer" wohl ganz gut an. Gegenüber Firmen-Chefs und Managern würde ich mir das aber lieber verkneifen, es sei denn, ich kann konkrete Studien und ihre korrekten Zahlenbereiche nennen.
Ja, das demonstriert meinen Punkt, es ist eine informiert und belegbar geschätzte Faustregel.
(Wie ich im übrigen gleich erwähnt hatte: Am Montag, 18. Oktober 2010 21:40:06 schrieb Bernhard Reiter:
Abschnitt 5 hat dazu ein paar wenige Worte und Verweise: http://intevation.de/~bernhard/publications/200408-hmd/200408- wandel_der_it_20j_fs.html
Dort wird Herr Wheeler ja zitiert.)
Bernhard Reiter reiter@fsfeurope.org schrieb:
Am Mittwoch, 20. Oktober 2010 16:01:46 schrieb Volker Grabsch:
Aber wie ich gerade sehe, spielst du damit auf konkrete Studien an, deren Ergebnisse - je nach Jahr und konkreter Software - auf Einsparungen zwischen 19% und 50% kommen:
Die Statistik sagt ja: http://www.dwheeler.com/oss_fs_why.html#tco
Das ging aus der Begriffswahl "Faustregel" nicht so klar hervor. Will sagen, wenn man mit Zahlen jongliert, sollte man vorsichtig sein. Beim Ottonormalverbraucher kommen Aussagen wie "20% besser" und "50% weißer" wohl ganz gut an. Gegenüber Firmen-Chefs und Managern würde ich mir das aber lieber verkneifen, es sei denn, ich kann konkrete Studien und ihre korrekten Zahlenbereiche nennen.
Ja, das demonstriert meinen Punkt, es ist eine informiert und belegbar geschätzte Faustregel.
Belegbar ist allerhöchstens eine Spanne zwischen 19% und 50% Kosten- Einsparung.
Aber die "Faustregel von 30%" - wodurch ist diese belegt?
Zumal diese Zahl - ohne weitere Angaben - eine Genauigkeit von +/- 5% suggeriert.
Will sagen, manchmal ist es besser, keine Zahlen zu nennen. Vorallem gegenüber von Leuten, die (mutmaßlich) wissen, was sie tun, und einem diese Dinger links und rechts um die Ohren hauen können.
Gruß Volker
* Volker Grabsch vog@notjusthosting.com [2010-10-21 02:33:24 +0200]:
Aber die "Faustregel von 30%" - wodurch ist diese belegt?
Faustregeln sind meistens durch individuelle Erfahrung belegt. Bernhard hat mit Intevation ja über 15 Jahre Erfahrung in dem Bereich.
Zumal diese Zahl - ohne weitere Angaben - eine Genauigkeit von +/- 5% suggeriert.
Will sagen, manchmal ist es besser, keine Zahlen zu nennen. Vorallem gegenüber von Leuten, die (mutmaßlich) wissen, was sie tun, und einem diese Dinger links und rechts um die Ohren hauen können.
Wenn du die 30% in einem kritischen Gespräch gut begründen kannst, sehe ich kein Problem das in der Kommunikation zu verwenden.
Viele Grüße Matthias
Matthias Kirschner mk@fsfe.org schrieb:
- Volker Grabsch vog@notjusthosting.com [2010-10-21 02:33:24 +0200]:
Aber die "Faustregel von 30%" - wodurch ist diese belegt?
Faustregeln sind meistens durch individuelle Erfahrung belegt. Bernhard hat mit Intevation ja über 15 Jahre Erfahrung in dem Bereich.
Ich möchte wirklich nicht den Wert langjähriger Erfahrung in Abrede stellen. Aber das reicht das beiweitem nicht aus, um konkrete Zahlen zu benennen. Es sei denn, er hat in dieser Zeit viele tausende Umstellungen einer repräsentativen Menge von Firmen begleitet.
Die vielen guten Erfahrungen bei den Umstellungen sind sicher erwähnenswert, aber (an sich) erst einmal nicht auf neue Fälle übertragbar, und sollten klar als rein anekdotisch kommuniziert werden.
Zumal diese Zahl - ohne weitere Angaben - eine Genauigkeit von +/- 5% suggeriert.
Will sagen, manchmal ist es besser, keine Zahlen zu nennen. Vorallem gegenüber von Leuten, die (mutmaßlich) wissen, was sie tun, und einem diese Dinger links und rechts um die Ohren hauen können.
Wenn du die 30% in einem kritischen Gespräch gut begründen kannst, sehe ich kein Problem das in der Kommunikation zu verwenden.
Genau das war meine Frage.
Überzeugt das die Leute? Hören sie dann noch weit genug zu, sodass es zu solchen kritischen Fragen überhaupt noch kommt? Oder schlucken die das sogar unkritisch?
Meine Befürchtung wäre, dass man die Leute in dem Moment verliert, wo man konkrete Zahlen nennt, ohne sofort dazu zu sagen, wo sie herkommen und in welchem Bereich sie schwanken. Also, dass man in dem Moment schon unten durch ist und von da an gar nicht mehr ernst genommen wird.
Zumindest _ich_ würde wahrscheinlich so reagieren, wenn ich nicht schon aus anderen Gründen von Freier Software überzeugt wäre. Aber gut, ich bin auch kein Manager. ;-)
Gruß Volker
Hallo,
On Fri, Oct 22, 2010 at 02:13:54PM +0200, Volker Grabsch wrote:
Meine Befürchtung wäre, dass man die Leute in dem Moment verliert, wo man konkrete Zahlen nennt, ohne sofort dazu zu sagen, wo sie herkommen und in welchem Bereich sie schwanken. Also, dass man in dem Moment schon unten durch ist und von da an gar nicht mehr ernst genommen wird.
Sorry, aber das halte ich ganz ehrlich für paranoid. "Oh nein, er hat eine ZAHL genannt! Ohne gleich ungefragt zehn Minuten darüber zu referieren, wo sie herkommt! Bloß fernhalten von dem..." So denkt doch kein normaler Mensch.
-antrik-
olafBuddenhagen@gmx.net olafBuddenhagen@gmx.net schrieb:
On Fri, Oct 22, 2010 at 02:13:54PM +0200, Volker Grabsch wrote:
Meine Befürchtung wäre, dass man die Leute in dem Moment verliert, wo man konkrete Zahlen nennt, ohne sofort dazu zu sagen, wo sie herkommen und in welchem Bereich sie schwanken. Also, dass man in dem Moment schon unten durch ist und von da an gar nicht mehr ernst genommen wird.
Sorry, aber das halte ich ganz ehrlich für paranoid. "Oh nein, er hat eine ZAHL genannt! Ohne gleich ungefragt zehn Minuten darüber zu referieren, wo sie herkommt! Bloß fernhalten von dem..." So denkt doch kein normaler Mensch.
Sowas meinte ich das gar nicht.
Um es mal auf die Spitze zu treiben: Wenn jemand mit irgendwelche offensichtlich ausgedachten Diagrammen (d.h. idealen Kurvenverläufen) daher kommt, ohne Achsenbeschritung oder sonstwas, dann von irgendwelchen konkreten Leistungsgewinnen spricht, die man gar nicht messen _kann_, und so weiter ... das _stinkt_ doch geradezu nach Scharlertarnerie. Und gerade im Softwarebereich gibt es jede Menge davon.
Gut, davon sind wir noch ein gutes Stück entfernt. Aber ich persönlich finde es wichtig, sich von derlei Geruchsquellen möglichst weit entfernt zu halten.
Gruß Volker
Am Donnerstag, 21. Oktober 2010 02:33:24 schrieb Volker Grabsch:
Belegbar ist allerhöchstens eine Spanne zwischen 19% und 50% Kosten- Einsparung.
Aber die "Faustregel von 30%" - wodurch ist diese belegt?
Durch den Mittelwert der obigen Studien, durch Abschätzung der Vergleichsaufwände der Kosten bei Lizenzmanagement und anderen Dingen.
Zumal diese Zahl - ohne weitere Angaben - eine Genauigkeit von +/- 5% suggeriert.
Will sagen, manchmal ist es besser, keine Zahlen zu nennen. Vorallem gegenüber von Leuten, die (mutmaßlich) wissen, was sie tun, und einem diese Dinger links und rechts um die Ohren hauen können.
Die meisten Leute werden eine Fachdiskussion meiden, da fange ich doch meine Aussage mit einer guten Zahl an. Die "Faustregel" bietet da genügend Rückzugsraum. Wenn immer nur theoretisch geredet wird, spielt das den anderen noch viel mehr in die Hände.
Bernhard Reiter reiter@fsfeurope.org schrieb:
Am Donnerstag, 21. Oktober 2010 02:33:24 schrieb Volker Grabsch:
Belegbar ist allerhöchstens eine Spanne zwischen 19% und 50% Kosten- Einsparung.
Aber die "Faustregel von 30%" - wodurch ist diese belegt?
Durch den Mittelwert der obigen Studien, durch Abschätzung der Vergleichsaufwände der Kosten bei Lizenzmanagement und anderen Dingen.
Ja, was denn nun? :-)
Wenn man die Studien zusammenfasst, kommt man auf 19% - 50%. Wenn Du nur die Zahl "30%" nennst, suggeriert das erstmal einen Bereich von 25% - 35%, was durch die Studien nicht abgedeckt ist.
Und wenn du konkrete Kostenaufstellungen machst, kommst du ebenfalls auf 30%? Das wäre irgendwie ... überraschend. Zumal die je nach Größe der IT-Abteilung ebenfalls stark variieren dürfte.
Und nochmal, ich will hier gar nicht den Nutzen von Erfahrungswerten schmälern. Aber es ist nunmal ein deutlichen Unterschied, ob man sich einen Haufen von Fakten ansieht (bzw. sich daran erinnert) und sich dann eine möglichst plausible Zahl ausdenkt, oder ob man sich hinsetzt und konkrete Modelle durchrechnet.
Und der Begriff "Faustregel" wirkt so, als hättest Du Dir die Mühe für letzteres nicht gemacht. Wenn ich Dir damit Unrecht tue, so möchte ich mich schon einmal vorab dafür entschuldigen. Aber diesen Eindruck erweckt diese Aussage nunmal, und das finde ich alles andere als Überzeugend. (... und hätte wiegesagt Angst, dass man damit Leute eher abschreckt als überzeugt)
Zumal diese Zahl - ohne weitere Angaben - eine Genauigkeit von +/- 5% suggeriert.
Will sagen, manchmal ist es besser, keine Zahlen zu nennen. Vorallem gegenüber von Leuten, die (mutmaßlich) wissen, was sie tun, und einem diese Dinger links und rechts um die Ohren hauen können.
Die meisten Leute werden eine Fachdiskussion meiden, da fange ich doch meine Aussage mit einer guten Zahl an. Die "Faustregel" bietet da genügend Rückzugsraum. Wenn immer nur theoretisch geredet wird, spielt das den anderen noch viel mehr in die Hände.
Das sehe ich genauso. Aber wäre eine Fallstudie mit "echten" Zahlen nicht deutlich besser geeignet?
Gruß Volker
Hallo,
On Fri, Oct 22, 2010 at 02:27:50PM +0200, Volker Grabsch wrote:
[...] Und der Begriff "Faustregel" wirkt so, als hättest Du Dir die Mühe für letzteres nicht gemacht.
Du scheinst entweder misszuverstehen, was eine Faustregel ist; oder worauf das Wort sich in diesem Fall bezieht -- oder Beides.
Faustregel heißt nicht "aus der Luft gegriffen". Eine Faustregel ist eine Regel (durch Berechnungen und/oder Erfahrungswerte bestimmt), mit der man einen groben Richtwert erhalten kann, wenn man (noch) keine genaue Berechnung gemacht hat. In diesem Fall ist es ein Richtwert, von dem man ausgehen kann, bevor man die jeweils spezielle Situation einer Firma analysiert hat, um eine konkretere fallspezifische Zahl zu bestimmen.
-antrik-
Hallo,
On Mon, Oct 18, 2010 at 09:40:06PM +0200, Bernhard Reiter wrote:
- olafBuddenhagen@gmx.net olafBuddenhagen@gmx.net [2010-10-15 11:31:09 +0200]:
Die Vorteile aus Benutzersicht waren sofort einleuchtend, aber die Frage, warum man auch als Entwickler seine Software frei stellen sollte
Die Standard-Antwort ist ganz einfach: Weil WIR den Kunden erklären, dass sie nur noch freie Software einsetzen sollten :-)
Klar, das ist das Argument: Der Kunde möchte es so. Leider wollen viele Kunden es noch nicht so, also ist die Frage: Warum sollte ich meinen Kunden überzeugen das zu verlangen.
Es geht ja nicht darum, dass der Anbieter seine eigenen Kunden von freier Software überzeugen soll... Das machen wir (die FSFE und Konsorten) schon. Den Anbieter müssen wir lediglich davon überzeugen, dass wir seine Kunden überzeugen können :-)
Um das zu bewerkstelligen, müssen wir dem Anbieter natürlich ebenfalls klar machen, warum es für seine Kunden riesige Vorteile hat. (Die teilweise sogar mit den Interessen des Anbieters im Konflikt stehen...) Welche Argumente man *dafür* benutzt, war in diesem Thread allerdings ausdrücklich *nicht* gefragt :-)
-antrik-
* olafBuddenhagen@gmx.net olafBuddenhagen@gmx.net [2010-10-20 06:31:19 +0200]:
Klar, das ist das Argument: Der Kunde möchte es so. Leider wollen viele Kunden es noch nicht so, also ist die Frage: Warum sollte ich meinen Kunden überzeugen das zu verlangen.
Es geht ja nicht darum, dass der Anbieter seine eigenen Kunden von freier Software überzeugen soll... Das machen wir (die FSFE und Konsorten) schon. Den Anbieter müssen wir lediglich davon überzeugen, dass wir seine Kunden überzeugen können :-)
Ganz so einfach ist das leider nicht. Freie-Software-Unternehmen müssen immer noch oft erklären, warum Freie Software besser ist. Aber wir helfen durch unsere Arbeit, dass mehr Leute doch schon etwas zu dem Thema wissen.
Viele Grüße Matthias
Hallo zusammen,
Montag, 18. Oktober 2010, 21:40:06 schrieb Bernhard Reiter:
http://intevation.de/~bernhard/publications/200408-hmd/200408- wandel_der_it_20j_fs.html
sorry für das Off-Topic: Aber hat vielleicht von euch jemand eine Idee, wie man KMail davon überzeugt, Links mit Bindestrichen nicht umzubrechen? Ich mag ansonsten KMail wirklich gerne, aber dieses Verhalten finde ich äußerst lästig.
LG micu
Am Donnerstag 04 November 2010, 17:00:02 schrieb micu:
sorry für das Off-Topic: Aber hat vielleicht von euch jemand eine Idee, wie man KMail davon überzeugt, Links mit Bindestrichen nicht umzubrechen? Ich mag ansonsten KMail wirklich gerne, aber dieses Verhalten finde ich äußerst lästig.
Das ist ein "Feature" seit Qt4.
https://bugs.kde.org/show_bug.cgi?id=163609
Die KMail-Developer sehen sich nicht als zuständig an weil sie nur ein Qt- Widget verwenden und das Widget kein intelligentes Word-Wrapping hat.
Der Bugtracker on Qt ist nicht öffentlich, daher keine Ahnung ob da jemand dran arbeitet.
Gruß, Bernd
Bernd Wurst bernd@bwurst.org schrieb:
Der Bugtracker on Qt ist nicht öffentlich, daher keine Ahnung ob da jemand dran arbeitet.
Ähh ... wie bitte?
Ich reporte schon seit längerem regelmäßig Bugs in Qt, und erhalte meist auch sinnvolle Reaktionen.
Der Bugtracker von Qt ist erreichbar unter:
http://bugreports.qt.nokia.com/
Ich gebe zu, man muss auf der Homepage ein wenig suchen, bis man den Link findet. Aber der Bugtracker ist auf jeden Fall öffentlich!
Gruß Volker
Am Donnerstag, den 04.11.2010, 23:01 +0100 schrieb Volker Grabsch:
Bernd Wurst bernd@bwurst.org schrieb:
Der Bugtracker on Qt ist nicht öffentlich, daher keine Ahnung ob da jemand dran arbeitet.
Ähh ... wie bitte?
Ich reporte schon seit längerem regelmäßig Bugs in Qt, und erhalte meist auch sinnvolle Reaktionen.
Der Bugtracker von Qt ist erreichbar unter:
http://bugreports.qt.nokia.com/Ich gebe zu, man muss auf der Homepage ein wenig suchen, bis man den Link findet. Aber der Bugtracker ist auf jeden Fall öffentlich!
Das kann man an der Stelle auch relativ sehen. Ohne den Tracker an sich wirklich gut zu kennen, fällt durchaus auch sofort auf, dass man einen Account haben muss, damit man auch Bugs reporten kann.
Soll Leute geben, die mit so etwas Probleme haben, ich zähle mich persönlich allerdings nicht dazu. ;)
Gruß, Dominic
Dominic Hopf dmaphy@googlemail.com schrieb:
Am Donnerstag, den 04.11.2010, 23:01 +0100 schrieb Volker Grabsch:
Bernd Wurst bernd@bwurst.org schrieb:
Der Bugtracker on Qt ist nicht öffentlich, daher keine Ahnung ob da jemand dran arbeitet.
Ähh ... wie bitte?
Ich reporte schon seit längerem regelmäßig Bugs in Qt, und erhalte meist auch sinnvolle Reaktionen.
Der Bugtracker von Qt ist erreichbar unter:
http://bugreports.qt.nokia.com/Ich gebe zu, man muss auf der Homepage ein wenig suchen, bis man den Link findet. Aber der Bugtracker ist auf jeden Fall öffentlich!
Das kann man an der Stelle auch relativ sehen. Ohne den Tracker an sich wirklich gut zu kennen, fällt durchaus auch sofort auf, dass man einen Account haben muss, damit man auch Bugs reporten kann.
... und was hat das mit "nicht öffentlich" zu tun?
Gruß Volker
Am Freitag, den 05.11.2010, 09:28 +0100 schrieb Volker Grabsch:
Dominic Hopf dmaphy@googlemail.com schrieb:
Am Donnerstag, den 04.11.2010, 23:01 +0100 schrieb Volker Grabsch:
Bernd Wurst bernd@bwurst.org schrieb:
Der Bugtracker on Qt ist nicht öffentlich, daher keine Ahnung ob da jemand dran arbeitet.
Ähh ... wie bitte?
Ich reporte schon seit längerem regelmäßig Bugs in Qt, und erhalte meist auch sinnvolle Reaktionen.
Der Bugtracker von Qt ist erreichbar unter:
http://bugreports.qt.nokia.com/Ich gebe zu, man muss auf der Homepage ein wenig suchen, bis man den Link findet. Aber der Bugtracker ist auf jeden Fall öffentlich!
Das kann man an der Stelle auch relativ sehen. Ohne den Tracker an sich wirklich gut zu kennen, fällt durchaus auch sofort auf, dass man einen Account haben muss, damit man auch Bugs reporten kann.
... und was hat das mit "nicht öffentlich" zu tun?
Das musst du dann die Leute fragen, die einen Bugtracker als nicht öffentlich ansehen, wenn man nicht anonym Bugs reporten kann. :)
Gruß, Dominic
Hallo Volker.
Am Donnerstag 04 November 2010, 23:01:41 schrieb Volker Grabsch:
Bernd Wurst bernd@bwurst.org schrieb:
Der Bugtracker on Qt ist nicht öffentlich, daher keine Ahnung ob da jemand dran arbeitet.
Ähh ... wie bitte?
Ich reporte schon seit längerem regelmäßig Bugs in Qt, und erhalte meist auch sinnvolle Reaktionen.
Okay, ich habe das zu stark vereinfacht: Im KDE-Bug steht geschrieben, dass der Bug an Nokia reported wurde, aber der Reporter hat von Nokia keine Issue-Number bekommen und es gibt momentan keine Möglichkeit den Status dieses Bugreports bei Nokia zu verfolgen.
Siehe Comment #19 ff im genannten KDE-Bug: https://bugs.kde.org/show_bug.cgi?id=163609#c19
Wenn du Grund zur Annahme hast, dass diese Aussage (die nicht von mir stammt!) falsch ist, setzte bitte einen Kommentar in den KDE-Bugreport mit dem Link auf den Qt-Bug.
Gruß, Bernd
On 11/05/2010 07:49 AM, Bernd Wurst wrote:
Okay, ich habe das zu stark vereinfacht: Im KDE-Bug steht geschrieben, dass der Bug an Nokia reported wurde, aber der Reporter hat von Nokia keine Issue-Number bekommen und es gibt momentan keine Möglichkeit den Status dieses Bugreports bei Nokia zu verfolgen.
Ich wuesste da jemanden mit direktem Kontakt zum Qt-Team.. Olaf? :)
Hallo,
On Fri, Nov 05, 2010 at 09:17:24AM +0100, Alexander Kahl wrote:
On 11/05/2010 07:49 AM, Bernd Wurst wrote:
Okay, ich habe das zu stark vereinfacht: Im KDE-Bug steht geschrieben, dass der Bug an Nokia reported wurde, aber der Reporter hat von Nokia keine Issue-Number bekommen und es gibt momentan keine Möglichkeit den Status dieses Bugreports bei Nokia zu verfolgen.
Ich wuesste da jemanden mit direktem Kontakt zum Qt-Team.. Olaf? :)
Nö, das wäre sinnloser Traffic. Ich finde die Situation ziemlich klar:
------- Comment #34 From Martin Koller 2010-01-07 17:56:06 -------
I entered the same information now again into the new Qt bugtracker. You can follow it here: http://bugreports.qt.nokia.com/browse/QTBUG-7215
-antrik-
olafBuddenhagen@gmx.net olafBuddenhagen@gmx.net schrieb:
On 11/05/2010 07:49 AM, Bernd Wurst wrote:
Im KDE-Bug steht geschrieben, dass der Bug an Nokia reported wurde, [...]
Ohne bestreiten zu wollen, dass da was getan werden sollte, kann ich gut verstehen, dass sich von den Qt-Leuten niemand mit einem Bugreport herumärgern möchte, bei dem sich _solche_ Kommentatoren tummeln:
| I can confirm this using [...]. Very annoying. Please fix it.
*schauder*
Gruß Volker
2010/11/4 Bernd Wurst bernd@bwurst.org:
Am Donnerstag 04 November 2010, 17:00:02 schrieb micu:
sorry für das Off-Topic: Aber hat vielleicht von euch jemand eine Idee, wie man KMail davon überzeugt, Links mit Bindestrichen nicht umzubrechen? Ich mag ansonsten KMail wirklich gerne, aber dieses Verhalten finde ich äußerst lästig.
Das ist ein "Feature" seit Qt4.
https://bugs.kde.org/show_bug.cgi?id=163609
Die KMail-Developer sehen sich nicht als zuständig an weil sie nur ein Qt- Widget verwenden und das Widget kein intelligentes Word-Wrapping hat.
Der Bugtracker on Qt ist nicht öffentlich, daher keine Ahnung ob da jemand dran arbeitet.
Der Qt Bugtracker ist sehr wohl öffentlich: http://bugreports.qt.nokia.com/
Weisst du gerade die Bug-Nummer?
Lieber Gruß, Myriam.
Hallo,
On Mon, Oct 18, 2010 at 10:56:52AM +0200, Matthias Kirschner wrote:
- olafBuddenhagen@gmx.net olafBuddenhagen@gmx.net [2010-10-15 11:31:09 +0200]:
Die Vorteile aus Benutzersicht waren sofort einleuchtend, aber die Frage, warum man auch als Entwickler seine Software frei stellen sollte
Die Standard-Antwort ist ganz einfach: Weil WIR den Kunden erklären, dass sie nur noch freie Software einsetzen sollten :-)
Das ist auch meist meine erste Antwort.
Ja was meinst Du wo ich das her habe? :-)
Natürlich kann man auch mit anderen Argumenten versuchen mühselig spezielle Vorteile für den Anbieter zusammenzukratzen; so wie es Open-Source-Verfechter gerne tun, und wie ich es früher auch immer versucht habe... Aber diese eigentlich naheliegende Antwort ist erstaunlich einfach und einleutend -- warum bin ich nicht selbst darauf gekommen? :-)
-antrik-
olafBuddenhagen@gmx.net olafBuddenhagen@gmx.net schrieb:
On Tue, Oct 12, 2010 at 03:47:40PM +0200, Thomas Koch wrote:
Die Vorteile aus Benutzersicht waren sofort einleuchtend, aber die Frage, warum man auch als Entwickler seine Software frei stellen sollte
Die Standard-Antwort ist ganz einfach: Weil WIR den Kunden erklären, dass sie nur noch freie Software einsetzen sollten :-)
Wenn die Entwickler nicht gerade in tiefster Microsoft- oder Apple- Abhängigkeit stecken, dann könnte auch folgendes Argument ziehen:
Weil euch dann mehr freie Bibliotheken zur Verfügung stehen, auf denen ihr aufbauen könnt.
(In dem Zusammenhang möchte ich nochmal darauf hinweisen, dass die erste Wahl für neue Libraries _nicht_ die LGPL, sondern die GPL bzw. AGPL ist.)
Oder auch:
Weil wir auf den Schultern von Giganten stehen.
(Das muss man dann unter Umständen genauer erklären.)
Gruß Volker
olafBuddenhagen@gmx.net olafBuddenhagen@gmx.net schrieb:
Das Verzichten auf Eigentumsrechte fördert dabei die Verbreitung, wodurch Bedarf an Dienstleistungen geschaffen wird -- und kann somit den Umsatz effektiv durchaus steigern.
Das kann man noch konkretisieren: Es gibt Projekte, die im proprietärem Modell mit einem kleinen Kundenstamm vor sich hin dümpelten, dann zu Freier Software gemacht wurden, und die Entwickler sich plötzlich vor Weiterentwicklungs-Aufträgen nicht mehr retten konnten.
Generell wäre eine "Wir haben's geschafft"-Liste ein nützliches Argument. Leider habe ich keine Ahnung, wie man eine solche aufbauen sollte, also wo man solche Leute/Firmen findet. Ich habe nur durch Zufall von einer oder zwei solcher Firmen erfahren. Beeindruckender wäre eine große Liste von der Sorte:
Wir verdienen unser Geld mit Freier Software: ... ... ...
Eine interessante Zwischenform sind Anbieter wie RedHat, die sich keine Eigentumsrechte am Code selbst vorbehalten; aber über den geschützten Markennamen trotzdem die freie Verbreitung ihrer Produkte erschweren... Bin mir nicht ganz schlüssig, was ich von solchen Modellen halten soll.
"Homesteading the Noosphere", würde ich dazu sagen. [1]
Will sagen, man darf nicht vergessen, dass es neben den 4 Freiheiten und den Lizenzen noch andere soziale Strukturen gibt, die das alles überhaupt zum Funktionieren bringen. Diese sind weniger offen und frei. Das müssen sie auch nicht sein. Möglicherweise _können_ sie es auch gar nicht sein, wenn sie gut funktionieren sollen. Zum Ausgleich gibt es den Wettstreit gegen die (potentiellen) Forks.
Via Markenrecht kann man diese Strukturen nochmals separat schützen und Forks erschweren. Was erstmal nicht so schick ist. Aber wann wird denn schon ein Fork das Original übernehmen? Doch nur dann, wenn die originale Entwicklergruppe eingeschlafen ist oder ziemlichen Mist verbockt hat. Und wenn das Vertrauen in die Entwicklergruppe erstmal gebrochen ist, dann hilft auch die Kontrolle über den (Marken-)Namen nicht mehr viel.
Gruß Volker
http://catb.org/esr/writings/homesteading/homesteading/
Guten Abend zusammen,
On Tuesday 19 October 2010 23:12:29 Volker Grabsch wrote:
Ich habe nur durch Zufall von einer oder zwei solcher Firmen erfahren. Beeindruckender wäre eine große Liste von der Sorte:
Wir verdienen unser Geld mit Freier Software:
Wie waere es mit mal einer Umfage in Xing? Unterstuetzt durch einen Eintrag auf einer (vermutlich besser anderen) Webseite, wo sich interessierte Firmen listen lassen koennen?
Es gibt ja einige solcher "Listen" bereits: Linux-Verband, Lisog e.V., es mag auch noch andere geben...
Betonung muesste meiner unmassgeblichen Meinung nach folgende sein, etwas anders formuliert als oben:
Wir verdienen unser Geld ausschliesslich mit Freier Software.
Ich koennte das unterschreiben, viele andere ebenfalls. Ohne Freie Software und die mir daraus gewonnenen Kenntnisse waere ich schon lange arbeitslos.
In diesem Sinne auch weiterhin: Frohes Schaffen
Johannes
Johannes Hubertz johannes@hubertz.de schrieb:
On Tuesday 19 October 2010 23:12:29 Volker Grabsch wrote:
Wir verdienen unser Geld mit Freier Software:
[...] Wir verdienen unser Geld ausschliesslich mit Freier Software.
Ja, stimmt. Das wäre ein besserer Titel.
Wobei ich in meinem konkreten Fall auf einen interessanten Sonderfall stoße: Was ist mit Auftrags-Programmierung?
Ich arbeite zum Teil an freier und zum Teil an proprietärer Software. Die proprietäre Software ist jedoch im Auftrag für größere Kunden, die diese intern einsetzen. Das heißt, die Kunden habe ziemlich viele Rechte an der Software - wenn's hart auf hart käme, könnten sie bestimmt alle 4 Freiheiten für sich einklagen.
Okay, die 4 Freiheiten würden dann immer noch nicht für _jeden_ gelten, wohl aber für alle tatsächlichen Anwender der Software - nämlich den Kunden bzw. die Kundenfirma selbst.
Rechtlich gesehen geht es hier um die subtilen Unterschiede zwischen einem Werkvertrag (Produkt wird im Auftrag des Kunden angefertigt) und einem Kaufvertrag (Produkt ist bereits fertig und wird vom Kunden lediglich erworben).
Die Frage ist, zählt man sowas dazu oder nicht? Einerseits ist es keine Freie Software, andererseits aber die konkreten Anwender, um die es letztlich geht, alle 4 Freiheiten.
Ich koennte das unterschreiben, viele andere ebenfalls. Ohne Freie Software und die mir daraus gewonnenen Kenntnisse waere ich schon lange arbeitslos.
Kleine Erbsenzählerei, um Missverständnisse zu vermeiden:
Dass man ohne Freie Software arbeitslos wäre, heißt noch lange nicht, dass man ausschließlich mit Freier Software Geld macht - sondern nur, dass man ohne sie kein Geld machen würde. Das ist ein wesentlicher Unterschied.
Beispiel: Ohne Bücher wäre ich auch nicht dort, wo ich heute wäre. Aber das heißt nicht, dass ich mein Geld ausschließlich mit Büchern verdiene. Im Gegenteil: Ich verdiene sogar _gar kein_ Geld mit Büchern, sondern eben mit Softwareentwicklung und Systemadministration.
Gruß Volker
Hallo,
On Wed, Oct 20, 2010 at 12:58:21AM +0200, Volker Grabsch wrote:
Was ist mit Auftrags-Programmierung?
Das ist orthogonal.
Ich arbeite zum Teil an freier und zum Teil an proprietärer Software. Die proprietäre Software ist jedoch im Auftrag für größere Kunden, die diese intern einsetzen.
Ausschließlich intern genutzte Software is generell weder frei noch proprietär -- da sie nicht weitervertrieben wird, greift die Unterscheidung gar nicht erst. Der Kunde besitzt in solchen Fällen in der Regel (fast) alle Rechte an der Software -- und er kann sich ja nicht selbst in seiner Freiheit einschränken... Es steht ihm sogar frei, die Software unter der GPL weiterzugeben, wenn er so lustig ist.
Das ist eines der häufigsten Missverständnisse über freie Software...
Okay, die 4 Freiheiten würden dann immer noch nicht für _jeden_ gelten,
Die gelten auch bei der GPL nicht für Jeden -- sondern nur für diejenigen, die auf legale Weise eine Kopie erhalten haben :-)
-antrik-
olafBuddenhagen@gmx.net olafBuddenhagen@gmx.net schrieb:
On Wed, Oct 20, 2010 at 12:58:21AM +0200, Volker Grabsch wrote:
Was ist mit Auftrags-Programmierung?
[...]
Die proprietäre Software ist jedoch im Auftrag für größere Kunden, die diese intern einsetzen.
Ausschließlich intern genutzte Software is generell weder frei noch proprietär -- da sie nicht weitervertrieben wird, greift die Unterscheidung gar nicht erst. [...]
Dennoch stellt sich auch bei solchen Projekten die Frage, ob es sinnvoll ist, möglichst große Teile als Freie Software zu veröffentlichen. Also solche Teile, die nicht zu speziell sind und daher auch für andere interessant sein könnten.
Eric S. Raymond hatte einmal in einem Artikel [1] argumentiert, dass genau das für haus-interne Softwareprojekte sinnvoll sei.
Gruß Volker
[1] den ich leider nicht wiederfinden kann ... das muss irgendwo in oder um "The Cathedral and the Bazaar" zu finden sein
Hallo,
On Wed, Oct 20, 2010 at 02:17:08PM +0200, Volker Grabsch wrote:
olafBuddenhagen@gmx.net olafBuddenhagen@gmx.net schrieb:
Ausschließlich intern genutzte Software is generell weder frei noch proprietär -- da sie nicht weitervertrieben wird, greift die Unterscheidung gar nicht erst. [...]
Dennoch stellt sich auch bei solchen Projekten die Frage, ob es sinnvoll ist, möglichst große Teile als Freie Software zu veröffentlichen. Also solche Teile, die nicht zu speziell sind und daher auch für andere interessant sein könnten.
Klar -- wenn Teile wiederverwendbar sind, macht es Sinn, die zu veröffentlichen... Aber deswegen ist nicht veröffentlichte Software noch lange nicht unfrei -- das wollte ich nur noch mal ganz deutlich klarstellen :-)
-antrik-
Am Mittwoch, 20. Oktober 2010 00:58:21 schrieb Volker Grabsch:
Wobei ich in meinem konkreten Fall auf einen interessanten Sonderfall stoße: Was ist mit Auftrags-Programmierung?
Das kommt für mich darauf an, was der Auftraggeber mit der Software macht. Insofern kann das tatsächlich Arbeit an proprietärer Software sein.
Ich arbeite zum Teil an freier und zum Teil an proprietärer Software. Die proprietäre Software ist jedoch im Auftrag für größere Kunden, die diese intern einsetzen. Das heißt, die Kunden habe ziemlich viele Rechte an der Software - wenn's hart auf hart käme, könnten sie bestimmt alle 4 Freiheiten für sich einklagen.
Okay, die 4 Freiheiten würden dann immer noch nicht für _jeden_ gelten, wohl aber für alle tatsächlichen Anwender der Software - nämlich den Kunden bzw. die Kundenfirma selbst.
Ich bemerke, das Produkte oder Komponenten, wenn sie gut sind, so entwicklet worden sind, dass sie Freie Software Komponenten nutzen und selbst auch gute Komponenten werden und Schnittstellen enthalten. Sprich: Ein typisches Freie Software Produkt wird anders entwickelt.
Hallo,
On Tue, Oct 19, 2010 at 11:43:35PM +0200, Johannes Hubertz wrote:
Betonung muesste meiner unmassgeblichen Meinung nach folgende sein, etwas anders formuliert als oben:
Wir verdienen unser Geld ausschliesslich mit Freier Software.
Warum willst Du Leute/Firmen ausschließen, die zusätzlich auf anderen Wegen Geld verdienen? Es geht ja schließlich nur darum zu zeigen, dass es profitabel sein kann -- Exklusivität scheint mir da eher irrelevant...
Andererseits denke ich dass die Formulierung wahrscheinlich zusätzlicher Erläuterungen bedarf: Schließlich behauten ja einige "Open Core"-Anbieter von sich ja auch, mit freier Software (bzw. in dem Fall eher "Open Source") Geld zu verdienen. Ist natürlich Quatsch, da in dem Fall die freie Version nur ein Lockmittel ist -- der tatsächliche Umstatz/Gewinn wird mit der proprietären Version generiert, und die Kunden haben nix von der angeblichen Freiheit... Trotzdem sollte man das klarstellen.
-antrik-
olafBuddenhagen@gmx.net olafBuddenhagen@gmx.net schrieb:
On Tue, Oct 19, 2010 at 11:43:35PM +0200, Johannes Hubertz wrote:
Betonung muesste meiner unmassgeblichen Meinung nach folgende sein, etwas anders formuliert als oben:
Wir verdienen unser Geld ausschliesslich mit Freier Software.
Warum willst Du Leute/Firmen ausschließen, die zusätzlich auf anderen Wegen Geld verdienen? Es geht ja schließlich nur darum zu zeigen, dass es profitabel sein kann -- Exklusivität scheint mir da eher irrelevant...
Exklusivität ist insofern interessant, weil sie klar macht, dass die Leute wirklich davon leben, und nicht dass es ein marginaler Mini- Profit in einem ganz anderen Geschäft ist. Oder - schlimmer noch - dass sie ihre Freie Software quersubventionieren, es also korrekterweise heißen müsste: "Wir verdienen unser Geld _trotz_ Freier Software". ;-)
Andererseits denke ich dass die Formulierung wahrscheinlich zusätzlicher Erläuterungen bedarf: Schließlich behauten ja einige "Open Core"-Anbieter [...]
Mit der obigen Formulierung könnten derartige Missverständnisse erst gar nicht auftreten. Aber wenn man mehr Leute ins Boot holen möchte, könnte man auch sagen:
Wir verdienen unser Geld hauptsächlich mit Freier Software.
Das würde Open-Core-Anbieter ebenfalls ausschließen, da die ihr Geld _hauptsächlich_ mit proprietärer Software machen.
Gruß Volker
Hallo,
On Wed, Oct 20, 2010 at 02:23:00PM +0200, Volker Grabsch wrote:
olafBuddenhagen@gmx.net olafBuddenhagen@gmx.net schrieb:
On Tue, Oct 19, 2010 at 11:43:35PM +0200, Johannes Hubertz wrote:
Wir verdienen unser Geld ausschliesslich mit Freier Software.
[...]
Andererseits denke ich dass die Formulierung wahrscheinlich zusätzlicher Erläuterungen bedarf: Schließlich behauten ja einige "Open Core"-Anbieter [...]
Mit der obigen Formulierung könnten derartige Missverständnisse erst gar nicht auftreten.
Naja, ich bin halt nicht sicher, ob "Open Core"-Anbieter nicht selbst das verdrehen würden, als "wir verdienen unser Geld ausschließlich mit einem Geschäftsmodell, das in gewisser Hinsicht auf freier Software aufbaut"...
Naja, vielleicht ist das zu weit hergeholt. Im Zweifelsfall muss man denen halt einfach sagen, dass sie da was missverstanden haben. Wahrscheinlich müssen eh alle Anwärter einzeln geprüft werden, um böse Überraschungen zu vermeiden...
-antrik-
Hallo,
On Tue, Oct 19, 2010 at 11:12:29PM +0200, Volker Grabsch wrote:
olafBuddenhagen@gmx.net olafBuddenhagen@gmx.net schrieb:
Eine interessante Zwischenform sind Anbieter wie RedHat, die sich keine Eigentumsrechte am Code selbst vorbehalten; aber über den geschützten Markennamen trotzdem die freie Verbreitung ihrer Produkte erschweren... Bin mir nicht ganz schlüssig, was ich von solchen Modellen halten soll.
"Homesteading the Noosphere", würde ich dazu sagen. [1]
Nee, nicht wirklich. ESR spricht zwar in seinem Aufsatz von "property" -- aber Prestige ist kein handelbarer Besitz, der direkt zu Gewinn gemacht werden kann. Prestige dient bei kommerziellen Anbietern freier Software lediglich als Aushängeschild, um die vom Anbieter angebotene Effizienz zu bestätigen.
RedHat verkauft bei seinen Support-Verträgen aber eben nicht nur seine Effizienz, sondern auch die offiziellen Installationsmedien für RHEL; und durch das Branding wird verhindert, dass diese in größerem Umfang weitervertrieben werden können. Dafür muss man sich stattdessen an Debranding-Projekte wie CentOS wenden -- was zwar technisch keine allzu große Hürde ist, aber psychologisch schon.
(Die konkreten psychologischen Ursachen dafür kann ich leider nicht aufzeigen -- aber ich bin mir ziemlich sicher, dass das nichts unmittelbar mit dem Prestige der beschäftigten Programmierer zu tun hat...)
Via Markenrecht kann man diese Strukturen nochmals separat schützen und Forks erschweren.
Das ist eine ganz andere Frage. Natürlich ist das Verwenden des ursprünglichen Namens bei einem Fork ein sehr unerwünschtes Verhalten -- egal ob es ein kommerzielles oder ein freiwilliges Projekt ist. (Und der Aufsatz erläutert sehr gut, warum das so ist.) Den Namen als Marke zu schützen, ist da absolut legitim. Es hat aber nichts mit dem erwähnten Geschäftsmodell von RedHat zu tun.
-antrik-
Am Dienstag, 19. Oktober 2010 23:12:29 schrieb Volker Grabsch:
Generell wäre eine "Wir haben's geschafft"-Liste ein nützliches Argument. Leider habe ich keine Ahnung, wie man eine solche aufbauen sollte, also wo man solche Leute/Firmen findet. Ich habe nur durch Zufall von einer oder zwei solcher Firmen erfahren.
Zope Corp. ist so ein Unternehmen, wenn ich mich richtig entsinne.
Volker Grabsch:
Generell wäre eine "Wir haben's geschafft"-Liste ein nützliches Argument. Leider habe ich keine Ahnung, wie man eine solche aufbauen sollte, also wo man solche Leute/Firmen findet. Ich habe nur durch Zufall von einer oder zwei solcher Firmen erfahren. Beeindruckender wäre eine große Liste von der Sorte:
Wir verdienen unser Geld mit Freier Software: ... ... ...
Hallo,
erstmal vielen Dank an alle, die zu diesem hochinteressanten Thread beigetragen haben!
Ich habe auch noch ein wenig gesucht und folgende Leseliste zum Thema erstellt:
ich habe ein paar grundlegende Texte zum Thema Freie Software zusammengesucht. Ich habe die Texte noch nicht alle gelesen, teilweise nur überflogen. Wer das "Executive Summary" haben will (für die wichtigen Leute mit wenig Zeit :-) muss noch etwas warten.
Vorher noch die versprochene Schlagfertige Antwort auf die Frage, was denn wäre, wenn Microsoft meine Freie Software nähme und verkaufen würde:
a) Wie sollte Microsoft eine Software verkaufen, die jeder kostenlos im Internet herunterladen darf? Microsoft müsste sich also schon etwas ausdenken, wofür jemand bereit wäre Geld zu bezahlen.
b) Angenommen, durch Microsofts bemühungen wird meine Freie Software (auch unter anderem Namen und leicht modifiziert) tatsächlich populär, dann
b1) Kann ich mir Änderungen nehmen, die Microsoft vorgenommen hat und wieder in meine Version integrieren, profitiere also von Microsofts Arbeit.
b2) Hat Microsoft eine große Benutzerbasis geschaffen die mir jetzt alle als potentielle Kunden für Supportdienstleistungen zur Verfügung stehen.
b3) Vielleicht fange ich aber auch einfach an, bei Microsoft zu arbeiten (rein hypothetisch natürlich!), denn ich bin ja der beste Experte für die von mir entwickelte Freie Software, die Microsoft vertreibt. - Ich kann auch jederzeit wieder kündigen und dann sogar die Weiterentwicklungen, die ich im Hause Microsoft an meiner Freien Software gemacht habe, weiter benutzen. Denn die ursprüngliche Lizenz gilt auch für alle abgeleiteten Werke.
Nur die Leseliste:
* Geschäftsmodelle basierend auf Freier Software: http://guide.conecta.it/index.php/6._FLOSS-based_business_models
* Open Source - Eine Einführung (Galileo Computing- Verlag): http://www.galileocomputing.de/artikel/gp/artikelID-221
* Die Open Source Jahrbücher 2004-2008 der TU Berlin: http://www.opensourcejahrbuch.de/
Die Jahrbücher bestehen jeweils aus einzelnen Essays rund um Freie Software. Ein paar Essays zum Thema:
Open Source Jahrbuch 2004, Kapitel 2 - Ökonomie:
* Alles aus Spaß? Zur Motivation von Open-Source-Entwicklern http://www.opensourcejahrbuch.de/download/jb2004/chapter_02/AllesAusSpass
* Open Source-Geschäftsmodelle http://www.opensourcejahrbuch.de/download/jb2004/chapter_02/OSSGeschaeftsmodelle
Open Source Jahrbuch 2004, Kapitel 5 - Gesellschaft
* Open Source im Kapitalismus: Gute Idee - falsches System? http://www.opensourcejahrbuch.de/download/jb2004/chapter_05/OpenSourceImKapitalismus
Open Source Jahrbuch 2007
* Open Source - ein aufstrebendes ökonomisches Modell http://www.opensourcejahrbuch.de/download/jb2007/osjb2007-02-03-perens.pdf
* Entwicklung von Open-Source-Software: Kostenrelevante Eigenschaften einer ungewöhnlichen Organisationsform http://www.opensourcejahrbuch.de/download/jb2007/osjb2007-03-02- bitzerschroeder.pdf
Open Source Jahrbuch 2008
* Unternehmen zwischen Offenheit und Profitstreben http://www.opensourcejahrbuch.de/download/jb2008/west-unternehmen.pdf
Thomas Koch, http://www.koch.ro
Thomas Koch thomas@koch.ro schrieb:
Vorher noch die versprochene Schlagfertige Antwort auf die Frage, was denn wäre, wenn Microsoft meine Freie Software nähme und verkaufen würde:
a) Wie sollte Microsoft eine Software verkaufen, die jeder kostenlos im Internet herunterladen darf? Microsoft müsste sich also schon etwas ausdenken, wofür jemand bereit wäre Geld zu bezahlen.
Du argumentierst hier damit, dass Microsoft einfallslos sei, nach dem Motto: "Ich kann mit nicht vorstellen, wie man mit einem frei verfügbaren Gut Geld machen kann, also schafft es auch Microsoft nicht." Solch eine Argumentationslinie ist vielleicht schlagfertig, aber nicht sehr überzeugend.
Zumal es durchaus Leute gab, die es geschafft haben, Freie Software überteuert zu verkaufen - besonders prominent ist der Fall bezüglich OpenOffice. Dazu gab es erst kürzlich einen Thread auf dieser Liste, vielleicht hilft der Dir weiter?
b) Angenommen, durch Microsofts bemühungen wird meine Freie Software (auch unter anderem Namen und leicht modifiziert) tatsächlich populär, dann
b1) Kann ich mir Änderungen nehmen, die Microsoft vorgenommen hat und wieder in meine Version integrieren, profitiere also von Microsofts Arbeit.
Das gilt erstmal nur für Copyleft-Lizenzen, also "virale" Lizenzen. Dies ist nicht verkehrt, aber man sollte darauf hinweisen, oder von vornherein die Fragestellung auf Copyleft- oder gar nur GPL-lizensierte Software einschränken.
Außerdem: Was ist, wenn Microsofts Änderungen gar keinen einen Mehrwert darstellen. Was ist, wenn stattdessen nur eine Spyware mit eingebaut wird? Oder ein nichtportables Feature, das nur in der Windows-Version der Software funktioniert.
(Auch das wäre IMHO kein Problem, aber man sollte begründen, warum das kein Problem ist.)
b2) Hat Microsoft eine große Benutzerbasis geschaffen die mir jetzt alle als potentielle Kunden für Supportdienstleistungen zur Verfügung stehen.
Was ist, wenn Microsoft Dich von dem Produkt verdrängt, indem sie allen Kunden erfolgreich einreden, man könne nur von Microsoft ernsthaften Support für das Produkt erhalten?
Bedenke: Auch bei proprietärer Software ist Microsoft sehr gut darin, andere vom Markt zu verdrängen, indem es deren proprietäre Software einfach nachbaut. Bei Freier Software müssen sie es noch nicht einmal nachbauen.
b3) Vielleicht fange ich aber auch einfach an, bei Microsoft zu arbeiten (rein hypothetisch natürlich!), denn ich bin ja der beste Experte für die von mir entwickelte Freie Software, die Microsoft vertreibt.
Was aber eine ebenso große Gefahr sein kann, da Dich Microsoft dann z.B. dazu zwingen (oder Dich entsprechend kaufen könnte), um die Software im nächsten Schritt proprietär zu machen.
(Auch hier gibt es übrigens einen einfachen Schutzmechanismus, den man allerdings erwähnen sollte.)
- Ich kann auch
jederzeit wieder kündigen und dann sogar die Weiterentwicklungen, die ich im Hause Microsoft an meiner Freien Software gemacht habe, weiter benutzen. Denn die ursprüngliche Lizenz gilt auch für alle abgeleiteten Werke.
Der Arbeitgeber hat grundsätzliche Rechte an allem, was Du in deiner Arbeitszeit leistest. Du müsstest einen expliziten "Freibrief" bei Microsoft durchsetzen, z.B. in Deinem Arbeitsvertrag, damit das anders wird.
Im Zweifelsfall würde das nicht bedeuten, dass Du die Änderungen nutzen darfst, sondern dass _niemand_ die Änderungen nutzen darf, also Deine gesamte Arbeitszeit bei Microsoft "verschwendet" wäre. (Naja, zumindest hast Du Geld dafür erhalten. :-))
Gruß Volker
Am Montag, 25. Oktober 2010 17:30:23 schrieb Volker Grabsch:
Das gilt erstmal nur für Copyleft-Lizenzen, also "virale" Lizenzen.
"Viral" ist wirklich ein unpassendes Wort dafür, denn die Lizenz "infiziert" keine anderen Werke. Es geht nur um abgeleitete Werke. Und hier sind die proprietären Lizenzen auch gern mal problematisch, am Ende muss ich hier auch die Lizenz genau prüfen. Da ist mir doch eine der gut verstandenen Standardlizenzen der Freien Software, viel lieber.
Eigentlich ist eine Freie Software Lizenz oft eine Impfung gegen unfreie Tendenzen, also eine Lizenz mit starkem oder schwachem Schutz der Freiheit.
Bernhard Reiter reiter@fsfeurope.org schrieb:
Am Montag, 25. Oktober 2010 17:30:23 schrieb Volker Grabsch:
Das gilt erstmal nur für Copyleft-Lizenzen, also "virale" Lizenzen.
"Viral" ist wirklich ein unpassendes Wort dafür, denn die Lizenz "infiziert" keine anderen Werke. Es geht nur um abgeleitete Werke.
Ja, der Begriff politisch gesehen auf jeden Fall unpassend, da Copyleft- Lizenzen etwas sehr Positives sind, während "viral" ein negatives Schlagwort der Freie-Software-Gegner ist.
Dennoch: Wenn ich ein großes Projekt habe, in welchem ich - neben vielen anderen Libraries - auch eine kleine GPL-lizensierte Library verwende, dann schlägt deren Lizenz durch auf das komplette Projekt.
Natürlich ist auch das immer noch keine "Infektion", da das Projekt ja die freie Wahl hatte, diese Library zu verwenden oder von vornherein auf diese zu verzichten. Wenn jedoch eine frühere Version der Library kein starkes Copyleft hatte, und plötzlich die neue Version unter GPL steht, dann hat das Projekt ein Problem. Es hat wahrscheinlich nicht die Resourcen, auf eine alternative Library umzusteigen oder die alte Version der Library selbst weiter zu pflegen.
In einem gewissen Sinne wäre das Projekt nun zur einer Umlizensierung nach GPL "gezwungen". Das heißt, die neue Version der Library hätte eine Lizenzänderung des gesamten Projektes erzwungen.
Beim ExtJS-Projekt gab es genau deswegen viel Kritik, als sie vor einiger Zeit plötzlich ihre Lizenz von einer LGPL+Zusatzklausel nach GPL geändert hatten.
(Allerdings muss man bei ExtJS dazu sagen, dass es hier nicht darum ging, dass alle Anwendungen Freie Software sind. Sie fahren ein Doppel- lizensierungs-Modell, und es ging einfach darum, den Anteil der zahlenden Kundschaft zu erhöhen.)
Und hier sind die proprietären Lizenzen auch gern mal problematisch, am Ende muss ich hier auch die Lizenz genau prüfen.
Gab es nicht auch proprietäre Compiler, bei denen der Hersteller Bedingungen an den damit generiertem Code geknüpft hat? Also, dass mit der kostenlosen Version des Compilers die erzeugten Binaries nur nichtkommerziell vertrieben werden dürfen, oder sowas?
_Das_ würde ich sogar eher als "viral" bezeichnen. ;-)
Eigentlich ist eine Freie Software Lizenz oft eine Impfung gegen unfreie Tendenzen, also eine Lizenz mit starkem oder schwachem Schutz der Freiheit.
Das ist auch ein nettes Bild.
Gruß Volker
Hallo,
On Tue, Oct 26, 2010 at 10:21:10AM +0200, Volker Grabsch wrote:
In einem gewissen Sinne wäre das Projekt nun zur einer Umlizensierung nach GPL "gezwungen". Das heißt, die neue Version der Library hätte eine Lizenzänderung des gesamten Projektes erzwungen.
Das stimmt so nicht. Es ist zwar richtig, dass die Gesamtheit unter GPL-Bedingungen zur Verfuegung stehen muss -- aber das erfordert nicht unbedingt eine Lizenzaenderung des nicht-GPL-Codes. Der Code kann weiterhin unter einer anderen Lizenz verbleiben. (Solange diese GPL-kompatibel ist...)
-antrik-
* Bernhard Reiter reiter@fsfeurope.org [2010-10-26 09:37:39 +0200]:
Am Montag, 25. Oktober 2010 17:30:23 schrieb Volker Grabsch:
Das gilt erstmal nur für Copyleft-Lizenzen, also "virale" Lizenzen.
"Viral" ist wirklich ein unpassendes Wort dafür, denn die Lizenz "infiziert" keine anderen Werke. Es geht nur um abgeleitete Werke. Und hier sind die proprietären Lizenzen auch gern mal problematisch, am Ende muss ich hier auch die Lizenz genau prüfen. Da ist mir doch eine der gut verstandenen Standardlizenzen der Freien Software, viel lieber.
Eigentlich ist eine Freie Software Lizenz oft eine Impfung gegen unfreie Tendenzen, also eine Lizenz mit starkem oder schwachem Schutz der Freiheit.
Freie-Software-Befürworter sollten möglichst von impfen, statt von viral oder infiziert sprechen. Hab das gerade in meinem Eintrag "Dradio Wissen: Freie-Software-Lizenzen" in meinem Blog http://blogs.fsfe.org/mk/?p=679 und auf Netzpolitik http://www.netzpolitik.org/2010/dradio-wissen-freie-software-lizenzen/ auch wieder so verwendet.
Viele Grüße Matthias
Matthias Kirschner mk@fsfe.org schrieb:
- Bernhard Reiter reiter@fsfeurope.org [2010-10-26 09:37:39 +0200]:
Am Montag, 25. Oktober 2010 17:30:23 schrieb Volker Grabsch:
Das gilt erstmal nur für Copyleft-Lizenzen, also "virale" Lizenzen.
"Viral" ist wirklich ein unpassendes Wort dafür, denn die Lizenz "infiziert" keine anderen Werke. Es geht nur um abgeleitete Werke. Und hier sind die proprietären Lizenzen auch gern mal problematisch, am Ende muss ich hier auch die Lizenz genau prüfen. Da ist mir doch eine der gut verstandenen Standardlizenzen der Freien Software, viel lieber.
Eigentlich ist eine Freie Software Lizenz oft eine Impfung gegen unfreie Tendenzen, also eine Lizenz mit starkem oder schwachem Schutz der Freiheit.
Freie-Software-Befürworter sollten möglichst von impfen, statt von viral oder infiziert sprechen. Hab das gerade in meinem Eintrag "Dradio Wissen: Freie-Software-Lizenzen" in meinem Blog http://blogs.fsfe.org/mk/?p=679 und auf Netzpolitik http://www.netzpolitik.org/2010/dradio-wissen-freie-software-lizenzen/ auch wieder so verwendet.
Wobei man "impfen" auch im weiteren Sinne sehen kann.
Zunächst natürlich durch Wahl einer strengen Lizenz wie GPL oder AGPL. Aber darüberhinaus auch durch entsprechende Verteilung / Verschiebung der Urheberschaft. Dadurch schützt man sich und das Projekt davor, erpressbar zu werden. Große Teile (A)GPL basieren auf der Idee "lieber tot als unfrei", sodass unangenehme Zeitgenossen erst gar nicht auf dumme Ideen kommen. Diese Strategie kann man weiter ausbauen.
Mir sind folgende Methoden für eine solche "erweiterte Impfung" eingefallen:
1) Abhängigkeit von einer GPL-Library
Man könnte das Projekt von vornherein auf eine GPL-lizensierte Library aufbauen, die später nicht ohne großen Aufwand ausgetauscht werden kann. So kann man immer sagen: "Also, _ich_ würde das ja gern anders lizensieren, aber dann müssten wir diese schicke Komponente ersetzen - ist das wirklich den Aufwand wert?"
2) Möglichst viele Urheber
Man könnte jedem Patch - auch kleine, triviale Patches - zum Anlass nehmen, die Autorenliste zu vergrößern. Eine große Autorenliste macht ohnehin mehr Eindruck. ;-) Und man kann dann immer sagen: "Also, _ich_ würde das ja gern anders lizensieren, aber da müssten alle anderen zustimmen. Oder wir müssten nachträglich allen Code entfernen, den bestimmte Personen beigesteuert haben. Ist das wirklich den Aufwand wert?"
3) Gemeinnützige Organisation als Urheber
Diese Form der Impfung ist vorallem durch das GNU-Projekt bekannt geworden, da dort jeder Kontributor seine Rechte an die FSF abgibt. Der Vorteil ist, dass sich unangenehme Zeitgenossen statt mit einem Individuum nun mit einer auf Freie Software spezialisierten Organisation anlegen müssten. Der Nachteil ist jedoch, dass dies allein nicht davor schützt, dass andere (z.B. Arbeitgeber) einen Anspruch auf die Verwertungsrechte erheben, wodurch die Übertragung an die FSF nichtig wird. Daher nenne ich diese Methode zuletzt.
Darüber hinaus gibt es auch eine Anti-Methode:
A1) Hauptentwickler als alleinige(r) Urheber
In einigen Projekten besteht der Hauptentwickler bzw. das Kernteam darauf, dass alle Kontributoren die Rechte an Ihren Zuarbeiten abgeben an den/die Hauptentwickler. Das sieht man vorallem bei Projekten, die von der kritikwürdigen Dual-Licensing-Strategie gebrauch machen. Diese Methode sieht zunächst so ähnlich aus wie das, was das GNU-Projekt auch macht (siehe Methode 3)). Allerdings wird in diesem Fall das genaue Gegenteil erreicht, denn es ist eine Negation der Methode 2). Was für Gefahren das im Ernstfall mit sich bringen kann, sieht man sehr deutlich bei der Übernahme von Sun durch Oracle.
Gruß Volker
* Volker Grabsch vog@notjusthosting.com [2010-10-26 16:39:16 +0200]:
Möglichst viele Urheber
Man könnte jedem Patch - auch kleine, triviale Patches - zum Anlass nehmen, die Autorenliste zu vergrößern. Eine große Autorenliste macht ohnehin mehr Eindruck. ;-) Und man kann dann immer sagen: "Also, _ich_ würde das ja gern anders lizensieren, aber da müssten alle anderen zustimmen. Oder wir müssten nachträglich allen Code entfernen, den bestimmte Personen beigesteuert haben. Ist das wirklich den Aufwand wert?"
Die Möglichkeit zur Relizenzierung sollte man sich immer offen halten. Es kann z.B. ja sein, dass man gerne von GNU GPLv2 auf v3 gehen will. Deshalb empfehlen und beraten wir zu unserem Fiduciary Licence Agreement (FLA) http://www.fsfe.org/projects/ftf/fla.de.html.
Viele Grüße Matthias
On 10/26/2010 04:43 PM, Matthias Kirschner wrote:
Die Möglichkeit zur Relizenzierung sollte man sich immer offen halten. Es kann z.B. ja sein, dass man gerne von GNU GPLv2 auf v3 gehen will. Deshalb empfehlen und beraten wir zu unserem Fiduciary Licence Agreement (FLA) http://www.fsfe.org/projects/ftf/fla.de.html.
Huch? Ich dachte bisher immer, das deutsche Urheberrecht sei per se nicht uebertragbar (was ja auch unlogisch waere), nur die daraus erwachsenden Recht - dies wurde auch schon oft als Begruendung fuer internationale Rechtsschwierigkeiten aufgefuehrt, ein Fall faellt mir da sogar ganz konkret ein. Wie funktioniert die FLA? Bitte erleuchtet mich!
Hallo Alex,
* Alexander Kahl e-user@fsfe.org [2010-10-26 17:04:38 +0200]:
Huch? Ich dachte bisher immer, das deutsche Urheberrecht sei per se nicht uebertragbar (was ja auch unlogisch waere), nur die daraus erwachsenden Recht - dies wurde auch schon oft als Begruendung fuer internationale Rechtsschwierigkeiten aufgefuehrt, ein Fall faellt mir da sogar ganz konkret ein. Wie funktioniert die FLA?
Hast Du Dir http://www.fsfe.org/projects/ftf/FLA.en.pdf schon durchgelesen?
Außerdem gabs zwei Pressemitteilungen dazu:
- [FSFE PR][DE] Die FSFE begrüßt die Einführung der 'Treuhänderischen Lizenzvereinbarung' (FLA) durch KDE e.V. http://mail.fsfeurope.org/pipermail/press-release-de/2008q3/000128.html - [FSFE PR][EN] FSFE releases solution for projects wishing to increase their legal strength http://mailman.fsfeurope.org/pipermail/press-release/2007q1/000168.html
Hilft das für die Erleuchtung? ;)
Viele Grüße Matthias
Matthias Kirschner mk@fsfe.org schrieb:
- Volker Grabsch vog@notjusthosting.com [2010-10-26 16:39:16 +0200]:
Möglichst viele Urheber
Man könnte jedem Patch - auch kleine, triviale Patches - zum Anlass nehmen, die Autorenliste zu vergrößern. Eine große Autorenliste macht ohnehin mehr Eindruck. ;-) Und man kann dann immer sagen: "Also, _ich_ würde das ja gern anders lizensieren, aber da müssten alle anderen zustimmen. Oder wir müssten nachträglich allen Code entfernen, den bestimmte Personen beigesteuert haben. Ist das wirklich den Aufwand wert?"
Die Möglichkeit zur Relizenzierung sollte man sich immer offen halten. Es kann z.B. ja sein, dass man gerne von GNU GPLv2 auf v3 gehen will. Deshalb empfehlen und beraten wir zu unserem Fiduciary Licence Agreement (FLA) http://www.fsfe.org/projects/ftf/fla.de.html.
Im Falle von GPL-Projekten dürfte doch die übliche "GPL v3 or later"- Klausel völlig ausreichen, oder?
Gruß Volker
Am Dienstag, 26. Oktober 2010 19:50:38 schrieb Volker Grabsch:
Die Möglichkeit zur Relizenzierung sollte man sich immer offen halten. Es kann z.B. ja sein, dass man gerne von GNU GPLv2 auf v3 gehen will. Deshalb empfehlen und beraten wir zu unserem Fiduciary Licence Agreement (FLA) http://www.fsfe.org/projects/ftf/fla.de.html.
Also die juristische Wartbarkeit sollte wirklich erhalten bleiben. Dazu ist es am besten, wenn mit einer Art treuhändischen Verhalten der exklusiven Nutzungsrechte (nicht der persönlichen Autorenrechte) durch eine Organisation gearbeitet wird.
Einmal sollte die Organisation der Freien Software verpflichtet sein und die Vereinbarung mit jedem Autoren muss das nochmals enthalten. Die treuhhänderischer Lizenzvereinbarung (FLA) ist ein Muster für eine solche Vereinbarung. Der KDE e.V. z.B. bietet das für KDE Anwendungen und andere Produkte der Initiative an.
Im Falle von GPL-Projekten dürfte doch die übliche "GPL v3 or later"- Klausel völlig ausreichen, oder?
Die ist schon gut, aber juristisch nicht sicher genug, da Du ja nicht genau weiss, was die zukünftigen Versionen der GNU GPL Lizenz bringen werden. Wenn die im Sinne der alten Lizenz waren, dann halte ich das für argumentierbar. Eine Spur sicherer ist es, wenn wirklich jemand die Rechte hat, um die Lizenz zu pflegen.
Gruß, Bernhard
Bernhard Reiter schrieb:
Am Dienstag, 26. Oktober 2010 19:50:38 schrieb Volker Grabsch:
Die Möglichkeit zur Relizenzierung sollte man sich immer offen halten. Es kann z.B. ja sein, dass man gerne von GNU GPLv2 auf v3 gehen will. Deshalb empfehlen und beraten wir zu unserem Fiduciary Licence Agreement (FLA) http://www.fsfe.org/projects/ftf/fla.de.html.
Also die juristische Wartbarkeit sollte wirklich erhalten bleiben. Dazu ist es am besten, wenn mit einer Art treuhändischen Verhalten der exklusiven Nutzungsrechte (nicht der persönlichen Autorenrechte) durch eine Organisation gearbeitet wird.
Einmal sollte die Organisation der Freien Software verpflichtet sein und die Vereinbarung mit jedem Autoren muss das nochmals enthalten. Die treuhhänderischer Lizenzvereinbarung (FLA) ist ein Muster für eine solche Vereinbarung. Der KDE e.V. z.B. bietet das für KDE Anwendungen und andere Produkte der Initiative an.
Im Falle von GPL-Projekten dürfte doch die übliche "GPL v3 or later"- Klausel völlig ausreichen, oder?
ohne Jurist zu sein: "or later" geht nach Deutschem Recht nicht, es kann nur die zum Zeitpunkt des Vertragsabschlusses gültige Version eine Bedeutung haben.
re, wh
On Friday 29 October 2010 16:45:41 walter harms wrote:
ohne Jurist zu sein: "or later" geht nach Deutschem Recht nicht, es kann nur die zum Zeitpunkt des Vertragsabschlusses gültige Version eine Bedeutung haben.
ohne Jurist zu sein: Gibt es nicht auch rechtliche Interpretationen der GPL, die sie _nicht_ als Vertrag ansehen?
Torsten
Am Freitag, 29. Oktober 2010 17:05:58 schrieb Torsten Grote:
On Friday 29 October 2010 16:45:41 walter harms wrote:
ohne Jurist zu sein: "or later" geht nach Deutschem Recht nicht, es kann nur die zum Zeitpunkt des Vertragsabschlusses gültige Version eine Bedeutung haben.
Das sehe ich anders. Der Passung ist eine klare Willenserklärung des Rechteinhabers und darf deshalb auch interpretiert und hinzugezogen werden. Solange die Lizenz im Sinn der Präamble bleibt und zum beispiel auf Rechtsänderungen reagiert, halte ich das auch in Deutschland für argumentierbar.
ohne Jurist zu sein: Gibt es nicht auch rechtliche Interpretationen der GPL, die sie _nicht_ als Vertrag ansehen?
In Deutschland ist mir das nicht bekannt, aber in anderen Ländern: Klar. Weiterhin sollen, wenn ich mich da richtig erinnere, Rechte aus anderen Jurisdiktionen auch in Deutschland so bewertet werden, dass es der Lage in der anderen Jurisdiktion gerecht wird.
Volker Grabsch:
Generell wäre eine "Wir haben's geschafft"-Liste ein nützliches Argument. Leider habe ich keine Ahnung, wie man eine solche aufbauen sollte, also wo man solche Leute/Firmen findet. Ich habe nur durch Zufall von einer oder zwei solcher Firmen erfahren. Beeindruckender wäre eine große Liste von der Sorte:
Wir verdienen unser Geld mit Freier Software: ... ... ...
Hallo Volker,
das Konzept, um freie Software herum Dienstleistungen anzubieten ist, glaube ich, leicht verständlich zu machen. Es ist also auch erklärbar zu machen, dass man mit (bereits bestehender) freier Software Geld verdienen kann.
Meine Frage ist aber, wie kann ich Menschen erklären, dass man viel Arbeit in die _Erstellung_ einer Software investiert und dann das Produkt dieser Arbeit nicht verkauft sondern als freie Software zur Verfügung stellt?
Aber ich glaube mit den vielen Gedanken aus diesem Thread kann ich schon weit kommen. Nochmal danke!
Thomas Koch, http://www.koch.ro
Hallo,
On Mon, Oct 25, 2010 at 09:10:50AM +0200, Thomas Koch wrote:
das Konzept, um freie Software herum Dienstleistungen anzubieten ist, glaube ich, leicht verständlich zu machen. Es ist also auch erklärbar zu machen, dass man mit (bereits bestehender) freier Software Geld verdienen kann.
Meine Frage ist aber, wie kann ich Menschen erklären, dass man viel Arbeit in die _Erstellung_ einer Software investiert und dann das Produkt dieser Arbeit nicht verkauft sondern als freie Software zur Verfügung stellt?
Aber ich glaube mit den vielen Gedanken aus diesem Thread kann ich schon weit kommen.
Um trotzdem nochmal ganz konkret zu antworten:
Indem ich in Entwicklung freier Software investiere, schaffe ich einen Markt für Dienstleistungen rund um diese Software. Gleichzeitig gewinne ich Expertise, die es mir ermöglicht, diese Dienstleistungen effizienter anzubieten als Andere.
-antrik-