Journal Relations entre projet libre et entreprise

Posté par  .
23
17
juin
2012

Sommaire

Cher journal,

Je souhaiterais connaître ton avis sur une situation qui me préoccupe en ce moment avec un projet opensource et l'entreprise pour laquelle je travaille.

Désolé, mon écrit est relativement long, mais il est difficile à résumer davantage sans dénaturer les événements. Par ailleurs, de part mon implication dans cette histoire, ce qui suit n'est pas forcément 100% impartial bien que je m'y soit attaché autant que faire ce peut.

Background

Dans le cadre professionnel, il y a quelques années déjà, j'ai repris pour le compte d'un client un projet opensource (license GPL2+) laissé à l'abandon (plus d'activité depuis plusieurs années). Après une phase de développement fermé (fork interne du logiciel avec des améliorations substancielles), le client a décidé de publier les modifications. Le code a donc été publié sur une forge publique (genre sourceforge). J'ai personnellement réalisé cette publication au nom du client et de mon entreprise.

Le projet étant terminé, le niveau d'activité sur le projet a baissé (qq correctifs uniquement), puis a complètement cessé (plus d'intérêt immédiat, ni du client, ni de mon entreprise). Après avoir essayé en vain de relancer les développements en interne sur ce projet (propositions de produits basés sur le logiciel notamment) pendant quelques temps, j'ai commencé petit à petit à assurer sur mon temps personnel du support sur le projet : réponses aux quelques personnes extérieures qui s'intéressaient au projet et posaient des questions sur la mailing list, corrections de quelques bugs reportés, génération de releases…).

Cette prise en charge a grandi petit à petit au fur et à mesure des mois et des années. Afin d'être plus réactif aux demandes des utilisateurs, j'ai remplacé sur la forge l'adresse email professionnel de mon compte par mon adresse email personnelle. Je pouvais ainsi travailler dessus le soir, le weekend ou pendant mes vacances. Ce faisant, j'ai en fait changé (sans trop en prendre conscience à ce moment-là) la "propriété" de la forge. Je l'ai fait avec les meilleurs intentions du monde, à savoir continuer à faire vivre le logiciel. Avec le recul, je me rends compte que ce changement était un peu cavalier vis à vis de mon entreprise et de mon client.

J'ai par la suite continué à développer le logiciel. Tant et si bien qu'il vit encore aujourd'hui : corrections de bugs, nouvelles fonctions, etc. La communauté autour du projet n'est pas encore très développée (99% des commits sont les miens), mais le projet connaît cette année ses premières contributions de patches (bugfixes, features). C'est très encourageant pour la suite !

1er événement déclencheur : une opportunité financière

Un jour, je suis contacté (pas sur la mailing list, mais par email privé) par une personne intéressée par du support et de nouvelles fonctions. Elle est prête à payer pour ça. Cool !

Passée la première réaction de joie, je commence à m'interroger sur la façon de procéder : travailler en freelance sur le projet à côté de mon job normal, ou bien mettre mon entreprise dans la boucle (et négocier une petite prime au passage) ? Quelque soit l'option, je ne souhaite pas bosser sur le projet sans en parler au préalable avec mon employeur afin que la situation soit claire.

Du coup, j'en parle à mon patron. Je lui explique la situation. Très rapidement, il me propose de réaliser le projet au sein de l'entreprise (normal, c'est un patron, il ne va pas refuser une opportunité financière ;-) et même d'aller plus loin : il souhaite sponsoriser le projet opensource !

Ne m'attendant à pas cette proposition, je suis agréablement surpris ! En effet, je gagne sur tous les tableaux (de mon point de vue) :
1. pas besoin de se lancer en freelance (création entreprise, gestion contrat/paiement…) pour un petit projet alors que je n'en aurais pe jamais d'autres,
2. pas besoin de mener 2 jobs en parallèle pendant la durée du projet,
3. je suis payé pour bosser sur un projet opensource que j'apprécie, que demander de mieux :)

On parle ensuite un peu organisation, objectifs techniques du sponsoring, etc. Tout va bien, on est d'accord sur tout. J'accepte donc l'offre et je mets mon entreprise en relation avec le potentiel client.

2nd événement déclencheur : le site web

Pendant que le dialogue avec le client se poursuit dans le cadre professionnel, je développe sur mon temps personnel un site web pour le projet. C'était une idée qui me passait par la tête depuis un bon moment car la forge est trop limitée. Le site présente de manière bien plus claire le logiciel et les ressources disponibles sur le projet.

Je place également sur le site le logo de mon entreprise et je mentionne que c'est un sponsors pour le projet. Comme il s'agit de l'image de l'entreprise, je montre le site à mon patron avant de le publier. Je souhaite avoir son aval sur la communication autour du nom de la société pour être sûr de ne pas faire de gaffe.

Je pensais que cela serait une simple formalité. Je me trompais.

Le site web a bcp plût techniquement parlant. En revanche, mon patron souhaite que le design suive totalement celui de l'entreprise (logo, formes, couleurs…). Il me fait également comprendre que le site devra être entièrement contrôlé par l'entreprise car il contribue financièrement au projet. Il veut de manière générale contrôler toute la communication autour du projet. La forge doit passer sous son contrôle (il me précise à plusieurs reprises que je n'aurais pas dû changer la "propriété" de la forge). La liste des contributeurs doit être remplacée et ne contenir que l'entreprise (mon nom et mon adresse perso dérangent). Je serais la personne qui gère techniquement le projet au sein de l'entreprise, mais si je quitte la société, tout restera sous son contrôle. Cela l'embête également que je continue à contribuer sur mon temps perso car cela serait trop compliqué à gérer. Il se garde également la possibilité de refuser des contributions de sociétés potentiellement concurrentes afin de conserver le lead du projet…

À l'issue de cet entretien, je suis consterné. La situation s'est complètement inversé. J'ai l'impression de m'être fait piéger : je ne souhaite pas me fâcher avec mon patron, ni démissionner, mais je ne souhaite pas non plus me faire "voler" le projet sur lequel j'ai passé autant de temps. Comment trouver une issue heureuse à tout ça ?

La phase de dialogue

Le côté positif à ce moment de l'histoire, c'est que mon patron reste ouvert à la discussion. S'enchaînent donc plusieurs entretiens dans lequel on essaie de comprendre nos points de vue respectifs, ainsi que nos vision de l'opensource respectives.

Les points qui m'embêtent :
1. contrôle total par l'entreprise : je souhaite que le projet puisse rester indépendant, je souhaite que n'importe qui puisse contribuer et que cela soit mentionné en bonne place sur le site.
2. site web "marketé" : je ne souhaite pas un site web qui laisse à penser que le projet est très lié à une société, que c'est du "faux opensource" (ouverture du code, mais contributions autres que celles de la société mal acceptées).

Mon patron est ouvert à l'idée de créer un "groupe" de personnes qui décident de l'orientation. Ce groupe de personnes pourrait inclure des personnes extérieures à l'entreprise (le client initial s'il le souhaite, de futurs contributeurs importants…). Cela peut permettre d'assurer un peu d'indépendance au projet.

En revanche, mon patron considère comme non négociable le contrôle sur la communication et le code : site web et forge. Si je quitte la société, je ne pars avec rien. Je garde la possibilité de forker le code bien évidemment, mais je repartirais à zéro au niveau de la communauté que j'ai commencé à créer.

La question (enfin !)

Que pensez-vous de la situation ? Dois-je accepter la proposition (je gagne un sponsors, mais je perds le contrôle du projet) ou bien la refuser (je ne gagne pas de sponsors, mais je conserve le contrôle du projet) ?

À vos stylos, vous avez 2 heures… ;-)

PS : J'ai créé un compte linuxfr pour l'occasion. Ce n'est pas génial (et cela contrevient aux règles décrites lors de la création d'un compte), mais je ne souhaite pas que mon identité révèle le nom de mon entreprise. Le but de ce journal n'est certainement pas de ternir en quoi que ce soit l'image de la société dont il est question. L'entreprise est très agréable par ailleurs. Si vous êtes en mesure de m'identifier, d'identifier le projet ou d'identifier la société (je sais que des employés lisent linuxfr), merci de ne mentionner aucun des trois et faites attention à ne pas donner d'indice non plus !

  • # Paternité

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

    Il me semble que le code appartient bel et bien à ta boite.
    En effet, le code que tu as produit sur le temps de ton boulot ne t'appartient pas puisque tu as été payé pour ça (les juristes pourront reformuler plus précisément, mais l'idée est là).
    D'autre part (et là je suis moins sûr de moi) le code que tu écris lors de ton temps libre ne t'appartient pas non plus car il est directement lié à ton boulot. Je me rappelle d'un cas d'un dev qui codait un soft entièrement sur son temps libre mais dans le domaine pour lequel il était payé par sa boite : il a dû redonner la paternité de son code à son entreprise.

    Tout ça pour dire que techniquement, si ton entreprise veut reprendre le contrôle du code, et même changer la license) elle en a entièrement le droit. Et toi tu as le droit de faire un fork.

    • [^] # Re: Paternité

      Posté par  . Évalué à 3.

      Tout ça pour dire que techniquement, si ton entreprise veut reprendre le contrôle du code, et même changer la license) elle en a entièrement le droit.

      Il s'agissait au départ de la reprise d'un projet en GPL externe à la boite. Du coup, je doute qu'elle puisse changer la licence de l'intégralité du projet. Mais je n'ai pas l'impression que c'est son objectif de toute façon.

      • [^] # Re: Paternité

        Posté par  . Évalué à 5.

        Tout ça pour dire que techniquement, si ton entreprise veut reprendre le contrôle du code, et même changer la license) elle en a entièrement le droit.

        Il s'agissait au départ de la reprise d'un projet en GPL externe à la boite. Du coup, je doute qu'elle puisse changer la licence de l'intégralité du projet. Mais je n'ai pas l'impression que c'est son objectif de toute façon.

        Le code d'origine est GPL. Le code que j'ai ajouté dans le cadre professionnel aussi. Le code que j'ai ajouté dans le cadre personnel aussi. Cela ne peut plus être changé sans l'accord de tous les auteurs. Le "copyright" est partagé entre les auteurs d'origine, mon entreprise et moi-même (pour les parties faites sur mon temps perso).

        • [^] # Re: Paternité

          Posté par  . Évalué à 1.

          En théorie, si il s'avère que le code appartient à ton employeur, rien n'autorisait à le diffuser (GPL ou pas).

    • [^] # Commentaire supprimé

      Posté par  . Évalué à 2.

      Ce commentaire a été supprimé par l’équipe de modération.

    • [^] # Re: Paternité

      Posté par  . Évalué à 6.

      Il me semble que le code appartient bel et bien à ta boite.
      En effet, le code que tu as produit sur le temps de ton boulot ne t'appartient pas puisque tu as été payé pour ça (les juristes pourront reformuler plus précisément, mais l'idée est là).
      D'autre part (et là je suis moins sûr de moi) le code que tu écris lors de ton temps libre ne t'appartient pas non plus car il est directement lié à ton boulot. Je me rappelle d'un cas d'un dev qui codait un soft entièrement sur son temps libre mais dans le domaine pour lequel il était payé par sa boite : il a dû redonner la paternité de son code à son entreprise.

      Que le code que j'écris sur mon temps appartienne à l'entreprise me paraît étonnant. As-tu un référence ?

      • [^] # Re: Paternité

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

        En effet, le code que tu as produit sur le temps de ton boulot ne t'appartient pas puisque tu as été payé pour ça (les juristes pourront reformuler plus précisément, mais l'idée est là).

        relire ton contrat de travail, dans le domaine informatique c'est souvent rappelé.

        le code que tu écris lors de ton temps libre ne t'appartient pas non plus car il est directement lié à ton boulot.

        Que le code que j'écris sur mon temps appartienne à l'entreprise me paraît étonnant. As-tu un référence ?

        Je ne suis pas juriste et il y a pour moi deux cas :

        • un où le code n'est pas lié à ton entreprise : là je vois mal comment une entreprise pourrait y avoir un lien (hormis si tu le fais sur les outils fournis par ton entreprise, et encore…)
        • un où le code est lié à ton boulot : là oui, ça semble envisageable, et encore (comme tu l'indiques tu n'avais plus de directives pour travailler sur ce projet au titre de ton boulot)

        La FSF recommande de faire signer à son entreprise un papier pour clarifier la situation, tu peux trouver par exemple :

    • [^] # Re: Paternité

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

      Je pense que tu as raison sur la propriété intellectuelle du code, par contre l'entreprise semble lui demander un peu plus : la "propriété" de la communauté, c'est-à-dire les droits d'accès sur l'infrastructure. Sur le plan purement légal, je ne pense pas que son employeur soit propriétaire de cela dans la mesure où ça a été réalisé personnellement.

      Telle que je comprends la situation, l'entreprise est bien propriétaire du code, mais pas forcément propriétaire des droits de commit sur le repository précis sur lequel le code se trouve actuellement.

      • [^] # Re: Paternité

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

        Après lecture des commentaires ci-dessous (désolé, la prochaine fois je le ferai avant de poster), il apparaît que l'auteur du journal a "volé" l'accès à la forge, qui était auparavant à la boîte. J'imagine que ca pourrait carrément être vu comme une faute professionnelle.

        Je crois qu'il y a au moins le "droit moral" de l'auteur qui lui permettra de réclamer que son nom personnel apparaisse, pour tout le reste c'est le patron qui dirige.
        Par contre, pour la forme, ce n'est pas de sponsoring qu'il s'agit. Le sponsor achète de l'influence, pas le contrôle total.

  • # négo

    Posté par  . Évalué à 10. Dernière modification le 17 juin 2012 à 17:28.

    c'est malheureux, mais si tu n'es pas prêt à te fâcher avec ton patron, il aura tout ce qu'il voudra. C'est dommage que tu n'aies pas eu conscience plus tôt de rentrer dans une phase de négociation, tu aurais pu mieux te préparer. Mais bon, ce n'est pas trop tard.
    - identifie les trucs qui sont absolument non négociables pour toi et ne lâche rien dessus,
    - identifie ce qui est vraiment pas négociable pour ton patron,
    à noter qu'à ce point là, on peut se rendre compte qu'il n'y a aucun accord possible.
    - identifie les trucs sur lesquels tu peux lâcher un peu,
    - identifie les moyens que tu peux utiliser pour faire pression (en étant prêt à aller jusqu'à les mettre en oeuvre): fork communautaire, désengagement total du projet, …)
    - identifie les arguments et prépare des contre arguments à ceux que peut faire valoir ton patron.

    par exemple, sur le site web, tu l'as développé sur ton temps libre. Si ton patron le veut, échange le contre plus de contrôle sur le projet (ou une prime, ou un autre truc qui est important pour toi)

    Sur le plan moral, la situation est pas si claire que ça. Le projet était développé pour le compte d'un client, donc pas un investissement de ta boite. Tu as ajouté des nouvelles fonctionnalités sur ton temps libre, pas sur ton temps de travail. Du coup, revendiquer le contrôle complet, je trouve ça gonflé.

    sinon, il n'a manifestement pas bien compris le concept de la sponsorisation. Un sponsor file des sous, et à ce titre peut avoir plus d'influence sur le projet que les autres gens, mais s'il prend le contrôle, ça ne s'appelle plus un sponsor. A voir s'il est vraiment persuadé qu'il est dans son bon droit, ou est-ce qu'il tente simplement le coup en se disant que si tu laisses passer, il gagne sur toute la ligne, et que si tu réagis, vous trouverez quand même un accord qui lui ira.

  • # Qui est le patron

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

    Dans le cadre professionnel,

    Voila, c'est dit : un mot, et c'est clarifié. Le patron, ce n'est pas toi, c'est ta boite. Ce que tu as fait sur ton temps perso est sympa, mais ça reste une chose précise : une contribution externe au projet. Ca ne te donne aucun droit sur la forge.

    je développe sur mon temps personnel

    Et la, le tout est de savoir comment tu as commité : copyright ta boite ou toi? Sachant que si c'est copyright toi, tu es dans un beau bordel, car tu as mélangé pro et perso sans prévenir, et donc en cas de conflit, à mon avis tu perds. Donc pro.

    J'ai l'impression que le problème principal est que tu n'as pas du tout réfléchi avant aux conséquences de tes commits persos sur un projet pro (de ta boite), du coup aïe.

    Les points qui m'embêtent : (…)

    De mon point de vue, ils sont normaux : le code et forges appartiennent à l'entreprise, donc elle contrôle. Tu as beaucoup bossé en perso, tu connais, OK, mais c'est juste un argument de discussion dans la discussion, et le patron est ta boite, pas toi.

    En revanche, mon patron considère comme non négociable le contrôle sur la communication et le code : site web et forge. Si je quitte la société, je ne pars avec rien.

    C'est normal, vu ce que tu nous as dit dessus.

    , mais je ne souhaite pas non plus me faire "voler" le projet sur lequel j'ai passé autant de temps.

    Le problème, si je comprend bien la situation, est que tu ne peux te faire voler une chose qui ne t'appartient pas, et tu n'as pas regardé ce problème avant de passer du temps. Pire, c'est plutôt toi qui a commencé à "voler", même si tu n'avais pas de mauvaises intentions. Bon, le mal est fait, maintenant tu ne peux pas revenir en arrière, faut vivre avec, et clarifier.

    Que pensez-vous de la situation ? Dois-je accepter la proposition (je gagne un sponsors, mais je perds le contrôle du projet) ou bien la refuser (je ne gagne pas de sponsors, mais je conserve le contrôle du projet) ?

    A mon avis, si tu refuses tu perds quand même le contrôle du projet, tu as réveillé le patron dessus (ne regrette pas de lui avoir dit : ça te serait retombé dessus un jour, au plus mauvais moment loi de Murphy oblige, et ça aurait pu faire mal, très mal), et il a vu que tu as commit une petite faute professionnelle en t'appropriant ce qui ne t'appartient pas (mettre ton adresse perso plutôt que pro). Ce n'est pas plus mal, maintenant ça va clarifier la situation.
    Donc de mon point de vue, ton patron est assez conciliant par rapport au bordel mis, et te laisse de la marge de manœuvre, donc accepte. Tu n'as finalement pas grand chose à gagner à ne pas avoir de "sponsor" (qui est un mauvais mot : il n'est pas sponsor, mais patron ;-) ), les armes sont chez ton entreprise à la base et ton patron ne te plombe pas, et ton unique alternative est de démissionner et forker.

    Bref, n'imagine pas qu'il sponsorise : il dirige, c'est lui le patron. Un sponsor, c'est quand tout t'appartient et que tu négocies un changement contre du fric, ici ce n'est pas le cas (il manque "tout t'appartient" comme condition). Ici, tu choisis sur quoi tu veux travailler, et négocie ta compétence sur le produit contre certains points de détail, pas sur les grands principes.

    Pour l'avenir, toujours, toujours faire attention à qui est le patron pour savoir si tu acceptes de faire un développement sur la forge "officielle" sur ton temps perso. Tu as codé en oubliant que 50% d'un code est les quelques premières lignes du fichier (sa licence + le nom du copyright).

    je ne souhaite pas que mon identité révèle le nom de mon entreprise. Le but de ce journal n'est certainement pas de ternir en quoi que ce soit l'image de la société dont il est question.

    C'est tout à ton honneur.

    • [^] # Re: Qui est le patron

      Posté par  . Évalué à 7.

      le code et forges appartiennent à l'entreprise

      la forge, oui. Pour le code, c'est beaucoup moins clair. Le projet de départ était un projet GPL externe. L'entreprise détient les droits sur tout le code produit par 261f030600e9 dans le cadre professionnel. Mais pour ce qui concerne le code développé sur son temps libre, je suis pas certain que ça soit si clair que ça. Il aurait pu tout aussi bien le diffuser sur un git quelque part.

      • [^] # Re: Qui est le patron

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

        Mais pour ce qui concerne le code développé sur son temps libre, je suis pas certain que ça soit si clair que ça.

        Le problème est qu'il est impossible techniquement de faire la différence (les heures de commit, ça ne compte pas vraiment…), donc si ça clashe et va en justice, à mon avis le juge ne fera pas la différence et considérera que c'est pro vu qu'il a un contrat de travail et que son poste portait sur ce projet. Je ne suis pas juge, certes, mais à mon avis c'est dangereux de compter sur le "perso" faute de séparation claire (ou alors, faudrait vraiment que son poste pro n'était plus du tout sur ce projet par exemple, de manière explicite)

        • [^] # Re: Qui est le patron

          Posté par  . Évalué à 4.

          ou alors, faudrait vraiment que son poste pro n'était plus du tout sur ce projet par exemple, de manière explicite

          c'est ce qu'il ressort de son explication. Une fois la livraison faite au client, hors un peu de support, le projet est tombé dans l'apathie. Même sans que ça soit explicite, il suffirait de montrer que ses tâches professionnelles ultérieures l'occupait à temps plein, ce qui ne laissait que le temps perso pour travailler sur ce projet.

          • [^] # Re: Qui est le patron

            Posté par  . Évalué à 4.

            ou alors, faudrait vraiment que son poste pro n'était plus du tout sur ce projet par exemple, de manière explicite

            c'est ce qu'il ressort de son explication. Une fois la livraison faite au client, hors un peu de support, le projet est tombé dans l'apathie. Même sans que ça soit explicite, il suffirait de montrer que ses tâches professionnelles ultérieures l'occupait à temps plein, ce qui ne laissait que le temps perso pour travailler sur ce projet.

            Oui. Les 2 phases sont bien séparées. De plus, je n'ai jamais fait un commit "perso" sur mes horaires de travail.

            • [^] # Re: Qui est le patron

              Posté par  . Évalué à 3.

              Oui. Les 2 phases sont bien séparées. De plus, je n'ai jamais fait un commit "perso" sur mes horaires de travail.

              Le probleme c'est que tu as change le controle de la forge sur ton email perso. En cas de conflit, ca donne des munitions a ton employeur.

              A ta place, j'essayerais de recuperer le max (en primes, responsabilites, etc.) pour ton travail perso, sachant que si ton patron veut recuperer le controle, il peut te faire chier (et gagner a l'epuisement) pour les raisons que Zenitram donne plus haut (i.e. pas de separation claire au niveau legal avec un accord signe).

              • [^] # Re: Qui est le patron

                Posté par  . Évalué à 4.

                Le probleme c'est que tu as change le controle de la forge sur ton email perso. En cas de conflit, ca donne des munitions a ton employeur.

                Oui, je ne vais pas oublier cette erreur pendant longtemps. C'est comme ça que l'on apprend ceci dit…

                • [^] # Re: Qui est le patron

                  Posté par  . Évalué à 6.

                  nan mais faut relativiser un peu aussi.

                  Si ton employeur insiste lourdement sur cet aspect des choses, tu peux désarmer ça en montrant ta bonne foi: soit en remettant ton e-mail pro à la place du perso, soit en l'attribuant à un alias e-mail de ta boite (ce qu'il aurait en fait été bien de faire dès le début si ton employeur avait vraiment eu envie de continuer sur ce projet).

                  à te lire, j'ai quand même du mal à comprendre la position de ton employeur qui trouve d'un seul coup que c'est projet super important qui lui appartient alors qu'il en a rien eu à battre pendant longtemps. Qu'aurait-il dit si tu avais abordé le sujet il y a 3 mois, c'est à dire avant qu'on te contacte pour proposer un contrat de support ?

                  est-ce qu'il est toujours aussi motivé pour investir là dessus si tu lui annonces que tu laisses tomber ?

                  bref, je vois le mal partout chez les méchants patrons ;-)

    • [^] # Re: Qui est le patron

      Posté par  . Évalué à 5.

      Dans le cadre professionnel,

      Voila, c'est dit : un mot, et c'est clarifié. Le patron, ce n'est pas toi, c'est ta boite. Ce que tu as fait sur ton temps perso est sympa, mais ça reste une chose précise : une contribution externe au projet. Ca ne te donne aucun droit sur la forge.

      Je suis d'accord avec toi. J'ai usurpé la propriété de la forge. Je ne me cache pas sur ce point.

      je développe sur mon temps personnel

      Et la, le tout est de savoir comment tu as commité : copyright ta boite ou toi? Sachant que si c'est copyright toi, tu es dans un beau bordel, car tu as mélangé pro et perso sans prévenir, et donc en cas de conflit, à mon avis tu perds. Donc pro.

      Email name@boite.com pour commit pro, email prenom@nom.org pour commit perso.

      J'ai l'impression que le problème principal est que tu n'as pas du tout réfléchi avant aux conséquences de tes commits persos sur un projet pro (de ta boite), du coup aïe.

      Oui, je n'ai pas réfléchi aux conséquences car cela ne s'est pas fait d'un coup, mais bien petit à petit. De plus le projet n'était plus actif au sein de l'entreprise, donc je n'ai pas au même instant mélangé les côtés pro et perso.

      Les points qui m'embêtent : (…)

      De mon point de vue, ils sont normaux : le code et forges appartiennent à l'entreprise, donc elle contrôle. Tu as beaucoup bossé en perso, tu connais, OK, mais c'est juste un argument de discussion dans la discussion, et le patron est ta boite, pas toi.

      La forge appartient à l'entreprise. Le code appartient à plusieurs personnes de mon point de vue : les auteurs du projet d'origine, ma boîte et moi-même.

      , mais je ne souhaite pas non plus me faire "voler" le projet sur lequel j'ai passé autant de temps.

      Le problème, si je comprend bien la situation, est que tu ne peux te faire voler une chose qui ne t'appartient pas, et tu n'as pas regardé ce problème avant de passer du temps. Pire, c'est plutôt toi qui a commencé à "voler", même si tu n'avais pas de mauvaises intentions. Bon, le mal est fait, maintenant tu ne peux pas revenir en arrière, faut vivre avec, et clarifier.

      Si j'avais fait un fork à l'époque, je n'aurais rien "volé". Et, pourtant la forge que je gérerais aujourd'hui serait la seule pertinente (car active), celle d'origine serait complètement morte. J'aurais dû faire cette démarche.

      Pour l'avenir, toujours, toujours faire attention à qui est le patron pour savoir si tu acceptes de faire un développement sur la forge "officielle" sur ton temps perso. Tu as codé en oubliant que 50% d'un code est les quelques premières lignes du fichier (sa licence + le nom du copyright).

      Le copyright est partagé comme précisé précédemment. Mon nom apparaît dans les headers.

      • [^] # Re: Qui est le patron

        Posté par  . Évalué à 4.

        Pourquoi ne pas faire un fork maintenant si tu souhaites continuer. Tu prends un pseudo et tu continues. Eventuellement contacte les anciens dev pour garder le nom de leur projet s'ils acceptent d'initialiser la nouvelle forge.
        D'un coté il va y avoir une forge qui ne va plus vivre puisque j'imagine mal ton patron payer quelqu'un pour faire des développements dans le vide et de l'autre une vrai communauté.

        • [^] # Re: Qui est le patron

          Posté par  . Évalué à 6.

          Pourquoi ne pas faire un fork maintenant si tu souhaites continuer. Tu prends un pseudo et tu continues. Eventuellement contacte les anciens dev pour garder le nom de leur projet s'ils acceptent d'initialiser la nouvelle forge.
          D'un coté il va y avoir une forge qui ne va plus vivre puisque j'imagine mal ton patron payer quelqu'un pour faire des développements dans le vide et de l'autre une vrai communauté.

          Je ne suis pas sûr de duper mon patron juste en utilisant un pseudo :)

      • [^] # Re: Qui est le patron

        Posté par  (site web personnel) . Évalué à 9. Dernière modification le 17 juin 2012 à 22:23.

        Si j'avais fait un fork à l'époque, je n'aurais rien "volé". Et, pourtant la forge que je gérerais aujourd'hui serait la seule pertinente (car active), celle d'origine serait complètement morte. J'aurais dû faire cette démarche.

        Effectivement. Mais tu ne peux revenir en arrière. Ca fait partir des erreurs qu'on peut commettre, on apprend.
        Avec ce que tu dis, mon conseil reste le même : tant pis, accepte la proposition de ton chef, elle n'est pas si mal par rapport à ce que tu peux te prendre (dont un licenciement pour faute? Peut-être…) et un client n'est pas assez pour forker (un fork, un projet, il faut pouvoir en vivre en libre donc qu'avec des demandes d'évolution et pas de vente à l'unité, ce n'est pas facile, je le sais j'y suis en plein dedans ;-) ).

        Démissionne et forke uniquement si tu as de l'épargne pour amortir le coup + tu as une grande visibilité à long terme sur les clients potentiels prêts à payer du développement (et qu'ils te suivront toi plutôt que la boite)

        Et n'oublie pas la prochaine (et ça vaut pour tout le monde qui a tendance à l'oublier, je le vois assez souvent sur LinuxFr et ailleurs) : le code n'est que 50% du travail d'un projet, un passionné de code ne doit pas se lancer (seul) dans un projet, il faut une personne chargé des 50 autres % ou se taper le boulot, faire attention à la licence, aux droits.

        • [^] # Re: Qui est le patron

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

          Je crois que Zenitram a tout résumé

          Démissionne et forke uniquement si tu as de l'épargne pour amortir le coup + tu as une grande visibilité à long terme sur les clients potentiels prêts à payer du développement (et qu'ils te suivront toi plutôt que la boite)

          ウィズコロナ

        • [^] # Re: Qui est le patron

          Posté par  . Évalué à 3.

          Euh, un licenciement pour faute, juste pour avoir changé le proprietaire d'une forge d'un projet mort, ce qui a tellement gené l'employeur que ca n'a jamais été remarqué avant que l'employé n'en parle lui meme ?

      • [^] # Re: Qui est le patron

        Posté par  . Évalué à 7.

        Si j'avais fait un fork à l'époque, je n'aurais rien "volé". Et, pourtant la forge que je gérerais aujourd'hui serait la seule pertinente (car active), celle d'origine serait complètement morte. J'aurais dû faire cette démarche.

        À mon avis l'essentiel est dit. Tu aurais dû séparer le privé et le pro, tu as mélangé les deux, alors qu'il fallait laisser mourir le pro et dév pour toi sur un projet libre à ton nom. C'est ça qui fait que tu es en tort à présent.

        Maintenant tu as dév pour ton patron sans être payé, et tu lui as même trouvé un client. Ce que tu peux donc faire, c'est signaler à ton patron que c'est grâce à toi que ce client est arrivé et donc demander une prime pour le temps passé dessus.

        Pareil pour le site etc…, tu as intérêt à abandonner tes revendications de propriété pour l'instant, sauf si tu sûr de pouvoir redémarrer le projet sans ton patron, et sans l'infra de la boîte derrière. Parce que formellement, le code appartient à ton patron, et vu que tu as mis son logo dessus et que tu l'as mis en sponsor alors qu'il est ton patron, c'est normal qu'il le prenne moyen.

        En revanche, tu peux forker ton projet une fois que le dév actuel pour le client actuel est terminé et faire ton propre site cette fois. À moins que tu ais une clause de non-concurrence ou un truc du style.

        Dans tous les cas, ça veut dire que tu peux au mieux «vendre» ton travail déjà fait à ton patron, puis forker après ce dév-ci. Pour le site, tu peux lui dire que tu le laisses en ligne à ses conditions s'il te paye pour ça (ou autre chose, en rtt ,).

        Mes deux cents.

  • # fork !

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

    Quelles sont les modalitées du sponsoring ? Parce qu'un sponsor qui ne fait que mettre son logo sur la forge et locker les contributions et la comm', ça ne va pas t'avancer à grand chose.

    Pour ce qui est des commits hors boulot: tant que tu n'as pas libéré un projet pro sans l'accord de la boite (dans ce cas ça semble bien être gpl depuis longtemps et officiellement libéré par la boite/le client) tu peux bien sur proposer du code/te servir du code sur ton temps perso. Le potentiel problème est qu'ici tu as éventuellement décidé des règles sur la tenu du projet au niveau des contributions externes, par forcément voulues par la boite. C'est donc ambigu.

    Mais si tu es le seul derrière pour le moment, la communautée devrait suivre le fork assez facilement. surtout si finalement ta boite "perd" l'opportunité en question, et décide finalement de ne rien faire de ce projet.

    Personnellement, je prendrais assez mal ce genre de situation, et je pense que je forkerais. Tu n'as rien à perdre dans ta boite, et tout à gagner en dehors.

    • [^] # Re: fork !

      Posté par  . Évalué à 4.

      Quelles sont les modalitées du sponsoring ? Parce qu'un sponsor qui ne fait que mettre son logo sur la forge et locker les contributions et la comm', ça ne va pas t'avancer à grand chose.

      J'ai un pool de jours par an à ma disposition (~0,5 jours par semaine). Et j'ai la maîtrise technique du projet (dans les limites que m'imposeront pe ou pe pas mes chefs au fur et à mesure du temps).

      Pour ce qui est des commits hors boulot: tant que tu n'as pas libéré un projet pro sans l'accord de la boite (dans ce cas ça semble bien être gpl depuis longtemps et officiellement libéré par la boite/le client) tu peux bien sur proposer du code/te servir du code sur ton temps perso. Le potentiel problème est qu'ici tu as éventuellement décidé des règles sur la tenu du projet au niveau des contributions externes, par forcément voulues par la boite. C'est donc ambigu.

      Je ne suis pas sûr de bien te comprendre sur les règles au niveau des contributions externes…

      Mais si tu es le seul derrière pour le moment, la communautée devrait suivre le fork assez facilement. surtout si finalement ta boite "perd" l'opportunité en question, et décide finalement de ne rien faire de ce projet.

      Le problème, c'est que la boîte pourrait bien gagner le contrat avec le client que je mentionnes. Dans ce cas, je pourrais me retrouver dans une situation à la con : côté pro je dév pour le client sur la forge actuelle, côté perso je dév pour moi-même sur le fork. Difficile à gérer, non ? Vu la taille de la boîte, il est difficile de faire gérer ça par une équipe différente.

      Personnellement, je prendrais assez mal ce genre de situation, et je pense que je forkerais. Tu n'as rien à perdre dans ta boite, et tout à gagner en dehors.

      En fait, ça se résume à :
      * je ne forke pas et j'accepte la proposition ;
      * je forke et je démissionne ;
      * je retourne au charbon pour négocier un meilleur compromis.

      • [^] # Re: fork !

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

        J'ai un pool de jours par an à ma disposition (~0,5 jours par semaine). Et j'ai la maîtrise technique du projet (dans les limites que m'imposeront pe ou pe pas mes chefs au fur et à mesure du temps).

        Donc rien… Te libérer du temps pour bosser dessus, c'est nécessaire pour que le projet avance, donc c'est nécessaire pour la ta boite en retire quelquechose. Et la maitrise technique c'est du vent pour te faire plaisir, mais ça aurait été le cas naturellement (tu es la personne la plus compétente sur le projet et jusque là ta boite s'en foutait), et tu auras toujours les limites des chefs au dessus… Bref comme dis plus haut par des moules, c'est pas du sponsoring.

        Pour ce qui est des commits hors boulot: tant que tu n'as pas libéré un projet pro sans l'accord de la boite (dans ce cas ça semble bien être gpl depuis longtemps et officiellement libéré par la boite/le client) tu peux bien sur proposer du code/te servir du code sur ton temps perso. Le potentiel problème est qu'ici tu as éventuellement décidé des règles sur la tenu du projet au niveau des contributions externes, par forcément voulues par la boite. C'est donc ambigu.

        Je ne suis pas sûr de bien te comprendre sur les règles au niveau des contributions externes…

        Et bien un projet peut être libre mais ne pas permettre l'intégration de modifications. Par exemple, pas le commit bit sur le repo. Tu ne dis rien là dessus: tu as peut être détourné la façon dont est géré les contributions externes (il n'y avait rien de possible, tu t'octrois le commit bit en perso, peut être à d'autres contributeurs…)

        Se pose donc le problème de copyright, et comme d'autres l'ont suggéré, ce n'est pas à nous de donner le verdict, et un juriste serait plus à même de juger.

        En fait, ça se résume à :
        * je ne forke pas et j'accepte la proposition ;
        * je forke et je démissionne ;
        * je retourne au charbon pour négocier un meilleur compromis.

        Alors si j'ai bien compris, tu gagne rien de rien avec 1. Pas d'augmentation, ni de prime non plus ? "Merci pour le cadeau"

        Je comprends que 2. soit une décision lourde à prendre. Peut être que tu peux encore rediscuter avec ton boss et prendre le temps d'y réfléchir.
        D'ailleurs, on a aucune idée de la "valeur" et de l'avenir de ce logiciel, et ça peut jouer.

        En tout cas ça montre le besoin de clarifier très tôt. Et encore, à part placer dans le contrat de travail que tout ce qui est produit est sous license libre ou avoir à demander à chaque fois l'autorisation au dessus, je sens que la "clarification" ne sera jamais suffisante, entre les incompréhensions ou les divergences d'intérêts entre la direction et les autres… En tout cas j'ai commencé à y penser fortement il y a peu, et ta problématique me montre à quel point ça peut être important.

        Bon courage, quelque soit ta décision !

        • [^] # Re: fork !

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

          Alors si j'ai bien compris, tu gagne rien de rien avec 1.

          Bosser sur ce qui intéresse, ce n'est pas rien. Et il peut négocier.

          • [^] # Re: fork !

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

            je pars du principe qu'il n'y a pas que dans cette boite qu'il peut bosser sur quelquechose qui l'intéresse.

            D'ailleurs, quelque soit le choix final, il bossera sur ce qui l'intéresse. Donc si ce n'est pas rien, c'est franchement pas grand chose.

            Reste à voir ce qu'il peut négocier. Il semble avoir pas mal palabré déja.

          • [^] # Re: fork !

            Posté par  . Évalué à 2.

            Tout à fait. Le fait de bosser sur un projet opensource qui me plaît tout en étant payé est un point très positif. J'ai ainsi l'assurance d'avoir assez de temps pour gérer le projet quelque soit le tps libre dont je dispose dans ma vie perso.

        • [^] # Re: fork !

          Posté par  . Évalué à 2.

          Donc rien… Te libérer du temps pour bosser dessus, c'est nécessaire pour que le projet avance, donc c'est nécessaire pour la ta boite en retire quelquechose.

          Euh, un peu quand même ! Quand je bosse sur ce projet-là, je ne bosse pas sur un autre qui rapporte de l'argent immédiatement. C'est donc de l'investissement de sa part. Si aucun contrat ne vient, il perd sa mise. Sinon, il gagne.

          Et la maitrise technique c'est du vent pour te faire plaisir, mais ça aurait été le cas naturellement (tu es la personne la plus compétente sur le projet et jusque là ta boite s'en foutait), et tu auras toujours les limites des chefs au dessus…

          Oui, c'est en partie vrai. Je n'ai pas d'assurance sur le long terme que cela se passera bien de ce point de vue-là.

          • [^] # Re: fork !

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

            Donc rien… Te libérer du temps pour bosser dessus, c'est nécessaire pour que le projet avance, donc c'est nécessaire pour la ta boite en retire quelquechose.

            Euh, un peu quand même ! Quand je bosse sur ce projet-là, je ne bosse pas sur un autre qui rapporte de l'argent immédiatement. C'est donc de l'investissement de sa part. Si aucun contrat ne vient, il perd sa mise. Sinon, il gagne.

            Même si le client potentiel annule ? Même après la fin du projet de ce client ?

            • [^] # Re: fork !

              Posté par  . Évalué à 1.

              Même si le client potentiel annule ? Même après la fin du projet de ce client ?

              J'ai sa parole. Je le connais bien. Sur ce point, sa parole me suffit.

      • [^] # Re: fork !

        Posté par  . Évalué à 3.

        • je forke et je démissionne ;

        Si c'est pour monter un business sur ton soft ou bosser sur ce soft dans une autre boite, je regarderais attentivement les clauses de non concurrence de mon contrat de travail.

        C'est une clause assez standard de ne pas pouvoir se tirer avec la techno pour rentrer en concurrence directe avec la boite qui à financé le dev.

        • [^] # Re: fork !

          Posté par  . Évalué à 1.

          Si c'est pour monter un business sur ton soft ou bosser sur ce soft dans une autre boite, je regarderais attentivement les clauses de non concurrence de mon contrat de travail.

          C'est une clause assez standard de ne pas pouvoir se tirer avec la techno pour rentrer en concurrence directe avec la boite qui à financé le dev.

          Après vérification, je n'ai pas de clause de non-concurrence dans mon contrat.

      • [^] # Re: fork !

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

        J'ai un pool de jours par an à ma disposition (~0,5 jours par semaine). Et j'ai la maîtrise technique du projet (dans les limites que m'imposeront pe ou pe pas mes chefs au fur et à mesure du temps).

        Le temps de dev pour répondre à la demande du client serait en plus des 0.5 jours ou te devra le faire pendant cette demi-journée ?

        Matthieu Gautier|irc:starmad

        • [^] # Re: fork !

          Posté par  . Évalué à 1.

          Le temps de dev pour répondre à la demande du client serait en plus des 0.5 jours ou te devra le faire pendant cette demi-journée ?

          En plus. La 1/2 journée est dédiée à la "maintenance" du projet et offerte par ma boîte. S'il y a des projets clients en plus, ils bénéficieront de leur propre "budget" jours.

  • # Commence par clarifier....

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

    …la situation de tes commits à titre personnel. Il faudrait l'avis d'un juriste, mais à mon avis les commits que tu as fait sur ton temps personnel sont sous le copyright de ton employeur (tu es auteur, mais tu n'as pas le copyright).

    • C'est sûrement dit dans ton contrat de travail : ça touche le domaine de ton entreprise (difficile de plus être le cas vu que c'est un projet de ton entreprise).
    • Il est difficile de toute les façons de prouver que tu l'as fait sur ton temps libre (ton employeur peut dire que tu as codé au bureau, et ramené le patch chez toi).

    Je pense que ton employeur ne te vole rien, tu lui a juste gracieusement offert ton temps (je sais ça ne te fait pas plaisir, mais je veux juste que tu ne te mettes pas dans la merde). Mais bon le mieux est de voir ça avec ton employeur ; du coup tu auras la réponse pour tes commits futurs.

    Mais dans tous les cas (que tu aies le copyright ou non), en fait ça ne va pas changer grand chose pour le futur à mon avis. De toute les façons si 99% des commits viennent de ta boite, et bien elle contrôlera le développement. Il te reste le fork :

    • Si ton employeur exige de récupérer ton copyright même pour ton temps libre, et bien du coup ça sera pareil pour le fork (ça restera du libre et tu contrôlerait ce projet ceci dit, mais pas sûr que ça te plaise).
    • Cette fois ci parle en avant à ton employeur ; tu ne sembles pas vouloir te fâcher avec ta boite, mais ce n'est pas dit que cette idée leur plaise (ça fait un concurrent etc…).
    • Avant le projet n'avançait plus du côté de ta boite, du coup tes commits allaient dans la seule version existante. Si tu forkes, la journée tes commits iront sur une version, et tes commits sur ton temps libre iront sur une autre version. Les 2 versions vont elles beaucoup diverger ? Essaieras tu de récupérer les avancées venant de ta boite dans ton fork ? Avec le temps ça risque d'être frustrant cette gymnastique et cette perte de temps.

    Je dirais qu'au final il te restera les issues suivantes :

    • Tant pis, tu as fait du zèle pour ta boite, et tu essais éventuellement d'en retirer quelque chose (une prime pour le site par exemple).
    • Tu estimes être en position de force (car un technicien reconnu et difficilement remplaçable) : tu négocies pour obtenir plus de contrôle sur le projet (contributions externes, indépendance par rapport à ta boite etc…).
    • Tu montes ta propre boite et tu fais vivre ton fork ; en tant que créateur d'entreprise, je ne peux que te prévenir que ça sera beaucoup moins pépère que ta vie de salarié ! Même si j'aimerais que plus de libristes franchissent le pas, il faut bien avouer que ce n'est pas fait pour tout le monde.

    En espérant t'avoir aidé.

    • [^] # Re: Commence par clarifier....

      Posté par  . Évalué à 3.

      Mais bon le mieux est de voir ça avec ton employeur ; du coup tu auras la réponse pour tes commits futurs.

      Tu as raison. C'est un point à clarifier avec lui.

      Mais dans tous les cas (que tu aies le copyright ou non), en fait ça ne va pas changer grand chose pour le futur à mon avis. De toute les façons si 99% des commits viennent de ta boite, et bien elle contrôlera le développement.

      En fait, ça serait moi qui ferait le dév dans la boîte :)

      Cette fois ci parle en avant à ton employeur ; tu ne sembles pas vouloir te fâcher avec ta boite, mais ce n'est pas dit que cette idée leur plaise (ça fait un concurrent etc…).
      Avant le projet n'avançait plus du côté de ta boite, du coup tes commits allaient dans la seule version existante. Si tu forkes, la journée tes commits iront sur une version, et tes commits sur ton temps libre iront sur une autre version. Les 2 versions vont elles beaucoup diverger ? Essaieras tu de récupérer les avancées venant de ta boite dans ton fork ? Avec le temps ça risque d'être frustrant cette gymnastique et cette perte de temps.

      Si je forke, ça implique soit démission de ma part, soit abandon du projet par la boîte. Je ne peux pas tenir le projet "officiel" et le "fork" sans qu'il y ait collusion d'intérêt…

      Je dirais qu'au final il te restera les issues suivantes :

      Tant pis, tu as fait du zèle pour ta boite, et tu essais éventuellement d'en retirer quelque chose (une prime pour le site par exemple).
      Tu estimes être en position de force (car un technicien reconnu et difficilement remplaçable) : tu négocies pour obtenir plus de contrôle sur le projet (contributions externes, indépendance par rapport à ta boite etc…).
      Tu montes ta propre boite et tu fais vivre ton fork ; en tant que créateur d'entreprise, je ne peux que te prévenir que ça sera beaucoup moins pépère que ta vie de salarié ! Même si j'aimerais que plus de libristes franchissent le pas, il faut bien avouer que ce n'est pas fait pour tout le monde.

      Merci pour tes commentaires/conseils. Je vais commencer par clarifier le côté propriété intellectuelle.

      • [^] # Re: Commence par clarifier....

        Posté par  . Évalué à 4.

        Mais bon le mieux est de voir ça avec ton employeur ; du coup tu auras la réponse pour tes commits futurs.

        Tu as raison. C'est un point à clarifier avec lui.

        Si tu veux la vraie réponse c'est à un juriste qu'il faut demander, pas à ton employeur, et pas plus aux utilisateurs de linuxfr ;).

        • [^] # Re: Commence par clarifier....

          Posté par  . Évalué à 1.

          Si tu veux la vraie réponse c'est à un juriste qu'il faut demander, pas à ton employeur, et pas plus aux utilisateurs de linuxfr ;).

          L'idée, c'est de voir ça à l'amiable avec lui dans un 1er temps. S'il me dit "OK pour que le code que tu as écrit soit sous ton copyright, ce n'est pas celui de la société" et que l'on met ça par écrit, je pense que ça devrait suffire. Après s'il refuse…

      • [^] # Re: Commence par clarifier....

        Posté par  . Évalué à 2.

        Côté droits d'auteur, il faudrait à mon avis que tu admettes d'abord que tu as bossé gratis pour ton patron parce que le projet te plaisais. Ça arrive, c'est malheureux, mais tu risques seulement de te fâcher avec ton patron de vouloir récupérer direct toute la propriété du truc.

        Donc négocie plutôt le truc comme : hé patron, j'ai ramené du boulot à l'entreprise, ça mérite bien un avancement, une prime, que sais-je ;)

  • # Deux versions

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

    Tu peux essayer de négocier d'avoir deux versions:

    • une "pro" sous le contrôle de ta boite qui en assure la qualité et le support.
    • une "open" sous le contrôle d'une communauté qui accepte les contributions externes.

    Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

    • [^] # Re: Deux versions

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

      C'est aussi ce que je proposerait.

      J'ai bossé une boite qui fait de l'open source. Ils ont deux sites:

      • Un en .org qui est le site du projet (doc, forum, …)
      • Un autre en .com qui est la version pro (service de dev, formation, …)

      Le soft est pas mal géré par la boite elle même (licence "perso") mais il y a quand même quelques patch d'autre entreprise (partenaires). Elle vend même une version propriétaire à des clients avec des fonctionnalités particulières.

      Tu pourrais proposer une double version (avec deux sites). Si tu propose de ne pas faire de dev payant et de diriger toutes les opportunités commerciales vers ta boite (dans la limite des clauses de loyauté et non concurrence), ton patron pourrait accepter.

      Je suis globalement d'accord avec les commentaires précédents sur le fait que le code ne t'appartient pas. Par contre pour le site web je suis moins sur. Ce n'est probablement pas ton corps de métier, ça peut donc s'apparenter à du code perso. Si c'est le cas (à voir avec un juriste) tu peux tous simplement refuser de le donner à ta boite. C'est un point en plus de ton coté pour la négo.

      De plus, même si tu ne l'a pas fait dans ce sens, tu as associé ton nom au projet. Tu as donc une certaine renommé. Si tu fork il faut se poser la question de "qui sera suivi par la communauté ? toi ou ta boite ?"

      (Il te faudra peut être négocier un peu moins brutalement que j'en parle ;-)

      Matthieu Gautier|irc:starmad

      • [^] # Re: Deux versions

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

        Tu peux aussi faire valoir à ton patron que la version "communautaire" est un excellent produit d'appel et que des entreprises qui ont bien réussi dans le libre font comme ça (Red Hat et Fedora par exemple).

        Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

      • [^] # Re: Deux versions

        Posté par  . Évalué à 1.

        Tu pourrais proposer une double version (avec deux sites). Si tu propose de ne pas faire de dev payant et de diriger toutes les opportunités commerciales vers ta boite (dans la limite des clauses de loyauté et non concurrence), ton patron pourrait accepter.

        Rediriger toutes les opportunités commerciales fait partie de l'accord. Je ne l'ai pe pas bien explicité dans ma présentation, je n'ai parlé que de la 1ère (et seule pour le moment).

        Deux sites (.org/.com) n'est pas ce que souhaite mon patron. Il pense que seul le .org va être correctement référencé (car contenu technique pertinent) et que le .com ne va pas attirer les foules.

        Je suis globalement d'accord avec les commentaires précédents sur le fait que le code ne t'appartient pas. Par contre pour le site web je suis moins sur. Ce n'est probablement pas ton corps de métier, ça peut donc s'apparenter à du code perso. Si c'est le cas (à voir avec un juriste) tu peux tous simplement refuser de le donner à ta boite. C'est un point en plus de ton coté pour la négo.

        C'est sûr que ce ne sont pas les technos que j'utilise le plus au boulot, donc techniquement ça devrait moins porter à confusion. Mais bon, avec le domaine juridique, les évidences n'ont pas l'air d'être les mêmes que dans l'informatique :-/

        De plus, même si tu ne l'a pas fait dans ce sens, tu as associé ton nom au projet. Tu as donc une certaine renommé. Si tu fork il faut se poser la question de "qui sera suivi par la communauté ? toi ou ta boite ?"

        Et, puis, compter sur l'immobilisme d'une partie des gens…

        (Il te faudra peut être négocier un peu moins brutalement que j'en parle ;-)

        Oui, ne t'inquiète pas, je ne compte pas répéter à l'identique ce qui a été dit ici, sinon il va mal le prendre ;-)

        • [^] # Re: Deux versions

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

          Deux sites (.org/.com) n'est pas ce que souhaite mon patron.

          Vous avez des souhaits contraires, donc il faudra bien un compromis. S'il ne veut en faire aucun tu as deux possibilités:

          • partir et bien faire comprendre qu'il perdra le meilleur dev du projet avec le risque de le voir forké.
          • rester et bosser comme un fonctionnaire: 0 contribution, 0 assistance aux utilisateurs hors des horaires de boulot,

          Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

  • # Merci !

    Posté par  . Évalué à 4.

    Merci à tous pour vous remarques, analyses et conseils ! Ça m'a permis d'identifier la problématique de la propriété intellectuelle et de mûrir ma réflexion globale.

    La discussion avec mon patron continue. Je créerais un nouveau (et probablement dernier) journal avec ce compte pour vous donner le résultat de tout ça !

    • [^] # Re: Merci !

      Posté par  . Évalué à 5.

      et un journal dans quelques dizaines d'années pour qu'on sache enfin de quel projet il s'agit ? ;-)

      • [^] # Re: Merci !

        Posté par  . Évalué à 1.

        Le problème c'est que ça révèlerait également le nom de la boîte et le nom de mon patron. C'est très délicat, donc je ne pense pas que cela arrive ! Désolé.

        • [^] # Re: Merci !

          Posté par  . Évalué à 3.

          note l'échelle de temps: dans "quelques dizaines d'années", je pense qu'il y aura prescription !

          • [^] # Re: Merci !

            Posté par  . Évalué à 1.

            Au temps pour moi, j'avais manqué le mot dizaine dans ta phrase. Dans ce cas pourquoi pas ! Le soucis sera plus de m'en souvenir à ce moment-là ;-)

Suivre le flux des commentaires

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