Développeur et contributeur individuels
La règle
Le logiciel libre et open source non fourni dans le cadre d’une activité commerciale est hors du champ du règlement. Aucune obligation ne pèse sur le développeur, personne physique ou morale, qui met son travail à disposition dans ce cadre.
Toute la difficulté tient à la frontière du « commercial ».
Ce qui ne suffit pas à qualifier une activité commerciale
Les considérants du règlement écartent explicitement plusieurs situations :
- contribuer à un projet libre, même de façon régulière et importante ;
- héberger le code sur une forge ou un dépôt public, y compris avec des services payants pour le mainteneur ;
- accepter des dons destinés à couvrir les frais de développement ou d’infrastructure ;
- facturer de simples services accessoires — support technique, conseil, formation — distincts de la fourniture du logiciel lui-même ;
- collaborer avec des entreprises qui utilisent le logiciel, y compris en intégrant leurs contributions.
Ce qui bascule
L’activité devient commerciale lorsque le logiciel lui-même est fourni dans une relation d’affaires. Les indices convergents :
- le logiciel est facturé, sous quelque forme que ce soit — licence, abonnement, accès ;
- le développement est réalisé contre rémunération dans le cadre d’une relation commerciale identifiée ;
- le logiciel libre sert de produit d’appel à une offre payante liée, du type édition entreprise ou fonctionnalités réservées ;
- l’entité intègre le logiciel dans un produit qu’elle met sur le marché — mais alors elle est fabricant, ce qui est un autre statut.
Le cas de vos propres contributions
Trois situations doivent être tranchées par une politique interne écrite.
1. Un salarié contribue à un projet amont, sur son temps de travail, pour corriger un défaut qui vous affecte. C’est le cas le plus fréquent et le plus sain. Il ne vous qualifie ni de fabricant du projet amont, ni de sponsor : vous restez un utilisateur qui contribue. Le règlement encourage d’ailleurs explicitement le partage à l’amont des correctifs de sécurité — voir Intégrer de l’open source.
2. Vous publiez un projet libre issu de vos travaux, sans offre commerciale associée. Hors périmètre tant que la mise à disposition reste non commerciale. À réexaminer si une offre payante vient s’y adosser.
3. Vous financez durablement le développement d’un projet libre dont vous ne êtes pas le fabricant, et vous en assurez la viabilité. C’est la définition du sponsor de logiciel libre : voir la page dédiée.
Ce qu’il faut écrire
Une politique interne de contribution open source, courte, qui répond à :
- Dans quels cas un salarié peut-il contribuer à un projet amont sur son temps de travail ?
- Sous quelle identité — personnelle ou de l’entreprise ?
- Qui autorise la publication d’un nouveau projet libre par l’entreprise ?
- Qui vérifie, avant publication, que le projet ne bascule pas dans une qualification commerciale non voulue ?
- Comment sont documentées vos remontées de correctifs de sécurité à l’amont, qui sont attendues par le règlement et constituent une preuve de diligence ?
Cette politique relève du juridique, mais elle est appliquée par l’ingénierie : elle doit tenir en une page.