Hallo Leute,
ich bin noch lang nicht soweit Support anzubieten. Aber mich beschäftigen zwei Fragen. Zunächst: Wir gehen davon aus, dass der Kunde Windows benutzt, und man als Entwickler EXE-Datei erstellen muss.
Frage 1: Wenn ein Kunde eine bestimmte Funktion wünscht, dann wird die gewünschte Funktion gegen Entgelt umgesetzt - soweit wie möglich. Aber was ist, wenn sich der Entwickler dabei an Bibliotheken bedient, die unter der GPL-Lizenz stehen? GPL besagt ja unter anderem, dass der Quelltext offen gelegt werden muss, richtig? Nun hat der Entwickler eine kundenspezifische Funktion fertig gestellt, verkauft dies dem Kunden. Muss der Entwickler nicht diese Funktion auch offen legen? Wenn ja, dann fühlt sich der Kunde ja glatt veräppelt? Ich meine, er bezahlt für seine Wünsche, und diese werden im nächsten Atemzug für jeden offen gelegt?
Frage 2: Diese Frage betrifft eher der Verwaltung. Neben der kundenspezifische Software entwickelt man ja eine kostenlose Basis-Software. Da man dem Kunden nicht modular die für ihn entwickelte Funktion zusenden kann, sondern man muss dem Kunden die komplette EXE-Datei samt anderen Dateien mitschicken, die vom py2exe, pyinstaller oder cx_freeze erstellt wurden, frage ich mich wie das verwaltungstechnisch geht? Der Entwickeler schreibt eine Aktualisierung für die Basis-Software, muss dann in diese Basis-Software dann die Wunsch-Funktion integrieren, dann als EXE-Datei samt anderen Dateien versenden. Bei einem Kunden arbeitet man also zwei Mal. Einmal bei der Basis-Software und einmal bei der Kunden-Software. Denn die Kundensoftware muss ja auf den gleichen Version-Stand sein wie die Basis-Software, nur dass der Kunde zusätzliche Funktionen hat. Und jetzt erweitert man den Kundenstand. Sagen wir mal 50 Kunden? Dann arbeitet man 51 Mal an einer Software. Wie gesagt, Basis-Software und 50 Kunden-Software. Jeder Kunde bekommt die aktuelle Version plus Kunden-Funktion. Jedesmal wenn eine neue Aktualisierung raus kommt - ganz gleich wie umfangreich die Aktualisierung ist - muss man dann alle Kunden-Programme einzeln aktualisieren. Wird man da nicht rammdösig bei?
Kundenspezifische Software
Den Quellcode offen legen und den Quellcode öffentlich machen ist nicht das gleiche. GPL besagt, dass dass die Anwendung (inklusive Quellcode) dem Entwickler und dem Anwender (d.h. dem Kunden ) gleichermaßen gehört, d.h. der Entwickler muss dem Kunden den Quellcode zugänglich machen, aber eben nur dem Kunden und nicht der ganzen Welt.Sophus hat geschrieben:Frage 1: Wenn ein Kunde eine bestimmte Funktion wünscht, dann wird die gewünschte Funktion gegen Entgelt umgesetzt - soweit wie möglich. Aber was ist, wenn sich der Entwickler dabei an Bibliotheken bedient, die unter der GPL-Lizenz stehen? GPL besagt ja unter anderem, dass der Quelltext offen gelegt werden muss, richtig? Nun hat der Entwickler eine kundenspezifische Funktion fertig gestellt, verkauft dies dem Kunden. Muss der Entwickler nicht diese Funktion auch offen legen? Wenn ja, dann fühlt sich der Kunde ja glatt veräppelt? Ich meine, er bezahlt für seine Wünsche, und diese werden im nächsten Atemzug für jeden offen gelegt?
Wichtig ist, dass der Entwickler die Verwendung von OpenSource vorher mit dem Kunden diskutiert und ihm erklärt, wieviel teurer es ohne OpenSource werden würde. Wenn der Entwickler den selben Quellcode auch an andere Kunden ausliefern will, dann sollte er das mit dem Kunden auch diskutieren und ihm erklären wieviel teurer es werden würde, wenn die Software ausschliesslich für den einen Kunden gemacht werden würde. Auch hat eine Software, die von vielen benutzt wird, in der Regel weniger Fehler.
Die Basis-Software würde ich nur dann aktualisieren, wenn der Kunde neue kundenspezifische Funktionen bekommt oder wenn in der Basis-Software ein ernster oder peinlicher Fehler gefixt wurde.Sophus hat geschrieben:Frage 2: Diese Frage betrifft eher der Verwaltung. Neben der kundenspezifische Software entwickelt man ja eine kostenlose Basis-Software. Da man dem Kunden nicht modular die für ihn entwickelte Funktion zusenden kann, sondern man muss dem Kunden die komplette EXE-Datei samt anderen Dateien mitschicken, die vom py2exe, pyinstaller oder cx_freeze erstellt wurden, frage ich mich wie das verwaltungstechnisch geht? Der Entwickeler schreibt eine Aktualisierung für die Basis-Software, muss dann in diese Basis-Software dann die Wunsch-Funktion integrieren, dann als EXE-Datei samt anderen Dateien versenden. Bei einem Kunden arbeitet man also zwei Mal. Einmal bei der Basis-Software und einmal bei der Kunden-Software. Denn die Kundensoftware muss ja auf den gleichen Version-Stand sein wie die Basis-Software, nur dass der Kunde zusätzliche Funktionen hat. Und jetzt erweitert man den Kundenstand. Sagen wir mal 50 Kunden? Dann arbeitet man 51 Mal an einer Software. Wie gesagt, Basis-Software und 50 Kunden-Software. Jeder Kunde bekommt die aktuelle Version plus Kunden-Funktion. Jedesmal wenn eine neue Aktualisierung raus kommt - ganz gleich wie umfangreich die Aktualisierung ist - muss man dann alle Kunden-Programme einzeln aktualisieren. Wird man da nicht rammdösig bei?
@Sophus: Am besten liest Du Dir mal die GPL gründlich, Absatz für Absatz durch. Dann weißt Du genau, welche Pflichten Du hast, wenn Du GP lizensierte Bibliotheken einsetzt.
Software für 50 Kunden schreibt man nicht mal so einfach. Da würde ich an Deiner Stelle ein paar Projektleiter einstellen, die sich um die Organisation kümmern und eine Handvoll Programmierer, die sich um die Programmierung kümmern, und einen Anwalt, der sich um die Lizenzfragen kümmert. Ganz im Ernst, ohne spezielle Ausbildung kann man nicht eine Software für 50 Kunden schreiben.
Software für 50 Kunden schreibt man nicht mal so einfach. Da würde ich an Deiner Stelle ein paar Projektleiter einstellen, die sich um die Organisation kümmern und eine Handvoll Programmierer, die sich um die Programmierung kümmern, und einen Anwalt, der sich um die Lizenzfragen kümmert. Ganz im Ernst, ohne spezielle Ausbildung kann man nicht eine Software für 50 Kunden schreiben.
@Sirius3: Die Zahl 50 habe ich nur genommen, um mein Anliegen zu verdeutlichen. Das man nicht mal eben so für 50 Kunden programmiert, ist mir einleuchtend. Ich dachte eher so an ein klassisches Bild. Man schreibt ein Programm, zeigt das seinen Freunden. Der eine Freund wünscht sich diese Funktion, der andere Freund hätte eine andere Funktion und dein Nachbar, mit dem du ab und zu Mal ein Bierchen trinkst, findet dein Programm auch klasse, nur vermisst er etwas, und du erfüllst seinen Wunsch. Alles in einem kleinen Kreis. Nun hat man mit drei Menschen zutun, und man hat dann drei unterschiedliche Programme. Mit unterschiedlichen Programme meine ich, dass jedes dieser Programme unterschiedlich Zusatz-Funktionen haben. Und weil man eine gute Rückmeldung von Freunden und Bekannten bekam entwickelt man sein kleines Programm weiter. Warum auch nicht? Und nun hat man allgemein für die Basis-Software weitere Funktionen hinzugefügt und bestimmte Fehler ausgemerzt. Das heißt, eine Aktualisierung steht an. Und nun komm der Punkt, den ich mit der Verwaltung meine. Ich muss dann nicht nur die Basis-Software aktualisieren, sondern alle drei Programme mit unterschiedlichen Zusatz-Funktionen, damit diese auch auf dem neusten Stand sind. Und von diesem Moment an arbeite ich dann 4 Mal. All die Neuerungen und Änderungen an der Basis-Software müssen auch bei den kundenspezifischen Programmen vorgenommen werden, und das manuell. Gut, unter Freunden ist es ja kein Problem, wenn deren Programm Version-Technisch der Basis-Software hinterher hängen, und man versucht schnellstmöglich deren spezifische Software zu aktualisieren.
Wenn Du die Basis-Software inkompatibel veränderst, dann ist das so, wenn Du sie kompatibel erweiterst, dann sollte es nicht so sein.Sophus hat geschrieben: Ich muss dann nicht nur die Basis-Software aktualisieren, sondern alle drei Programme mit unterschiedlichen Zusatz-Funktionen, damit diese auch auf dem neusten Stand sind. Und von diesem Moment an arbeite ich dann 4 Mal. All die Neuerungen und Änderungen an der Basis-Software müssen auch bei den kundenspezifischen Programmen vorgenommen werden, und das manuell.
Der kundenspezifische Teil benutzt Klassen und Funktionen der Basis-Software, diese Klassen und Funktionen sind die Schnittstelle zwischen der Basis-Software und dem kundenspezifischen Teil. Wenn Du die Klassen der Schnittstelle umbennst, Methoden umbenennst, dann ist das eine inkompatible Änderung. Wenn Du die Anzahl der Parameter von vorhandenen Methoden veränderst, dann kann man das kompatibel machen, es kann aber auch inkompatibel werden. Wenn Du die Erweiterungen der Basis-Software über neue Methoden oder neue Klassen in der Schnittstelle zugänglich machst, dann ist das eher kompatibel.Sophus hat geschrieben:Inkompatible? Inwiefern?
Dann hast du sowieso schon verloren. Software die beim Kunden läuft ist eine schlechte Idee die du vermeiden möchtest.Sophus hat geschrieben:ich bin noch lang nicht soweit Support anzubieten. Aber mich beschäftigen zwei Fragen. Zunächst: Wir gehen davon aus, dass der Kunde Windows benutzt, und man als Entwickler EXE-Datei erstellen muss.
Das tut ein Entwickler der bei Sinnen ist in diesem Fall nicht. Tatsächlich nutzen viele Entwickler GPL lizensierte Software grundsätzlich nicht.Frage 1: Wenn ein Kunde eine bestimmte Funktion wünscht, dann wird die gewünschte Funktion gegen Entgelt umgesetzt - soweit wie möglich. Aber was ist, wenn sich der Entwickler dabei an Bibliotheken bedient, die unter der GPL-Lizenz stehen?
Nein, dass tut man nicht unbedingt. Selbst wenn man Software schreibt die man für mehrere Kunden verwendet, würde man dies wahrscheinlich nicht "Basis-Software" nennen sondern wohl eher Library oder Framework.Frage 2: Diese Frage betrifft eher der Verwaltung. Neben der kundenspezifische Software entwickelt man ja eine kostenlose Basis-Software.
Wieso sollte es nicht gehen?Da man dem Kunden nicht modular die für ihn entwickelte Funktion zusenden kann, sondern man muss dem Kunden die komplette EXE-Datei samt anderen Dateien mitschicken, die vom py2exe, pyinstaller oder cx_freeze erstellt wurden, frage ich mich wie das verwaltungstechnisch geht?
Ähm, nein, du nutzt ja schliesslich einfach interne Libraries/Frameworks die du wie jede andere Abhängigkeit einfach Updaten kannst. Es sei den du stellst sich äußerst blöd an.Der Entwickeler schreibt eine Aktualisierung für die Basis-Software, muss dann in diese Basis-Software dann die Wunsch-Funktion integrieren, dann als EXE-Datei samt anderen Dateien versenden. Bei einem Kunden arbeitet man also zwei Mal. Einmal bei der Basis-Software und einmal bei der Kunden-Software.
Nur wenn man sich - wie bereits erwähnt - blöd anstellt. Andererseits ist das natürlich Arbeitszeit die du in Rechnung stellen könntest, vielleicht gleicht dass die "rammdösig"-keit wieder aus.Denn die Kundensoftware muss ja auf den gleichen Version-Stand sein wie die Basis-Software, nur dass der Kunde zusätzliche Funktionen hat. Und jetzt erweitert man den Kundenstand. Sagen wir mal 50 Kunden? Dann arbeitet man 51 Mal an einer Software. Wie gesagt, Basis-Software und 50 Kunden-Software. Jeder Kunde bekommt die aktuelle Version plus Kunden-Funktion. Jedesmal wenn eine neue Aktualisierung raus kommt - ganz gleich wie umfangreich die Aktualisierung ist - muss man dann alle Kunden-Programme einzeln aktualisieren. Wird man da nicht rammdösig bei?
@Sophus:
Wikipedia bringt einen groben Überblick zu Softwareentwicklung -- https://de.wikipedia.org/wiki/Softwaretechnik
Ansonsten schließ ich mich Sirius an - stell Dir Projektleiter mit ordentlich Erfahrung ein, alles weitere fügt sich dann. Das von Dir skizzierte modulare System braucht eine gehörige Portion Erfahrung von Anforderungsanalyse bis Deployment. Das wird Dir hier keiner kostenlos machen.
Wikipedia bringt einen groben Überblick zu Softwareentwicklung -- https://de.wikipedia.org/wiki/Softwaretechnik
Ansonsten schließ ich mich Sirius an - stell Dir Projektleiter mit ordentlich Erfahrung ein, alles weitere fügt sich dann. Das von Dir skizzierte modulare System braucht eine gehörige Portion Erfahrung von Anforderungsanalyse bis Deployment. Das wird Dir hier keiner kostenlos machen.
unglaublichDasIch hat geschrieben:Software die beim Kunden läuft ist eine schlechte Idee die du vermeiden möchtest.
eins, zwei, vieleDasIch hat geschrieben:Tatsächlich nutzen viele Entwickler GPL lizensierte Software grundsätzlich nicht.
@DasIch:
Hast Du die Ironie-Tags in Deinem Beitrag vergessen?
Wir fahren sehr gut mit GPL-Software und speziellen Kundenanpassungen. Das Vertriebsmodell sieht dann halt etwas anders aus - Kunde wünscht Feature XY - kostet ihn die Entwicklungsarbeit, aber bekommt es nicht exklusiv, sondern es wird allen als Updates angeboten (gegen Update-Aufwand). Gegen Aufpreis bei Featurewünschen gibts das dann auch exklusiv - geht auch mit GPL.
Hast Du die Ironie-Tags in Deinem Beitrag vergessen?
Wir fahren sehr gut mit GPL-Software und speziellen Kundenanpassungen. Das Vertriebsmodell sieht dann halt etwas anders aus - Kunde wünscht Feature XY - kostet ihn die Entwicklungsarbeit, aber bekommt es nicht exklusiv, sondern es wird allen als Updates angeboten (gegen Update-Aufwand). Gegen Aufpreis bei Featurewünschen gibts das dann auch exklusiv - geht auch mit GPL.
Ich kann die in Frage 2 skizzierte Problematik nicht so recht nachvollziehen: Wenn der Kunde das neue Feature exklusiv nur für sich wünscht, dann steckt man es in die Kundenerweiterung. Wenn das neue Feature hingegen für alle zugänglich sein soll, dann steckt man es in die Basis-Software / Bibliothek / was-auch-immer. Bei letzterem kann dann z.B. nach einer gewissen Zeit ein neues Release der Basis-Software (=neue Version) erscheinen und die Kunden könnten dies gegen Entgelt erwerben. Oder man verteilt kostenpflichtige Lizenzen, bei denen die Kunden sich die neuen Releases gratis herunterladen können. Auf jeden Fall sehe ich nicht, wo da die doppelte oder gar 51-fache Arbeit stecken soll.
Das mit der GPL sehe ich ähnlich wie die Vorposter: GPL heißt Veröffentlichung des Quellcodes für den oder die Anwender. Wenn aber nur ein Kunde (oder Unternehmen) der Anwender ist, dann muss auch nur diesem der Quellcode offengelegt werden. Daher sollte man bei Vorbehalten gegenüber der GPL das Ganze auch etwas differenzierter sehen. GPL heißt *nicht*, dass der Quellcode zwangsläufig auf Github oder so landen muss. Die Gefahr bei GPL ist nur, dass der Kunde, der ja den Quelltext besitzt, diesen selbst (gegen Bezahlung) weitergeben könnte.
Das mit der GPL sehe ich ähnlich wie die Vorposter: GPL heißt Veröffentlichung des Quellcodes für den oder die Anwender. Wenn aber nur ein Kunde (oder Unternehmen) der Anwender ist, dann muss auch nur diesem der Quellcode offengelegt werden. Daher sollte man bei Vorbehalten gegenüber der GPL das Ganze auch etwas differenzierter sehen. GPL heißt *nicht*, dass der Quellcode zwangsläufig auf Github oder so landen muss. Die Gefahr bei GPL ist nur, dass der Kunde, der ja den Quelltext besitzt, diesen selbst (gegen Bezahlung) weitergeben könnte.
Wenn man als kleiner Entwickler für großen Kunden kundenspezifische Software entwickelt, dann ist das nach meiner Erfahrung aber sowieso die Regel, dass der Kunde den Quelltext besitzen möchte.snafu hat geschrieben:Die Gefahr bei GPL ist nur, dass der Kunde, der ja den Quelltext besitzt, diesen selbst (gegen Bezahlung) weitergeben könnte.
Diese Veröffentlichungsgefahr besteht zugegebenermassen in beide Richtungen (programmierer- wie kundenseitig) - eine wirklich exklusive Entwicklung/Lizensierung kann es mit der GPL nicht geben - Nebenabsprachen im Sinne von freiwilligem Rechteabtritt sind entweder nicht wirksam oder würden die GPL aushebeln und wären damit ebenfalls unwirksam. Und das geht nur solange gut, wie das Vertragsverhältnis nicht gestört ist. Insofern sind die Bedenken auf beiden Seiten verständlich, im Zweifelfalle hat man keinen belastbaren Schutz.snafu hat geschrieben:Die Gefahr bei GPL ist nur, dass der Kunde, der ja den Quelltext besitzt, diesen selbst (gegen Bezahlung) weitergeben könnte.