Journal Propriété du code d'un logiciel commandé

Posté par  .
Étiquettes :
8
8
oct.
2008
Je suis en relation avec une organisation qui utilise un logiciel écrit par une société à sa demande et sur ses spécifications.
Ce logiciel ne peut servir à rien ni personne d'autre, mais il représente une partie fondamentale de l'activité de l'utilisateur.
Il semble que le contrat de développement ne précise pas de licence.
Maintenant que l'utilisateur veut le code source, le développeur refuse.
De quel droit le développeur peut-il refuser ? Il n'a pas été précisé que la fourniture de ce logiciel ne couvrait que l'exécutable.
Quand on commande une maison à un architecte, il fournit le plan au client, afin que celui-ci puisse assurer les réparations, l'entretien, les réparations, etc.
Le client a-t-il un recours pour obtenir son code source ?

  • # Simple

    Posté par  (site web personnel) . Évalué à 10.


    De quel droit le développeur peut-il refuser ?

    De par le droit d'auteur.

    Pour obtenir le code source, le seul moyen légal que je vois est de négocier avec le développeur.

    La prochaine fois ton entreprise réfléchira avant à ce qu'elle stipule dans son contrat...

    • [^] # Re: Simple

      Posté par  . Évalué à 4.

      Exact, par défaut le droit d'auteur est « tout droits réservés » (et ce n'est même plus la peine de l'écrire depuis les années 70). On n'a donc aucun droit sur n'importe quel code qui ne stipule pas de conditions d'utilisation, c'est par la suite que l'auteur peut stipuler des conditions et des exceptions (par exemple avec des licences libres, EULA, etc.).

    • [^] # Re: Simple

      Posté par  . Évalué à 10.

      Bis

      Et ce n'est pas l'exception, les grosses SSII reste propriétaire des sources (pour pouvoir réutiliser des bouts de code pour d'autres clients) dans les contrats type par défaut.

      Mais pratiquement tous les clients demande les sources et les droits dans le contrat négocié.

      Par contre, si le logiciel utilise des composants copyleft, là il est possible d'obtenir les sources (mais si il paye les licences MySQL et Qt, il n'y a rien a redire).

      (P.S. pour les analogies foireuse : quand on commande un meuble à un ébéniste, on a pas les plans de découpe).

      • [^] # Re: Simple

        Posté par  . Évalué à 3.

        Pour continuer avec les analogies foireuses, lorsqu'un journal commande un article à un journaliste, celui-ci fournit le texte de l'article et non juste une photographie du texte destinée à la mise en page.
        Cela n'empêche pas le journaliste de conserver ses droits sur l'article.

        • [^] # Re: Simple

          Posté par  (site web personnel) . Évalué à 9.

          Mais dans le cas du journaliste indépendant, le texte de l'article est le produit fini, c'est un binaire que le rédac-chef ne peut modifier sauf accord express de l'auteur, les sources peuvent donner lieu à d'autres articles vendus à d'autres journaux

          • [^] # Re: Simple

            Posté par  . Évalué à 3.

            La réponse d'un avocat est que les droits relatifs à la propriété intellectuelle ne peuvent être cédés qu'après creation. On ne peut anticiper la cession des droits.
            Il faut donc que le développeur cède explicitement ses droits a la fin du développement. Aucun contrat passé ne peut concerner le code développé.
            Et s'il y a eu cession de droits, seul le code antérieur à la cession est concerné, pas les patchs et avenants.

  • # Pas si simple

    Posté par  . Évalué à 9.

    Parfois, le developpeur lui-même n'a pas le source, ayant fait appel à des librairies précompilées pour developper le produti.

    D'autres fois encore, le developpeur a acheté une licence non-redistribuable d'un composant logiciel en forme source mais donc, ne peut diffuser le code source qu'il utilise à personne, y compris ses propres clients.

    En résumé, la FSF a raison : linker avec du propriétaire, c'est mal.

    • [^] # Re: Pas si simple

      Posté par  . Évalué à 2.

      Aucun problème.
      Le logiciel est fait avec Qt et ne contient que la mise en oeuvre du cahier des charges.
      Autrement dit, l'intelligence du programme appartient à l'utilisateur, ce qui interdirait de fait au programmeur de le vendre à quelqu'un d'autre.

      • [^] # Re: Pas si simple

        Posté par  . Évalué à 4.

        Avec qu'elle version de Qt ? La commerciale ? Si non, il doit vous redistribuer les sources ...

        • [^] # Re: Pas si simple

          Posté par  . Évalué à 2.

          Probablement commerciale

          • [^] # Re: Pas si simple

            Posté par  (site web personnel) . Évalué à 4.

            Vérifie, si c'est pas le cas il devra vous filer le code. À moins qu'il ne soit possible d'acheter rétrospectivement une licence Qt, mais ça me paraîtrait louche. :)

            • [^] # Re: Pas si simple

              Posté par  . Évalué à 5.

              > À moins qu'il ne soit possible d'acheter rétrospectivement une licence Qt

              Trolltech (Nokia) demande de choisir la license AVANT de coder quoi que ce soit.

  • # contract ?

    Posté par  (site web personnel) . Évalué à 6.

    Il faut voir les termes du contrat. Il n'y a rien d'automatique, je pense. En gros, il faut voir la liste des livrables.

    "La première sécurité est la liberté"

    • [^] # Re: contract ?

      Posté par  (Mastodon) . Évalué à 5.

      Exactement.

      L'exemple de larchitecte n'est pas bon, puisque c'est son livrable, par contre, on peut faire des analogies avec :
      - Mon boulanger ne me file pas la recette de son pain (meme si je lui en commande un spécial)
      - Pour mon mariage, le photographe ne m'a pas filé les négatifs (pourtant j'avais explicité pas mal de besoins)

      Le client est tenu par les couilles, il a pas le choix. Fallait stipuler que le code source devait etre dans les livrables (et le prix n'aurait surement pas été le meme !!!)

      En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

      • [^] # Analogie foireuse (suite)

        Posté par  . Évalué à 6.

        Pour mon mariage

        Le client est tenu par les couilles

        On n'aurait pas là comme le début d'une analogie foireuse ?


        --------> [] Hop !

        Il se prend pour Napoléon, son état empire.

      • [^] # Re: contract ?

        Posté par  . Évalué à 0.

        Le client n'a pas à être un expert du domaine.

        Pour le pain, je pense que c'est une connaissance générale qu'il y a une recette, et qu'elle n'est pas incluse dans le prix du pain. (et en générale est tenue secrète).

        L'informatique reste un domaine d'expert.

        C'est peut-être au prestataire de proposer...

        - Voulez vous les sources ?
        - les sources ??? c'est quoi ?
        - c'est ce qui vous permet de modifier le programe plus tard
        - ah ben oui

        Du peu qui en est dit, le préstataire ne m'a pas l'air très pro...

        • [^] # Re: contract ?

          Posté par  . Évalué à 7.

          Il est "pro". S'il veut facturer des modifications mineures ou pas dans le code, il peut ainsi le faire au tarif qu'il veut. Car si le client a le code il peut faire jouer la concurrence ou aller définitivement voir ailleurs. Je dis pas que c'est bien, mais c'est je pense les motivations du presta.

          De plus une fois que le client se rend compte de l'importance des sources le prestataire peut se permettre de les vendre à un tarif important voir indécent. D'un autre côté, il y a des chances que le client prévenu avant ne comprenne pas qu'il faille payer (un peu) plus pour obtenir les sources, donc la tenaille fonctionne mieux après.

          • [^] # Re: contract ?

            Posté par  . Évalué à 1.

            C'est très probablement le cas ici.

          • [^] # Re: contract ?

            Posté par  . Évalué à 1.

            Oui, c'est exactement ce que j'entends par "pas très pro". Assurer son business en liant son client, plutot que de briller en répondant à ses besoins. Quand tout se passe bien, en général les clients reviennent, il n'y a pas besoin de les attacher, ni de les "tenailler".

            Pour revenir à la question des possibilités de recours, il faut effectivement commencer par relire le contrat. Et puis... demander à un avocat.

            > De quel droit le développeur peut-il refuser ?
            voilà une bonne question à lui poser. Quelle est la raison du refut?

            Pas le temps? Utilise des bibliotheques proprio?

  • # Propriété du plan...

    Posté par  . Évalué à 1.

    Oui, mais avec le plan de l'architecte, a-t-on le droit de le revendre pour que quelqu'un d'autre fasse une maison identique avec ?!?

    Quand au contrat de développement, ce n'est pas tant la licence qu'il doit spécifier mais qui est le propriétaire des droits du logiciel

    • [^] # Re: Propriété du plan...

      Posté par  . Évalué à 1.

      Il n'y a rien à revendre.

      Actuellement, le client redistribue gratuitement des copies du binaire à des partenaires, qui ne peuvent pas s'en servir s'ils sont sous Linux (seuls les binaires Mac et Windows existent).

      • [^] # Re: Propriété du plan...

        Posté par  . Évalué à 1.

        ok, mais mon commentaire était surtout pour mettre en avant le fait qu'avec un plan de maison, tu es propriétaire du papier sur lequel est le plan, mais pas de la propriété intellectuelle du plan.

        Mais effectivement, selon le contrat, le client peut aussi avoir les sources en sa possession sans en être propriétaire sur le plan intellectuelle..
        Donc comme indiqué plus haut, cela dépend du contrat passé, et des livrables spécifiés dans ce contrat

  • # Tu as pensé au reverse engineering

    Posté par  . Évalué à 0.

    Il est développé dans quel langage ton logiciel.

    car tu pourrais peut être faire du reverse dessus si c'est du Java ou .net ?

    PS: A vérifier pour le .net.

    • [^] # Re: Tu as pensé au reverse engineering

      Posté par  . Évalué à 2.

      La question ne se pose pas.
      Le client connaît parfaitement les specs et n'importe qui peut redévelopper le logiciel.
      C'est juste un peu de travail.

      • [^] # Re: Tu as pensé au reverse engineering

        Posté par  (Mastodon) . Évalué à 6.

        "C'est juste un peu de travail"

        Je te trouves vraiment injuste avec les développeurs. Si il suffisait de s'arrêter aux specs pour faire un logiciel, ça fait belle lurette que le métier n'existerait plus.

        Prends 100 informaticiens, files-leur les memes specs, t'auras 100 programmes différents (et de qualité différente !)

        Et si "c'est juste un peu de travail", retrousses-toi les manches et vas-y !!!

        En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

        • [^] # Re: Tu as pensé au reverse engineering

          Posté par  . Évalué à 3.

          Le "un peu" fait allusion que c'est un petit logiciel.
          Une seule fenêtre, quelques requêtes SQL.
          Normalement, une semaine de travail.

          • [^] # Re: Tu as pensé au reverse engineering

            Posté par  . Évalué à 8.

            Si c'est un aussi petit logiciel, et que ça ne coûte qu'une semaine de travail pour quelque chose qui représente "une partie fondamentale de l'activité de l'utilisateur", ça peut quand même valoir le coup de la dépense...

            Le logiciel a coûté moins cher parce qu'il n'était pas prévu que le code soit livré, j'imagine... Si tu tiens absolument à avoir ces sources, soit tu t'arranges avec le développeur, soit tu refais (ou fais refaire) ta propre version. Dans tous les cas, ça coûtera de l'argent. Mais je ne pense pas qu'il y ait de solution gratuite dans un cas comme celui-là...

            • [^] # Re: Tu as pensé au reverse engineering

              Posté par  . Évalué à 1.

              J'imagine que ça a été fait au forfait? sinon normalement en régie c'est comme pour un salarié du client: ce qui est produit appartient au client et non au salarié, droit d'auteur compris.

              • [^] # Re: Tu as pensé au reverse engineering

                Posté par  . Évalué à 3.

                Il faut que ça soit clairement stipulé dans le contrat !

                Quand tu signes un contrat pour un poste de développeur, tu as une clause qui précise que tout le travail accompli pendant tes heures de bureau appartient à l'entreprise.

                Pour cette histoire c'est pareil, pour que le code lui appartienne, il faut que ça ait été écrit dans le contrat. Dans le cas contraire, c'est le droit d'auteur qui prévaut.

                (je ne suis pas spécialiste en droit, je peux dire des bêtises, mais les quelques vagues notions que j'ai me font penser ça)

            • [^] # Re: Tu as pensé au reverse engineering

              Posté par  . Évalué à 5.

              A ta place, je dirais au développeur de la solution originale qu'il a le choix entre faire une licence qui inclue l'ouverture des sources et continuer à travailler pour et avec toi, ou te voir attribuer les ressources nécessaires au re-développement de la petite partie actuelle à quelqu'un d'autre (en interne ?) et arrêter d'utiliser sa solution et de faire appel à lui pour les développements futurs.

              A mon avis il va réfléchir 2 minutes, additionner 1 + 1 et se rendre compte qu'il a intérêt à rouler avec toi s'il veut te garder comme client.

              Dans le cas contraire, à mon avis tu n'as pas très envie de continuer à faire des affaires avec quelqu'un qui n'accorde aucune importance à tes demandes.

              • [^] # Re: Tu as pensé au reverse engineering

                Posté par  . Évalué à 4.

                Peut-être que le développeur a fait un code bien gruik et justement ne veut pas montrer le code pour ne pas perdre ce client...

              • [^] # Re: Tu as pensé au reverse engineering

                Posté par  . Évalué à 3.


                A ta place, je dirais au développeur de la solution originale qu'il a le choix entre faire une licence qui inclue l'ouverture des sources et continuer à travailler pour et avec toi, ou te voir attribuer les ressources nécessaires au re-développement de la petite partie actuelle à quelqu'un d'autre (en interne ?) et arrêter d'utiliser sa solution et de faire appel à lui pour les développements futurs.

                A mon avis il va réfléchir 2 minutes, additionner 1 + 1 et se rendre compte qu'il a intérêt à rouler avec toi s'il veut te garder comme client.


                Les promesse n'engagent que ceux qui y croient

                • [^] # Re: Tu as pensé au reverse engineering

                  Posté par  . Évalué à 1.

                  Les promesse n'engagent que ceux qui y croient

                  oui, mais quand tu promet a ton fournisseur que tu ne travaillera plus avec lui, je suis sur qu'il va la croire, là.

              • [^] # Re: Tu as pensé au reverse engineering

                Posté par  . Évalué à 3.

                Je pense que c'est la meilleure solution.

                C'est comme les licences MS qui baissent de prix dès qu'on prononce le mot Linux.

                Et, comme ces gens-là comprennent toujours trop tard, eh bien tant pis pour tout le monde :
                -pour lui, qui va perdre du travail
                -pour ceux qui vont redévelopper le truc en interne

                • [^] # Re: Tu as pensé au reverse engineering

                  Posté par  . Évalué à 2.

                  Redévelopper le truc en interne, je ne vois pas en quoi ce serait "tant pis". C'est "tant pis" pour celui qui va attribuer les ressources en interne, parce que les ressources en question vont être occupées à quelque chose d'autre que ce qu'elles pourraient faire pendant ce temps de plus rentable, mais comme ça permet de s'affranchir d'un fournisseur mal disposé c'est encore moindre mal.

                  Et de toute façons ils n'en seraient pas là si quelqu'un avait pensé à vérifier la licence et les termes du contrat avant, donc c'est celui qui a fait l'erreur qui en subit les conséquences les moins triviales (et elles sont quand même plutôt triviales malgré tout)...

  • # Piste (négative)

    Posté par  . Évalué à 5.

    Si on en croit http://www.celog.fr/cpi/lv1_tt1.htm#8 :

    "L'existence d'un contrat de commande de logiciel n'entraîne pas la cession automatique au commanditaire des droits afférents au logiciel."

    Faute d'accord préalable, le développeur est donc probablement dans son droit.

  • # Classique

    Posté par  . Évalué à 1.

    Malheureusement! Je l'ai vu -et vécu- un certain nombre de fois dans plusieurs boites, mais c'était il y a longtemps. Suivant la date du contrat, on peut envisager ou non de virer celui qui l'a signé (je blague) car à notre époque il faut être un demeuré pour ne pas voir ce problème dans le cas d'une application stratégique (que faire, par exemple, si la société auteur disparait et que ça tombe en panne?).
    Bon, deux solutions: ou racheter les sources (à négocier...) ou réécrire de zéro en améliorant au passage, cela parait le mieux s'il n'y a pas urgence; de toutes façons il faudra obligatoirement y passer un jour, j'espère pour eux que c'est amorti...
    Petite porte de sortie, si le logiciel est récent et qu'il présente un-des bug(s) on peut jouer là dessus pour obtenir un abattement, mais il faut être convainquant !

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.