Was sollte jeder Entwickler über rechtliche Angelegenheiten wissen? [geschlossen]

Heute hatte ich eine schlimme Überraschung, als ich etwas über die Auswirkungen der GPL-Lizenz erfuhr, hauptsächlich, dass ich sie nicht so frei nutzen konnte, wie ich dachte.

Jetzt weiß ich.

Was sollte ich noch wissen und was sollte jeder Entwickler über solche rechtlichen Dinge wissen?

Sie können Mitarbeiter, Freiberufler, Open-Source-Projektmitarbeiter (usw.) trennen oder eine umfassendere Antwort geben.

Zwölf rechtliche Überlegungen zur Softwareentwicklung

1. Software ist urheberrechtlich geschützt, wenn sie der Öffentlichkeit zugänglich gemacht wird. Es ist nicht mehr erforderlich, einen Copyright-Hinweis auf die Anwendung oder den Quellcode zu setzen. Der Inhaber des Urheberrechts ist der Autor oder die Firma, die den Autor bezahlt.

2. Das Urheberrecht an Software kann vom Inhaber des Urheberrechts übertragen werden, oder es kann vom Eigentümer beibehalten werden, und die Software kann dem Benutzer oder den Benutzern vom Eigentümer lizenziert werden.

3. In der Entwicklung verwendete Bibliotheken unterliegen wahrscheinlich Einschränkungen in ihrer Verwendung und Verteilung. Die GPL macht eine Bibliothek weder gemeinfrei noch die Tatsache, dass die Bibliothek mit einer Entwicklungsplattform ausgestattet ist. Sie sollten die Lizenz lesen und verstehen, bevor Sie Ihre Anwendung verteilen. Einige Bibliotheken verlangen Lizenzgebühren, obwohl dies in den letzten Jahren seltener geworden ist.

4. Software-Patentklagen sind Misttriebe. Sie sollten ein Softwarepatent natürlich nicht wissentlich verletzen. Es besteht jedoch eine kleine, aber echte Chance, dass ein Unternehmen Sie wegen Verletzung seines Patents verklagt. Dies kann auch dann passieren, wenn Sie Ihre Software unabhängig entwickeln, noch nie von dem Patent gehört haben und das Patent eine Technik abdeckt, die intuitiv offensichtlich ist und fast nichts mit Ihrer Software zu tun hat. Angesichts der aktuellen USPTO-Richtlinien können Sie nicht viel tun, um dies zu vermeiden, außer eine Versicherung abzuschließen. Die gute Nachricht ist, dass Patenttrolle im Allgemeinen große Unternehmen mit viel Geld verklagen.

5. Wenn Sie einen Mitarbeiter oder Freiberufler zur Entwicklung von Software einsetzen, sollten Sie schriftlich klarstellen, wem das Urheberrecht an der Anwendung einschließlich des Quellcodes gehört. Einige Freiberufler und Vertragsentwicklungsunternehmen betrachten den Quellcode als ihr eigenes Eigentum, sodass das Unternehmen von den ursprünglichen Entwicklern abhängig ist. Dies ist legal, wenn es in der Entwicklungsvereinbarung steht.

6. Wenn Sie einen Mitarbeiter haben, der Software "rund um die Uhr" entwickelt, sollten Sie klarstellen, wem diese Software gehört und welche Art von Software der Mitarbeiter außerhalb des Unternehmens schreiben und vertreiben kann.

7. Wenn Sie ein Mitarbeiter oder Freiberufler sind, der Software entwickelt, sollten Sie klarstellen, wem das Urheberrecht an Ihrer Anwendung gehört, bevor Sie mit der Entwicklung beginnen. Außerdem sollten Sie wissen oder klären, wem Software gehört, die Sie in Ihrer Freizeit schreiben. Einige Unternehmen haben Klauseln in Arbeitsverträgen, die das Eigentum an Software beanspruchen, die von einem Entwickler während der Beschäftigungszeit geschrieben wurde, sei es zu Hause oder bei der Arbeit. Viele Unternehmen haben Wettbewerbsverbote in Arbeitsverträgen, die die Software einschränken, die ein Mitarbeiter für den Vertrieb außerhalb des Unternehmens produzieren kann. Manchmal sind diese Einschränkungen ziemlich weit gefasst.

8. Eine Marke ist ein Name oder ein Symbol, nicht die Software selbst. Wenn Sie Software vertreiben, sollten Sie (a) sicherstellen, dass Ihr Anwendungsname und Ihre "Marke" oder das Design des Namens nicht "verwirrend ähnlich" mit anderen Anwendungen sind, und (b) Ihre Marke registrieren. Das Datum der ersten Verwendung ist wichtig für die Lösung von Konflikten. Sie sollten daher dokumentieren, wann die Anwendung zum ersten Mal im Handel verwendet wird.

9. Wenn Sie eine Anwendung benennen, suchen Sie nach eingetragenen Marken, aber auch nach Google. Eine Anmeldung mit erstmaliger Verwendung des Namens kann möglicherweise Ihren Namen und Ihre Marke übernehmen, nachdem Ihre Anmeldung erfolgreich war, auch wenn sie die Marke nicht registriert hat und Sie dies getan haben.

10. Wenn Sie einen Vertrag oder eine Vereinbarung verwenden oder unterzeichnen, stellen Sie sicher, dass beide Parteien ihn verstehen. In einem Arbeitsvertrag kann die Erwähnung potenziell sensibler Bereiche im Vorfeld später viele Probleme verhindern. Wenn in einer Entwicklungsvereinbarung beide Parteien wissen, wem der Quellcode gehört, wer für Upgrades verantwortlich ist oder wer für die Wartung usw. verantwortlich ist, die in das Entwicklungsprojekt einfließen, ist die Wahrscheinlichkeit einer Klage nach der Anwendung viel geringer Wurde vervollständigt. Stellen Sie in einer Vertriebsvereinbarung sicher, dass der Vertriebshändler die Verantwortlichkeiten und die Laufzeit der Vereinbarung versteht.

11. Jede nicht triviale Anwendung hat Fehler (oder "Designüberlegungen" :-)). Jede Benutzervereinbarung oder Vertriebsvereinbarung sollte klarstellen, dass Sie nicht für fehlerfreie Software verantwortlich sind und nicht erwartet werden kann, dass alle Fehler behoben werden. Stellen Sie klar, dass Änderungen, Korrekturen und Upgrades nach Wahl (oder nach besten Kräften) des Entwicklers vorgenommen werden, und machen Sie deutlich, wer für Fixes und Upgrades bezahlt.

12. Selbst nachdem Sie einen Anwalt zu Softwareentwicklungs- und Vertriebsvereinbarungen konsultiert haben, sollten Sie die Vereinbarungen anderer Softwareunternehmen lesen und sehen, was deren Anwälte sich ausgedacht haben.

13. Ich bin kein Anwalt, und dies ist keine Rechtsberatung.

Wenden Sie sich im Zweifelsfall an einen Anwalt.

Ich bin kein Anwalt, aber im Laufe der Zeit habe ich einige Faustregeln von juristischen Personen gesammelt, mit denen Sie Zeit sparen können:

• Die GPL-Lizenz ist "copy-left" oder "viral". Dies bedeutet, dass jeder Code, den Sie schreiben und der von einer GPL-Komponente abhängt, auch unter der GPL freigegeben werden muss. Als Faustregel gilt: Wenn Sie zum Kompilieren Ihrer Software eine GPL-Komponente benötigen, muss Ihre Software unter einer GPL-Lizenz veröffentlicht werden.
• Sie sind nicht verpflichtet, Ihre Quelle zur Verfügung zu stellen, wenn Sie Ihre Software nicht vertreiben. Wenn Sie die Software beispielsweise für interne Zwecke oder auf einem Webserver ausführen, müssen Sie die Quelle nicht freigeben. Aus diesem Grund muss Google keine Software veröffentlichen, die GPL-Bibliotheken verwendet. Es war ein wichtiger Streitpunkt in GPL v3.
• Für LGPL (Library oder Lesser GPL) müssen Sie Ihren eigenen Quellcode nur dann GPL, wenn Sie die LGPL-ed-Bibliothek so einbinden, dass sie unersetzlich wird. Ihre eigene Software muss keine GPL sein, wenn Sie nur die Bibliothek "verwenden". Das Einfügen von Header-Dateien und das Verknüpfen mit einem .dll/ .soder Bibliothek ist eine der Möglichkeiten, LGPL-ed-Code unverbindlich zu verwenden, mit Ausnahme des entsprechenden Copyright-Hinweises.
• Mit der BSD-Lizenz (die Apache-Lizenz ist sehr ähnlich) können Sie kommerzielle Erweiterungen erstellen, die die Open Source-Komponente verwenden. Aus diesem Grund hat Apple FreeBSD anstelle von Linux als Kernel für OSX ausgewählt.
• MPL ist sehr kommerziell freundlich, da Netscape dachte, dass sie zum Zeitpunkt der Lizenzerstellung mit Mozilla etwas Geld verdienen könnten.

Es ist oft hilfreich, den Betreuer des Open Source-Projekts zu kontaktieren. Sie sind am besten in der Lage, Sie über die ursprüngliche Absicht der Lizenz sowie über ihre eigenen Ansichten zu Open Source zu beraten. Manchmal sind Betreuer bereit, Software unter mehreren Lizenzen freizugeben, um Ihnen zu helfen. Oft sind sie nicht. Hängt von der Person ab, die das Urheberrecht besitzt.

Das KDE-Projekt verfügt über eine praktische Matrix

Ich denke, der Rechtsleitfaden zur Web- und Softwareentwicklung von Stephen Fishman Attorney ist genau das, wonach Sie suchen.

Rezension

Ein tolles Buch! Beantwortet fast alle rechtlichen Fragen, die Sie sich vorstellen können, und einige, an die Sie nie gedacht hätten. - John Dvorak, PC Magazine

Deckt jedes erdenkliche Detail ab, das für ein so schnell wachsendes und immaterielles Medium wichtig ist. -- Unternehmer

Dieses Buch besteht meinen persönlichen Test für Rechtsführer - mit höheren Noten als jeder andere Rechtsführer. - Jeff Duntemann, Herausgeber, PC Techniques Magazine

Produktbeschreibung

Schützen Sie Ihre Rechte und Ihre harte Arbeit!

Die Gesetze zur Entwicklung von Websites und Software sind komplex und verwirrend. Wenn Sie sie jedoch nicht entwirren, kann dies Tausende von Dollar an Anwaltskosten und Gerichtsverfahren kosten.

Glücklicherweise entschlüsselt Legal Guide to Web & Software Development diesen komplexen Rechtsbereich gründlich und in leserfreundlichem Englisch. Es enthält auch Verträge, Vereinbarungen und Rechtsformulare auf CD-ROM mit schrittweisen Anweisungen zum Ausfüllen, sodass Sie Ihre Software und Website schützen können, ohne das Lösegeld eines Anwalts zu zahlen.

Verwenden Sie den rechtlichen Leitfaden zur Web- und Softwareentwicklung, um Folgendes zu erfahren:

• Welche Art von Rechtsschutz benötigen Sie?
• die Stärken und Grenzen jeder Art von Schutz
• wie man Verstöße vermeidet
• Welche Bestimmungen benötigen Sie bei der Ausarbeitung einer Vereinbarung?
• wie man die Erlaubnis erhält, Materialien anderer Leute zu verwenden

Sie finden eine vollständige, schrittweise Anleitung zum Entwurf:

• Arbeitsverträge
• Vereinbarungen zwischen Auftragnehmern und Beratern
• Entwicklungsvereinbarungen
• Lizenzvereinbarungen

Die 5. Ausgabe des Legal Guide to Web & Software Development wurde vollständig aktualisiert, um die neueste Rechtsprechung und gesetzliche Überarbeitungen bereitzustellen.

Einige andere Vorschläge:

• Für sich selbst arbeiten: Recht und Steuern für unabhängige Auftragnehmer, Freiberufler und Berater (gleicher Autor).
• Vereinbarungen mit Beratern und unabhängigen Auftragnehmern (gleicher Autor).
• Handbuch zur Softwarelizenzierung von Jeffrey I. Gordon.
• Praktischer Leitfaden zur Softwarelizenzierung für Lizenznehmer und Lizenzgeber von H. Ward Classen.
• The Tech Contracts Pocket Guide: Software- und Serviceverträge für Verkäufer, Vertragsmanager, Geschäftsentwickler und Anwälte von David Tollen.

Wenn Sie Freiberufler oder Auftragnehmer sind: Stellen Sie sicher, dass Sie über eine gute Haftpflichtversicherung verfügen und wissen, was darunter abgedeckt ist.

Zum Beispiel übernimmt meine nicht die Haftung für Fehler im Code, die Kreditkartennummern offenlegen könnten. Also fasse ich das Zeug nicht mehr an!

Für Mitarbeiter: Wir sollten in der Lage sein, Ihren Kunden eine erste Beratungsrunde zu geben - wie können sie / wir die gewünschte Komponente in ihrer Anwendung verwenden?

Für Freiberufler: Wir müssen in der Lage sein, Ihre Kunden stark zu beraten. und wählen Sie aus, welche Komponenten wir für die Anwendungen verwenden können, die wir für sie entwickeln.

Natürlich ist Ihr Wort nicht so gut wie die Ratschläge, die ein Anwalt Ihnen geben kann. aber Sie können bereits für eine erste Runde helfen; Zum Beispiel zu sagen "Wir können das definitiv nicht verwenden, weil es bedeuten würde ..."
Am Ende wird der Anwalt viel über Eckfälle wissen - aber wenn Sie ein bisschen helfen können ...

Für OSS-Mitwirkende: Es kann wichtig sein, einige Unterschiede zwischen kostenlosen Lizenzen zu kennen, wenn Sie sich darum kümmern, was Benutzer mit Ihrem Code tun können (neu verteilen, ändern, in kommerziellen Anwendungen verwenden, in proprietären Anwendungen verwenden?)

Eine Antwort hat behauptet, dass das Gesetz nicht wie Code ist. Ich stimme dir nicht zu.

In den frühen Tagen bezahlte IBM Programmierer durch die Anweisung. (Jemand, den ich kannte, sagte, er habe mit einem Programmierer zusammengearbeitet, der auf diese Weise reich geworden sei. Anscheinend wusste der Typ nicht, wie man das Indexregister der Maschine verwendet; er schrieb eine Routine für den Speicher Null, die manuell Null in jeder Speicheradresse speicherte.)

Es gab auch eine Zeit (vor langer Zeit), in der Anwälte nach dem Wort bezahlt wurden. Dies trug dazu bei, Praktiken wie die Ansprache von Menschen als "die am höchsten geschätzten so und so" und andere Ausführlichkeiten bekannt zu machen.

Ich habe gerade eine Antwort auf SO gelesen, dass VB.NET 2008 weiterhin Zeilennummern zulässt . Sie können immer noch reines DOS auf einem modernen PC ausführen. Und der Witz ist sehr wahr, dass alle COBOL-Programme durch inkrementelle Änderungen von einem gemeinsamen Vorfahren abstammen. Abwärtskompatibilität und "historische Gründe" sind in unserem Bereich weit verbreitet.

Dies ist vergleichbar mit dem Bereich des Rechts. Es gibt Gesetze, die kleine (oder große) Änderungen an anderen Gesetzen vornehmen. Du hast eine Art Abhängigkeitshölle. Es gibt einige lächerliche historische Gesetze (in Hobart, Tasmanien, ist es für einen Mann illegal, nach Sonnenuntergang ein Frauenkleid zu tragen - denn einst haben sich Sträflinge als Frauen verkleidet und Menschen überfallen), von deren Durchsetzung niemand träumen würde Es gibt einige historische Funktionen in Software, die niemand mehr verwendet.

Gesetze haben oft unbeabsichtigte Konsequenzen (Fehler!), Werden auf kreative Weise verwendet (Hacks!), Enthalten Lücken (Sicherheitslücken!), Von denen einige beabsichtigt sind (Hintertüren!), Werden geändert (Patches!) Oder umgestürzt (Deinstallation!) .

Ja, Gesetze (im Gegensatz zu Code) können interpretiert werden. Aber ich denke, das ist eher wie Code-Wartung. Es hilft, Gesetze an neue soziale Normen anzupassen.

Um die Frage direkt zu beantworten: Jeder Entwickler sollte wissen, dass das Gesetz eher wie ein lächerlich großes Softwareprojekt ist, das seit Hunderten von Jahren in der Entwicklung ist. (Tatsächlich hat jedes Land sein eigenes Projekt und sie lösen Probleme auf unterschiedliche Weise.) Theoretisch wissen Sie nach dem Lesen einer Lizenz, was Sie mit Ihrem Code tun können und was nicht. Aber wenn ein kompetenter Programmierer nicht alle Fehler in seinem Code erkennen kann, indem er ihn liest, welche Chance hat dann ein Nicht-Anwalt , die Eckfälle und Grauzonen eines Rechtsdokuments zu analysieren?

Wie beim Software-Quellcode erhalten Sie normalerweise den Kern eines Rechtsdokuments, indem Sie es lesen. Wenn Sie jedoch etwas Bestimmtes wissen müssen, wenden Sie sich an einen Fachmann .

NOLO (ich arbeite nicht für sie) veröffentlicht eine Reihe guter legaler Bücher für Laien.

http://www.nolo.com/products/a-legal-guide-to-web-&-software-development-SFT.html

Ich würde dies genauso beantworten wie "Was sollte jeder Anwalt über Programmierung wissen?" Das heißt, wissen Sie, dass es unmöglich ist, das Tiefenfeld gut genug zu kennen, um mehr als das Einfachste zu tun. Holen Sie sich einen Experten.

Sie sollten die grundlegenden Rechte und Pflichten der Lizenz kennen, die Sie verwenden möchten. Es ist nicht so schwer, und selbst wenn es viele davon gibt, müssen Sie nur die sorgfältig lesen, die Sie verwenden oder berühren werden. Lesen Sie sie einfach, in den meisten Fällen sind sie ziemlich klar.

Alles andere, was Sie brauchen könnten, hängt davon ab. Patentierung? Warenzeichen ? Wenn Sie diese Dinge benötigen, sind Sie wahrscheinlich in einem Unternehmen und haben eine Rechtsabteilung, die dies für Sie erledigt.

Ich würde immer davon ausgehen, dass die Entwickler eines Projekts möchten, dass Software, die ihre Arbeit verwendet, unter genau derselben Lizenz veröffentlicht wird. Lesen Sie die FAQs und rechtlichen Seiten, um weitere Informationen zu erhalten, und zögern Sie nicht, sich an die Entwickler / Betreuer zu wenden, wenn Sie sich immer noch nicht sicher sind.

Wenn Sie Hilfe beim Verständnis der Details einer Lizenzvereinbarung benötigen, wenden Sie sich an einen Anwalt.

1. Arbeiten Sie nicht in einem Land, in dem es mehr Anwälte als Entwickler gibt.
2. Ein extrem großer Prozentsatz aller (US-) Softwarepatente ist gefälscht, aber Sie können nicht bezahlen oder warten, bis sie ungültig werden.
3. Wenn Sie Open Source-Software verwenden / entwickeln möchten, verwenden Sie eine vorhandene Lizenz und ändern Sie sie nicht. Gehen Sie nicht in die Nähe der Grenzen dessen, was die Lizenz bedeuten soll.

Der Name eines guten IP-Anwalts.

6.Wenn Sie einen Mitarbeiter haben, der Software "rund um die Uhr" entwickelt, sollten Sie klarstellen, wem diese Software gehört und welche Art von Software der Mitarbeiter außerhalb des Unternehmens schreiben und vertreiben kann.

Das Recht auf freie Meinungsäußerung, wie es in den meisten Verfassungen angegeben ist (insbesondere wenn Entwickler außerhalb der Uhr s / w frei machen), kann dazu führen, dass solche Begriffe vor Gericht kläglich scheitern

Das Gesetz ist nicht wie Code. Es handelt sich nicht um eine Reihe von Schritten und Regeln, die eindeutig verstanden werden können.