[enh] Add YEP 1.3 about licensing information #413
Conversation
|
Je trouve cette yep très bien écrite, mais j'ai peur que ça soit trop compliqué et un peu le entre "trop compliqué" et "pas assez compliqué". Je pense aux fichiers debian où y a des globs pour décrire quels fichiers sont sous quelle licence, ici on a à la fois pas ce niveau de détails et un niveau de détails déjà assez poussé. J'arrive pas à savoir ce qui serait le plus utile en fin de compte. |
|
Perso, ce que j'aimerais à terme c'est pouvoir afficher des infos dans la webadmin sur la licence de l'application. Le choix free ou non-free me semble un peu juste en terme d'information, d'autant que la notion "free" fait débat. Dans l'idée, il faudrait pouvoir afficher le texte des licences. Le must serait d'avoir un résumé compréhensible façon Creative Commons (à voir si il y a des résumés quelques part). Pour moi il faudrait au moins que l'admin sache: est ce que c'est entièrement libre ou partiellement libre ou proprio ? Est ce que si je fais une modif sur mon instance je dois la republier forcément ? |
|
Quelques ressources :
|
|
YEP très bien rédigée, mais un peu complexe à mon avis. Cela étant, je ne vois pas comment faire plus simple que le nom abrégé de la license. |
There was a problem hiding this comment.
Merci pour cet effort.
C'est un sujet compliqué. J'ai déjà discuté de ça par le passé, je pense que résumer la license du paquet complet à un petit acronyme est difficile/tendancieux, quand ce n'est pas impossible.
Ta solution est néanmoins, AMHA, proche du "mieux qu'on puisse faire", si on veut absolument ça.
Du coup je validerais bien en l'état (validation mitigée, mais bon)
|
|
||
| Les listes d'applications official.json et community.json n'acceptent que les paquets dont la licence est libre, de même pour la licence de l'application contenue. Certaines applications libres nécessitent des dépendances non-libres (exemple: mp3, drivers, etc.). Dans ce cas, il faut ajouter `+dep-non-free` à l'acronyme et si possible donner des précisions dans le README.md du paquet, l'intégration sera dans ce cas acceptée au cas par cas. | ||
|
|
||
| Dans le future, YunoHost affichera sans doute des détails sur la licence de l'application. Pour y parvenir, l'acronyme doit être celui issue de cette [liste de licences répertoriées sur gnu.org](https://www.gnu.org/licenses/license-list.fr.html) (si il y a 2 acronymes, il faut prendre celui contenant le numéro de version). Pour plus de cohérence, la casse doit être respectée. |
|
|
||
| Si deux applications distinctes sont dans le même paquet d'installation et ont des licences distinctes, dans ce cas on peut utiliser le `&` pour séparer les licences. | ||
|
|
||
| Dans les deux cas, le mainteneur est encouragé à réfléchir à la possibilité de créer deux paquets distincts. Le manifeste permet des questions de type `app` de façon à faire référence à une autre application déjà installée. |
There was a problem hiding this comment.
C'est pas clair : "Le manifeste permet des questions de type app" meme si après y avoir réfléchi une 3eme fois j'ai compris de quoi tu parles (je mentionnerait "paramètres d'installation" par ex., plutot que "questions")
There was a problem hiding this comment.
Moi j'ai pas compris de quoi il s'agit...
app dans le manifest?
There was a problem hiding this comment.
C'est vis à vis du type de question. Dans la doc du manifeste il y a:
type : (optionnel) type de paramètre parmis domain, path, user, app, boolean et password.
There was a problem hiding this comment.
Et ça fait quoi "app"?
| #### YEP 1.3 - Indiquer la licence associée au paquet | brouillon | AUTO | WORKING | | ||
| La licence du paquet est à indiquer dans un fichier `LICENSE` à la racine du paquet. Attention à ne pas confondre avec la licence de l'application qui va être installée dont l'acronyme est à renseigner dans le champ `license` du manifeste. | ||
|
|
||
| Les listes d'applications official.json et community.json n'acceptent que les paquets dont la licence est libre, de même pour la licence de l'application contenue. Certaines applications libres nécessitent des dépendances non-libres (exemple: mp3, drivers, etc.). Dans ce cas, il faut ajouter `+dep-non-free` à l'acronyme et si possible donner des précisions dans le README.md du paquet, l'intégration sera dans ce cas acceptée au cas par cas. |
There was a problem hiding this comment.
En fait je ne trouve pas que la mention de "dépendance" soit appropriée. Tu peux avoir une grosse appli avec plein de code libre et une toute petite partie non libre, ou l'inverse, un gros bouzin non libre qui appelle de tps en tps un bout de code libre. Y a t il une différence fondamentalement ?
There was a problem hiding this comment.
Pour moi ça change quand même l'"engagement" en terme de PI pour l'app.
En gros une app proprio avec des dépendances MIT ou LGPL, c'est une app purement propriétaire avec une entité qui a droit de vie ou de mort dessus.
Une app LGPL ou MIT avec des dépendances proprio, c'est bof, mais à priori il est possibe de remplacer les codes proprio voir même en faire un fork sous AGPLv3... Donc pour moi la proportion de code sous license libre me semble importante tout de même.
Bref pour ma part je fais une grande différence entre mediagoblin (qui doit pouvoir gérer aussi des format propriétaire) et youtube.
Pour respecter les règles actuelles du manifest. Concernant la licence, voir YunoHost/doc#413
|
@julienmalik, j'ai corrigé les 2 coquilles dans le texte. @M5oul, et tout le groupe Com, êtes-vous d'accord pour que les modifications des YEP soient sous le giron du groupe Apps? |
|
@opi du coup j'ai intégré l'utilisation de la liste d'accronyme du SPDX qui me semble plus complète. |
This YEP is a draft about how inform user about app or package license. Some points regarding how to fill licence in manifest.json may be unconsensual.
Cette YEP est un brouillon à propos de la façon dont les licences doivent être indiquées dans les paquets. Certains points à propos de la façon de remplir le champ licence dans le manifeste peuvent faire débat.