Le risque nettement plus pratique, c'est que ton employeur va avoir un gros doute : est-ce que sur tes heures de travail, tu ne vas pas te consacrer à "ton" projet open-source ?
Si c'est bien cloisonné il ne devrait pas y avoir de souci : on ne fait rien relatif au projet au boulot, les heures de commits (et de réponse aux tickets et requêtes de fusion) montreront eux que c'est bien fait en dehors des heures de boulot.
Où est la démarcation entre les deux ? Que faire quand tu trouves un bug au boulot dans ton projet "perso" ?
Au boulot, tu laisses les collègues régler les soucis et le signaler (perso je ne regarde même pas ce qu'ils font pour ne pas être influencé/pollué par leur résolution —histoire de ne pas emprunter du code à mon insu) ou tu fais un bug report sur le git(hub/lab/ea/olite/etc.) du projet perso, que tu regarderas sur ton temps libre quand tu en auras le temps.
Cette zone grise est mauvaise tant pour toi (équilibre vie pro / vie perso) que pour ton projet (risque à tout moment que l'employeur réclame la propriété de l’œuvre et invalide la licence open-source que tu aurais alors octroyée sans le droit de le faire).
Faudrait que ça corresponde à un besoin de l'employeur et exprimé tel quel avant que le projet démarre, et/ou que ce soit fait dans le contexte dédié (heures de travail ou outils de l'employeur)
Et même si l'employeur est d'accord dans un premier temps, rien ne dit que l'ambiance ne va pas changer (difficultés financières par exemple), mettant en péril ce qui a été bâti.
Si c'est l'employeur qui initie le projet, il faut que ce soit fait dans son cadre (et même pour la publication sur une forge publique, il faut que ce soit sous son logo et que les commits soient depuis les comptes pros et non persos.)
Oui, il faut une certaine schizophrénie, mais il est important de bien cloisonner.
"It is seldom that liberty of any kind is lost all at once." ― David Hume
[^] # Re: Quelques réponses
Posté par Gil Cot ✔ (site web personnel, Mastodon) . En réponse au journal Droits d'auteurs. Évalué à 4.
Si c'est bien cloisonné il ne devrait pas y avoir de souci : on ne fait rien relatif au projet au boulot, les heures de commits (et de réponse aux tickets et requêtes de fusion) montreront eux que c'est bien fait en dehors des heures de boulot.
Au boulot, tu laisses les collègues régler les soucis et le signaler (perso je ne regarde même pas ce qu'ils font pour ne pas être influencé/pollué par leur résolution —histoire de ne pas emprunter du code à mon insu) ou tu fais un bug report sur le git(hub/lab/ea/olite/etc.) du projet perso, que tu regarderas sur ton temps libre quand tu en auras le temps.
Faudrait que ça corresponde à un besoin de l'employeur et exprimé tel quel avant que le projet démarre, et/ou que ce soit fait dans le contexte dédié (heures de travail ou outils de l'employeur)
Si c'est l'employeur qui initie le projet, il faut que ce soit fait dans son cadre (et même pour la publication sur une forge publique, il faut que ce soit sous son logo et que les commits soient depuis les comptes pros et non persos.)
Oui, il faut une certaine schizophrénie, mais il est important de bien cloisonner.
"It is seldom that liberty of any kind is lost all at once." ― David Hume