• [^] # explication longue du pourquoi du comment ...

    Posté par . En réponse au journal rénumération des auteurs de logiciels libres. Évalué à 2.

    J'ai dit :
    ta proposition est ce que fait la SACEM :

    tu paies un droit à la SACEM qui est un pourcentage qui est redistribué à l'interprete / chanteur / compositeur / parolier / auteur / longueur / largeur ...


    et
    le modele à la SACEM restera le seul pour garantir un minimum de redistribution ( mais il ne faut pas se leurer qu'une structure de ce genre va avoir des frais qui vont faire qu'elle devra aussi prendre une commission ).



    tu as dit
    Faux.
    Le monsieur il dit une plateforme ou tu choisis le projet auquel tu donnes, et une fraction va récompenser les projets parents/liés automatiquement.

    Totalment différent de la Sacem, ou tu donnes, et la totalité se fractionne selon les qotas sacem.

    puis
    Je me réponds.
    Oui, on peut considérer que acheter un disque donne de l'argent àl'auteur, puis de l'argent à la sacem qui en théorie sera redistrubué au prorata des ventes eux auteurs interprètes créateurs, et en ce sens on peut dresser une parallèle entre la méthode décrite et la sacem.


    tu reconnais donc le paralelle entre la SACEM et les schemas proposés.

    Seulement la Sacem est une usine à gaz, et les limites dans ce modèle "mon argent récompense théoriquement le projet que j'aime sont multiple".

    tu pourras constater que :
    le modele à la SACEM restera le seul pour garantir un minimum de redistribution ( mais il ne faut pas se leurer qu'une structure de ce genre va avoir des frais qui vont faire qu'elle devra aussi prendre une commission ).


    cela veut dire qu'une structure de la sorte generera enormement de frais "à terme". pour commencer, il y en aura moins car peu de projet seront enregistrés. mais avec qq milliers de projet, il faudra un systeme de suivi transparent, des audits de comptes, de la production de facture, de notes d'honoraire, notes de droits d'auteurs, des declarations d'impots et de TVA, de l'URSSAF, de la CPAM, des CIF, et j'en passe ( car il peut y avoir besoin de personnes dans plusieurs pays, et le benevolat dans la gestion de structures financieres n'a jamais donné de résultat ) ...

    et j'ai aussi fait mention du statut de la GLibc . la GLibc est le projet qui justifie l'appelation GNU/Linux car tout le monde l'utilise. donc, il y aura sous cette forme un impot GLibc ? ou tout projet qui se retrouve à utiliser un projet bindé à la GLib paiera pour la GLibc.

    un exemple :
    je fais un projet en perl -> don à la perl-Foundation .
    perl utilise la GLib -> perl-Foundation donne à la FSF.

    Apres, le truc fun :
    un soft est linkable avec uclibc, glibc, skarlibc, et plein d'autres libc utilisable selon les archi et besoins ... si il y a 5 projets de libc maintenu officiellement, combien à donner à ce projet ? puis aux divers compilos libres qui existent ? ( tcc et gcc pour en citer 2 )

    Par exemple, si tu fait une soiré publique/semipublique, tu payes un fofait à la sacem, et là tu ne chosi plus rien.
    Où encore, le fait que tu ne puisse pas donner autant que tu veux à ton artiste préféré via le systeme SACEM.

    ce ne sont que des derives qui ont un sens :
    - pour le premier, cela evite de t'astreindre a donner la play list et/ou a payer un commissaire ( pas au sens policier ) pour qu'il constate la playlist joué et le nombre de personne
    - le second est que la SACEM est issu de plus d'un siecle d'histoire et qu'il y a donc toute une adaptation pour permettre un reglement à la PayPal.



    donc, a moins de tomber à faire une SACEM du libre ou de trouver une solution pour eviter qu'il y ait un effet boule de neige au cas ou un dev qui ne paie pas, je ne vois pas.


    Le concept de la bande de pote planetaire ne tiens pas la route, donc ce probleme de "je ne te paie pas car j'aime pas ton projet meme si je l'utilise" doit etre pris serieusement en consideration pour ne pas faire une SACEM du libre.