
Hallo Liste, ich bin dabei eine grössere applikation (Warenwirtschaft) zu schreiben. Realisiert soll dieses als Client-Server werden. Der Client wird, bis auf wenige Ausnahmen, nur zur Datenanzeige herhalten müssen. Der Server wird in Python geschrieben. Der Client in Delphi. (Vorgabe vom Kunden) Die Frage die sich jetzt stellt ist: Wie bewerkstellige ich die Kommunikation zwischen Client und Server. Nach langen Lesen und viel googeln bin ich auf xml.rpc und soap gestoßen. Da ich mit keinem dieser Produkte Erfahrung habe, möchte ich euch um Rat bitten. Ist SOAP bzw. rcp der richtige Weg oder laufe ich damit ins Nirwana? Gibt es Alternativen? Wenn ja, bitte Welche? Kann mir jemand Beispiel/Testprogramme sagen wo ich ein wenig Abgucken kann? Gibt es sonstige Probleme bei der kommunikation zwischen Windoof und Linux. (Bzgl. SOAP, RPC, ...? Bin um jede Unterstützung Dankbar. Guten Rutsch ins neue Jahr. -- Roland Kruggel _______________________________________________ python-de maillist - python-de@python.net http://python.net/mailman/listinfo/python-de

Roland M. Kruggel wrote:
ich bin dabei eine grössere applikation (Warenwirtschaft) zu schreiben. Realisiert soll dieses als Client-Server werden.
Vorweg: Ich hab' nur eine sehr begrenzte Vorstellung davon, was so 'ne Warenwirtschaft macht, zumal sowas wohl sehr branchenspezifisch ist.
Der Client wird, bis auf wenige Ausnahmen, nur zur Datenanzeige herhalten müssen.
Was sind denn die Ausnahmen?
Der Server wird in Python geschrieben.
Gut Idee!
Der Client in Delphi. (Vorgabe vom Kunden)
Brr! ;-)
Die Frage die sich jetzt stellt ist: Wie bewerkstellige ich die Kommunikation zwischen Client und Server. Nach langen Lesen und viel googeln bin ich auf xml.rpc und soap gestoßen. Da ich mit keinem dieser Produkte Erfahrung habe, möchte ich euch um Rat bitten.
Mit XML RPC hab' ich wenig Erfahrung, mit Soap schon mehr. Was Sinn macht hängt wie immer von deinen Anforderungen ab. Wenn du sicher sein, kannst, daß nur dein Server und dein Client im Spiel sind, würde ich Soap eher für übertrieben halten. Und XML RPC macht warsch. genau das, was du mit Soap auch machen würdest. Soap ist spannend wenn Clients von denen du jetzt noch nichts weißt vieleicht mal auf dein API zugreifen sollen. In der Realität hat das bei mir bisher aber nie sooo reibungslos funktioniert, da sich die Implementierungen z.T. noch nicht vertragen.
Ist SOAP bzw. rcp der richtige Weg oder laufe ich damit ins Nirwana?
Hängt meiner Meinung nach in erster Linie davon ab, ob du stateless arbeiten kannst.
Gibt es Alternativen? Wenn ja, bitte Welche?
Z.B. COM oder Corba, oder auch ganz einfach HTTP, Sockets, ...
Gibt es sonstige Probleme bei der kommunikation zwischen Windoof und Linux. (Bzgl. SOAP, RPC, ...?
Ups ... somit scheidet COM wohl aus. Du solltest dir zuerst überlegen, was du brauchst und dann die Technologie suchen, die am besten paßt. Reichen dir stateless Verbindungen (also XML RPC, Soap, HTTP, ...) oder mußt du mit lebenden Objekten arbeiten (also Corba)? Ist dein API so einfach, daß du mit freien Funktionen hinkommst, oder wären Objekte besser? ...?
Guten Rutsch ins neue Jahr.
Ebenfalls! Gruß, Achim _______________________________________________ python-de maillist - python-de@python.net http://python.net/mailman/listinfo/python-de

Achim Domma (Procoders) schrieb:
Roland M. Kruggel wrote:
ich bin dabei eine grössere applikation (Warenwirtschaft) zu schreiben. Realisiert soll dieses als Client-Server werden.
Vorweg: Ich hab' nur eine sehr begrenzte Vorstellung davon, was so 'ne Warenwirtschaft macht, zumal sowas wohl sehr branchenspezifisch ist.
Eigentlich ist so eine Warenwirschaft nichts anderes als ein großer Datensammler und diese dann in verschiedenen Formen wieder auszugeben und zu verknüpfen. Also im grunde genommen 'recht trivial'.
Der Client wird, bis
auf wenige Ausnahmen, nur zur Datenanzeige herhalten müssen.
Was sind denn die Ausnahmen?
Einige wenige Berechnungen, die Connectivity zu Windoofprogrammen, (Word excel etc)
Der Server wird in Python geschrieben.
Gut Idee!
Der Client in Delphi. (Vorgabe vom Kunden)
Brr! ;-)
So schlimm ist das gar nicht. Nicht so flexibel wie Python, aber die GUI ist reletiv schnell zusammengeklickt. Späteren Änderungen sind auch relativ unproblematisch. Und - was dem Kunden wichtig ist - eine gute Schnittstelle zu Windowsprogrammen. Es gibt hat noch viele Windoof-Anwender. Besonders in Firmen. Ich versuchen immer einen guten Mittelweg zu finden.
Die Frage die sich jetzt stellt ist: Wie bewerkstellige ich die Kommunikation zwischen Client und Server. Nach langen Lesen und viel googeln bin ich auf xml.rpc und soap gestoßen. Da ich mit keinem dieser Produkte Erfahrung habe, möchte ich euch um Rat bitten.
Mit XML RPC hab' ich wenig Erfahrung, mit Soap schon mehr. Was Sinn macht hängt wie immer von deinen Anforderungen ab. Wenn du sicher sein, kannst, daß nur dein Server und dein Client im Spiel sind, würde ich Soap eher für übertrieben halten. Und XML RPC macht warsch. genau das, was du mit Soap auch machen würdest.
Hört sich gut an.
Soap ist spannend wenn Clients von denen du jetzt noch nichts weißt vieleicht mal auf dein API zugreifen sollen. In der Realität hat das bei mir bisher aber nie sooo reibungslos funktioniert, da sich die Implementierungen z.T. noch nicht vertragen.
Ich glaube dann brauche ich SOAP nicht. Die Clients die auf meinen Server zugreifen liegen immer in meiner Hand.
Ist SOAP bzw. rcp der richtige Weg oder laufe ich damit ins Nirwana?
Hängt meiner Meinung nach in erster Linie davon ab, ob du stateless arbeiten kannst.
Stateless ?? Wenn du meinst das sowohl der Server als auch der Client ausschließlich uner meiner Kontrolle liegen und beide von mir programmiert werden, kann ich mit ja antworten.
Gibt es sonstige Probleme bei der kommunikation zwischen Windoof und Linux. (Bzgl. SOAP, RPC, ...?
Ups ... somit scheidet COM wohl aus. Du solltest dir zuerst überlegen, was du brauchst und dann die Technologie suchen, die am besten paßt.
Ja, da bin ich ja gerade bei.
Reichen dir stateless Verbindungen (also XML RPC, Soap, HTTP, ...) oder mußt du mit lebenden Objekten arbeiten (also Corba)?
Hier kann ich wohl mit Ja antworten. (auf den ersten Teil der Frage)
Ist dein API so einfach, daß du mit freien Funktionen hinkommst, oder wären Objekte besser? ...?
Gute Frage. :) Die kann ich zum jetztigen Zeitpunkt nicht wirklich beantworten. Ich tendiere aber eher zu den Funktionen. Bin da aber flexibel. -- Roland Kruggel _______________________________________________ python-de maillist - python-de@python.net http://python.net/mailman/listinfo/python-de

Roland M. Kruggel wrote:
Der Client in Delphi. (Vorgabe vom Kunden)
Brr! ;-)
So schlimm ist das gar nicht. Nicht so flexibel wie Python, aber die GUI ist reletiv schnell zusammengeklickt. Späteren Änderungen sind auch relativ unproblematisch. Und - was dem Kunden wichtig ist - eine gute Schnittstelle zu Windowsprogrammen. Es gibt hat noch viele Windoof-Anwender. Besonders in Firmen. Ich versuchen immer einen guten Mittelweg zu finden.
Naja, ich kann Delphi halt überhaupt nicht leiden. Aber jedem das seine. Ich hab' grundsätzlich nix gegen Windows, würde aber in jedem Fall eher C++, C#, ... nehmen, bevor ich Delphi anfasse.
Hängt meiner Meinung nach in erster Linie davon ab, ob du stateless arbeiten kannst.
Stateless ?? Wenn du meinst das sowohl der Server als auch der Client ausschließlich uner meiner Kontrolle liegen und beide von mir programmiert werden, kann ich mit ja antworten.
Nö, es geht darum, ob zwischen Client und Server eine Connection bestehen bleibt. Beispiele sind z.B. Fälle wo du große Ergebnisse in Teilen abholen willst. Also sowas in der Art: obj.generateReport(... komplizierte Anfrage mit diversen Parametern ...) Jetzt wirst du nicht tausende Ergebnisse über's Netz schieben wollen, sondern z.B. blättern: items=obj.getPage(start,pagesize) for item in items: mache etwas In dem Fall muß ja irgendwo ein Status gespeichert werden, der sich merkt, daß getPage zum Aufruf von generateReport gehört. Bei Soap und XML RPC geht sowas nicht, zumindest nicht out-of-the box. Bei Corba schon. Gruß, Achim _______________________________________________ python-de maillist - python-de@python.net http://python.net/mailman/listinfo/python-de

Achim Domma (Procoders) schrieb:
Roland M. Kruggel wrote:
Der Client in Delphi. (Vorgabe vom Kunden)
Brr! ;-)
So schlimm ist das gar nicht. Nicht so flexibel wie Python, aber die GUI ist reletiv schnell zusammengeklickt. Späteren Änderungen sind auch relativ unproblematisch. Und - was dem Kunden wichtig ist - eine gute Schnittstelle zu Windowsprogrammen. Es gibt hat noch viele Windoof-Anwender. Besonders in Firmen. Ich versuchen immer einen guten Mittelweg zu finden.
Naja, ich kann Delphi halt überhaupt nicht leiden. Aber jedem das seine. Ich hab' grundsätzlich nix gegen Windows, würde aber in jedem Fall eher C++, C#, ... nehmen, bevor ich Delphi anfasse.
Ist doch ok. Ich bin ein großer freund von Pascal - und ein noch größerer Feind von C++. Aber, jedem das Seine.
Hängt meiner Meinung nach in erster Linie davon ab, ob du stateless arbeiten kannst.
Stateless ?? Wenn du meinst das sowohl der Server als auch der Client ausschließlich uner meiner Kontrolle liegen und beide von mir programmiert werden, kann ich mit ja antworten.
Nö, es geht darum, ob zwischen Client und Server eine Connection bestehen bleibt. Beispiele sind z.B. Fälle wo du große Ergebnisse in Teilen abholen willst. Also sowas in der Art:
obj.generateReport(... komplizierte Anfrage mit diversen Parametern ...)
Jetzt wirst du nicht tausende Ergebnisse über's Netz schieben wollen, sondern z.B. blättern:
items=obj.getPage(start,pagesize) for item in items: mache etwas
In dem Fall muß ja irgendwo ein Status gespeichert werden, der sich merkt, daß getPage zum Aufruf von generateReport gehört. Bei Soap und XML RPC geht sowas nicht, zumindest nicht out-of-the box. Bei Corba schon.
Ups. Das ist ein sehr interessanter Einwand. - hmm Jetzt komme ich ins grübeln. Die Funktion 'Blättern' ist immer sehr nützlich. *Roland am grübeln* Ich werden keine Programmfunktionen bereitstellen bei der der User einige zigtausen Datensätze durchblättern kann. Das macht kein Sinn. Da ist der Anwender stundenlang mit lesen/suchen beschäftigt. In diesem Fall könnte der Anwender eine Meldung bekommen das er seinen Suchstring näher eingrenzen soll. Durchblätterbare Listen schätze ich mal in eine Größenordnung von 10 bis 100 ein. In Ausnahmen vieleicht max 500. Diese Datensätze kann ich in einem rutsch durch's Netz schieben und dann auf dem Client zwischenspeichern und zum Blättern anzeigen. Sollte nicht das große Problem werden. Danke für diesen wichtigen Tip. Das wäre z.B. so ein Punkt geworden bei dem ich eventuell 'vor die Wand gelaufen' wäre. -- Roland Kruggel _______________________________________________ python-de maillist - python-de@python.net http://python.net/mailman/listinfo/python-de

Am Freitag, 31. Dezember 2004 17:49 schrieb Roland M. Kruggel:
In dem Fall muß ja irgendwo ein Status gespeichert werden, der sich merkt, daß getPage zum Aufruf von generateReport gehört. Bei Soap und XML RPC geht sowas nicht, zumindest nicht out-of-the box. Bei Corba schon. Ups. Das ist ein sehr interessanter Einwand. - hmm Jetzt komme ich ins grübeln. Die Funktion 'Blättern' ist immer sehr nützlich. Zur Not kann man das Blättern auch in der URL codieren.
ciao & guten Rutsch! thomas -- When you die, you lose a very important part of your life. -- Brooke Shields _______________________________________________ python-de maillist - python-de@python.net http://python.net/mailman/listinfo/python-de

Ist SOAP bzw. rcp der richtige Weg oder laufe ich damit ins Nirwana? Gibt es Alternativen? Wenn ja, bitte Welche?
Definitiv CORBA - ich habe gerade selber eine client/server Anwendung geschrieben (Appserver + Admingui in python/qt), und dabei auf den omniORB gesetzt. Sowohl performance als auch Funktionsumfang von CORBA im Verhältnis zu xmlrpc/soap sind wesentlich besser. Wenn es keine Probleme mit corba unter delphi gibt, dann nimm das. Ich habe auch xmlrpc-Unterstützung für bestimmte, einfache Funktionalitäten, da php und corba nicht gut zusammengehen - aber für einer komplexen Client wie deinen würde ich das nicht empfehlen. Und mit der Standardkonformität ist's bei SOAP auch nicht so allzuweit her. Diez _______________________________________________ python-de maillist - python-de@python.net http://python.net/mailman/listinfo/python-de

Roland M. Kruggel wrote:
ich bin dabei eine grössere applikation (Warenwirtschaft) zu schreiben. Realisiert soll dieses als Client-Server werden. Der Client wird, bis auf wenige Ausnahmen, nur zur Datenanzeige herhalten müssen.
Tipp: Schau dir mal lx-ep an <http://www.lx-office.org/>. Ist leider in Perl geschreiben, abrer ich hätte das gerne in python (weniger Probleme :-) -- Schönen Gruß - Regards Hartmut Goebel | Hartmut Goebel | IT-Security -- effizient | | h.goebel@goebel-consult.de | www.goebel-consult.de | _______________________________________________ python-de maillist - python-de@python.net http://python.net/mailman/listinfo/python-de

Hartmut Goebel schrieb:
Roland M. Kruggel wrote:
ich bin dabei eine grössere applikation (Warenwirtschaft) zu schreiben. Realisiert soll dieses als Client-Server werden. Der Client wird, bis auf wenige Ausnahmen, nur zur Datenanzeige herhalten müssen.
Tipp: Schau dir mal lx-ep an <http://www.lx-office.org/>. Ist leider in Perl geschreiben, abrer ich hätte das gerne in python (weniger Probleme :-)
Hallo Hartmut, habe mir lx-office mal angesehen. Die ganze Sache ist ein wenig trivial. Ausserdem verfolgen die einen komplett anderen weg als ich. Ich sehe, so auf den ersten Blick, einige Mängel. 1. Das ganze ist in Perl geschrieben. Perl ist mir zu kryptisch und zu schwer wartbar. Ist warscheinlich deswegen ein Sicherheitsrisiko. 2. Das ganze läuft im Browser. Ich bin da kein besonders großer Freund von. Ist zu unflexibel und hat viele Einschärnkungen. 3. Der Leistungsumfang. Damit lockt man nicht wirklich jemanden hinter dem Ofen hervor. Das eignet sich höchstens für ein kleinen Einmann-Unernehmen was ein paar ebay Verkäufe tätigt. Sorry. Ist nicht böse gemeint, aber wenn ich diese Software meinen Kunden zeigen würde, würde ich nur Lacher ernten. Bspl. Adressen. - Warum sind Kunden und Lieferanten getrennt. Es ist immer die selbe Adresse. Eine Kennzeichnung wäre besser. - Wo verwalte ich die Mitarbeiter, Privatadressen, Sonstige Kontakte? - Nur einen Ansprechpartner. Wo verwalte ich die anderen 75? - Genauso Telefon, Fax email. Haben alle Kunden nur eine max zwei Telefonnummer und eine emailadresse? Kein Handy, Funktelefon, Fax, Private Telefonnummern? - Wo werden die Abteilungen der Kunden gekennzeichnet? - Warum hat der Kunde nur eine Lieferadresse? Es gibt doch bestimmt Kunden die haben für jede Artikelgruppe eine andere Lieferadresse. - Zahlungsziel? Standard wäre zum Beispiel: 5 Tage 3%; 10 Tage 1%; 30 Tage Netto. Oder: Zum Ende des Monats 3%; Zum 15. des Folgemonats 1,75%; Zum Ende des zweiten Folgemonats Netto. - Firmenname nur eine Zeile? - Keine logisch teilbare Kundennummer. Gut wäre z.b. 21-322-32443. Das wäre so etwas wie Warengruppen für Adressen. Das ist ein wenig was mir so auf anhieb einfällt. Ich bekomme bestimmt noch eine ganze Seite voll, aber ich glaube du weis was ich meine. Diese Einschränkungen ziehen sich durch das ganze Programm und sind oftmals so groß, daß selbst kleine Unternehmer damit nicht zurecht kommen. Meine Adressenverwaltung hat schon allein 12 Bildschirmseiten. Schön durch Notepads mit Reitern getrennt. Nochmal Thema Sicherheit. Die Möglichkeit mit einem Browser auf diese Software zu kommen läßt mir die Nachenhaare Kräuseln. Ist zwar schön für den Aussendienst, aber der kann auch einen Client auf seinem Notbook mitschleppen. Aus Seiten der Sicherheit ist das bestimmt wesentlich besser. Laß mich mal mit dem Projekt anfangen. Vieleicht stelle ich es später ja unter GPL. Dann haben alle was davon. Aber dazu muß erstmal was da sein. Die Kundenentwicklung ist vorrangig. Ich muss nebenbei auch ein wenig Geld verdiehnen. :) Mir fällt immer wieder auf, das viele Warenwirtschaftssysteme auf dem Markt sind die nicht viel taugen. Der Ansatz mag vieleicht noch gut sein, aber in der Praxis sieht das dann alles etwas anders aus. Ich vertreibe, programmiere und warte jetzt sein 15 Jahren Warenwirtschaftssysteme. Da kommt einem schon so manches unter. Überigens gehört SAP auch zu meine 'Favorieten' SAP kann fast alles. Sehr Mächtig. Sehr gut gonfigurierbar. Die deutsche Übersetzung von SAP kennst du? Sanduhr Ablauf Programm. Teilweise ist mit dem Ding nicht zu Arbeiten. So. Genug gesülzt :) Horch mal in dich rein, ob LX wirklich das ist was du brauchst, oder ob du so manches Feature benötigst was du nicht findest. -- Roland Kruggel _______________________________________________ python-de maillist - python-de@python.net http://python.net/mailman/listinfo/python-de

Hallo zusammen
Tipp: Schau dir mal lx-ep an <http://www.lx-office.org/>. Ist leider in Perl geschreiben, abrer ich hätte das gerne in python (weniger Probleme :-)
Ich kenn kein Warenwirtschaftsystem (?), aber schaut euch mal http://www.gnuenterprise.org an. Ist in Python geschrieben und stellt schon enorm viele Grundlagen zur Verfügung: Financials, Customer Relations, Forecasting, Human Resources, Manufacturing - producing products for your customers.... Bevor ihr über Tools streitet, stellt zuerst einmal einen genauen Anforderungskatalog auf. Gruss _______________________________________________ python-de maillist - python-de@python.net http://python.net/mailman/listinfo/python-de

Andreas Wapf schrieb:
Hallo zusammen
Tipp: Schau dir mal lx-ep an <http://www.lx-office.org/>. Ist leider in Perl geschreiben, abrer ich hätte das gerne in python (weniger Probleme :-)
Ich kenn kein Warenwirtschaftsystem (?), aber schaut euch mal http://www.gnuenterprise.org an. Ist in Python geschrieben und stellt schon enorm viele Grundlagen zur Verfügung: Financials, Customer Relations, Forecasting, Human Resources, Manufacturing - producing products for your customers....
Schon besser. Aber bei mir geht es erstmal darum die wünsche des Kunden zu befriedigen.
Bevor ihr über Tools streitet, stellt zuerst einmal einen genauen Anforderungskatalog auf.
Ich glaube das du mit deiner Bemerkung, ist wohl gut gemeint, ein wenig vorbeigeschossen hast. Ich/wir streiten nicht über tools. Ich habe nur eine einfache frage gestellt, die auch hier gut beantwortet wurde. Bzw. es sind gute Anregungen rübergekommen. Darauf kann ich aufbauen und weiterplanen. Der Anforderungskatalog steht bereits. Ihn hier komplett wiederzugeben wäre allerdings ein wenig viel. Der Anforderungskatalog den ich hier gestellt habe war doch eindeutig. - Es geht um eine neuprogrammierung eines WWS - Ich habe einen AppServer, der in Python geschrieben ist (wird). - Ich habe einen Client der in Delphi geschrieben ist (wird) - Ich mur diese beiden miteinander verbinden. - Wie stelle ich es an. Ist das nicht eindeutig genung? Welche Infos möchtes du noch? Sag es, ich werde sie liefern. -- Roland Kruggel _______________________________________________ python-de maillist - python-de@python.net http://python.net/mailman/listinfo/python-de

ich bin dabei eine grössere applikation (Warenwirtschaft) zu schreiben.
Komplett? Hut ab. GNUe, TinyERP und ERP5 existieren schon.
Ist SOAP bzw. rcp der richtige Weg oder laufe ich damit ins Nirwana? Gibt es Alternativen? Wenn ja, bitte Welche?
Sprach- und systemunabhängig: Corba. GNUe verwendet übrigens Corba (Orbit). Und ein GNUe Client muß ja nicht mit GNUe Designer und GNUe Forms implementiert werden, sondern man kann ihne ja auch in Delphi bauen. Einziger "Nachteil": Wenn Du den GNUe-Sourcecode anfäßt (muß man aber nicht unbedingt, um damit eine Anwendung zu bauen), fallen die Änderungen/Ergänzungen auch unter die GPL. Aber nicht z.B. der Client. MfG Wolfgang Keller _______________________________________________ python-de maillist - python-de@python.net http://python.net/mailman/listinfo/python-de

Hallo
Einziger "Nachteil": Wenn Du den GNUe-Sourcecode anfäßt (muß man aber nicht unbedingt, um damit eine Anwendung zu bauen), fallen die Änderungen/Ergänzungen auch unter die GPL. Aber nicht z.B. der Client.
Also ich finds von Vorteil, wenn es dann unter diese Lizenz fällt ;) _______________________________________________ python-de maillist - python-de@python.net http://python.net/mailman/listinfo/python-de

Einziger "Nachteil": Wenn Du den GNUe-Sourcecode anfäßt (muß man aber nicht unbedingt, um damit eine Anwendung zu bauen), fallen die Änderungen/Ergänzungen auch unter die GPL. Aber nicht z.B. der Client.
Also ich finds von Vorteil, wenn es dann unter diese Lizenz fällt ;)
Deshalb ja auch die "...". :-) Wenn es sich um eine bezahlte Auftragsentwicklung handelt, kann es natürlich sein, daß der Auftraggeber nicht wünscht, daß sein teuer bezahlter Sourcecode veröffentlicht werden muß. Deshalb kann die GPL manchmal für Softwareentwickler (vor allem freiberufliche) von Nachteil sein. BSD-Lizenz o.dgl. ist da praktischer. Da _kann_ man, _muß_ aber nicht. MfG Wolfgang Keller _______________________________________________ python-de maillist - python-de@python.net http://python.net/mailman/listinfo/python-de

Wolfgang Keller <wolfgang.keller.nospam@gmx.de> writes:
Einziger "Nachteil": Wenn Du den GNUe-Sourcecode anfäßt (muß man aber nicht unbedingt, um damit eine Anwendung zu bauen), fallen die Änderungen/Ergänzungen auch unter die GPL. Aber nicht z.B. der Client.
Also ich finds von Vorteil, wenn es dann unter diese Lizenz fällt ;)
Deshalb ja auch die "...". :-)
Wenn es sich um eine bezahlte Auftragsentwicklung handelt, kann es natürlich sein, daß der Auftraggeber nicht wünscht, daß sein teuer bezahlter Sourcecode veröffentlicht werden muß.
Die GPL verlangt keine Veröffentlichung des Quelltextes. Das ist also kein Problem. Wenn dein Auftraggeber nicht möchte, dass Du die von ihm bezahlten Änderungen Anderen gibst, kannst Du z.b. eine Klausel in den Vertrag aufnehmen, nach der Du Dich verpflichtest, die Software für einen gewissen Zeitraum nicht an Andere weiterzugeben ohne Genehmigung des Auftraggebers. Bernhard -- Intevation GmbH http://intevation.de/ Skencil http://skencil.org/ Thuban http://thuban.intevation.org/ _______________________________________________ python-de maillist - python-de@python.net http://python.net/mailman/listinfo/python-de

Die GPL verlangt keine Veröffentlichung des Quelltextes.
Wenn ich ein Programm im Sourcecode verändere, das von jemand anderem unter der GPL veröffentlicht wurde, und dieses geänderte Programm an Dritte (den Auftraggeber der Anpassung) weitergebe? Dann muß ich da was Wichtiges falsch verstanden habe. Für reinen Eigenbedarf (ohne Weitergabe an Dritte) kann ich mit GPL-Software machen, was ich will. MfG Wolfgang Keller _______________________________________________ python-de maillist - python-de@python.net http://python.net/mailman/listinfo/python-de

Wolfgang Keller <wolfgang.keller.nospam@gmx.de> writes:
Die GPL verlangt keine Veröffentlichung des Quelltextes.
Wenn ich ein Programm im Sourcecode verändere, das von jemand anderem unter der GPL veröffentlicht wurde, und dieses geänderte Programm an Dritte (den Auftraggeber der Anpassung) weitergebe?
In dem Fall musst Du natürlich den Quelltext an den Auftraggeber geben. Die GPL allein verpflichtet Dich aber nicht, den Quelltext weiteren Leuten zu geben. Bernhard -- Intevation GmbH http://intevation.de/ Skencil http://skencil.org/ Thuban http://thuban.intevation.org/ _______________________________________________ python-de maillist - python-de@python.net http://python.net/mailman/listinfo/python-de

Bernhard Herzog wrote:
Die GPL verlangt keine Veröffentlichung des Quelltextes.
Wenn ich ein Programm im Sourcecode verändere, das von jemand anderem unter der GPL veröffentlicht wurde, und dieses geänderte Programm an Dritte (den Auftraggeber der Anpassung) weitergebe?
In dem Fall musst Du natürlich den Quelltext an den Auftraggeber geben. Die GPL allein verpflichtet Dich aber nicht, den Quelltext weiteren Leuten zu geben.
Das stimmt nicht. Siehe http://www.gnu.org/copyleft/gpl.html#SEC3 Punkt 2b: "You must cause any work that you distribute or publish, that in whole or in part contains or is derived from the Program or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this License." Du mußt alle Änderungen für beliebige Leute verfügbar machen. Genau das ist ja Sinn und Zweck der GPL. Gruß, Achim _______________________________________________ python-de maillist - python-de@python.net http://python.net/mailman/listinfo/python-de

"Achim Domma (Procoders)" <domma@procoders.net> writes:
In dem Fall musst Du natürlich den Quelltext an den Auftraggeber geben. Die GPL allein verpflichtet Dich aber nicht, den Quelltext weiteren Leuten zu geben.
Das stimmt nicht. Siehe http://www.gnu.org/copyleft/gpl.html#SEC3 Punkt 2b:
"You must cause any work that you distribute or publish, that in whole or in part contains or is derived from the Program or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this License."
Das bezieht sich, wie der Satz sagt, auf "any work that you distribute or publish". Das heisst also, Du musst jedem, der die Software von Dir bekommt (direkt oder indirekt), erlauben, sie unter den Bedingungen der GPL nutzen zu dürfen. Es ergibt sich aber keine Verpflichtung, sie jemandem zu geben. Siehe auch die GPL FAQ (http://www.gnu.org/licenses/gpl-faq.html): Does the GPL require that source code of modified versions be posted to the public? The GPL does not require you to release your modified version. [...] But if you release the modified version to the public in some way, the GPL requires you to make the modified source code available to the program's users, under the GPL. If I know someone has a copy of a GPL-covered program, can I demand he give me a copy? No. The GPL gives him permission to make and redistribute copies of the program if he chooses to do so. He also has the right not to redistribute the program, if that is what he chooses. The GPL says that modified versions, if released, must be "licensed ... to all third parties." Who are these third parties? Section 2 says that modified versions you distribute must be licensed to all third parties under the GPL. "All third parties" means absolutely everyone--but this does not require you to *do* anything physically for them. It only means they have a license from you, under the GPL, for your version. Bernhard -- Intevation GmbH http://intevation.de/ Skencil http://skencil.org/ Thuban http://thuban.intevation.org/ _______________________________________________ python-de maillist - python-de@python.net http://python.net/mailman/listinfo/python-de

Bernhard Herzog wrote:
Das bezieht sich, wie der Satz sagt, auf "any work that you distribute or publish". Das heisst also, Du musst jedem, der die Software von Dir bekommt (direkt oder indirekt), erlauben, sie unter den Bedingungen der GPL nutzen zu dürfen. Es ergibt sich aber keine Verpflichtung, sie jemandem zu geben.
Den letzten Teil des Absatzes verstehe ich logisch nicht!? Wichtig ist an der Stelle aber vor allem, daß du deine Arbeit vertreibst bzw. veröffentlichst in dem Moment in dem du sie einem Kunden gibst. D.h. 'distribute or publish' gilt nicht erst, wenn du sie im Netz anbietest sondern sobald sie deine eigenen vier Wände für mehr als privaten Gebrauch verläßt.
Does the GPL require that source code of modified versions be posted to the public?
The GPL does not require you to release your modified version. [...]
Soweit klar. Hier zu Hause kann ich mit dem Code machen was immer ich will.
But if you release the modified version to the public in some way, the GPL requires you to make the modified source code available to the program's users, under the GPL.
Das bezieht sich erstmal nur auf den Kunden, aber ...
The GPL says that modified versions, if released, must be "licensed ... to all third parties." Who are these third parties?
Section 2 says that modified versions you distribute must be licensed to all third parties under the GPL. "All third parties" means absolutely everyone--but this does not require you to *do* anything physically for them. It only means they have a license from you, under the GPL, for your version.
... hier steht ganz klar 'absolutely everyone'. D.h. wenn du deinem Kunden X eine Änderung verkaufst, bin ich auch 'third party' und habe ein Recht auf deine Änderung. Du mußt die Änderung natürlich nicht supporten, dokumentieren oder sonstwas damit machen. Nur für mich verfügbar, also z.B. zum Download anbieten mußt du sie. BTW: Du scheinst mit OS Software dein Geld zu verdienen. Vieleicht solltet ihr mal schleunigst zum Anwalt gehen. Gruß, Achim _______________________________________________ python-de maillist - python-de@python.net http://python.net/mailman/listinfo/python-de

Achim Domma (Procoders) wrote:
Section 2 says that modified versions you distribute must be licensed to all third parties under the GPL. "All third parties" means absolutely everyone--but this does not require you to *do* anything physically for them. It only means they have a license from you, under the GPL, for your version.
... hier steht ganz klar 'absolutely everyone'. D.h. wenn du deinem Kunden X eine Änderung verkaufst, bin ich auch 'third party' und habe ein Recht auf deine Änderung.
Du mußt die Änderung natürlich nicht supporten, dokumentieren oder sonstwas damit machen. Nur für mich verfügbar, also z.B. zum Download anbieten mußt du sie.
Keine Ahnung, sie du zu dieser Schlussfolgerung kommst. Insbesondere, da du ja den nachfolgenden Satz ebenfalls zitierst: "but this does not require you to *do* anything physically for them." Das Schlüsselwort ist "license", im Gegensatz zu "give". Das heisst nur, das *wenn* jemand auf irgend eine Weise in den Besitz des Codes kommt, dass du ihm dann nicht verbieten kannst, ihn auch zu benutzen (und weiterzugeben). Eine Pflicht zur aktiven Verbreitung deinerseits geht daraus in keiner Weise hervor. Gleiches gilt auch für deinen Kunden: Er *kann* den Code weitergeben, muss aber nicht.
BTW: Du scheinst mit OS Software dein Geld zu verdienen. Vieleicht solltet ihr mal schleunigst zum Anwalt gehen.
Neben den schon erwähnten Gründen ist das ein weiterer Grund für mich, die GPL selber nicht zu verwenden. Das ist so ein verzwicktes mentales Konstrukt, dass nicht nur Laien, sondern öfters mal auch gestandene Juristen nicht mehr klar durchblicken, was da eigentlich verboten resp. erlaubt wird. -schorsch -- Georg Mischler -- simulations developer -- schorsch at schorsch com +schorsch.com+ -- lighting design tools -- http://www.schorsch.com/ _______________________________________________ python-de maillist - python-de@python.net http://python.net/mailman/listinfo/python-de

Am Mi, den 12.01.2005 schrieb Achim Domma (Procoders) um 15:16:
Bernhard Herzog wrote:
Soweit klar. Hier zu Hause kann ich mit dem Code machen was immer ich will.
But if you release the modified version to the public in some way, the GPL requires you to make the modified source code available to the program's users, under the GPL.
Das bezieht sich erstmal nur auf den Kunden, aber ...
The GPL says that modified versions, if released, must be "licensed ... to all third parties." Who are these third parties?
Section 2 says that modified versions you distribute must be licensed to all third parties under the GPL. "All third parties" means absolutely everyone--but this does not require you to *do* anything physically for them. It only means they have a license from you, under the GPL, for your version.
... hier steht ganz klar 'absolutely everyone'. D.h. wenn du deinem Kunden X eine Änderung verkaufst, bin ich auch 'third party' und habe ein Recht auf deine Änderung.
Das stimmt so nicht, der Kunde, der die Software erhalten hat, kann bei GPL Software den Quellcode anfordern und muss ihn bekommen. Er hat des weiteren das Recht das Programm und den Code an jeden beliebig oft weiterzugeben, nicht mehr und nicht weniger. Ich kann auch ein Programm schreiben, es unter die GPL stellen, und es für immer auf meiner Festplatte liegen lassen, ins Netz stellen muss ich da noch lange nix, denn das Urheberrecht liegt immer noch bei mir, und ich kann mit meinem Code machen, was ich will. Wenn ich eine GPL-Software modifiziere, und diese weitergebe, dann muss ich das auch unter der GPL tun, und damit natürlich auch die Quellen offen legen, d.h. aber nicht, dass jeder freien Zugriff darauf in Form von einem kostenlosen Download etc. haben muss, sondern nur die, an die ich das Programm weiter gebe. Wie die Weitergabe geschieht, liegt in meiner Entscheidung, d.h. ich kann es auch kommerziell tun, indem ich mir den Service der Modifikation, die ich vorgenommen habe, bezahlen lasse bspw. Guck Dir doch mal die Enterprise Linux-Distributionen (Redhat z.B.) an: Die bieten veränderte GPL Software für Geld an, sie liefern natürlich auch alle Sourcen mit, aber deswegen stellen die das dennoch nicht kostenlos für alle zum Download zur Verfügung. Diese Vorgehensweise ist völlig GPL-konform, ansonsten würde die FSF sicherlich rechtlich gegen sämtliche kommerziellen Distributoren vorgehen. Natürlich hat jeder, der eine solche Distribution gekauft oder auf anderem Wege erhalten hat, das Recht diese beliebig oft, und an jeden unter den Vorzeichen der GPL (und der anderen Lizenzen, die in verschiedenen Projekten verwendet werden) weiterzugeben, ein einklagbares Recht auf Erhalt dieser Software, gibt es aber nicht. André _______________________________________________ python-de maillist - python-de@python.net http://python.net/mailman/listinfo/python-de

Georg Mischler wrote:
Das heisst nur, das *wenn* jemand auf irgend eine Weise in den Besitz des Codes kommt, dass du ihm dann nicht verbieten kannst, ihn auch zu benutzen (und weiterzugeben). Eine Pflicht zur aktiven Verbreitung deinerseits geht daraus in keiner Weise hervor. Gleiches gilt auch für deinen Kunden: Er *kann* den Code weitergeben, muss aber nicht.
Ok, da ist was dran. Ich hab' das wohl mit der Lizenz der BerkeleyDB verwechselt. Die haben explizit verlangt, daß Software basierend auf ihrer Engine aktiv frei verfügbar gemacht wird. Aber gut, daß wir die Diskussion hatten. Von dem Standpunkt aus eröffnet das neue Denkmodelle mit GPL Software Geld zu verdienen! ;-) Gruß, Achim _______________________________________________ python-de maillist - python-de@python.net http://python.net/mailman/listinfo/python-de

ßt die Änderung natürlich nicht supporten, dokumentieren oder
sonstwas damit machen. Nur für mich verfügbar, also z.B. zum Download anbieten mußt du sie.
Keine Ahnung, sie du zu dieser Schlussfolgerung kommst. Insbesondere, da du ja den nachfolgenden Satz ebenfalls zitierst: "but this does not require you to *do* anything physically for them."
Das Schlüsselwort ist "license", im Gegensatz zu "give".
Das heisst nur, das *wenn* jemand auf irgend eine Weise in den Besitz des Codes kommt, dass du ihm dann nicht verbieten kannst, ihn auch zu benutzen (und weiterzugeben). Eine Pflicht zur aktiven Verbreitung deinerseits geht daraus in keiner Weise hervor. Gleiches gilt auch für deinen Kunden: Er *kann* den Code weitergeben, muss aber nicht.
Das geht ja auch nicht. Sonst gäbe es ja tausende von neuen Vesionen von abertausenden softwarpaketen. Wo soll das alles sein? -- Roland Kruggel IT-Security Coordinator Tel.: 02351 668446 Mobil: 0179 4808083 ICQ: 317-130-354 Internettelefonie Skype: rkruggel _______________________________________________ python-de maillist - python-de@python.net http://python.net/mailman/listinfo/python-de
participants (10)
-
Achim Domma (Procoders)
-
Andreas Wapf
-
André Kelpe
-
Bernhard Herzog
-
Diez B. Roggisch
-
Georg Mischler
-
Hartmut Goebel
-
Roland M. Kruggel
-
Thomas Flaig
-
Wolfgang Keller