Quellcode von Programmierarbeiten freigeben? Pflicht?

[MrUnbekannt]

Guten Tag,

nehmen wir an, ein AN arbeitet in einer SW-lastigen Abteilung bei einem Konzern, wo er eine koordinative Tätigkeit inne hat. Ihm fällt auf, dass es Arbeitsabläufe gibt, die sehr häufig auftreten und weil er Lust auf programmieren hat, entwickelt er ein Tool, mit welchem sich diese Abläufe automatisieren lassen. Er teilt die Idee seinem Gruppenleiter mit, um sich abzusichern, dass dieser ihm nicht kurzfristig neue andere Projekte vergibt - der Gruppenleiter findet die Idee klasse und sagt, der Mitarbeiter solle doch weiterentwickeln, weil das Tool klasse zu sein scheint. Das ganze Tool spart enorm Zeit, wobei auch andere Mitarbeiter an dessen Verwendung Interesse haben.

Nun ist die Frage:
Muss der AN den Quellcode für das Tool rausgeben?
Im Prinzip handelt es sich ja um die Idee des Mitarbeiters und aufgrund des Toolpotentials möchte er natürlich persönliche Vorteile dadurch rausschlagen; und außerdem verhindern, dass das Tool hinterher von einer zentralen Toolabteilung des Konzerns vereinnahmt und gepflegt wird. Er will, dass es "sein" Baby bleibt. Er möchte versuchen, darüber seine Entgeltstufe durch "Zusatzverantwortung" bei dem nächsten Mitarbeitergespräch über das Tool hoch-zu-argumentieren. Patentwürdig ist das Tool nicht, falls die Frage aufkommt, denn es geht dabei nur um interne Arbeitsabläufe.

Auf der einen Seite ist der Mitarbeiter natürlich über seinen festen Arbeitslohn entlohnt, und daher könnte man davon ausgehen, dass ALLES, was er macht, danach Eigentum der Firma ist. Aber die Frage ist natürlich, ob das tatsächlich so ist, oder ob dies im vorliegenden Falle anders zu bewerten ist, da der Mitarbeiter ja nicht als Entwickler / Programmierer eingestellt ist, sondern dies "frei" dem Programmierwunsch des Mitarbeiters entsprungen ist.

Danke vorab!

[deGier]

Nun ist die Frage:
Muss der AN den Quellcode für das Tool rausgeben?

Ja.

[SusanneBerlin]

Auf der einen Seite ist der Mitarbeiter natürlich über seinen festen Arbeitslohn entlohnt, und daher könnte man davon ausgehen, dass ALLES, was er macht, danach Eigentum der Firma ist. Aber die Frage ist natürlich, ob das tatsächlich so ist,

Ja das ist tatsächlich so.

da der Mitarbeiter ja nicht als Entwickler / Programmierer eingestellt ist, sondern dies "frei" dem Programmierwunsch des Mitarbeiters entsprungen ist.

Auch ein Arbeitnehmer, der mal in einer anderen Abteilung aushilft oder etwas tut, das nicht in seiner Stellenbeschreibung steht, darf deswegen nicht das Ergebnis seiner Arbeit behalten. Auch dann nicht, wenn es seine eigene Idee war, dass er ein für die Firma nützliches Produkt oder tool herstellen könnte, das normalerweise gar nicht seine Aufgabe ist.

Z.B. wenn wir das auf den Bereich der nicht-geistigen, mit Händen getanen Arbeit und einem materiellen Arbeitsergebnis übertragen: ein Programmierer in einem TV- Geräte herstellenden Betrieb, der auf eigenen Wunsch einen Tag in der Produktion aushilft und dabei einen Fernseher zusammenbaut, der darf auch nicht den Fernseher, den er selbst zusammengebaut hat, behalten mit dem Argument, dass Fernseher zusammenbauen nicht die Arbeit ist, für die er eingestellt worden ist.

Er will, dass es "sein" Baby bleibt. Er möchte versuchen, darüber seine Entgeltstufe durch "Zusatzverantwortung" bei dem nächsten Mitarbeitergespräch über das Tool hoch-zu-argumentieren.

Das kann er doch auch versuchen unabhängig davon, dass der Quellcode der Firma gehört.

Er sollte jedoch vermeiden, dass der Eindruck entsteht, er würde einen Deal "Herausgabe des Quellcodes gegen Gehaltserhöhung" versuchen. Das könnte übel genommen werden und nach hinten losgehen.

[gmmg]

Für Software bestehen eigenständige Regeln im Urheberrecht. Gut dargelegt ist das hier: http://www.it-recht-kanzlei.de/umfang-n ... ehmer.html

Folgender Abatz ist hier interessant:

Im Arbeits- und Dienstvertrag gilt aber grundsätzlich auch die Zweckübertragungsregel. Danach wird im Zweifel zu Lasten des Rechteerwerbers (hier Arbeitgeber) angenommen, dass der Urheber (hier Arbeitnehmer) ein Nutzungsrecht nur in demjenigen Umfang einräumen will, den der Vertragszweck unbedingt erfordert (siehe Zweckübertragungsregel ). Im Zweifel verbleiben also die Nutzungsrechte beim Arbeitnehmer oder Beamten. Die Beweislast trägt der Arbeitgeber oder Dienstherr. Die Einräumung der Nutzungsrechte wird nicht gesondert vergütet, sondern sie ist mit dem Arbeitslohn abgegolten.

Ob nun der Vertragszweck nur die Einräumung der Nutzungsüberlassung dieser Software oder auch die Verfügbarmachung des Quellcodes einschliesslich dem Recht der Änderung umfasst, darüber lässt sich streiten.

[Evariste]

Folgender Abatz ist hier interessant:

Die Überschrift zu dem Absatz ist aber auch interessant, da steht nämlich:

Nutzungsrechte an Werken mit Ausnahme von Computerprogrammen

... und auf der nächsten Seite steht dann:

Für Computerprogramme einschließlich des Entwurfsmaterials im Sinne von § 69a UrhG gilt eine von § 43 UrhG abweichende Regelung gemäß § 69b UrhG. Hiernach ist festgelegt, dass für Computerprogramme, die von einem Arbeitnehmer oder Beamten in Wahrnehmung seiner Aufgaben nach den Anweisungen seines Arbeitgebers oder Dienstherrn geschaffen werden, ausschließlich der Arbeitgeber oder Dienstherr zur Ausübung*aller vermögensrechtlichen* Befugnisse berechtigt ist, sofern nichts anderes vereinbart ist (gesetzliche Lizenz). Einer Verfügung des Arbeitnehmers zur Übertragung der Rechte bedarf es somit nicht.

[gmmg]

Na dann ist der Drops wohl gelutscht, bzw. der AN muss wohl sämtliche Zutaten herausrücken und bekommt nichts weiter vom Kuchen ab.

[matthias.]

Im Prinzip handelt es sich ja um die Idee des Mitarbeiters und aufgrund des Toolpotentials möchte er natürlich persönliche Vorteile dadurch rausschlagen; und außerdem verhindern, dass das Tool hinterher von einer zentralen Toolabteilung des Konzerns vereinnahmt und gepflegt wird. Er will, dass es "sein" Baby bleibt. Er möchte versuchen, darüber seine Entgeltstufe durch "Zusatzverantwortung" bei dem nächsten Mitarbeitergespräch über das Tool hoch-zu-argumentieren.

Man glaubt also AG lassen sich gerne erpressen?


Es spricht nichts dagegen beim Mitarbeitergespräch darauf hin zu weisen, dass man durch diese Tool dem AG z.b. eine Summe X.- € gespart hat oder allgem die Arbeitsabläufe stark verbessert hat.
Man sollte schon sein Licht unter dem Scheffel hervor ziehen.

Aber quasie damit zu drohen, wenn man keine Gehaltserhöhung bekommt, den Quellcode zu behalten und damit für den AG unkalkulierbar zu machen, kommt gar nicht gut im Sinne einer vertrauensvollen Zusammenarbeit.

Von solchen Spielchen sollte man Abstand nehmen und einfach seine Arbeit für sich sprechen lassen, ohne Drohungspotential.

[fodeure]

Ich denke hier überschätzt jemand ganz gewaltig seinen Wert für das Unternehmen. Ein Tool, welches in einer überschaubaren Zeit von einer einzigen Person (Hobbyprogrammierer?) entwickelt wurde, die offensichtlich nicht voll ausgelastet ist, kann sicherlich notfalls auch von der zuständigen Fachabteilung mit vertretbarem Aufwand entwickelt werden, wenn es denn als erfoderlich angesehen wird.

[MrUnbekannt]

Danke euch allen, das hat für mich schon viel aufgeklärt!

Im Prinzip handelt es sich ja um die Idee des Mitarbeiters und aufgrund des Toolpotentials möchte er natürlich persönliche Vorteile dadurch rausschlagen; und außerdem verhindern, dass das Tool hinterher von einer zentralen Toolabteilung des Konzerns vereinnahmt und gepflegt wird. Er will, dass es "sein" Baby bleibt. Er möchte versuchen, darüber seine Entgeltstufe durch "Zusatzverantwortung" bei dem nächsten Mitarbeitergespräch über das Tool hoch-zu-argumentieren.

Man glaubt also AG lassen sich gerne erpressen?

Stimmt, das klang tatsächlich etwas danach, wobei ich das so gar nicht gemeint hatte. Erpressen will hier niemand niemanden; wie gesagt, es ging eher darum, über das Potential im Gespräch seine Einstufung hoch-zu-argumentieren. Quellcode muss man dann früher oder später wohl sowieso rausgeben, aber der AN möchte das nur deswegen rauszögern, damit niemand "sein" Baby vereinnahmt und er eben in der Verantwortung bleibt. Aber ich denke, das wird so oder so so bleiben

Ich denke hier überschätzt jemand ganz gewaltig seinen Wert für das Unternehmen. Ein Tool, welches in einer überschaubaren Zeit von einer einzigen Person (Hobbyprogrammierer?) entwickelt wurde, die offensichtlich nicht voll ausgelastet ist, kann sicherlich notfalls auch von der zuständigen Fachabteilung mit vertretbarem Aufwand entwickelt werden, wenn es denn als erfoderlich angesehen wird.

Da ist was wahres dran, aber ich sage mal so: Wenn die Abteilung (und ja, es geht hier um das Kerngeschäft eines Mrd-Konzerns) es nach 15 Jahren immer noch nicht hinbekommen hat (und ja, dort arbeiten Hunderte Mitarbeiter alleine in diesem Umfeld), etwas auf die Beine zu stellen, das nur ansatzweise an das beschriebene Tool heranragt, darf ein AN sich sicherlich etwas darauf einbilden. Das Problem liegt vermutlich eher darin, dass eine zentrale Toolentwicklungsstelle einfach nicht das KnowHow der internen Arbeitsabläufe besitzt und es sehr schwierig wäre, alle Sonderfälle zu vermitteln usw. Aber darum soll sich die Diskussion hier sowieso nicht drehen.

[webelch]

Wenn die Abteilung (und ja, es geht hier um das Kerngeschäft eines Mrd-Konzerns) es nach 15 Jahren immer noch nicht hinbekommen hat (und ja, dort arbeiten Hunderte Mitarbeiter alleine in diesem Umfeld), etwas auf die Beine zu stellen, das nur ansatzweise an das beschriebene Tool heranragt, darf ein AN sich sicherlich etwas darauf einbilden.

Ich hoffe für den AN sehr, dass Eigen- und Fremdwahrnehmung hier nicht zu stark auseinanderfallen.

[windalf]

Da ist was wahres dran, aber ich sage mal so: Wenn die Abteilung (und ja, es geht hier um das Kerngeschäft eines Mrd-Konzerns) es nach 15 Jahren immer noch nicht hinbekommen hat (und ja, dort arbeiten Hunderte Mitarbeiter alleine in diesem Umfeld), etwas auf die Beine zu stellen, das nur ansatzweise an das beschriebene Tool heranragt, darf ein AN sich sicherlich etwas darauf einbilden.

Das Problem ist ja meist nicht die Software sondern das Verständnis dafür was nun genau überhaupt zu programmieren ist. Daran mangelt es insbesondere angestellten Programmierern gern.

Hinzu kommt wenn du das in einem großen Konzern machen lassen möchtest darfst du ja meist die dafür zuständige IT-Abteilung damit beschäftigen. Die Stellen dann einen Projektleiter, schreiben Seitenweise auf was zu tun ist, diverse Programmierer denen erklärt werden muss was genau zu tun ist plus massenweise nicht funktionale Anforderungen die der CIO-Bereich verlangt, damit das programmiert wird. Da ist die Summe schon sechsstellig wenn nur "Hello World" gebaut werden soll.

Deshalb gibt es in größeren Konzernen ja oft den Wildwuchs, dass sich in den Abteilungen jeder selbst nen Server unter den Tisch stellt, weil man a) auf Lösungen Jahrelang warten muss und b) dann nicht das bekommt was man bestellt hat. Kommt dann aber Wanna Cry oder ähnliches um die Ecke führt das gern mal zu riesen Problemen.

Der eigentliche Mehrwert ist ja auch nicht der Code (es sei den da sind irgendwelche Algorithmen drin verbaut, die die Welt noch nicht kennt) sondern die Strukturierungsleistung das Problem genau so abzubilden, wie man es benötigt.

Ich hoffe für den AN sehr, dass Eigen- und Fremdwahrnehmung hier nicht zu stark auseinanderfallen.

Naja ich kenne das Thema zur genüge. Ich habe diverse kleine Tools/Prototypen gebaut, die es eigentlich nicht mehr geben dürfte und schon lange in eine große IT-Lösung gegossen werden sollten. Gefühlt überleben solche Protoypen in Konzernen 5-10 Jahre bis das endlich mal in die IT mit übernommen wird. Entweder ist die NUmemr dann shcon überflüssig geworden weil es was Neues gibt oder aber man hat es dann endlich geschafft das abzubilden. (Mit Releasezyklen von 6 Monaten die die Nutzer in den Wahnsinn treiben) So lange warten und schlecht arbeiten will aber keiner. Also nutzen alle das kleine Tool, was jemand an ein paar Wochenenden zusammengeschraubt hat und mal eben schnell und kurzfristig angepasst werden kann.

[MrUnbekannt]

@webelch:
Es ist genau, wie Windalf schreibt.
Meine 7000 Zeilen kompakter Pythoncode (EDIT: zzgl 10000 Zeilen Code von einem Parser eines Kollegens, der mir das freundlicherweise zur Verfügung gestellt hat -> also sicherlich nicht mal so eben in einer "gescheiten" Sprache nachgebildet) sind sicherlich nicht DAS Problem, wenn überhaupt die Logik aufgrund der Arbeitsabläufe dahinter. Wobei ich davon ausgehe, dass eine Toolabteilung sowas in einer "gescheiten" Sprache wie C#, Java o.ä. programmieren würde, wenn auch nicht notwendig. Das würde den zeitlichen Umfang sicher enorm aufblähen, in Python geht das prototypen ja seeehr sehr schnell (rapid ) Und mit Sicherheit ist da noch der ein oder andere Bug oder nicht abgefangene Fall im Code, aber hauptsache ist, wir haben überhaupt etwas (und das funktioniert zu 99%!).

Aber weder gibt es hier eine Toolabteilung, die sowas bauen würde (damit die sowas übernehmen, müsste es dann wieder die global-galaktische Superlösung sein, die ALLES kann), noch kann man die Arbeitsweisen und Ablagestrukturen in Lastenheften erklären usw. Toolabteilungen würden wahrscheinlich besseren und ISO26262 und FMEA und schlagmichtot-zertifizierten Code schreiben, aber die Features nicht so umsetzen, wie benötigt. Außerdem sind viele Probleme erst bei der Entwicklung aufgefallen, die es zu lösen gab, von denen niemand wusste.

Aber ist auch egal, darum soll es nicht gehen, wir driften vom Thema ab. Jeder der mal in einem Mrd-Konzern gearbeitet hat, wird wissen, woran es da mangelt.

Und last but not least -> ich wurde ja auch schon von diversen Abteilungsleitern dafür gelobt und es wurde mehrfach gesagt, was für ein "tolles Weihnachtsgeschenk" ich der Firma damit gemacht habe (O-Ton, ich muss mich hier sicherlich nicht anonym beweihräuchern) usw... Nun müssen den Worten der großen Herren eben auch Taten folgen.

Die Ursprungsfrage wurde auf jeden Fall geklärt, dafür danke allen Beteiligten.

[matthias.]

Die Ursprungsfrage wurde auf jeden Fall geklärt, dafür danke allen Beteiligten.

Das ist doch schön!