Risques des projets informatiques et des équipes informatiques

Une mauvaise situation avec Nginx - cela donne l'occasion de rappeler d'autres cas de problèmes lors du travail avec des équipes de projet, d'autant plus qu'il est beaucoup plus difficile de corriger des erreurs dans la conception des commandes que des erreurs dans le code. (les affaires vont - non pas par «importance» mais par ordre de rappel)

" Accords de non-divulgation et de non-concurrence "

NDA & NCA (accord de non-divulgation et de non-concurrence)
Papier standard, généralement vide de sens, téléchargé par une avocate du réseau et jeté dans une pile générale de papiers pour signature lors de l'acceptation de nouveaux développeurs. Dans 99% des cas - personne ne lit jamais après la signature. Mais dans le 1% restant - cela peut causer des problèmes.

Par exemple, le développeur dans la NDA et dans les instructions de service peut dire: "il est interdit de donner accès aux informations de service de personnes non autorisées ". (il s'agit d'un cas spécifique) S'il y était écrit: "il est interdit de transmettre ", des questions ne se poseraient pas. Mais ce qui est écrit est écrit. Dans le même temps, le développeur lui-même peut s'asseoir dans la salle commune et le moniteur peut se tenir « face » à l'allée et être visible par tous les passants. Et / ou chaque fois qu'il doit envoyer des documents imprimés à une imprimante partagée.

En conséquence, un beau jour (mais pas pour lui) à son entrée au bureau - le trousseau ne fonctionnera pas, après quoi le gardien sortira une boîte avec son cactus préféré (et des pantoufles remplaçables) et lui donnera l'ordre de licencier «Violation brute ponctuelle des devoirs du travail» sous la forme de « violation de la description de poste » et de « divulgation d'informations officielles » (pour le développement personnalisé - un contrat, pour l'exécution - article 81 p.6B du Code du travail). Si les managers complètent tout correctement, il sera impossible de contester ...

Cependant, ce jeu - vous pouvez jouer ensemble. Si le développeur décide fermement de partir, ou que lui, comme dans le cas de Nginx (pour autant que l'on puisse en juger par la situation) scie son propre projet au travail, alors il peut prendre un crayon et lire attentivement ce qui est écrit dans cette NCA téléchargée par une avocate de Neta NDA &. Ensuite - pour enrouler le service qu'il ne peut catégoriquement pas remplir la tâche qui lui est confiée, en relation avec l'employeur ou le client ne lui fournissant pas les conditions prescrites dans les instructions et la NDA, et nécessaires pour remplir les exigences de sécurité.

Toute la circonstance de la situation est qu'il est impossible de le licencier pour un tel refus, et il sera obligé de payer son salaire (taux / temps) jusqu'à ce qu'il soit pourvu des conditions nécessaires ou s'il en bénéficie. ou ne sera pas transféré à un projet qui ne nécessite pas de travail avec des données sensibles; ou ils ne seront pas d'accord avec lui sur l'indemnisation. C'est ce qu'on appelle la « grève italienne » (« Officiellement, sans arrêter le travail, les travailleurs le paralysent par des exigences insensées de strict respect de toutes les formalités prescrites par eux ».)

Dans le même temps, si le développeur n'est pas embauché pour le projet, mais en l'état (pour la main-d'œuvre), alors son embauche (et le calcul d'un taux fixe) commence et est calculé à partir de la date du contrat, et non à partir de la date de début réel des travaux.

Cas: À la réception, quelques développeurs - ils m'ont donné de signer un paquet de papier standard (travail, description de poste, personnel, NDA et NCA, mesures de sécurité, etc.), qu'ils semblent tous avoir signé.

Puisqu'il y avait beaucoup de monde, la vérification et l'analyse de tous les papiers ont été faites le lendemain, et il s'est avéré que quelque chose avait été signé deux fois et que quelque chose avait été manqué. Avec toutes les autres personnes, tout a été rapidement réparé et corrigé, et ce couple, du jour au lendemain, a apparemment changé d'avis et a commencé à remuer quelque chose.

Mais les managers étaient déjà expérimentés, donc ils ont soigneusement (mais rapidement) tout pris d'eux, et soigneusement (mais rapidement) les ont mis dehors. Et dans la description de travail, la secrétaire du bureau, en gros caractères, a attribué la clause stipulant qu'elle vérifie d'abord les signatures sur tous les autres documents, puis tamponne directement le contrat de travail lui-même (qui le cache immédiatement dans le coffre-fort, en donnant une photocopie aux victimes).

Mais le mieux est bien sûr d'inscrire tous ceux qui travaillent sur le travail dans un bureau séparé spécialement créé à cet effet, dont les éventuels problèmes ultérieurs ne submergeront pas le travail sur d'autres projets.

Un point spécial de la NDA - il est nécessaire de prescrire l'interaction des développeurs avec les représentants du client (le cas échéant). Nous avons besoin d'une liste de documents que le développeur ne doit pas transmettre et d'une liste de questions auxquelles il ne doit pas répondre.

Cas: Le développeur a envoyé une version intermédiaire d'une pièce du système avec des talons au client. Ils ont cherché et demandé quelques modules qui étaient censés être à la place des talons et qui étaient à un stade intermédiaire. Il les leur a envoyés.
Ces modules ont été créés sur un grand ensemble d'outils, qui écrit ses journaux dans les versions intermédiaires. À la livraison du projet, toutes ces ordures sont naturellement nettoyées, mais elles sont nettoyées à la main, donc dans les versions de travail, elles ne le touchent pas. Le service technique du client - a vu les numéros de série et les journaux et les a remis à leurs supérieurs, supérieurs - a contacté le fabricant du colis, qui a déclaré que cette copie du colis n'avait pas été fournie à la Fédération de Russie. Il y avait beaucoup de bruit et de vacarme.

Sur un autre projet, un développeur - pendant trois jours a installé et mis en place un package chez le client, où il y avait des jeunes filles enthousiastes, à qui il a dit du haut de sa grande sagesse qu'elles n'avaient peur de rien, car la plupart de ce package fonctionnait déjà avec succès avec le client précédent. Le client a appelé et a demandé pourquoi ils lui avaient pris le prix total pour ce qui avait déjà été vendu à quelqu'un auparavant. Ils s'en sont sortis avec un petit scandale. Mais si le client contactait soudainement le premier client, beaucoup plus important, les problèmes seraient bien plus importants.

" Secret commercial "

Le premier problème avec com secret est qu'il n'y a pas de secret commercial en Fédération de Russie. La loi de 2004 sur les secrets commerciaux, c'est un papier calque de la loi sur les secrets d'État, et tout ce qui s'y trouve est lié à un support matériel, sans lequel toutes les actions et procédures ne fonctionnent pas. Par conséquent, si l'entreprise n'a pas de chambre " secrète " (avec des fenêtres étroitement fermées), un journal de visite ligné et d'autres passions hollywoodiennes, alors ce régime ne l'est pas, et tous les mots sur " informations secrètes " et " informations fermées " ont une signification purement psychologique, et dans un incident réel et grave, ils n'auront pas d'importance.

Le deuxième problème avec le secret de communication est que même si dans un incident particulier il n'y a pas de fait prouvé, c'est-à-dire correctement documenté, du transfert, c'est-à-dire une action spécifique par une personne pour recevoir la transmission (ou aucune reconnaissance personnelle du contrevenant), aucune violation - non. Encore une fois: pour un « transfert » - il faut non seulement « donner », mais aussi « accepter », il n'y a pas de reçu - il n'y a pas de transfert (c'est-à-dire que publier sur Internet « pour tous » n'est pas un « transfert »).

Cependant, cela est compensé par la possibilité d'un enregistrement interne de l'entreprise du fait de la violation des descriptions de travail (journaux du serveur, enregistrement vidéo correctement formaté des caméras internes, etc.). Et après la fixation, la réprimande, la perte de bonus et le licenciement sont déjà possibles en vertu de la clause de travail habituelle, ou, si l'exécution n'était pas conforme à l'ordre de travail, mais selon une ordonnance unique, selon une violation flagrante du contrat (mais alors vous devez regarder ce qui était écrit dans le contrat).

Cas: Si un montant spécifique de salaire est indiqué dans le contrat ou la main-d'œuvre, il est extrêmement difficile de le réduire avec des amendes (les coûts de transaction - dépasseront le montant retenu), le salaire des employés n'est même pas inclus dans la masse de la faillite pendant la faillite. Mais si le taux de base y est indiqué, et par exemple, un bonus a été fixé pour l'observation du régime de protection des informations, alors en cas de violation de ce régime, supprimer le bonus (ou plutôt ne pas l'attribuer) sera beaucoup plus facile. Si une équipe suffisamment hétéroclite est recrutée pour le projet, parmi des personnes qui n'ont pas déjà travaillé ensemble, alors inscrire tout le monde sous le même contrat de travail, avec des conditions communes à tous, est le moyen sûr de l'échec du projet. Les termes et conditions d'embauche et d'inscription Junior et Lead ne peuvent pas être les mêmes. (si le junior n'est pas en l'état, mais par exemple sur le test, alors il ne peut avoir aucun secret)

Et enfin, le troisième problème avec le secret de communication est que si ce mode est effectivement établi dans l'entreprise, l'entreprise ne pourra pas fonctionner. Il ne s'agit pas de la « grève italienne », mais de l'incohérence des processus commerciaux.
Cas: Au développeur - il fallait approuver la mise en page des pages du service personnalisé chez le client, et la fillette-avocate, sur l'ensemble du produit avant la date de livraison / acceptation, apposait le cachet " com secrets ". Et le développeur demande: " Mais comment puis-je les transmettre au client? " Le rideau.

Patch: Afin de ne pas bricoler les lois russes locales et la pratique judiciaire russe (qui est absente en premier lieu (en raison de l'absence de mécanisme de précédent judiciaire en Fédération de Russie), et en second lieu ne s'applique pas en dehors de la Fédération de Russie (pour les clients étrangers)) dans ces cas , lorsque vous devez en quelque sorte fermer votre secret, vous pouvez écrire que toutes les informations internes sont régies par les règles ADPIC (Accord sur les aspects des droits de propriété intellectuelle qui touchent au commerce). Ce sont des règles pratiques, claires et compréhensibles qui s'appliquent dans le monde entier ( y compris la Fédération de Russie).

Patch 2: Si le client ou l'un des hauts de l'équipe vient des États-Unis, alors au lieu de thrips, il est préférable de mettre immédiatement le " Defend Trade Secret Act " & " Economic Espionage Act " (lois américaines sur les secrets de com et l'espionnage). Cela - non seulement donne immédiatement " +100 karma ", mais réduit également considérablement la probabilité de malentendus ultérieurs lors de l'acceptation et du paiement du travail (le client saura que la conception de l'équipe est faite correctement, c'est-à-dire les gens - dans le sujet, et juste comme ça, leur - vous ne pouvez pas tromper (même si vous voulez)).

Accord de non-concurrence (NCA / CNC)

Le problème avec lui est que l'emploi et le travail ultérieurs ne peuvent être interdits.
L'interdiction de l'emploi et du travail est juridiquement nulle dans tous les pays. Autrement dit, il est possible de l'écrire, mais ces mots n'auront aucune conséquence juridique.
Cependant, en même temps, NCA / CNC - travaille dans d'autres cas spécifiques, à savoir dans les cas:

• Prévention des dommages à l'entreprise par l'utilisation non autorisée d'informations officielles par le salarié après son licenciement;
• divulgation et diffusion non autorisées par un employé de l'expérience technologique de l'entreprise;
• nuire intentionnellement à l'entreprise en refusant à l'employé de travailler après avoir été payé par la formation externe ou interne de l'entreprise.

C'est-à-dire que dans la première option - le manque à gagner est récupéré, dans la seconde - un contrat remboursable gratuit est conclu avec les obligations mutuelles des parties, et dans la troisième - le coût de la formation est facturé (comme dans le cas d'une formation ciblée régulière, par exemple, dans une université).

Cas n ° 1: avec des développeurs clés - des contrats personnels individuels ont été conclus indiquant des postes spécifiques dans des entreprises concurrentes spécifiques dans lesquelles l'employé ne peut pas obtenir un emploi et des conditions (pas plus de 4 mois), une interdiction a été imposée d'ouvrir sa propre entreprise et des entrepreneurs individuels sur le sujet du projet , et dans le cadre de ces contrats, pendant ces 4 mois. après le licenciement - une compensation monétaire a été versée (il ne s'agit pas d'un salaire (ils ne sont plus des employés)).

Cas n ° 2: pour un développeur spécifique et un projet spécifique - un lieu de travail coûteux avec un package coûteux (CAD) a été acquis, et un contrat de travail a été émis un contrat supplémentaire pour compenser ces coûts en cas de départ anticipé avant l'achèvement du projet.

"Un reçu sur l'absence d'obstacles pour un travail à part entière dans un nouveau lieu "

La chose est importante. Il est nécessaire de se protéger contre la violation des droits des tiers. Premièrement, il assure contre les conséquences de l'utilisation des informations (et de la violation des NCA / CNC) d'anciens (anciens) lieux de travail, et deuxièmement, il est assuré que d'autres projets (y compris les leurs) sont entraînés dans l'entreprise (l'affaire Nginx en est un bon exemple).

Nous l'avons réalisé après deux incidents désagréables avec des pigistes étrangers éloignés fusionnant dans nos projets (et probablement même plusieurs autres) des morceaux de projets de leurs précédents lieux de travail (ce qui est devenu clair plus tard). Le reçu lui-même n'empêche pas naturellement que la saleté extérieure soit entraînée dans le projet, mais l'entreprise en a besoin pour confirmer son intégrité (toutes les précautions nécessaires ont été prises) et, par conséquent, se protéger contre d'éventuelles réclamations ultérieures de tiers.

En remplacement (ou duplication) d'un tel reçu, certains projets publient parfois de manière proactive des informations sur le réseau concernant la réception de développeurs potentiellement problématiques (tels que " enfin rejoint notre équipe amicale ..."), mais il est plus facile (et plus fiable) de faire un reçu papier explicite en trois paragraphes.

Il y a eu des cas où il s'est avéré que les développeurs ont utilisé leurs propres solutions, descriptions ou idées dans des projets commerciaux qu'ils ont néanmoins « brillés » dans les hackathons maintenant populaires, et dans les candidatures à des concours et des subventions, dont ils sont responsables de projets. pas signalé en temps opportun. Cependant, dans de nombreux hackathons, concours et subventions - il existe des dispositions concernant les droits des organisateurs-organisateurs pour l'utilisation ultérieure du matériel envoyé, au moins à des fins éducatives.

Et par exemple, dans les descriptions des hackathons Yandex et Sberov - il est directement indiqué qu'il est possible d'étudier le matériel envoyé pour l'applicabilité en entreprise. En conséquence, la solution ainsi mise en œuvre, mise en œuvre dans un projet commercial, comporte des risques potentiels. (Le cas où un développeur fait glisser une partie de son projet actuel sur un hackathon est soumis à une violation NDA (voir ci-dessus).)

Un cas distinct (et assez curieusement fréquent) de la nécessité d'un reçu concernant l'absence d'obstacles est celui des situations dans lesquelles les développeurs eux-mêmes ne connaissent pas (bien qu'ils le puissent) leurs restrictions similaires.

Cas: Dans l'un des projets, un homme est arrivé à un poste de direction, peu de temps auparavant, il avait travaillé un an sur le sujet d'un projet dans une université britannique dans le cadre d'une bourse d'échange de recherche. Avant cet incident, nous n'avions pas rencontré de situations similaires, nous n'y avons donc pas prêté attention. Mais alors le co-investisseur étranger du projet nous a expliqué que nous n'avions pas tout à fait raison. Lorsque les documents nécessaires ont été pris à l’université elle-même, il s’est avéré que la personne n’avait vraiment pas encore terminé l’année de « quarantaine », qui était prescrite à la fois dans le contrat de subvention et dans les documents internes de l’université. De plus, les conditions dans ce pays se sont révélées beaucoup plus graves que ce à quoi on aurait pu s'attendre.

" Interdiction de l'utilisation / diffusion des informations et litiges après licenciement "

Ici - en premier lieu, tout ce qui était déjà dans NDA & (NCA / CNC) est à nouveau dupliqué, mais en même temps, il est applicable non seulement pendant, mais aussi après la fin du travail. S'il y a des problèmes avec le papier et les imprimantes, alors cette interdiction - vous pouvez " intégrer " dans le texte du NDA principal (NCA / CNC). Cependant, économiser sur trois paragraphes supplémentaires ne coûte pas beaucoup de nerfs et de temps pour la preuve à long terme ultérieure que le texte « intégré » se réfère à la fois au temps du projet et au temps après son achèvement. Conserver une seule feuille de papier de ces risques ne vaut pas la peine.

Deuxièmement, ici (bien qu'avec un seul paragraphe, mais un paragraphe important), une interdiction est imposée sur la distribution ultérieure de négativité à propos du projet / de la société, et la seconde est la situation de dépôt de poursuites contre la société (à la fois pour leur propre compte et leur participation (co-plaignante) dans d'autres).

Sur le premier point: l'obligation de ne pas dire du mal de l'entreprise et du projet, prise unilatéralement et indépendamment, est également annulée unilatéralement et indépendamment. Par conséquent, en cas de licenciement - il est nécessaire de conclure un contrat " sous silence ", avec des obligations mutuelles et le paiement d'une compensation (dans les deux sens).

Selon le deuxième paragraphe: L'obligation de ne pas poursuivre est juridiquement nulle et le papier sur lequel elle est écrite n'en vaut pas la peine. Ce problème est corrigé - encore une fois, avec un contrat avec des obligations mutuelles claires et des compensations / amendes. En réalité, la période de « silence » de six mois suffit. C'est tout - cela a l'air effrayant et monstrueux, mais en réalité - cela prend un quart de la feuille (bien qu'en petits caractères).

" Développement de bureau "

Les cas sont la mer, mais après Nginx, tout a déjà été discuté des centaines de fois, et il n'y a rien à expliquer à personne.

À moins qu'il ne soit utile de répéter encore une fois que dans les contrats de projets destinés à être utilisés en dehors de la Fédération de Russie, vous ne devez pas vous référer aux lois et normes juridiques de la loi de la Fédération de Russie.

" Ne vous opposez pas à l'utilisation de la solution "

Cas: Lorsque vous travaillez sur un projet, une nouvelle solution a été créée qui est déposée pour brevet. Les périodes de brevetage aux États-Unis, par exemple, les solutions client-serveur, peuvent prendre jusqu'à trois ans, et les architectures / poids / techniques sur les réseaux de neurones peuvent prendre jusqu'à cinq ans (plus le sujet est chaud, plus il y a d'applications, plus les temps d'examen sont corollaires). Et d'ici là, le projet - a longtemps été fermé, et le développeur lui-même - ne se contentera pas de quitter, mais aura déjà le temps de travailler sur quelques autres projets. Et sans sa signature, certaines choses ne peuvent pas être faites avec le brevetage. Par conséquent, encore une fois - un contrat distinct, bien que 1/4 page. Naturellement signé strictement avant le début du projet. (il est possible - déjà après l'embauche pour un emploi, ou un pigiste "indépendant", mais - strictement avant le début du projet, dans lequel la candidature sera soumise)

" L'interdiction de l'utilisation implicite d'informations externes "

Tout ce qui est inséré dans le projet de l'extérieur - doit être vérifié très soigneusement et monté (s'il est absolument impossible sans lui) avec la possibilité d'un remplacement rapide ou d'une suppression complète (s'il est impossible de le remplacer rapidement).

Cas 1. Le développeur, quelque part sur le site pour les programmeurs - a vu une solution adaptée au projet et l'a insérée dans le projet. Il est devenu clair peu de temps avant l'achèvement du projet. Ensuite, cette pièce du projet a dû être coupée longtemps et fastidieusement.

Cas 2. Développeur - J'ai vu une solution utile publiée par son auteur (solution) lui-même. L'auteur, qui donnait la décision à tout le monde, en tant que brevet de la décision, avait déjà cessé d'être valide (en ne payant pas les frais), et l'entreprise elle-même était en faillite.
On ne sait pas qui a réussi à profiter de cette générosité, mais on sait qu'après six mois, la faillite a pris fin, et la nouvelle société a rétabli tous les brevets.

Cas 3. Développeur - J'ai vu le signe " open source " et y ai tapé un cadeau de brouette complet.
Cependant - il n'y a pas une seule licence de logiciel ouvert dans le texte de laquelle serait le mot « freebie ».

( À propos d'OpenSource sur Habr - a déjà écrit )
Open-sourse, c'est du code source " ouvert ", mais ce n'est pas une question d'argent. Dans une licence " gratuite " - il peut être indiqué: " Gratuit uniquement pour une utilisation dans les refuges pour chiens", et dans votre cas particulier, l'abri peut être non pas semblable à un chien, mais mixte (chiens et chats)
. Mais dès que le logiciel sera même absolument gratuit (et encore plus payé) sera livré sous une telle licence à au moins un PC d'un refuge pour non-chiens, une violation des conditions de la licence se produira, avec toutes les conséquences administratives et pénales. Les capteurs sont un cas très fréquent.

Entièrement gratuit - il n'y a que ce logiciel dont les idées (méthodes de travail) sont tombées dans le domaine public (les brevets ont cessé et ne peuvent pas être restaurés), et le code source a été écrit par l'auteur, décédé il y a 70/75/80 (dans différents pays différemment) des années . Dans tous les autres cas, l'open source peut avoir (et très probablement) des pièges. Encore une fois: open source, ce n'est pas un tirage au sort.

Cas 4. Développeur - des modules téléchargés à partir de la bibliothèque Intel " gratuite " pour le traitement d'images et en fouillant dans le code, ont construit quelques-uns de ses blocs à partir de leurs morceaux. Amélioré et optimisé. Cependant, la bibliothèque intellectuelle " gratuite " n'est en aucun cas un " cadeau " ". Elle a des conditions d'utilisation très claires et difficiles. Bien sûr, les blocs du projet ont été laissés, mais le développeur a été invité à ne pas recommencer.

" L'obligation de tester la nouveauté de leurs propres développements "

Si le développeur lui-même propose quelque chose, c'est très bien. Le seul problème est que s'il pouvait le proposer, il y a une probabilité non nulle que la même chose (ou quelque chose de proche) puisse être inventée par quelqu'un d'autre. Et qui s'est levé en premier - ça et les pantoufles.
En conséquence, c'est nouveau - vous devez emprunter jusqu'à ce que quelqu'un d'autre l'ait fait. Pour que le développeur puisse le faire (au lieu du codage à la pièce), il devrait être stimulé soit par des primes (dans le cadre du contrat de travail), soit par des paiements supplémentaires par contrat.

" "

Si (à l'étape précédente) la nouveauté de la solution créée a été établie, elle doit être corrigée. Ou des brevets, ou (s'il n'atteint pas un brevet à part entière par nouveauté) au moins en tant que publication ouverte (sur le principe " Alors ne touchez personne! "). En pratique, si dans les projets de clients étrangers les demandes de brevet ne sont pas du tout déposées (ou cessent d'être déposées), les clients commencent à devenir nerveux et à vérifier le projet. C'est au mieux. Au pire, ils pensent que les gens font ce code « pour la nourriture » et mettent un prix moins cher que les Indiens. Par conséquent, des applications, ou au moins des publications (toute ressource publique est appropriée) sont strictement souhaitables.

Ici, cependant, il existe un élément important et « sensible"moment. Le développeur - ils paient le code et le brevet - soit le client, soit la société. Par conséquent, si le développeur déménage ensuite dans une autre société, il ne pourra pas utiliser cette décision (dont il est l'auteur) à son nouveau poste. Il ne pourra pas - non seulement à cause de la non-concurrence (NCA / CNC), mais à cause de l'ensemble du brevet à part entière, dont l'auteur est lui-même, pour cette raison, les développeurs sabotent souvent le processus de préparation et de dépôt des demandes de brevet, se référant à la charge de travail sur le principal au projet, ce bug est corrigé - dans des compteurs séparés ktami et les paiements nettement primes lors du dépôt (démontage du brevet appartenant entre le client et la société - sa propre chanson triste privée).

« Droit au développement »

Avec cette question, pour une raison quelconque, il y a tout le temps des difficultés. Bien que la question soit extrêmement simple. " Copyright - ne s'applique pas aux idées, concepts, principes, méthodes, processus, systèmes, méthodes, solutions aux problèmes techniques, organisationnels ou autres "
Encore une fois: aux algorithmes, aux formats de données, aux méthodes de travail et à l'interaction des blocs, etc., etc., pas de droits d'auteur - non. Toute cette économie (méthodes et dispositifs) est une propriété industrielle brevetable (mais pas « copyright ») (et après enregistrement - « actifs incorporels »).

Copyright - s'applique uniquement et exclusivement aux œuvres littéraires et artistiques. En même temps, ce " droit ""- il consiste uniquement et exclusivement dans le droit de se faire appeler l'auteur du texte. Le droit d'auteur ne donne aucun autre droit d'utiliser ce texte. Tout - comme dans l'édition, l'éditeur - commande un livre, l'auteur - écrit, le nom de l'auteur - est indiqué sur la couverture, mais le texte lui-même appartient à l'éditeur.

En même temps, appliquer le droit d'auteur au code du programme est absolument stupide. Si vous réorganisez simplement les blocs de code dans un projet logiciel, le projet en tant qu'œuvre littéraire disparaîtra et le droit d'auteur disparaîtra également. Si le code est compilé, alors le " texte " source disparaît complètement. Les avocats (en règle générale) n'écrivent pas de programmes, ne collectent pas de packages à partir de blocs, ne les testent pas, etc., etc., etc. ils ne savent pas tout cela, alors ils écrivent sur "droit d'auteur ".

Comme pour le développement dit" de service ". Habituellement, les risques de démontages ultérieurs sont supprimés tout simplement. L'architecture d'un produit ou service, et les principaux problèmes techniques de sa construction et de son fonctionnement (bien qu'avec une élaboration préliminaire au niveau des exécuteurs finaux) sont approuvés au niveau de les directives du projet, et sont rédigées sous la forme d'un mandat de base, qui est transféré à l'œuvre.Dans ce cas, tous les droits sont fondés au niveau du mandat, et les risques de réclamations ultérieures éventuelles sont supprimés (l'auteur est celui qui a émis le mandat).

Cas: Dans de nombreux centres de développement étrangers opérant en Fédération de Russie, la règle suivante a été adoptée. Si les développeurs locaux proposent quelque chose de nouveau, une demande de brevet est déposée, dont le premier auteur indique toujours un employé étranger du bureau russe. Cela supprime de nombreux risques.

" Sécurité "

Presque tout le développement de logiciels en Russie, au-delà des frontières de la Fédération de Russie, se situe dans la zone grise . Lorsque vous travaillez sur Internet et via Internet, les frontières étatiques et douanières de la Fédération de Russie passent le long de la surface du moniteur. Tout ce qui se cache derrière, ce n'est plus exactement la Fédération de Russie. Et souvent - pas du tout de la Fédération de Russie. (Amazon ou les services cloud de Google sont garantis en dehors de la Fédération de Russie).

Par conséquent, si un développeur envoie un fichier de projet à un bâtiment voisin, il n'y a pas de problème, mais s'il envoie ce fichier aux États-Unis, par exemple, puis lorsqu'il clique sur le bouton d' envoi , le fichier de projet traverse à la fois les frontières étatiques et douanières de la Fédération de Russie! En conséquence, lors du franchissement de la première frontière - il existe des risques de " contrôle des exportations " .", et à l'intersection de la seconde -" contrebande " douanière (le développeur n'a pas émis de déclaration en douane pour le dossier à transférer).

Par conséquent, avec tous ceux qui, dans le cadre du projet, contacteront ou pourront contacter des destinataires étrangers, il est nécessaire de suivre des instructions et de construire un schéma un travail qui minimise les risques (il est obstrué par la création d'une micro-entreprise dans le pays du client, et le bureau russe est enregistré en tant que bureau de représentation ou service).

« L' interaction avec le client »

C'était déjà plus tôt, mais il y a encore quelques points. De nombreux risques cachés se situent dans le domaine de l'interaction entre le développeur et le client pendant la livraison à long terme du projet, et / ou son support technique lors de la poursuite de l'exploitation. Si une entreprise possède soudainement son propre système CRM interne, un mode séparé doit être prévu pour ces interactions. Mais dans tous les cas, un « papier » doit être reçu du client indiquant que l'action de l'entrepreneur (c'est-à-dire l'entreprise) n'est considérée que celle qui vient (ou vient avec une deuxième « signature ») du gestionnaire responsable de l'interaction avec le client.

Cas n ° 1: d'un client aux États-Unis - une demande a été reçue pour résoudre le problème. Il a été transmis au développeur avec les contacts de l'employé client. Le développeur (presque via le réseau social) a contacté l'employé et, après un certain temps, a interrompu la communication, lui donnant simultanément des informations précieuses sur ses capacités professionnelles et mentales. Client - a fait une réclamation concernant le prétendu refus de l'assistance technique.

Cas n ° 2: d'un client aux États-Unis (déjà différent) - une demande a été reçue pour résoudre le problème. Manager - l'a transmis au développeur, et considérant la question close, a mis une note sur l'exécution. C'était la fin de la journée, et le développeur pensait que " demain nous le ferons ". — . , , . — .

, ( //) , , — . — , " ". User Agreement , ( ).

" "&« »

Identique aux paragraphes précédents, mais s'applique au mécanisme de paiement. Si les développeurs (en particulier les indépendants) sont payés sur un papier ou un pager, les problèmes qui peuvent survenir avec l'un de ces comptes / portefeuilles ne devraient pas causer de problèmes à d'autres personnes et projets. Et si les gens obtiennent des cartes personnelles liées à une entreprise à l'étranger, alors sur un compte général, les fonds de plusieurs destinataires ne doivent pas être accumulés en même temps.

Séparément et surtout, il est nécessaire de réglementer les problèmes de transfert de fonds des cartes et comptes impersonnels vers les cartes « blanches » des employés des banques de la Fédération de Russie. Si un développeur retire des fonds d'une carte grise dans un GAB, puis immédiatement, dans un GAB voisin, les dépose sur son compte blanc, les fonds sont compensés ". , — , .

— . , — , — . , — , — . ( - , ) .. " ", .

— .