La valorisation de logiciels de recherche au sein de l'Inria? / Transfert marchand-non-marchand présentation_laa_inria

Le transfert des logiciels au sein d’Inria Journées JDEV / Transfert marchand et non marchand

Laure Aït-Ali STIP Inria Rennes – Bretagne Atlantique 1e juillet 2015

SOMMAIRE

1. Droit et logiciel

2. La protection des logiciels

3. Transfert des logiciels : qu’est-ce qu’une licence ?

4. Transfert des logiciels : différents schémas de licencing

5. Précautions élémentaires et les « bonnes pratiques »

1e juillet 2015 Laure Aït-Ali - La diffusion des logiciels au sein d’Inria - 2

Droit et Logiciel Propriété intellectuelle, brevet vs droit d’auteur

Laure Aït-Ali - La diffusion des logiciels au sein d’Inria 1e juillet 2015 - 3

1

Propriété Intellectuelle

Propriété Industrielle Propriété Littéraire et Artistique

•  Brevets (inventions)

•  Marques •  Dessins et modèles •  …

Noms de domaine

•  Droit d’auteur : notamment logiciels et bases de données

•  Droits voisins (audiovisuel)


Propriété intellectuelle

Brevet / Droit d’auteur

Acquisition des droits

Formalités indispensables : à dépôt d’une demande à procédure d’examen à délivrance (ou rejet)

Droit reconnu à l’auteur « du seul fait de sa création » (art. L111-1 CPI)


Droits associés au brevet vs logiciels

Droit d’auteur et logiciel

Spécificités du logiciel

•  Lorsque le logiciel est développé dans le cadre de vos missions, les droits patrimoniaux sont dévolus à l’employeur

•  Reproduction, traduction, adaptation •  Mise sur le marché à titre onéreux ou gratuit

•  Les droit moraux restent acquis à l’auteur



Protection des logiciels Dépôts à l’APP, brevet, marque et nom de domaine

2

La protection du logiciel / droit d’auteur

•  Objet de la protection

•  Seule la mise en forme est protégée

•  Eléments non protégés •  Algorithmes •  Interfaces

•  Eléments protégés •  Architecture du programme •  Code source •  Ébauches, maquettes, dossiers d’analyse

fonctionnelle, documentation, etc.


La protection du logiciel / dépôt APP

Pourquoi déposer ?

Le logiciel est protégé par le droit d'auteur du fait de son existence, sans formalité.

A défaut d'avoir un titre de propriété, à l'image des brevets, le dépôt APP :

•  permet d'identifier précisément le logiciel •  aide à se constituer une preuve de l'antériorité •  permet l’identification des auteurs et des ayant-droit •  permet une meilleure traçabilité d’un logiciel et de ces versions

successives •  facilite la sanction des contrefacteurs •  apporte une garantie pour les partenaires


La protection du logiciel / dépôt APP Quand déposer un logiciel ?

Il appartient à chaque responsable de projet de développement d’identifier les moments dans la vie du logiciel, qui méritent que soit effectué un dépôt

•  Etat de maturité suffisant •  Changement de versions majeures •  Départ d’un membre important de l’équipe •  Apport dans un contrat (PI antérieure) •  Transfert ou autre valorisation du logiciel •  Avant toute diffusion (Open source ou code binaire)


La protection du logiciel / dépôt APP

Que déposer ?

•  Code source et/ou le code objet

•  Matériaux de conception préparatoire : spécifications

détaillées, architecture, maquettes, description des tests

d'intégration, scénarios

•  Documentation technique

•  Documentation d'utilisation


La protection du logiciel / Droit des Marques

Protéger le nom du logiciel Il est possible de déposer le nom du logiciel à titre de marque, mais ce n’est pas automatique :

•  à réserver pour les logiciels à forte visibilité •  pour des logiciels à visibilité moyenne, on peut réserver le nom de domaine (le nom de domaine est un droit opposable)

Intérêt de déposer la marque •  Sécuriser la forte utilisation faite du nom d’un logiciel •  Permet de « réserver » l’utilisation du nom d’un logiciel libre à la branche développée par Inria et ses partenaires : c'est un point crucial qui, typiquement, est un moyen de "contrôle" utilisé par des grosses communautés (on autorise les forks mais on contrôle la notoriété par le nom).

Attention une marque ou un nom de domaine ne peut être déposé par le chercheur en son nom propre


La protection du logiciel / Brevet

•  Conditions de brevetabilité •  Est brevetable une invention

•  Nouvelle : si l’invention n’est pas comprise dans l’état de la technique

•  Inventive : si, pour un homme du métier, elle ne découle d’une manière évidente de l’état de la technique

•  Et susceptible d’application industrielle : si l’objet de l’invention peut être fabriqué ou utilisé dans tout genre d’industrie

•  Ne sont pas considérées comme des inventions •  les découvertes ainsi que les théories scientifiques et les

méthodes mathématiques •  Les créations esthétiques •  Les plans, principes et méthodes dans l’exercice d’activités

intellectuelles ou dans le domaine économique ainsi que les programmes d’ordinateur

•  Les présentations d’informations


La protection du logiciel / Brevet

La brevetabilité du logiciel : une protection indirecte en Europe •  les programmes d’ordinateur ne sont pas brevetable « en tant que

tel » •  Un logiciel n’est pas un programme d’ordinateur « en tant que tel »

s’il présente un « effet technique » •  Exemples de brevets basés sur des logiciels dont la mise en œuvre

produit des caractéristiques techniques nouvelles et inventives : •  Traitement numérique d’image •  Traitement des signaux TV •  Pilotage d’un équipement •  Compression de données pour diminuer les temps de calcul •  Visualisation d’états de fonctionnement d’un système •  Protocole de communication •  Procédé de traitement de la parole en présence de bruits •  Un procédé de cryptage



Transfert des logiciels Qu’est-ce qu’une licence ?

3

Diffusion d’un logiciel

•  Transmission des droits

•  Cession : le titulaire perd ses droits

•  Concession : le titulaire garde ses (ou « des ») droits

•  L’autorisation d’utilisation est traduite par une « licence »

•  Une licence est NECESSAIRE pour toute diffusion de logiciel


Transfert des logiciels

Le choix de la licence

•  Document contractuel définissant les droits concédés au licencié par le titulaire des droits patrimoniaux

•  De la licence temporaire (gratuite ou pas) pour l’évaluation

•  … à la licence d’exploitation commerciale

•  Précise l’étendue des droits concédés (domaine, territoire, exclusivité, garanties, etc.) et la contrepartie financière


18

ü  Objet à licencier

ü  Domaine d’exploitation

ü  Territoire

ü  Exclusivité

ü  Droits concédés

ü  Produits dérivés

ü  Sort des améliorations

ü  Maintenance

ü  Garanties liées à la qualité technique du logiciel

ü  Garanties liées à la propriété intellectuelle

ü  Publicité sur le transfert

ü  L’accès du concédant aux dérivés du licencié

ü  Les restrictions de collaboration

Points importants dans un contrat de licence

1e juillet 2015 Laure Aït-Ali - La diffusion des logiciels au sein d’Inria

Les licences de logiciel libre

Open source software, free software au sens de la Free Software Foundation

http://www.gnu.org/philosophy/free-sw.fr.html Un logiciel est « libre » si la licence qui l’accompagne accorde à l’utilisateur : •  Liberté d’exécution, sans restriction de temps, de lieu, de

motif, de personne, etc. •  Liberté d’étudier le fonctionnement du programme et de

l’adapter à ses besoins •  Liberté de redistribuer des copies •  Liberté d’améliorer et de diffuser les améliorations

Ce qui implique l’accès au code source


Les licences de logiciel libre, quel choix ?

Ne pas confondre !!!

•  Logiciel du domaine public •  Logiciel pour lequel aucun droit patrimonial ne peut

être revendiqué •  N’implique pas la disponibilité du code source

•  Logiciel gratuit •  Logiciel mis à la disposition d’un public, à titre gratuit •  Généralement sous forme exécutable •  N’est pas un logiciel libre

•  Un logiciel libre peut-être commercial



Transfert des logiciels Focus sur différents schémas de transfert

4

22

•  Licence propriétaire

•  Diffusion en open-source

•  100% open-source

•  Diffusion mixte propriétaire / open-source

•  Dual licensing

•  OpenCore

•  Autres schémas

•  Diffusion en mode SaaS

Différents schémas de licensing


Les licences de logiciel libre, quel choix ?

Multiples ! Comment choisir ? Quelques critères •  Analyser l’impact de la licence

- sur le contributeur - sur l’utilisateur

•  Aspect héréditaire : tout logiciel dérivé doit se voir imposer une licence identique (ex : GPL, LGPL ; mais pas BSD)

•  Aspect contaminant : l’inclusion du logiciel dans un autre propage-t-il le caractère « libre » (ex : GPL mais pas LGPL)

•  Contrôle sur le développement (QPL interdit la diffusion des versions modifiées ; les modifications doivent être diffusées sous forme de patch)

24

•  Principe de double licence pour un logiciel

•  Diffusion sous licence libre non permissive (ex GPL)

•  A la demande sous licence propriétaire

ou

•  Diffusion sous licence libre non permissive (ex GPL) de la version n-1

•  Diffusion sous licence propriétaire de la version n

ou

•  Diffusion sous licence libre non permissive (ex GPL) d’une version « light »

•  Diffusion sous licence propriétaire d’une version « pro »

Dual licensing exemples


25

•  Principe de modularité d’un logiciel

•  « cœur » du logiciel sous licence libre permissive (LGPL, EPL, BSD, etc.)

•  Cœur : version minimale du logiciel qui le rend intéressant et utilisable notamment par les entreprises

•  Important : comment décider ce que l’on met dans le cœur

•  Modules à forte valeur ajoutée sous licence propriétaire

•  Ou version « pro » du logiciel sous licence propriétaire

Dans ce cas, cœur = version « light »

Open Core exemple


26

•  Le logiciel en tant que service ou Software as a Service (SaaS) •  Le logiciel est installé sur le serveur du licencieur (ou son

hébergeur, ou Cloud) •  Le licencié utilise le logiciel via une interface sur son poste de

travail (souvent un navigateur web)

•  Adapté aux logiciels applicatifs, possible aussi pour les librairies

•  Intérêts •  Pour une entreprise : transformer des revenus de licence en

revenus récurrents •  Pour un labo académique : diffuser un logiciel de recherche

sans avoir à diffuser ni code objet, ni code source et simplifier le support

Mode SaaS


Diffusion des logiciels, quelle licence ?

• Adapter la solution au besoin •  Utilisation gratuite du logiciel

à « freeware » suffit, pas besoin des codes sources •  Permettre à un industriel de tester et d’adapter avant d’acheter

à Licence d’évaluation •  Permettre le libre échange dans la communauté scientifique

à Licence spécifique (« académique ») •  Stimuler un maximum de contributions extérieures

à Licence connue, peu permissive (ex GPL)



Les bonnes pratiques 4

29

•  Des pratiques de réutilisation de code préexistant plus ou moins importantes

•  Un développement souvent collaboratif, à des niveaux d’échelle variables

•  dans l’entité

•  projets open-source

•  unités mixtes dans la recherche publique

•  Un développement parfois « éclaté »

Constat : tension entre pratiques de développement et propriété intellectuelle

Quelques éléments préalables sur le développement logiciel aujourd’hui


Attention aux mélanges hasardeux…

Licence propriétaire

Auteurs externes

Licence libre

Autre licence libre

Statut du logiciel ? Licence ? Transfert marchand ? Non marchand ?

Archive stagiaires Auteurs internes

Nouveau logiciel


Quelques histoires vraies

•  Création d’une start-up sur un « gros » logiciel •  20 à 30 ans de développement •  Un seul dépôt APP dans les année 90 •  Création de start-up •  Comment identifier les ayant-droit et les auteurs, notamment pour l’intéressement ? Ø  Le dépôt APP est un bon outil de traçabilité des auteurs



•  Logiciel libre versus logiciel propriétaire •  un gros logiciel open source dans un centre Inria •  Décision de création de start-up sur un schéma de double licensing •  La licence permissive du logiciel n’est alors plus adaptée •  6 mois de travaux pour rendre compatible le logiciel avec la licence choisie Ø  Code modulaire et identification composants exogènes importants



•  Contrat de consortium dans le cadre de projet européen •  Grosse base de logiciel embarqué •  Une équipe souhaiterait avoir une relation avec une PME •  Le contrat de consortium indique clairement que les résultats doivent être diffusés en OS •  Que faire ?



•  Arrêt EDUCAFIX c/ CNRS, UJF •  Cession d’une licence propriétaire vers EDUCAFIX •  EDUCAFIX découvre que le logiciel contient un composant GPL •  Procès ! Ø  Il est important d’avoir une maitrise de la PI dès les phases de développement


Dès la phase initiale du développement

Codage

•  Ne jamais considérer a priori qu’un soft est « jetable » •  Veiller à la qualité du code, de la documentation, etc. •  Attention à toute intégration d’un logiciel externe ; bien le

mettre en évidence (conséquence pour la diffusion) •  Entêtes •  Attention aux contributions des différents auteurs :

l’indiquer dans la documentation •  Faire des architectures modulaires : possibilité de retirer le

code tiers, facilite les analyses juridiques du logiciel •  Décrire et mettre à jour régulièrement l’architecture du

logiciel : aide la traçabilité



Utilisation de la forge •  Gestion du logiciel doit être très rigoureuse sur l’archivage des versions et la doc associée -> bien identifier ce qu’est une release •  Distinguer le code endogène du code exogène •  Usage de mailing-list préconisée •  Bien identifier les auteurs de documents afin de pouvoir identifier les auteurs du logiciel qui n’ont pas développé de code

Entêtes •  Bon entête = bon suivi historique et juridique


Dès la phase initiale du développement Propriété du logiciel •  Intégrer du code tiers implique qu’on n’est pas propriétaire à

100% du code •  Le tracer

•  il peut être recommandé de réécrire le code si faible contribution •  Sinon, mise en place d’une convention d’indivision avec les partenaires

Dépôt APP •  Ne pas diffuser n’empêche pas de déposer : protection, preuve d’antériorité •  Faire un dépôt à chaque étape importante de la vie du logiciel •  S’accorder fréquemment sur la répartition des % de contributions des auteurs



Envisager une licence •  Ne pas présupposer de la licence qui sera utilisée pour

la diffusion du logiciel •  Ne pas cocher la case « licence souhaitée » sous la

Forge qui permet le choix de la licence (garder le logiciel à diffusion interne) : la laisser à « none »

•  S’assurer de la compatibilité de licences des composants ; si ce n’est pas le cas, il faut le tracer

•  Vérifier que les contributions externes comprennent bien une licence


Avant toute diffusion externe

Décision de diffusion •  On ne diffuse pas un logiciel dès qu’on a fait quelque chose •  Nécessaire d’avoir l’accord de l’ensemble des titulaires des

droits patrimoniaux

Contacter les services adéquats •  Identification des auteurs et de leurs employeurs (titulaires

des droits patrimoniaux) •  Identification des éventuelles parties externes intégrées au

logiciel, ou nécessaires pour pouvoir utiliser le logiciel •  Identification des contrats ayant une incidence sur le logiciel •  Mise en place d’une éventuelle convention d’indivision •  Dépôt à l’APP


Avant toute diffusion externe

•  Choix de la licence (chef de projet, valo) •  Il faut étudier l’ensemble des possibles

•  Packaging •  Bien afficher la licence de distribution choisie •  Logiciels composites : est-ce vraiment nécessaire de distribuer le tout ? est-ce un vrai plus ?

•  Autres droits

•  Faire attention aux icones, nom du logiciel (marque), provenance des images, etc.


Lors de l’évolution du logiciel diffusé •  Codage

•  Intégration de composants externes, attention aux contradictions avec le schéma de licensing out déjà choisie

•  Changement de licence •  Ssi bonnes raisons de la faire •  Il faut l’accord de tous les ayant-droits

•  Entêtes •  A modifier à bon escient •  Garder l’historique des contributions antérieures

•  Gouvernance (projets open source) •  Centralisation des droits ou licences sur les contributions externes en fonction de la stratégie

•  Dépôt APP •  Dépôts réguliers afin de prendre en compte la dilution des versions successives et l’accumulation des efforts



Conclusion 5

La « politique » d’Inria

Maximiser l’impact des logiciels développés chez Inria

•  Identifier les logiciels qui ont passé l’étape « outil de labo » et qui ont vocation à être diffusés •  Vérifier leur « qualité » (code et PI) •  Protéger ces logiciels avant toute diffusion •  Choisir la ou les modalité(s) de diffusion et de valorisation •  Quand le « libre » est retenu, choisir la licence adaptée aux objectifs •  Faire connaitre ces logiciels •  Gérer les licences commerciales

1e juillet 2015 Laure Aït-Ali - La diffusion des logiciels au sein d’Inria 43

Développement logiciel : Quelques conseils

-  Réfléchir dès le départ à la finalité du logiciel : - transfert industriel ? Outil interne ? Démonstrateur ?

-  Pour chaque nouveau développement : - identifier l’équipe de développeurs - identifier les éléments de PI antérieurs (si besoin)

-  Déposer régulièrement à l’APP : - avant un contrat à connaissances antérieures - nouvelles versions, changements d’équipe, …

A retenir


A retenir

•  Le logiciel appartient aux employeurs des auteurs •  La protection de ce patrimoine est impérative •  Attention à l’intégration de logiciels « extérieurs » •  Exigence croissante sur la qualité (code et doc) •  Le transfert du logiciel peut prendre des formes diverses •  Le choix, de la licence « libre » en particulier, doit être étudié en fonction et être adapter au besoin


Merci

Questions ?

Inria Rennes – Bretagne Atlantique Journées JDEV 2015

www.inria.fr

Internet

La valorisation de logiciels de recherche au sein de l'Inria? / Transfert marchand-non-marchand présentation_laa_inria