Savoir si tu es à ton propre compte ou non ne suffit pas à déterminer si tu es en droit de décider de la licence de ton cadriciel, ni même de sa publication. Par exemple, si tu as développé ce cadriciel dans le cadre d'un contrat de prestation qui prévoit la cession des droits patrimoniaux à ton client (cas de figure assez fréquent), la décision appartient entièrement à ton client, et il n'a aucunement à te consulter ou à obtenir ton approbation pour cela.
Si ce n'est pas le cas (i.e. si tu as développé ce cadriciel de ta propre initiative, en le finançant sur fonds propres, ou si le contrat de prestation ne prévoit pas la cession des droits patrimoniaux), tu es en droit de décider de publier ton cadriciel sous licence libre.
La licence choisie doit être compatible avec celles des composants intégrés. Il faut donc commencer par établir leur liste. Selon les langages considérés et les outils disponibles, cette liste en profondeur – que l'on appelle un « Software Bill of Materials » (SBOM) ou « Software Supply Chain » – peut être établie de manière automatique ou non. De nos jours, il est de bon ton de publier ce SBOM au format CycloneDX. Publier le SBOM va même devenir une obligation en Europe avec la publication récente du « Cyber Resilience Act » (CRA).
Je ne l'ai jamais utilisé, mais je sais qu'un greffon Maven permet effectivement d'établir la liste exhaustive et en profondeur des composants intégrés. En effectuant une recherche rapide, je suis tombé sur l'article How to create SBOMs in Java with Maven and Gradle.
Si aucun des composants intégrés n'a de licence plus exigeante que la licence permissive Apache v2.0, tu peux décider de diffuser ton cadriciel sous cette licence ou sous une licence diffusive (faiblement, comme la licence GNU LGPL ou fortement, comme la licence GNU GPL). S'agissant d'un cadriciel, je déconseille le recours à une licence fortement diffusive qui dissuaderait beaucoup de personnes de l'utiliser (cette licence se diffusant alors à leur propre application), mais ce choix peut être une stratégie assumée.
La licence Apache v2.0 exige qu'une copie de la licence soit fournie à la racine du projet, dans un fichier nommé LICENSE(.txt), ainsi qu'un fichier NOTICE(.txt) contenant la liste des composants intégrés (liste de premier niveau, ceux que tu utilises explicitement et non ceux qui se trouvent intégrés en cascade, du fait des dépendances de dépendances).
Il est ensuite de bon ton de placer à la racine du projet un fichier README(.txt|.md|.rst) dans lequel tu auras inséré une mention de copyright et de licence (en renvoyant vers le fichier LICENSE(.txt).
Pour terminer, il est recommandé de placer une entête de copyright au début de chaque fichier dont le format le permet. Pour la licence Apache, cet entête peut être :
/* * Copyright (C) 2022-2024 John Doe * * This file is part of Taack-UI * * https://taack-ui.org/ * * Licensed under the Apache License, Version 2.0 (the "License"); * you may not use this file except in compliance with the License. * You may obtain a copy of the License at * * http://www.apache.org/licenses/LICENSE-2.0 * * Unless required by applicable law or agreed to in writing, software * distributed under the License is distributed on an "AS IS" BASIS, * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. * See the License for the specific language governing permissions and * limitations under the License. */
À ce stade, tu commences à avoir fait les choses plutôt bien. Reste éventuellement à choisir une licence différente et plus adaptée pour la documentation, les exemples et les ressources tierces. Pour plus d'informations à ce sujet, cf. mon article Projet libre : à chaque ressource sa licence.
# Marche à suivre
Posté par Sébastien Dinot (site web personnel) . En réponse au journal Java et les licences Open Source. Évalué à 8.
Bonjour,
Savoir si tu es à ton propre compte ou non ne suffit pas à déterminer si tu es en droit de décider de la licence de ton cadriciel, ni même de sa publication. Par exemple, si tu as développé ce cadriciel dans le cadre d'un contrat de prestation qui prévoit la cession des droits patrimoniaux à ton client (cas de figure assez fréquent), la décision appartient entièrement à ton client, et il n'a aucunement à te consulter ou à obtenir ton approbation pour cela.
Si ce n'est pas le cas (i.e. si tu as développé ce cadriciel de ta propre initiative, en le finançant sur fonds propres, ou si le contrat de prestation ne prévoit pas la cession des droits patrimoniaux), tu es en droit de décider de publier ton cadriciel sous licence libre.
La licence choisie doit être compatible avec celles des composants intégrés. Il faut donc commencer par établir leur liste. Selon les langages considérés et les outils disponibles, cette liste en profondeur – que l'on appelle un « Software Bill of Materials » (SBOM) ou « Software Supply Chain » – peut être établie de manière automatique ou non. De nos jours, il est de bon ton de publier ce SBOM au format CycloneDX. Publier le SBOM va même devenir une obligation en Europe avec la publication récente du « Cyber Resilience Act » (CRA).
Je ne l'ai jamais utilisé, mais je sais qu'un greffon Maven permet effectivement d'établir la liste exhaustive et en profondeur des composants intégrés. En effectuant une recherche rapide, je suis tombé sur l'article How to create SBOMs in Java with Maven and Gradle.
Si aucun des composants intégrés n'a de licence plus exigeante que la licence permissive Apache v2.0, tu peux décider de diffuser ton cadriciel sous cette licence ou sous une licence diffusive (faiblement, comme la licence GNU LGPL ou fortement, comme la licence GNU GPL). S'agissant d'un cadriciel, je déconseille le recours à une licence fortement diffusive qui dissuaderait beaucoup de personnes de l'utiliser (cette licence se diffusant alors à leur propre application), mais ce choix peut être une stratégie assumée.
La licence Apache v2.0 exige qu'une copie de la licence soit fournie à la racine du projet, dans un fichier nommé LICENSE(.txt), ainsi qu'un fichier NOTICE(.txt) contenant la liste des composants intégrés (liste de premier niveau, ceux que tu utilises explicitement et non ceux qui se trouvent intégrés en cascade, du fait des dépendances de dépendances).
Il est ensuite de bon ton de placer à la racine du projet un fichier README(.txt|.md|.rst) dans lequel tu auras inséré une mention de copyright et de licence (en renvoyant vers le fichier LICENSE(.txt).
Pour terminer, il est recommandé de placer une entête de copyright au début de chaque fichier dont le format le permet. Pour la licence Apache, cet entête peut être :
À ce stade, tu commences à avoir fait les choses plutôt bien. Reste éventuellement à choisir une licence différente et plus adaptée pour la documentation, les exemples et les ressources tierces. Pour plus d'informations à ce sujet, cf. mon article Projet libre : à chaque ressource sa licence.