Demande à la communauté / Ask the community

en
fr

#22

Bon je vois que tout ceci est compliqué j’adore le projet de YNH et je pense vraiment que l’on peux trouver une solution pacifique.
Comme je le dis dans mon message si vous ne voulez pas de mes apps sur le depot git community et je ne parle pas de les référencer. Alors je les supprimerais si cela m’est demandé mais je ne vais pas arreter de maintenir mes apps pour autant et je préfére continuer au sein du github de yunohost si cela est possible.
Je tiens à dire aussi que yunohost m’a beaucoup apporté.
Je tiens à remercier @Bram @frju365 @Maniack_Crudelis meme si je suis pas d’accord avec certains je ne compte pas créer de polémique mais je pense que @Lobo-Tommy et d’autres ont soulevé des points similaires à mes inquiétudes.
Donc je suis de tout coeurs dans l’idée de continuer à travailler à améliorer YNH comme je le peux et d’essayer de respecter au mieux les demandes utilisateurs j’espère ne pas me priver de votre soutien quand je dev une apps meme si nous sommes pas d’accord.
Pour ce qui est du maintien d’une app je pense que c’est au packager concerné de s’en occupé s’il le peut.

Bien Cordialement


#23

Alors, moi, je continuerai à t’aider. Ça n’altérera pas la coopération et l’aide que peut apporter le groupe Applications non plus (et sûrement jamais).
Je pense que la solution qui plaît à tous, et qui me semble la plus logique est la liste non-free indépendante en partie de la liste community, qui sera ou pas ajoutée par l’utilisateur. L’idée de Débian est d’ailleurs intéressante sur sa gestion des dépôts (à approfondir).

Pour ce qui est de @Lobo-Tommy, je souhaite qu’il respecte les règles de ce forum du mieux qu’il peut (lire les propos fondateurs du projet serait bien aussi) et qu’il entame un débat constructif d’idées. Il n’y aura pas de deuxième avertissement de la modération.


#24

Hello,

Since nothing constructive was coming out from some over aggressive previous exchanges, I’ve moved them in another topic after consulting other members of YunoHost.

To go back to the discussion and try to find a solution, here are the 2 solutions to handling apps not present in our lists (that would be the case for non-free apps for example) that have arised from the discussion:

  • you can already install an app using the github url (or git cloning locally and “yunohost app install /path/to/git/repo”), this is not perfect but it’s already there and working. One of the problem is that you won’t get updates
  • the other solution is that a group of people joined together and create another (or more) apps list like we do with community and official lists.

If some people actually consider create their own app list, it’s not something especially hard (but you’ll probably want to stay in touch we us as things evolved from time to time but we, for now, have always take care about keeping backward compatibility).

It looks like that:

  • create another app list in json somewhere in the fashion of official.json or community.json
  • run the python script list_builder.py this way: python list_builder.py the_list.json
  • this will give a file the_list-build.json
  • make this file available through https, people will then be able to add it to their YunoHost using the link to this file
  • you’ll probably want to automate the building of the list, we do that using this script in a crontab (every few minutes)

There are more things around that like translations but that’s not needed.

If some of you decide to go this way, please try to be in touch with me since I’m generally the one (but not only) evolving this toolchain and I have plan in mid-terms to change the translation mechanism for apps.

I hope we can get back to a more constructive discussion regarding this subject forward one or more solution.

(EDIT: this reply doesn’t mean we can’t think of other solutions)


#25

#[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: https://github.com/YunoHost/doc/pull/413 .

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: https://github.com/YunoHost/doc/pull/413 .

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] (https://www.inria.fr/content/download/5896/48452/version/2/file/INRIA_recueil_fiches_licences_libres_vf.pdf) 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] (https://yunohost.org/#/selfhosting_en) 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.


#26

That’s a pretty complete answer :+1:

My point of view on this questions would be simply that the YunoHost team should not be involved in such a list, also for legal considerations. So my answers are:

  • The name should be up to the people who would maintain it.
  • I think there’s already a way to add custom list. That’s enough for me.
  • As said before, no.

#27

Bonjour

D’un point de vue strictement FSF, les projets ont le droit d’y respecter rigoureusement la philosophie, l’objectif déclaré et d’y promouvoir le concept.

Tout projet se déclarant de l’esprit FSF, peut-être amené a évoluer si le but est de permettre aux utilisateurs issue du monde propriétaire a utiliser d’avantage les applications ou les OS, opensource.

Il y a des alliances qui peuvent être prometteuses pour l’utilisateur final…

Cela doit rester une question de choix, et d’objectif…


#28

Ok have make a test is : https://github.com/YunoHost-Apps/teamspeak-3_ynh/blob/master/README.md

Sorry for french is better for me !
Il s’agit d’un message d’avertissement pour l’utilisateur quand à la responsabilité qu’il l’engage quand il installe cette application cela dois etre en FR et EN j’ai demandé car sinon cela n’est pas valide est j’ai une amie juriste je vais lui demandé de vérifier et corriger ce que j’ai mis !

Cordialement


#29

Hello,

Ce petit débat interne aura eu au moins le mérite de soulever des questions intéressantes.
Je précise en premier lieu que je ne suis que concerné de loin dans la mesure où la totalité des app présentes sur mon instance sont 100% libres. Je me permets d’ajouter ici quelques reflexions car comme on l’a bien vu ce débat va plus loin que l’intégration ou non des quelques apps mentionnées plus haut dans la liste “Community”.

Le site officiel mentionne le libre et sa philosophie en lien avec l’auto-hébergement, mais n’est pas aussi “politisé” que ce qu’on peut lire ici

Après lecture des échanges, j’ai commencé par aller faire un petit tour sur le site de présentation du projet.
Le mieux est de commencer par “qu’est-ce que YunoHost”, lien cliquable depuis la page d’accueil, non ?
Peut-être que le rédacteur du site avait lu le bouquin “start with why”, en tout cas c’est agréable de tomber d’emblée sur ce qui compte vraiment, à savoir “qu’est-ce que YunoHost” au sens de “à quoi et à qui ça sert”.

OK, jusque là je pense qu’on est tous d’accord. C’est précisément parce que YunoHost correspond exactement à cette définition qu’il est apprécié et utilisé par nous tous (et par beaucoup d’autres).

Je continue à lire,

Cette dernière phrase a déjà été citée plus haut par @ljf . C’est la première mention du libre faite depuis mon parcours du site officiel, que j’estime être classique. Après tout, j’ai ouvert yunohost.org puis cliqué sur un des premiers liens disponibles. On m’y explique donc, si je lis correctement le français :

  1. Que YunoHost est libre [c’est un fait]
  2. Que l’ensemble de configurations automatiques et les interfaces accessibles sont libres [c’est un fait]
  3. Qu’il existe une philosophie de l’auto-hébergement, et que celle-ci semble liée avec la philosophie du libre (puisqu’elle est incompatible avec tout autre modèle de développement logiciel) [c’est l’expression d’un message politique de la part de l’équipe YunoHost]

Par bonheur, il y a un lien qui - a priori - va me permettre d’en savoir plus sur cette fameuse philosophie ainsi que ses liens avec le libre. Je clique donc sur le lien et je lis entre autres :

et

Ce sont les deux seuls paragraphes où le libre est mentionné. J’y vois :

  • Une forme de “profession de foi” de l’équipe YunoHost envers internet “libre, ouvert et décentralisé”, et dont YunoHost est en quelque sorte une pierre à l’édifice. Quelqu’un qui serait sensible à ces problématiques ou philosophies pourrait y voir un argument supplémentaire pour essayer voire adopter YunoHost - et par là même l’auto-hébergement (cf le titre “Pourquoi s’auto-héberger”)
  • Une mise en garde (intelligente et bien construite) sur les différences de qualité qui peuvent être constatées (et inscrit en creux, le caractère méritant et engagé des auto-hébergés qui sont prêts à migrer leurs services cloud sur un serveur un peu moins performant au nom de l’argumentaire et de la philosophie exposée plus haut)
  • Que “la plupart” des applications packagées sont libres,ce qui sous-entend qu’elles ne le sont pas toutes et, plus important encore, ce qui sous-entend que l’équipe YunoHost n’interdit pas explicitement les applications non-libres.

Les apps non-libres sont-elles autorisées à devenir officielles ou intégrer la community list ? Pas clair…

J’étais très surpris en lisant cette phrase, mais au vu des autres messages et clarifications de @Aleks j’imagine que @Maniack_Crudelis voulait plutôt dire “Currently, only free and open source apps are allowed in YunoHost community list of apps”.

OK, “fair enough” comme disent les anglais, mais ça veut dire quoi exactement, “libre et open source” ? J’ai cherché sur le forum sans trouver de “règles officielles” pour cette fameuse liste. Sur le github officiel, dans la section “contributing”, https://github.com/YunoHost/apps/blob/master/README.md#contributing, aucune mention d’obligation libre pour intégrer la liste community.

Sur le site officiel, je suis tombé sur le paragraphe suivant :

Pas non plus mention d’une obligation libre pour devenir app officielle !
Pas de description des licences autorisées ou non. Certaines sont un peu “entre deux”. Parfois, une application est open-source mais pas totalement libre. Parfois une application peut être open-source, libre, mais douteuse.
Prenons par exemple l’application Rainloop. Je me suis un peu renseigné, il semble y avoir pas mal de doutes sur la légalité de la provenance du code initial. Pourtant, il s’agit d’une application officielle !

Conclusion

  1. Je comprends parfaitement que l’équipe YunoHost, qui dépense une énergie (et parfois même un argent) considérable dans ce projet soit portée par une certaine philosophie dont la version la plus pure voudrait écarter tout code non-libre et par là-même faire réfléchir ou “éduquer” les utilisateurs de ce logiciel
  2. Je comprends parfaitement que pour des raisons de protection juridique du projet (et c’est en lien avec sa pérénité), l’équipe de YunoHost décide de “compliquer” l’installation d’apps comportant des composants non-libres. Après, que ce soit via un avertissement, des clics supplémentaires dans l’interface, une liste séparée, je ne suis clairement pas le mieux placé pour décider !
  3. Je comprends également que l’équipe YunoHost, qui prend très au sérieux et se sent forcément un peu “responsable” de la sécurité des serveurs de ses utilisateurs veuille ecarter ces logiciels non-libres, par définition opaques et pouvant infester les serveurs de backdoors, trackers et autres joyeusetés
  4. Néanmoins, je constate que ces prises de position / décisions sont mal présentées et peu claires pour le nouvel arrivant - voire même pour un contributeur tel que @liberodark. En l’absence de règles claires et concises, le fait d’écarter son travail peut paraître comme une décision unilatérale justifiée par des arguments politico-philosophiques.
  5. Puisse ce débat un peu houleux être bénéfique au projet, en permettant d’établir des règles claires sur ce que doit respecter une app en termes de licence pour pouvoir intégrer la community list, de trouver une solution pour proposer (plus ou moins simplement / intuitivement) des apps “non conformes” aux utilisateurs de YunoHost, et de clarifier la position “officielle” de l’équipe vis-à-vis du libre sur le site et le forum.

#30

Effectivement pour le passage en officiel on pourrait parler d’une ligne éditoriale.
Rainloop c’est effectivement à la limite je dirais… Le code de Rainloop est open source en théorie mais dans les faits des morceaux entiers sont cryptés ou incompréhensibles. La provenance du code porte à débat.
Autre exemple : CouchPotato et Sickrage sont libres, open source etc… Mais aucun usage de ces apps ne semble vraiment légal… (Contrairement à transmission). Même si leur intégration YNH était parfaite, il y a peu de chance qu’elles passent officielles…

Du coup il y a certes des guidelines, des procédures et de la d’oc, mais aussi une bonne dose de jugement humain, de débats et de philosophie entre les lignes.

Ceci vaut pour les apps officielles. Mais le débat porte ici maintenant des apps community.
YunoHost a-t-il vocation à soutenir les apps community (ligne éditoriale par conséquent), ou bien est-ce totalement community, c’est-à-dire aux mains de la communauté (sans ligne éditoriale) ?
Par exemple sur WordPress on trouve à boire et à manger en termes d’apps (open, propriétaire, légal, illégal,…). WordPress n’engage pourtant pas sa responsabilité sur les apps de la communauté. Pareil pour Kodi, qui au passage se fait ficher comme OS illégal du fait de certaines apps communautaires illégales.

N’y aurait-il donc pas moyen peut être de dé-responsabiliser le projet YNH de la liste community, et de ne la responsabiliser que sur la liste official ?


#31

Bonsoir,
Je trouve que ton initiative est très sympathique. Mêmes si tous ces services ne sont pas libres ils méritent à mon sens d’être disponible pour les utilisateurs de la solution yunohost. Préférer le libre je comprends totalement, mais je trouve vraiment dommage de limiter les utilisateurs alors que yunohost est vraiment génial.


#32

Bonjour,

Je suis actuellement en contact avec un cabinet d’avocat spécialisé en propriété intellectuel pour voir ce problème de licence.
Mais actuellement je suis très occupé personnellement donc dès que j’ai plus de temps.
Je vais tenter d’aider et de cadrer ce point en accord avec vous et les fondateurs.

Cordialement


#33

Has anybody started this ? Having a non-official list could be a great step forward into practical solutions to this debate :wink:


#34

Not that we (the contributors) are aware of and no one has reached me for that.

We are also in the process to change the design of the apps list right now (not that much but still) but it’s moving fast (main starting point of the discussion is here and the initial discussion is here)