#[French version]
Déjà comme dit Bram, merci liberodark que je vois s’activer depuis quelques temps. Ci-dessous mon avis ainsi que quelques éléments de réflexions et de contexte.
Sur la possibilité technique d’installer un logiciel propriétaire sur une instance YunoHost
Comme vous l’avez constaté, il est possible techniquement d’installer des logiciels propriétaires sur une instance YunoHost. C’est assez simple à faire à partir du lien de l’app.
Sur l’autorisation de le faire par le projet YunoHost (en tant que logiciel et/ou en tant que groupe)
De façon implicite, via la YEP-1.3 nous avons définis qu’il était valable de créer des paquets basés sur des applications non-libres. De mémoire, on en avait d’ailleurs discuté (probablement réunion ou sur le chat) il y a 2 ans lors de la PR sur l’écriture de cette YEP: [enh] Add YEP 1.3 about licensing information by zamentur · Pull Request #413 · YunoHost/doc · GitHub .
Reste tout de même une inconnue (pour moi): YunoHost est sous licence AGPLv3, ce qui implique que seuls sont possibles les “compositions” avec d’autres logiciels sous licences compatibles… La question est donc peut on parler de “composition” dans le cas de la fonction “système d’exploitation” ou “gestionnaire de paquet” de YunoHost ? Personnellement, j’ai considéré que non, d’autant que cette restriction concernerait aussi des apps avec des licence splus permissives et que les créateurs eux mêmes ont empaqueter des apps avec ces licences (il me semble). J’ai moi même créé des packages d’app “non-free” pour automatiser certains déploiements. Franchement à mon avis même un⋅e juriste spécialisé⋅e aura du mal à répondre, mais on peut toujours demander à celle qui nous a aidé sur la question de Odoo (ce serait bien ennuyeux si la conclusion était qu’on ne respecte pas la licence de YunoHost…).
Pour y comprendre un peu plus de chose en matière de licence, je vous recommande cette fiche de l’inria et le site http://vvlibri.org/fr
A noter que la licence a été choisi par les créateurs de YunoHost qui ne sont plus actifs. A l’époque ils n’ont peut être pas pensé à cette question (ou peut être que si). Nous, les contributeurs, sommes rassemblés autour de ce code et de cette licence. Une des spécificités de YunoHost est justement qu’il s’agit d’un projet libre avec un mode de gouvernance expliquée.
Sur l’autorisation par l’éditeur de l’app de packager son app
Ben oui il se peut aussi que Plexmediaserver, teamspeak ou autre ne soit pas d’accord pour que leurs marques soient utilisées. C’était typiquement le problème avec Odoo (qui vend l’utilisation de sa marque) ce qui a mené à la création du paquet LibreERP…
Ce n’est pas parce que le code source est téléchargeable qu’on a le droit de créer un paquet. Je ne sais pas si ça a été fait, mais il serait une bonne idée de vérifier qu’il est bien autorisé de faire ces paquets pour teamspeak, plexmediaserveur etc… et de les distribuer. C’est à voir au cas par cas. Je suis censé ajouter un bout de doc à ce sujet pour les packageurs.
Sur les critères d’intégration d’une app dans les listes “official” ou “community”
Comme vu plus haut la YEP-1.3 explique bien l’état actuel des choses. A savoir nous n’acceptons pas les apps proprios dans ces listes.
Ça n’empêche évidement pas qu’on peut débattre de l’ouverture de ces listes à des apps propriétaires. Mais il faut aussi comprendre qu’il y a aussi des utilisateurs qui s’attendent à ce que toutes les apps présentées soient de confiances. Autrement dit le débat va être complexe et il y aura (visiblement) des déçus.
Et clairement, si vous ne vous en êtes pas encore rendu compte, et comme l’explique Bram, il y a pas mal de personnes qui contribuent à YunoHost qui sont très concerné⋅e⋅s par les questions des enjeux autour de la construction d’internet (en terme de vie privée, de confiance en la technologie, de censure, etc…). En fait, agir pour un internet plus respectueux des usagers, semble être une des grandes motivations du bénévolat au sein de YunoHost.
Nous n’avons peut être pas été assez clair sur notre site de présentation, nous parlons souvent de le refaire… Il y a tout de même ceci:
Le tout est bien entendu entièrement libre . La philosophie de l’auto-hébergement étant à nos yeux incompatible avec tout autre modèle de développement logiciel.
Sur la création d’une liste “non-free”
Personnellement, je ne suis pas contre (je suis pas spécialement “pour” non plus). SI je suis sensibles aux arguments exposés de libertés de l’administrateur d’installer une app non-free et de pouvoir le faire facilement, il s’avère surtout que de toute façon on n’empêche personne de créer sa liste d’application (la brique internet l’a fait il fut un temps par exemple).
A noter que le critères de la licence n’est pas exclusifs, on pourrait aussi se poser la question de l’autorisation d’intégrer dans community des logiciels qui traquent leurs utilisateurs (libre ou pas), ou qui ont une gouvernance ou un fort risquent de piéger leurs utilisateurs etc… De fait l’équipe a déjà fait des efforts pour patcher certains soft contenant des trackers.
Reste donc pour moi 3 questions:
- Doit 'il s’agir d’une liste “non-free” ou d’une liste “app présentant un risque” ?
- Doit-on simplifier l’ajout de cette liste sur le même modèle que la liste communautaire ?
- L’équipe YunoHost doit-elle passer du temps au maintient de cette liste ?
Sur la question de l’acceptation de la licence par la personne qui installe
Je recommande que les package proprio, pose la question de l’acceptation de la licence lors de l’installation dans le manifest, ceci avec un lien vers la licence.
Il reste également possible de faire une PR pour proposer quelques choses de plus aboutit.
Sur la question de mettre l’app dans l’orga YunoHost-Apps
L’organisation YunoHost-Apps sur github a été créé dans 2 buts:
- faire connaître un package pour éviter que plusieurs personnes fassent le même travail
- pouvoir faire des fix de sécurité
A noter qu’il n’est logiquement pas possible légalement et parfois techniquement de faire un fix de sécu sur un soft proprio. Par contre je conçois l’intérêt du premier point.
Sur la question de YunoHost en tant que projet politique
Je vais parler pour moi, mais clairement ces derniers mois, j’avais l’impression que nous étions en phase sur ce point avec les personnes présentent lors des meetings du mardi (auxquels tous le monde est conviés chaque fois sur ce forum) …
Pour moi, oui, YunoHost est un projet politique, car déjà un code c’est politique (puisqu’on fait des choix pour d’autres) mais aussi parce que ce projet a le potentiel de remettre en question une certaines façon de concevoir internet sur de nombreux aspects (y compris en terme de répartition des pouvoirs). Et personnellement, je ne contribuerai pas si ce n’était pas le cas.
Décider d’inclure par défaut des apps propriétaires comme le ferait par exemple Ubuntu est un choix que clairement nous ne ferons pas, car il s’agit de promotion (ils mettent en avant skype, dropbox et WhatsApp sur le gestionnaire de paquet).
En fait nous faisons l’inverse, nous faisons la promotion des logiciels libres et surtout des logiciels respectueux de leurs utilisateurs.
Sur la contribution
Pour information, actuellement, certains contributeurs sont exactement dans la situation de sacrifier une partie de revenue pour faire en sorte que YunoHost vive.
Toutefois, on est d’accord qu’on attend pas ça des utilisateurs, ni de personne d’ailleurs. Et les avis sont toujours bon à prendre.
#[English version]
Already as Bram says, thank you liberodark that I have seen happening for some time. Below my opinion as well as some elements of reflections and context.
On the technical possibility of installing proprietary software on a YunoHost instance
As you have noticed, it is technically possible to install proprietary software on a YunoHost instance. It’s quite simple to do from the app link.
On the authorization to do so by the YunoHost project (as software and/or as a group)
Implicitly, via[YEP-1.3] (https://github.com/YunoHost/doc/blob/master/packaging_apps_guidelines_en.md#yep-13) we have defined that it is valid to create packages based on non-free applications. From memory, we discussed it (probably at a meeting or on the chat) 2 years ago during the PR on the writing of this YEP: [enh] Add YEP 1.3 about licensing information by zamentur · Pull Request #413 · YunoHost/doc · GitHub .
Still, there is an unknown (for me): YunoHost is under AGPLv3 license, which means that only “compositions” with other compatible licensed software are possible… So the question is can we talk about “composition” in the case of the “operating system” or “package manager” function of YunoHost? Personally, I considered that no, especially since this restriction would also apply to apps with splus permissive licenses and since the creators themselves have packaged apps with these licenses (it seems to me). I myself have created “non-free” app packages to automate some deployments. Frankly in my opinion even un⋅e lawyer spécialisé⋅e will have trouble answering, but we can always ask the one who helped us on the Odoo question (it would be very annoying if the conclusion was that we do not respect YunoHost’s license…).
To understand a little more about licensing, I recommend this[inria sheet] (Accueil | Inria) and the website http://vvlibri.org/fr
Note that the license was chosen by the creators of YunoHost who are no longer active. At the time they may not have thought about this question (or maybe they did). We, the contributors, are gathered around this code and this license. One of the specificities of YunoHost is that it is a free project with an explained mode of governance.
On the authorization by the editor of the app to pack his app
Well yes it may also be that Plexmediaserver, teamspeak or others do not agree that their trademarks should be used. This was typically the problem with Odoo (who sells the use of his brand) which led to the creation of the LibreERP package…
Just because the source code is downloadable does not mean you can create a package. I don’t know if it has been done, but it would be a good idea to check that it is allowed to make these packages for teamspeak, plexmediaserver etc… and distribute them. This is to be considered on a case-by-case basis. I’m supposed to add a piece of doc about this for packageers.
On the criteria for integrating an app into the “official” or “community” lists
As seen above, YEP-1.3 explains the current state of affairs well. Namely we do not accept proprietary apps in these lists.
This obviously does not prevent us from debating the opening of these lists to proprietary apps. But it must also be understood that there are also users who expect all the apps presented to be trustworthy. In other words, the debate will be complex and there will be (obviously) disappointments.
And clearly, if you haven’t realized it yet, and as Bram explains, there are quite a few people who contribute to YunoHost who are very concerné⋅e⋅s by the issues surrounding the construction of the Internet (in terms of privacy, trust in technology, censorship, etc…). In fact, acting for a more user-friendly Internet seems to be one of the main motivations for volunteering at YunoHost.
We may not have been clear enough on our presentation site, we often talk about doing it again… There is still this:
The whole thing is of course entirely free. The philosophy of[self-hosting] (YunoHost • index) is in our opinion incompatible with any other software development model.
On the creation of a “non-free” list
Personally, I am not against it (I am not especially “for” it either). If I am sensitive to the administrator’s stated arguments of freedom to install a non-free app and to be able to do it easily, it turns out that anyway we don’t prevent anyone from creating his application list (the internet brick did it for a while for example).
Note that the criteria of the license is not exclusive, we could also ask ourselves the question of the authorization to integrate into community software that track their users (free or not), or that have a governance or a strong risk of trapping their users etc… In fact, the team has already made efforts to patch some softwares containing trackers.
So there are still three questions for me:
- Should it be a “non-free” list or a “risk app” list?
- Should we simplify the addition of this list on the same model as the Community list?
- Does the YunoHost team need to spend time maintaining this list?
On the question of the acceptance of the license by the person installing
I recommend that proprietary packages, ask the question of license acceptance when installing in the manifest, with a link to the license.
It is also possible to do a PR to propose some more successful things.
On the question of putting the app in the YunoHost-Apps organ
The YunoHost-Apps organization on github was created for 2 purposes:
- make a package known to avoid that several people do the same work
- to be able to make security fixings
It should be noted that it is not legally and sometimes technically possible to make a security fix on a soft owner. On the other hand, I understand the interest of the first point.
On the question of YunoHost as a political project
I will speak for myself, but clearly these last few months, I had the impression that we were in tune with the people present at the Tuesday meetings (to which everyone is invited every time on this forum)…
For me, yes, YunoHost is a political project, because already a code is political (since we make choices for others) but also because this project has the potential to question a certain way of conceiving internet on many aspects (including in terms of power distribution). And personally, I wouldn’t contribute if I didn’t.
Deciding to include proprietary apps by default as Ubuntu would do, for example, is a choice that we will clearly not make, because it is a promotion (they highlight skype, dropbox and WhatsApp on the package manager).
In fact, we are doing the opposite, promoting free software and especially software that respects its users.
On the contribution
For information, at the moment, some contributors are exactly in the situation of sacrificing part of their income to make YunoHost live.
However, we agree that we do not expect that from users, nor from anyone else. And opinions are always good to take.
