web-dev-qa-db-fra.com

Que doit savoir chaque développeur sur les questions juridiques?

Aujourd'hui j'ai eu une mauvaise surprise en apprenant certaines implications de la licence GPL, principalement que je ne pouvais pas l'utiliser aussi librement que je le pensais.

Maintenant je sais.

Que dois-je savoir d'autre et, plus largement, que devrait savoir tout développeur sur des choses légales comme ça?

Vous pouvez séparer les employés, les indépendants, les contributeurs de projets open source (etc.) ou donner une réponse plus large.

open-sourcelicensing
80
marcgg

Douze considérations juridiques pour le développement de logiciels

  1. Le logiciel est protégé par le droit d'auteur s'il est mis à la disposition du grand public. Il n'est plus nécessaire de mettre une mention de copyright sur l'application ou dans le code source. Le titulaire du droit d'auteur est le ou les auteurs ou la société qui paie les auteurs.

  2. Le droit d'auteur du logiciel peut être attribué par le propriétaire du droit d'auteur, ou il peut être conservé par le propriétaire et le logiciel peut être concédé sous licence à l'utilisateur ou aux utilisateurs par le propriétaire.

  3. Les bibliothèques utilisées dans le développement ont probablement des restrictions dans leur utilisation et leur distribution. La GPL ne rend pas une bibliothèque publique, ni le fait que la bibliothèque soit livrée avec une plateforme de développement. Vous devez lire et comprendre la licence avant de distribuer votre application. Certaines bibliothèques exigent des redevances, bien que cela soit devenu moins courant ces dernières années.

  4. Les poursuites en matière de brevets logiciels sont des conneries. Bien entendu, vous ne devez pas violer sciemment un brevet logiciel. Cependant, il existe une petite mais réelle chance qu'une entreprise vous poursuive pour violation de son brevet. Cela peut se produire même si vous développez votre logiciel de manière indépendante, vous n'avez jamais entendu parler du brevet, et le brevet couvre une technique qui est intuitivement évidente et presque totalement sans rapport avec votre logiciel. Il n'y a pas grand-chose que vous puissiez faire pour éviter cela, étant donné les politiques actuelles de l'USPTO, à part acheter une assurance. La bonne nouvelle est que les trolls des brevets poursuivent généralement les grandes entreprises avec beaucoup d'argent.

  5. Si vous utilisez un employé ou un pigiste pour développer un logiciel, vous devez indiquer clairement, par écrit, à qui appartient le droit d'auteur sur l'application, y compris le code source. Certains pigistes et sociétés de développement de contrats considèrent le code source comme leur propre propriété, laissant l'entreprise dépendante du ou des développeurs originaux. C'est légal si c'est dans l'accord de développement.

  6. Si vous avez un employé qui développe des logiciels "hors horloge", vous devez indiquer clairement à qui appartient ce logiciel et quel type de logiciel l'employé devrait être en mesure d'écrire et de distribuer en dehors de l'entreprise.

  7. Si vous êtes un employé ou un pigiste développant un logiciel, vous devez indiquer clairement qui détiendra les droits d'auteur de votre application, avant de commencer le développement. En outre, vous devez savoir ou clarifier à qui appartient le logiciel que vous écrivez à votre rythme. Certaines entreprises ont des clauses dans les contrats d'emploi revendiquant la propriété de tout logiciel écrit par un développeur pendant la période d'emploi, que ce soit à la maison ou au travail. De nombreuses entreprises ont des clauses de non-concurrence dans les accords de travail qui restreignent les logiciels qu'un employé peut produire pour une distribution en dehors de l'entreprise. Parfois, ces restrictions sont assez larges.

  8. Une marque est un nom ou un symbole, pas le logiciel lui-même. Si vous distribuez un logiciel, vous devez (a) vous assurer que le nom et la "marque" ou la conception de votre application ne sont pas "similaires à la confusion" avec d'autres applications, et (b) enregistrer votre marque. La date de première utilisation est importante pour résoudre les conflits, vous devez donc documenter la première utilisation de l'application dans le commerce.

  9. Lorsque vous nommez une application, vérifiez les marques déposées, mais vérifiez également Google. Une application avec la première utilisation du nom peut être en mesure de prendre votre nom et votre marque une fois que votre demande a été acceptée, même si elle n'a pas enregistré la marque et vous.

  10. Lorsque vous utilisez ou signez un contrat ou un accord, assurez-vous que les deux parties le comprennent. Dans un contrat de travail, la mention préalable de toute zone potentiellement sensible peut éviter de nombreux problèmes ultérieurement. Dans un accord de développement, si les deux parties savent à qui appartient le code source, ou qui est responsable des mises à niveau, ou qui est responsable de la maintenance, etc., qui entrent dans le projet de développement, alors il y a beaucoup moins de chances de poursuite après l'application a été complété. Dans un accord de distribution, assurez-vous que le distributeur comprend les responsabilités et la durée de l'accord.

  11. Chaque application non triviale a des bugs (ou "considérations de conception" :-)). Tout accord d'utilisateur ou accord de distribution doit indiquer clairement que vous n'êtes pas responsable des logiciels sans bogues et que vous ne pouvez pas être amené à corriger tous les bogues. Indiquez clairement que les modifications, les correctifs et les mises à niveau sont effectués au choix (ou au mieux) du développeur, et indiquez clairement qui paie les correctifs et les mises à niveau.

  12. Même après avoir consulté un avocat au sujet des accords de développement et de distribution de logiciels, vous devriez lire les accords d'autres sociétés de logiciels et voir ce que leurs avocats ont trouvé.

  13. Je ne suis pas avocat et ce n'est pas un conseil juridique.

135
xpda

En cas de doute, contactez un avocat.

28
mmr

Je ne suis pas avocat mais au fil du temps j'ai rassemblé quelques règles empiriques de personnes juridiques que vous pouvez utiliser pour gagner du temps:

  • La licence GPL est "copiée à gauche" ou "virale". Cela signifie que tout code que vous écrivez qui dépend d'un composant GPL doit également être publié sous GPL. Une bonne règle d'or est que si vous avez besoin d'un composant GPL pour compiler votre logiciel, votre logiciel doit être publié sous une licence GPL.
  • Vous n'êtes pas obligé de rendre votre source disponible si vous ne distribuez pas votre logiciel. Par exemple, si vous exécutez le logiciel à des fins internes ou sur un serveur Web, vous n'avez pas besoin de libérer la source. C'est pourquoi Google n'a pas besoin de publier son logiciel qui utilise les bibliothèques GPL. C'était un point de discorde clé dans la GPL v3.
  • LGPL (Library ou Lesser GPL) ne vous oblige à GPL votre propre code source que si vous incorporez la bibliothèque LGPL-ed de telle manière qu'elle devienne irremplaçable. Votre propre logiciel n'a pas besoin d'être GPL si vous n'utilisez que la bibliothèque. Inclusion de fichiers d'en-tête et liaison avec un .dll/.so de la bibliothèque est l'une des façons dont vous pouvez "utiliser" le code édité par LGPL sans aucune obligation, à l'exception de la mention de copyright appropriée.
  • La licence BSD (la licence Apache est très similaire) vous permet de créer des extensions commerciales qui utilisent le composant open source. C'est pourquoi Apple a choisi FreeBSD sur Linux comme noyau pour OSX.
  • MPL est très commercial car Netscape pensait qu'ils pourraient gagner de l'argent avec Mozilla au moment où la licence a été écrite.

Il est souvent utile de contacter le responsable du projet Open Source. Ils sont les mieux placés pour vous conseiller sur l'intention initiale de la licence ainsi que sur leurs propres opinions sur l'open source. Parfois, les responsables sont prêts à publier des logiciels sous plusieurs licences pour vous aider. Ce n'est souvent pas le cas. Dépend de la personne qui détient le droit d'auteur.

Le projet KDE a un matrice pratique

26
leonm

Je pense que Guide juridique du développement Web et logiciel par Stephen Fishman L'avocat est ce que vous recherchez.

alt text

Examen

Un livre incroyable! Répond à presque toutes les questions juridiques que vous pouvez imaginer et auxquelles vous n'auriez jamais pensé. - John Dvorak, PC Magazine

Couvre tous les détails imaginables importants pour un milieu aussi rapide et intangible. -- Entrepreneur

Ce livre passe mon propre test personnel pour les guides juridiques - avec des notes plus élevées que tout autre guide juridique. - Jeff Duntemann, rédacteur en chef, PC Techniques Magazine

Description du produit

Protégez vos droits et votre travail acharné!

Les lois couvrant le développement de sites Web et de logiciels sont complexes et déroutantes, mais si vous ne les démêlez pas, cela pourrait vous coûter des milliers de dollars en honoraires d'avocat et en poursuites.

Heureusement, Legal Guide to Web & Software Development décode ce domaine complexe du droit, en profondeur et dans un anglais convivial. Il fournit également des contrats, des accords et des formulaires juridiques sur CD-ROM, avec des instructions étape par étape pour les remplir, afin que vous puissiez protéger votre logiciel et votre site Web sans payer la rançon d'un avocat.

Utilisez le Guide juridique du développement Web et logiciel pour apprendre:

  • de quel type de protection juridique vous avez besoin
  • les forces et les limites de chaque type de protection
  • comment éviter la contrefaçon
  • les dispositions dont vous avez besoin pour rédiger un accord
  • comment obtenir la permission d'utiliser le matériel d'autrui

Vous trouverez des instructions complètes, étape par étape, pour rédiger:

  • accords de travail
  • accords d'entrepreneur et de consultant
  • accords de développement
  • accords de licence

La 5e édition du Guide juridique du développement Web et logiciel est entièrement mise à jour pour fournir la dernière jurisprudence et les révisions statutaires.

Quelques autres suggestions:

8
Moayad Mardini

Si vous êtes un pigiste ou un entrepreneur: assurez-vous d'avoir une bonne assurance responsabilité civile et de savoir ce qui est couvert par celle-ci.

Par exemple, le mien ne couvre pas la responsabilité pour les erreurs de code susceptibles d'exposer les numéros de carte de crédit. Donc je ne touche plus à ça!

4
Jeremy McGee

Une réponse a affirmé que la loi n'est pas comme le code. Je ne suis pas d'accord.

Dans les premiers jours, IBM a payé les programmeurs par l'instruction. (Quelqu'un que je connaissais a dit qu'il travaillait avec un programmeur qui s'est enrichi de cette façon. Apparemment, le gars ne savait pas comment utiliser le registre d'index de la machine; il a écrit une routine de mémoire nulle qui stockait manuellement zéro dans chaque adresse mémoire.)

Il y a aussi eu un temps (il y a longtemps) où les avocats étaient payés par la Parole. Cela a contribué à vulgariser des pratiques telles que le fait de s'adresser aux gens comme "tel ou tel le plus estimé" et d'autres verbosités.

Je viens de lire une réponse sur SO qui dit que VB.NET 2008 autorise toujours les numéros de ligne . Vous pouvez toujours exécuter pure DOS sur un PC moderne. Et il y a beaucoup de vérité dans la plaisanterie selon laquelle tous les programmes COBOL sont décédés d'un ancêtre commun par des changements incrémentiels. La rétrocompatibilité et les "raisons historiques" sont monnaie courante dans notre domaine.

C'est comparable au domaine du droit. Il existe des lois qui apportent de petites (ou grandes) modifications à d'autres lois. Vous avez une sorte d'enfer de dépendance. Il y a des lois historiques ridicules (à Hobart, en Tasmanie, il est illégal pour un homme de porter une robe de femme après le coucher du soleil - car il était une fois, les condamnés se déguisaient en femmes et en agresseurs) que personne ne rêverait d'appliquer, tout comme il y a des fonctionnalités historiques dans les logiciels que personne n'utilise plus.

Les lois ont souvent des conséquences imprévues (bugs!), Sont utilisées de manière créative (hacks!), Contiennent des failles (vulnérabilités de sécurité!), Dont certaines sont intentionnelles (backdoors!), Sont modifiées (correctifs!) Ou renversées (désinstallation!) .

Oui, les lois (contrairement au code) sont sujettes à interprétation. Mais je pense que c'est un peu comme la maintenance du code. Il aide à adapter les lois aux nouvelles normes sociales.

Pour répondre directement à la question: chaque développeur doit savoir que la loi est un peu comme un énorme projet logiciel ridiculement développé depuis des centaines d'années. (En fait, chaque pays a son propre projet, et ils résolvent les problèmes de différentes manières.) En théorie, après avoir lu une licence, vous saurez ce que vous pouvez et ne pouvez pas faire avec votre code. Mais si un programmeur compétent ne peut pas repérer tous les bogues de son code simplement en le lisant, alors quelle chance un non-avocat a-t-il d'analyser le cas d'angle et zones grises d'un document juridique?

Comme avec le code source du logiciel, vous pouvez généralement obtenir l'essentiel d'un document juridique en le lisant, mais si vous avez besoin de savoir quelque chose de spécifique, demandez à un professionnel.

3
Artelius

Pour les employés: nous devrions être en mesure de donner un premier tour de conseil à vos clients - comme peuvent-ils/nous utiliser le composant que nous voulons, dans leur application?

Pour les indépendants: nous devons être en mesure de donner des conseils solides à vos clients; et choisir les composants que nous pouvons utiliser pour les applications que nous développons pour eux.

Bien sûr, votre Parole n'est pas aussi bonne que les conseils qu'un avocat peut vous donner; mais vous pouvez déjà aider pour un premier tour; par exemple, pour dire "nous ne pouvons certainement pas utiliser cela car cela signifierait ..."
En fin de compte, l'avocat en saura beaucoup sur les cas de coin - mais si vous pouvez aider un peu ...


Pour les contributeurs OSS: connaître certaines différences entre les licences gratuites peut avoir de l'importance si vous vous souciez de ce que les gens peuvent faire avec votre code (redistribuer? Modifier? Utiliser dans une application commerciale?

3
Pascal MARTIN

NOLO (je ne travaille pas pour eux) publie un bon ensemble de livres juridiques pour les profanes.

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

1
Steve

Je répondrais à cette question de la même manière que je répondrais "que devrait savoir chaque avocat au sujet de la programmation?" C'est-à-dire, sachez qu'il n'y a aucun moyen de connaître suffisamment le domaine en profondeur pour faire plus que la plus simple des choses. Obtenez un expert.

1
Beska
  1. Ne travaillez pas dans un pays qui compte plus d'avocats que de développeurs.
  2. Un pourcentage extrêmement élevé de tous les brevets logiciels (américains) sont faux, mais vous ne pouvez pas payer ou attendre leur invalidation.
  3. Si vous souhaitez utiliser/développer un logiciel open source, utilisez une licence existante et ne la modifiez pas. Ne vous approchez pas des limites de ce que la licence est censée signifier.
1
Stephan Eggermont

Je suppose toujours que les développeurs d'un projet souhaitent que tout logiciel utilisant leur travail soit publié sous la même licence. Lisez leurs FAQ et pages légales pour plus d'informations et n'hésitez pas à contacter les développeurs/mainteneurs si vous n'êtes toujours pas sûr.

Si vous voulez de l'aide pour comprendre les détails d'un accord de licence, parlez à un avocat.

1
Tom Savage

6.Si vous avez un employé qui développe des logiciels "hors horloge", vous devez indiquer clairement à qui appartient ce logiciel, et quel type de logiciel l'employé devrait être en mesure d'écrire et de distribuer en dehors de l'entreprise.

le droit à la liberté d'expression tel qu'énoncé dans la plupart des constitutions (en particulier si les développeurs autorisent la gratuité de la distribution de l'électricité 24 heures sur 24) peut faire échouer ces termes misérablement devant les tribunaux

0
George Birbilis

Le nom d'un bon avocat spécialisé en propriété intellectuelle.

0
EBGreen