Quelle License pour une API Rest consommée par une app FOSS

#1

Bonjour,
Je développe une application web libre et open source sous une license GPL3.0, et j’ai un doute sur le type de license que je devrais choisir pour le backend :
Je développe une API en Rust qui sera consommée par l’appli, l’API ne repose sur aucun service propriétaire.
Sur le principe j’ai envie de dire que cette API devrait être libre et open source aussi puisqu’elle fait partie d’un écosystème libre, mais je ne sais pas si c’est une bonne idée.
Donc je me demandais quelles était les pratiques habituelles dans les projets open-source au niveau des licenses et de la visibilité du repo (un repo pour un projet open source peut-il n’être visible que par les contributeurs ?).

Merci d’avance pour vos conseils et retours d’expérience.

#2

Salut,

Sur le principe j’ai envie de dire que cette API devrait être libre et open source aussi puisqu’elle fait partie d’un écosystème libre, mais je ne sais pas si c’est une bonne idée.

C’est pas une mauvaise idée, ça dépend vraiment de ce que tu veux faire de ton logiciel.

Exemple, quand tu choisis la GPL v3.0 en principe c’est que tu souhaites que ton programme soit un logiciel libre et le reste. Tu ne peux plus ou difficilement faire une version propriétaire de ce logiciel par la suite. Les personnes qui veulent redistribuer ton logiciel doivent en fournir les sources et, s’ils souhaitent faire des modifications, elles doivent être contribuées sur le projet.

Comme ton logiciel semble être en SaaS, et si tu veux renforcer le point si dessus, je te conseil de regarder la AGPL. Regarde cette page elle expliquera mieux que je pourrais le faire les avantages de la AGPL dans le cas d’une application en Saas. Pourquoi la GPL Affero ? - GNU Project - Free Software Foundation.

un repo pour un projet open source peut-il n’être visible que par les contributeurs

Pas impossible mais très bizarre, en principe si tu fais un logiciel libre, tu cherches à le développer publiquement et faciliter les contributions externes. Donc ton repo est public.

Voilà je ne m’étends pas trop sur le sujet qui est vraiment vaste, n’hésite pas à poser des questions pour orienter la discussion si besoin.

Attention aussi, sur les licences c’est extrêmement complexe, je pense avoir une connaissance de base et pas dire trop de bêtises. Mais sur certains points seul un juriste spécialisé sur le sujet pourra répondre correctement, c’est un métier.

2 « J'aime »
#3

Merci!

Oui c’est bien le cas, je tiens à ce que ça reste du libre.

Oui on peut dire ça je pense. Si je donne quelques détails ce sera peut-être plus concret:
En fait c’est une application en JS qui permet de construire un genre de jeu vidéo sans rien coder, on crée des images, on définit des actions possibles etc. Cette partie est complètement autonome en elle même, elle n’a pas besoin d’API.
Ensuite la partie API va servir à permettre aux utilisateur de publier et modifier leurs jeux, de consulter et jouer aux jeux publiés, et de “forker” un jeu pour en faire une autre version, etc.

Voilà, je vais regarder la AGPL pour le serveur, je ne connaissais pas.

Je me posais cette question par rapport aux questions de sécurité liées au fait d’exposer du code serveur (j’ai pas de doute pour le code de l’appli, le repo est déjà public). C’est un peu pour ça que je me demande comment les autres projets fonctionnent, pour connaître les pratiques courantes sur des projets libres sur une architecture web/rest ( et en plus je suis pas très fort en sécurité donc ça me fait toujours peur :sweat_smile: ).

#4

Je me posais cette question par rapport aux questions de sécurité liées au fait d’exposer du code serveur

C’est prouvé que la sécurité du code par obscurantisme ne marche pas. Donc de mon point de vue, c’est pas un problème. Je pense même que en mettant ton code en public, tu peux avoir des contributeurs qui te remontent des problèmes de sécurités. Plus tu auras de relecteurs plus le code sera fiable.
Et déjà si tu essayes de suivre les recommandations de l’OWASP (OWASP Top Ten Web Application Security Risks | OWASP) tu vas grandement limiter les risques. A relativiser aussi, manifestement ton application ne semble pas manipuler des données hautement confidentielles.

2 « J'aime »