KDE adopte la FLA de la FSFE

Posté par . Modéré par Jaimé Ragnagna.
Tags : aucun
9
24
août
2008
KDE
La Free Software Foundation Europe se réjouit de la signature de l'accord fiduciaire sur les licences (Fiducary License Agreement, ou FLA) par le projet K Desktop Environment (KDE). Le FLA est une délégation de droits d'auteur qui permet à des projets de Logiciels Libres de consolider leurs droits auprès d'une organisation ou d'une personne unique. Cela permet aux projets de s'assurer qu'ils sont maintenables juridiquement, ce qui inclut des sujets importants comme la préservation de la possibilité de changer de licence, et l'assurance de posséder des droits suffisants pour pouvoir assurer l'application des licences devant un tribunal. « Nous voyons dans la signature du FLA par KDE une étape positive et importante dans la maturité de la communauté du Logiciel Libre », déclare Georg Greve, président de la Free Software Foundation Europe.

« Le FLA a été conçu pour aider les projets à consolider la pérennité juridique de leurs logiciels afin d'assurer une protection fiable sur le long terme. KDE est une des plus grandes initiatives des Logiciels Libres et joue un rôle central dans l'apport de liberté pour les environnements bureautiques. La décision du projet KDE souligne son engagement à faire durer cette liberté. »

Adriaan de Groot, vice-président de KDE e.V., l'association derrière le projet KDE, déclare : « KDE e.V. a approuvé un FLA particulier directement dérivé d'un exemple de la FSFE comme meilleur moyen de céder les droits d'auteur à l'Association. Nous reconnaissons que la cession est une option que les particuliers pourraient vouloir exercer, mais ce n'est aucunement une obligation faite aux contributeurs de KDE. Il y a d'autres possibilités de cession du droit d'auteur que le FLA, mais nous croyons qu'il s'agit du moyen le plus efficace pour ce faire, sans qu'il soit trop lourd administrativement. L'enthousiasme pour le FLA a été immédiat: des personnes demandaient des imprimés avant la fin de la semaine afin de les signer. »

« Le FLA est un document conçu pour fonctionner dans des pays différents, avec autant de perceptions différentes du droit d'auteur et de la paternité d'une oeuvre », déclare Shane Coughlan, coordinateur de la Freedom Task Force. « En tant que projet international, KDE donne un bon exemple de la manière dont le FLA peut apporter une cohérence juridique à moyen et long terme. Ce fut un plaisir de participer au processus d'adoption de l'accord, et la Freedom Task Force de la FSFE est prête à poursuivre son soutien à KDE à l'avenir. »

L'adoption du FLA par KDE est le fruit de la coopération entre KDE e.V. et la Freedom Task Force de la FSFE au cours des dix-huit mois passés, symbole de la collaboration étroite entre les deux organisations associées.
  • # Des exemples ?

    Posté par (page perso) . Évalué à 8.

    Ce serait bien d'avoir quelques exemples pour comprendre la portée de cette annonce. Tout ce qui est dit est certainement très bien mais c'est assez difficile à concrétiser pour ceux qui ne sont pas juristes.
    • [^] # Re: Des exemples ?

      Posté par . Évalué à 5.

      Si ça peut te rassurer, même pour des juristes c'est pas facile à concrétiser avec aussi peu d'éléments...
      Surtout, qu'en droit français, il est impossible de renoncer à la paternité d'une oeuvre donc je vois mal comment on pourrait "déléguer" ses droit d'auteurs (et plus particulièrement les droits moraux) à une seule personne, physique ou morale.

      J'aimerais bien en savoir plus sur le sujet, quelqu'un aurait plus d'informations ?
      • [^] # Re: Des exemples ?

        Posté par (page perso) . Évalué à 7.

        En fait, c'est tout à fait possible : tu ne renonces pas à la paternité, simplement à la titularité des droits. Ainsi, tu es l'auteur, mais c'est un autre qui détient les droits (de la même façon que l'employeur détient les droits sur le logiciel dont son salarié est l'auteur).

        L'équilibre est ensuite assuré par le contrat : je te donne mes droits, mais tu t'engages à les utiliser de telle ou telle façon. Si tu ne respectes pas le contrat, tu le rompes et tu n'as plus aucun droit. Et après, cheminement classique...

        Ben
    • [^] # Re: Des exemples ?

      Posté par (page perso) . Évalué à 5.

      C'est une annonce classique : y a le sigle FSF qui n'est pas à côté des expressions « nouveau super diff », « algo qui tue sa race », « on s'éclate à hacker comme des fous », mais à côté de « blablabla », « droit d'auteur », « protection juridique ++ », « faites nous confiance » :

      http://www.fsfeurope.org/projects/ftf/fla.fr.html

      « La Freedom Task Force de la FSFE utilise son équipe d'experts techniques et juridiques pour s'assurer de la conformité des licences, permettant ainsi aux projets de se concentrer sur leur travaux techniques. »

      La FSF, voici une organisation de confiance, compétente sérieuse et honnête ! Résout vos problèmes : Logiciel - retour de code immédiat, détivoisation, protection contre le logiciel propriétaire, fidélité absolue de la licence - chance aux examens et dans tous domaines. Résultat rapide et efficace, facilités de paiement.
    • [^] # Re: Des exemples ?

      Posté par . Évalué à 9.

      En gros, les développeurs ont dorénavant la possibilité de céder les droits de leur code à KDE si ils le souhaitent.
      • [^] # Re: Des exemples ?

        Posté par . Évalué à 8.

        Ah voilà ! Comme ça c'est clair. J'ai cru un instant que c'était une session de code à la FSF.

        Cette simple phrase en plus dans la dépêche, ça serait pas un mal !

        Sinon, c'est un réponse à la difficulté qu'il y a eu à passer de la GPL 2 à la GPL 3 , non? Éviter que ce genre de difficulté se reproduise: http://linuxfr.org/2007/11/26/23404.html
        • [^] # Re: Des exemples ?

          Posté par (page perso) . Évalué à 5.

          Tout à fait, le besoin d'un changement de licence possible a propulsé ce besoin au premier plan.

          Aussi une réponse au fait que certains développeurs peuvent disparaitre (soit d'internet, soit tout court). Si ils ont assigné leur code auparavant à KDE eV, ca permet de gérer des problématiques juridiques plus facilement.

          La FLA mets aussi des protections autour du changement de licence qui serait initié par KDE eV:
          - la priorité est avant tout de contacter le développeur original, c'est que quand vraiment ça ne marche pas que KDE eV peut envisager d'utiliser son droit de modification de licence.
          - a priori, c'est uniquement pour passer d'une licence Open Source a une licence d'esprit Open Source. C'est pas pour tout relicencier en propriétaire (de tout façon, les membres de KDE eV s'y opposeraient).
          • [^] # Re: Des exemples ?

            Posté par . Évalué à 4.

            « Aussi une réponse au fait que certains développeurs peuvent disparaitre (soit d'internet, soit tout court). »

            Mais non, les développeurs ne disparaissent pas voyons. Par contre, leur femme ...

            ----[--]--> *plula*
      • [^] # Re: Des exemples ?

        Posté par . Évalué à 1.

        Juste une question qui me travaille depuis 10 minutes :
        Un développeur pond un code, il est l'auteur, il choisit la licence.
        Plusieurs autres développeurs patchs, ajoutent des fonctionnalités etc, il me semble logique qu'ils adhèrent à la licence en cours à ce moment.
        Lors d'un changement de licence, il n'y a plus un auteur mais plusieurs de mon point de vue (c'est devenu un travaille collectif).

        C'est l'auteur original qui à encore le droit de regard sur la licence ou c'est le collectif ?
        En gros qu'elles sont les droits des contributeurs ?
        • [^] # Re: Des exemples ?

          Posté par . Évalué à 2.

          Non, chaque auteur choisi la licence de sa contribution.
          Mais s'ils veulent que la contribution puisse être redistribuée avec l'ensemble il faut qu'ils choisissent une licence compatible.

          Par exemple tu peux contribuer à un projet GPLv2 et mettre tes patch en BSD. Dans ce cas, l'auteur principal n'a pas besoin de ton accord pour passer par exemple en GPLv3 puisque ta BSD est aussi compatible.
          Si par contre tu choisis de contribuer toi aussi en en GPLv2, un passage en GPLv3 devra se faire avec ton accord, ou alors se passer de ta contribution.

          Le cas inverse, fournir une contribution en GPL à un projet BSD n'a probablement aucune chance d'être accepté dans le projet principal, mais tu peux fournir de ton côté le patch, l'ensemble se retrouvant sous GPL. Si la contribution est bien cloisonnée il est possible qu'elle soit ajoutée à une liste de contrib, non intégrées de base (pour conserver un noyau pur BSD) mais facilement disponibles.
        • [^] # Re: Des exemples ?

          Posté par . Évalué à 2.

          1. Celui qui commence est bien l’auteur et celui qui choisit la licence ;
          2. si quelqu’un modifie le code, il le fait dans le respect de la licence, donc :
            a. à la question « Quels sont les droits des contributeurs ? », la réponse simple est « C’est dans la licence ! » ;
            b. conservation de la licence pour le code d’origine ;
            c. ajout de son nom dans la liste des auteurs (donc, en général, dans les mentions « Copyright xxx » des fichiers).
            d. il ne peut choisir la licence que de ce qu’il a écrit, dans le respect des compatibilités avec la licence originale.

          Pour un changement de licence, il y a de nombreux cas différents, selon que le projet est organisé ou non et comment il l’est s’il l’est :
          — pour un travail collectif, c’est la totalité qui doit être d’accord (ex. le noyau Linux) ;
          — parfois, les contributeurs cèdent quelques droits au « primauteur » ou à une entité supérieure (ex. la FSF et GNU) ;
          — et puis il y a le cas général des « reprises » (utilisation du code, fork, etc.) avec changement de licence. Dans ce dernier cas, il faut évidemment que la licence d’origine le permette et il faut la suivre. Donc ça dépend des licences. Il faut aussi rappeler que le code original reste dans sa licence d’origine ; donc le mieux est d’avoir une séparation ou une bonne traçabilité du code. Pour les mélanges à base de ou avec la GPL, c’est expliqué là : http://www.softwarefreedom.org/resources/2007/gpl-non-gpl-co(...)

          Sinon, il y a aussi de bonnes explications pratiques chez KDE : http://techbase.kde.org/index.php?title=Policies/Licensing_P(...)
  • # Et Gnome ?

    Posté par . Évalué à 5.

    Pour quand l'adoption de la FLA par Gnome ?
  • # Vite KDE sous license BSD ou MIT!

    Posté par . Évalué à -10.

    Bon ce qui est pas cool, c'est que trolltech vend des versions propriétaires de QT et seulement lui grâce à la GPL. C'est pas fair-play, je voudrais pouvoir vendre des versions de QT améliorée ou "spéciale"(cf Qtopia) en propriétaire et garder mon code amélioré ou "spécial" non publié, satanée GPL avec ses gardes fous! Un bon modèle est celui de lzo: version GPL médiocre, et version propriétaire/fermée géniale et performante. La centralisation des licences sur un auteur permet ce genre de choses même avec la licence GPL, pas besoin de BSD ou MIT, la FLA est une bonne idée (sauf pour aller vers du GPLv3 ou pire du AGPLv3)!
    Bon la licence MIT serait encore mieux car je peux tout relicencier et faire disparaître les auteurs d'origines au profit d'une exposition exclusive de ma version.
    C'est que c'est chiant avec Linux, il y un paquet d'auteurs donc impossible de faire tourner un Linux en BSD ou MIT. J'ai plein d'idées géniales mais il est hors de question que j'en publie le code. Pouvoir faire une version proprio serait vraiment cool, ça me rappellerait l'âge d'or des BSDs: SCO, SunOS, AT&T etc...
    • [^] # Re: Vite KDE sous license BSD ou MIT!

      Posté par (page perso) . Évalué à 6.

      Avant de raconter n'importe quoi, je me permets de porter à ta connaissance quelques cas précédent de changement de licence au sein d'un projet libre important :
      - XFree86 4.4.0 qui change sa licence. Résultat fork => les anciens gars du coeur du projet passe pour des crétins
      - et dans une moindre mesure OpenOffice.org avec Go-oo. Là aussi, Sun réclame que lorsque tu contribues, le code appartienne à Sun afin de le publier dans openoffice mais également de le remettre tranquillos dans Star Office sous licence propriétaire.

      Je pense qu'on est quand même très loin de la situation que tu nous décris ici. Pour info, Trolltech qui s'est fait racheté par Nokia publie QT sous double licence (GPL pur et proprio pour faire du proprio avec). Sache que Trolltech a signé un agrément avec la communauté KDE pour justement éviter tout problème de changement de licence. Tu peux le consulter à cette adresse : http://www.kde.org/whatiskde/kdefreeqtfoundation.php

      En gros, si Trolltech (ou Nokia puisqu'ils ont racheté Trolltech) verrait la dernière version de QT se retrouver en licence BSD. Pour te donner un ordre d'idée, ça voudrait dire qu'en gros, la société perdrait son code et sa communauté. Les exemples du passé me montre que Trolltech n'a aucun intérêt à ce que cela se produise.

      Concernant KDE, il s'agit d'un projet en GPL. Si une bande d'hérétique s'amusait à changer ceci pour du BSD, je pense qu'il y aurait un fork dans l'heure qui ne serait dans aucun cas bénéfique pour le projet ni pour personne.

      Donc, pour conclure, la signature de ce genre d'agrément est en soit une bonne nouvelle, ça va permettre la prochaine fois de passer en GPL v4 beaucoup plus rapidement que ne pourra jamais le faire l'autre projet-de-desktop-linux-ne-l'ayantpour-l'instant-pas-signé (attention lecteur avisé, sauras-tu reconnaître le nom du projet en question ?).
      • [^] # Re: Vite KDE sous license BSD ou MIT!

        Posté par . Évalué à 3.

        Un autre cas typique de changement de license est : Nessus
        refs:
        https://linuxfr.org//2004/05/19/16305.html
        http://fr.wikipedia.org/wiki/Nessus_(logiciel)
        http://www.nessus.org/plugins/index.php?view=newest


        Sans vouloir nullement troller, ce type d' accord ressemble drolement à un SCA (typique des contrib. SUN) sauf qu' il est ici adossé à la GPL (et non à la CDLL).
        Non ?

        Perso je n' en sais rien, est ce mieux d' avoir une multitude d' auteurs (avec les difficultés que cela peux représenter lors du passage d' une version de livense à une autre) ou tout délégué à un organisme ? Je crois quant même pencher pour le bazar de ce côté là...

        (Qui ne s' est jamais dit :" ouaih ce logiciel est fantastique et me sert tout les jours, je vais contribuer par qq lignes sous une fausse identité pour être [quasi] sûr qu' il restera toujours libre"...) okok je connais le chemin, j' ai vu la porte
        • [^] # Re: Vite KDE sous license BSD ou MIT!

          Posté par . Évalué à 2.

          Petite remarque quand même. La FLA limite les licences sous lesquelles KDE e.V peut relicencier le code qui lui est donné par ce moyen. Pas de risque de voir KDE devenir proprio même si tous les contributeurs signaient cet accord.
    • [^] # Re: Vite KDE sous license BSD ou MIT!

      Posté par . Évalué à 3.

      "J'ai plein d'idées géniales mais il est hors de question que j'en publie le code."
      Et bien figure-toi que la GPL a pensé à toi : elle ne t'impose pas de publier ton code... tant que tout ceci reste uniquement pour toi.
      • [^] # Re: Vite KDE sous license BSD ou MIT!

        Posté par . Évalué à 1.

        KDE restera toujours sous licence GPL mais en ce qui concerne Qt, il y a des pressions ( dont Mark Shuttlework, CEO de Canonical et ancien patron de KDE ) qui voudraient que Qt utilise la LGPL v3 qui est plus permissive que la GPL v3.
        • [^] # Re: Vite KDE sous license BSD ou MIT!

          Posté par (page perso) . Évalué à 2.

          "patron" en anglais signifie "mécène" ou "bienfaiteur". Il a juste fait un gros don financier au projet KDE.
          Mark Shuttlework peux vouloir ce qu'il veux, ce n'est pas lui qui décide. Il n'a rien a voir avec Qt et KDE.

          Qt restera GPL.
      • [^] # Re: Vite KDE sous license BSD ou MIT!

        Posté par . Évalué à -9.

        Et comment je valorise mon code? Comment je le vends? Le modèle d'Apple est bon là: Comme LZO, ils s'arrangent pour que la version proprio/fermée soient plus attirante que la version open source. Darwin est loin d'avoir tout ce qui fait MacOS (ntfs, interface graphique, drivers de matériel etc...), sinon comment Apple valoriserait son OS? Y en a qui me parlent des contributeurs non employés d'Apple et bien si ils ne sont pas content, ils ont qu'a avoir la puissance marketing d'Apple, c'est de leur faute.
        D'ailleurs, qu'est-ce que vous croyez qu'Apple fait avec son LLVM, c'est pourtant claire, la version open source sera incapable de générer du code de shaders aussi performant que la version proprio qui sera dans MacOS (avec l'aide d'indications secrètes de la part de NVIDIA par exemple). Donc si vous voulez un OS performant, il faudra acheter MacOS, pour un sous-OS, vous aurez le droit de vous prendre la tête à installer Darwin. Et ça RMS ne l'a pas compris avec sa GPL: comment Apple pourrait justifier de mettre de l'argent dans le développement d'un OS si il n'était pas sous licence BSD!
    • [^] # Re: Vite KDE sous license BSD ou MIT!

      Posté par (page perso) . Évalué à 2.

      ~GPL, on t'a reconnu...

      Bon, c'est une belle démonstration du problème des comptes multiples, qui peut proposer une solution pour éviter ça?

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.