pulkomandy a écrit 1717 commentaires

Le tour de force de Rust c'est d'arriver à faire "presque aussi bien" que Ada de ce point de vue (toutes proportions gardées, mais en comparant au C et C++) mais avec uniquement des vérifications à la compilation et pas à l'exécution.

Ce qui change pas mal du point de vue des performances.

C'est aussi vrai qu'on a pas forcément besoin de tant de performances partout. Mais parfois oui.

On peut donc penser que Rust se trouvera une place confortable quelque part entre Ada (très sécurisé mais moins performant) et C++ (plutôt pas sécurisé, mais possibilités d'optimisations importantes).

Interrupteur étant sur le réseau personnel et fonctionnant avec une plateforme cloud du fabricant, qu'il y a-t-il pas un risque ?

Oui.

Au niveau du fonctionnement, en général, la prise va se connecter au "cloud" du fabricant (ce sera peut être juste un serveur, peut être un cloud sous-traité chez Azure, AWS ou autre), ainsi c'est une connexion sortante et il n'y a pas besoin de configurer de pare-feu pour ça.

L'application Android se connecte au même cloud et c'est ce dernier qui relaie les messages.

Les risques sont:

• Quelqu'un pourrait prendre le contrôle à distance de la prise s'il trouve un moyen de contourner les protections mises en place. Si rien n'est open source il faudra faire confiance au fabricant pour avoir tout bien chiffré et sécurisé.
• Si le fabricant décide d'arrêter son service de cloud, plus rien ne fonctionne.

Il existe aussi des systèmes qui ne dépendent pas du cloud, par exemple https://energenie.com/item.aspx?id=7416 qui se pilote avec une interface web embarquée (un simple navigateur web suffit) ou via des requêtes REST. Par défaut ce n'est pas accessible de l'extérieur du réseau sur lequel c'est connecté.

(je ne recommande pas spécifiquement ce modèle pour d'autres raisons: a priori il a une durée de vie d'environ 2 ans, après quoi, les relais qui connectent/déconnectent les prises ne fonctionne plus correctement).

L'avantage par rapport à Telegram: le serveur est en logiciel libre, pour Telegram ce n'est pas le cas. Tu n'as donc absolument aucune idée de ce qui est fait avec tes messages côté serveur.

De plus, il y a plusieurs serveurs et tu peux aussi héberger le tien. Dans un contexte professionnel, on a fait ça dans mon entreprise il y a quelques temps (serveur interne pas connecté avec le reste du réseau XMPP). Alors bien sûr, dans ce cas, c'est plus d'infrastructure à mettre en place, mais ça permet d'avoir la main sur tout le service et d'être sûr que les messages ne sont pas diffusés et stockés n'importe où.

Justement, avec du HTML bien fait ça ne devrait poser aucun problème.

On devrait avoir des emails qui ressemblent à ça. Pas des trucs qui clignotent comme un sapin de Noël.

Et du coup ça se redimensionne bien à la taille de la police de caractères et à la taille de la fenêtre dans laquelle on l'affiche. Où à la taille du papier si on l'imprime.

Ce n'est pas le cas avec les emails au format texte où c'est l'expéditeur qui choisit combien de caractères par ligne il veut mettre. Par exemple sur mon téléphone, si quelqu'un envoie un mail avec une ligne un peu trop longue, mon téléphone réduit la taille du texte pour faire rentrer cette ligne sur une ligne, et tant pis si ça donne une taille de texte microscopique. Ou alors, il ne le fait pas, et il faut faire défiler le mail de gauche à droite pour le lire.

On peut commencer à se dire qu'on va reformater le texte et ajouter ou supprimer des retours à la ligne là ou ça va bien mais, ce n'est pas comme ça que les mails au format texte sont supposés fonctionner. D'où l'introduction du HTML qui permet de
transporter du texte en indiquant clairement les endroits ou il y a des paragraphes normaux, et les endroits ou il y a un schéma en ASCII art par exemple, qu'il ne faut surtout pas transformer sous peine de les rendre incompréhensibles.

les liens dans les emails sont presque toujours du spam

Je dirais qu'on se rend pas compte à quel point on utilise souvent des liens dans des emails. Moi c'est tout le temps (aussi bien en envoi qu'en réception) et ça m'embêterait bien de pas pouvoir faire autrement.

Je pense pas que le problème soit technique, pouvoir envoyer des mails au format HTML, c'est super, et ça peut s'afficher beaucoup mieux que le format texte préhistorique avec ses retours à la ligne tout moisis (tu as toi-même constaté ce problème malgré la tentative d'activer une option pour contourner le souci).

On peut faire du HTML léger avec juste quelques tags là ou c'est utile.

ça me rappelle les débats sur UTF-8 qui faisait perdre quelques octets par rapport aux encodages historiques. Certes, mais ça ouvre tellement de possibilités et simplifie tellement de choses.

Faire de la frugalité en HTML ne pose pas vraiment problème, en fait.

Pour ma part travailler chez moi ça voudrait dire partager l'espace (limité) dans mon appartement avec ma colocataire. Ce qui, en plus des problèmes d'organisation et de vie commune, pose aussi des problèmes de confidentialite des données.

Il faudrait donc que je déménage dans un logement avec une ou deux pièces en plus, ou alors que je travaille dans mon lit (pas bon pour mon dos). Et les 10€ par mois d'indemnité téléravail proposés par mon entreprise (pour 2 jours par semaine) ne permettent pas de financer ça (ça paie même pas la différence de facture d'électricité). Donc ce serait surtout des économie pour l'entreprise et un report des coûts sur les employés.

J'ai eu aussi des problèmes de droit à la déconnexion avec mon chef qui m'appelle 2h après la fin de ma journée de travail pour "juste une petite question", ou juste de mon propre fait defaire un "je finis jutse un truc" jusqu'à 23h… ou encore les mails et appels téléphoniques qui continuent d'arriver pendant la pause déjeuner.

Côté transports je suis privilégié avec seulement 10 minutes de vélo, certes.

Bref, dans mon cas le fait d'avoir un endroit dédié pour le travail ou je peux laisser tous mes problèmes professionnels le soir est essentiel à mon bon équilibre. Tant mieux pour vous si vous vous portez mieux sans, mais c'est pas le cas de tout le monde.

Et ceci indépendament des aspects "sociabilisation". Y'a des jours ou je suis tout seul dans mon openspace avec tous les collègues en télétravail et je prèfére toujours ça plutot que de travailler chez moi.

En effet, l'article ne dit rien sur le ressenti des employé.es chez Apple. Certes, l'entreprise a continué a fonctionner et a gagné plein de sous.

Il y a probablement des gens très content de faire du télétravail et d'autres beaucoup moins. Ça dépend de la culture d'entreprise, de l'aménagement des bureaux, de la distance à parcourir pour s'y rendre, du moyen de transport utilisé, de la sympathie des collègues, de la place disponible chez soi hour travailler, de la façon dont on gère la déconnection, et des goûts personnels de chacun.

Aucune info là-dessus dans l'article. Qui sait, peut-être que les employés d'Apple ont vraiment demandé en majorité (mais certainement pas à l'unanimité) à revenir sur place?

Soit on fait du matériel super-compliqué qui est facile à programmer, mais qui coûte cher et qui est peu flexible.

Soit on fait du matériel simple, pas cher, qui peut faire plein de trucs, mais qui demande beaucoup de logiciel pour fonctionner.

Comme la deuxième solution coûte moins cher pour le même résultat, c'est celle là qui est utilisée.

Il y a quelques dizaines d'années, le compromis était différent parce que les machines avaient peu de CPU et de mémoire. Aujourd'hui ces ressources sont en général largement disponibles. Il existe toujours du matériel de lapremière catégorie, par exemple des interfaces réseau qui font tout plein de trucs en interne. Sauf qu'en fait, elles contienne simplement un CPU spécialisé, pour toujours la même raison: c'est moins cher et plus flexible.

Je ne vois pas bien comment on peut vérifier la validité d'un diplôme si on ne fait pas confiance à l'université qui l'a délivré.

On peut donc avoir une université qui signe tous ses diplômes chaque année et publie les clés permettant de vérifier cette signature. C'est une bête signature numérique et il y a pas besoin de blockchain.

C'est bien ce qui a déjà été dit: la blockchain permet de faire des trucs en se passant d'un tiers de confiance, mais c'est une solution en quête d'un problème, parce que c'est beaucoup plus simple d'avoir un tiers de confiance. Sauf peut-être si on est libertarien ou complotiste

ReactOS avance doucement et on est pas tellement en concurrence. La technodiversité, c'est bien, et avoir plusieurs choix de système permet de stimuler le développement et de motiver les différentes équipes. Et à chacun de trouver son système préféré en fonction de ses besoins!

est ce que les logiciels ordinaires (libreoffice, gimp, openshot, vlc, thundie, firefox, opera, brave, falkon et autres vivaldi) pourraient tourner dessus?

Pas tous, pour l'instant.

Libreoffice est disponible ainsi que la plupart des logiciels basés sur Qt. Les logiciels basés sur GTK devraient arriver petit à petit. Pour les navigateurs web par contre, c'est compliqué, les moteurs sont très complexes et utilisent beaucoup de fonctionalités du système à tous les niveaux. Sans compter que, par exemple, Google qui maintient Blink (et donc Chromium, Vivaldi, Opera…) est carrément hostile au fait de le voir fonctionner sur des systèmes autres que Linux, Windows et MacOS et rejette les patch à cet effet. Pour Firefox, personne ne s'est lancé dans un portage récemment à ma connaissance.

Le mieux pour voir les logiciels actuellement disponibles sans installer Haiku, c'est de regarder le site Haiku Depot Server qui est une interface web pour les dépôts de logiciels.

Pour ma part j'utilise Haiku autant que possible, cependant je ne pense pas qu'il soit raisonnable pour le moment de l'utiliser comme unique système.

En vrai ça pourrait être utile si l'ordre entre les éléments n'est pas un ordre total. Dans ce cas il peut en effet y avoir plusieurs maximums (éléments qui sont sont supérieurs à tous les autres, soit n'ont pas de comparaison définie avec les autres).

En effet, je compare le C (avec ni exceptions ni destructeurs) avec le C++ (avec exceptions et destructeurs). Voyons la solution intermédiaire ou on aurait droit aux destructeurs mais pas aux exceptions.

Ok, on passe de:

    faire_un_truc();

à:

    if (faire_un_truc())
        return;

En admettant qu'on enlève les accolades pour gagner un maximum, on est quand même à 50% des lignes qui ne sont là que pour la gestion d'erreur. Et ça c'est dans un code simple ou il n'y a pas de boucles ou autres structures de contrôle compliquées.

Mais, si on écrit le code comme ça, au-delà du bête calcul sur le nombre de lignes utiles, tout le code qui fait des trucs est "caché" dans des if() qui vérifient si les fonctions ont fonctionné. Et là on est dans un cas ou la fonction retourne juste un bool pour dire si elle a fonctionné. Mettons qu'on veut par exemple ouvrir un fichier.

Version C++ avec exceptions et destructeurs:

    void OuvrirFichier() {
        Fichier leFichier;
    }

Si ça marche pas, la fonction lève une exception.

Version C sans rien:

    void OuvrirFichier() {
        Fichier* leFichier = open();
        if (leFichier == NULL)
            return;
        close(leFichier);
    }

Version C++ sans les exceptions:

    void OuvrirFichier() {
        Fichier leFichier();
        if (!leFichier.Ouvrir())
            return;
    }

Et ça c'est juste en regardant une fonction de très près. La classe ou structure Fichier va être plus compliquée: il faut une méthode Ouvrir qui retourne une erreur, il faut un destructeur qui vérifie si le fichier est vraiment ouvert avant de le fermer.

Et là on a toujours une seule ressource dans cette fonction. Quand il y en a 2 ou plus, la complexité de la gestion d'erreur va augmenter. Il y a le risque d'oublier un cas d'erreur et de ne pas mettre un if là ou il faudrait, et de se retrouver avec un objet dans un état invalide (on peut avoir un objet Fichier qui ne correspond pas à un vrai fichier, soit parce qu'on n'a pas encore appelé la méthode Ouvrir, soit parce que la méthode a rencontré une erreur).

Quelques erreurs se sont glissées dans le texte:

• à un endroit on parle de la licence SIL OLF, il faut bien sûr lire SIL OFL (les mentions suivantes sont correctes)
• Il est question d'une police Ysabeau Infans (avec un s) mans dans les exemples c'est Ysabeau Infant (avec un t). Je ne sais pas qui a raison.

Mon ressenti sur l'utilisation des exceptions, après avoir travaillé sur des projets en C et en C++ avec et sans exceptions, c'est plutôt l'inverse.

Sans exceptions, on se retrouve à écrire au moins 3 lignes de code de gestion d'erreur par ligne de code "utile":

Code utile:

faire_un_truc();

Avec gestion d'erreurs:

result = faire_un_truc();
if(result) {
    libérer_les_resources();
    return;
}

Si on a une fonction un peu plus longue qui alloue plusieurs resources, ça devient très vite le bazar de s'assurer que on a bien libéré toutes les ressources allouées.

Alors que avec les exceptions et la RAII en C++, ça se fait tout seul: tous les objets alloués sur la pile sont automatiquement libérés lorsqu'on quitte la fonction.

Bien sûr, pour que ça marche bien, il faut que toutes les resources soient liées à l'existence d'un objet sur la pile. Ce qui peut être compliqué si on en a pas l'habitude ou si le projet (ou les bibliothècues utilisées, ou l'OS ciblé) n'a pas été pensé pour.

Dans le même genre mais avec des composants un tout petit peu plus miniaturisés:

https://monster6502.com

Tout ça pour dire qu'il existe aujourd'hui un réel flou juridique concernant ces technologies. Et c'est pas les développeurs ni des entreprises privées qui le résolveront. Ce seront des avocats/juristes/gouvernements à coup de nouvelles licences et de nouvelles lois.

Je ne pense pas que la solution ça soit une nouvelle licence ou une nouvelle loi. C'est effectivement une lecture "juridique" du texte de la licence existante.

Le texte de la licence MIT a justement l'avantage d'être extrêmement clair et simple. Il donne le droit de faire tout ce qu'on veut à condition de reproduire le texte de la licence et la notice de copyright.

Alors on peut prendre un.e juriste et lui demander de faire dire à la licence le contraire de ce qui est écrit, mais comme la licence est simple, courte et claire, son travail va être compliqué. Oui, iel pourra tenter des trucs. Mais iel va avoir du mal à trouver quelque chose.

Par exemple, la question "est-ce que github a obtenu une copie du code?" ça va être difficile de dire que non.

À la question "est-ce que Copilot reproduit la licence avec le code quand il le réutilise?" la réponse est clairement non.

Et comme je le disais, la question qui se pose est plutôt "jusqu'où on peut aller si on ne veut pas respecter les termes de la licence?" (dans ce cas, reproduire la licence et la notice de copyright)?

La réponse est là aussi assez simple: c'est le droit d'auteur qui s'applique. Il donne quelques droits "par défaut", j'en ai cité quelques uns. Et c'est plutôt là que le débat va se situer: est-ce que les droits donnés par défaut par le droit d'auteur sont suffisants pour l'utilisation que Github a fait du code? Là, on arrive dans une question plus pointue, et effectivement, comme je ne suis pas juriste de formation, je ne vais pas m'engager dans une réponse à ce niveau là parce que ça dépasse mes compétences. Mais il n'est pas difficile de trouver des informations sur ces droits si on veut se pencher sur la question.

Mais sur la lecture d'une licence et son application dans les cas classiques, je pense que tous les développeurs devraient au moins être sensibilisés au sujet. Ça évite de faire n'importe quoi. Un peu de la même façon qu'on demande aux gens de connaître un minimum le code de la route avant de conduire une voiture, pas tous les articles par cœur, mais de quoi se débrouiller au quotidien dans les situations courantes.

Ces licences couvrent la redistribution et la modification du code. Elles ne couvrent pas son usage dans une analyse automatique.

Voici ce que dit la license:

Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the “Software”), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so

(avec une clause d'attribution ensuite).

Donc la permission qui est donnée est: "to deal in the Software without restriction", avec quelques exemples non exhaustifs ("including witohut limitation"), dont la redistribution.

Il n'y a pas du tout de limitation à la redistribution ou à la modification du code. Si tu as reçu une copie de ce code (trouvé sur github ou il a été volontairement publié par exemple), tu as le droit de faire ce que tu veux avec sans restriction, tant que tu cites le nom de l'auteur.

Si tu ne cites pas le nom de l'auteur tu as les droits donnés par:
- Les conditions d'utilisations de github (droit pour n'importe qui de forker le dépôt par exemple, ce qui ne fait pas vraiment de copie et donc ne pose pas de problème de droit d'auteur en soi)
- La loi sur le droit d'auteur, qui par défaut interdit tout, sauf accord de l'auteur, et des exceptions pour les courtes citations, parodies, etc (variables selon les pays).

A priori la loi sur le droit d'auteur n'a pas de clause spéciale pour l'analyse automatique. Les conditions d'utilisation de Github, peut-être. Mais si des gens ont déposé sur Github du code dont ils ne sont pas détenteur du copyright, sans l'autorisation dudit détenteur, je vois mal comment les conditions d'utilisations de Github pourraient alors outrepasser la license.

Dans le pire des cas on va en détruire un (Haiku Jam) pour le remplacer par un autre (Ham). Dans le meilleur des cas, on va en détruire deux (Haiku Jam et Boost Jam) pour les remplacer tous les deux par Ham.

En fait tout cela est assez neutre puisqu'on ne crée pas de nouveaux fichiers de build, on crée un nouvel outil qui utilise les fichiers déjà existants. Qui sont d'ailleurs loin d'être parfaits dans Jam, mais je pense que ça va permettre de travailler sur des aspects intéressants du problème (intégration dans les IDE, meilleur suivi des dépendances, rapidité de parsing des fichiers) en sautant les étapes "réinvention de la roue" de la conception d'un nouveau langage de build.

Peut-être que d'autres outils devraient faire ça? Est-ce qu'on adopterait plus rapidement un outil qui fait "tout comme CMake mais deux fois plus vite" qu'un outil "il faut réécrire tous les scripts de build mais ça va trois fois plus vite"?

Utiliser les outils existants (en tout cas ceux qui existaient en 2001, j'ai pas re-vérifié depuis) pour Haiku c'est compliqué. Pour un build de Haiku il y a 3 compilateurs qui entrent en jeu: un pour compiler des trucs sur le système hôte, et un gcc2 et un gcc11 pour compiler sur la cible. Et au début il nous fallait un outil qui fonctionnait sous BeOS. Sans compter les petits morceaux compilés en assembleur, les astuces pour générer un bootloader EFI valide (qui est en gros un .exe pour Windows mais pas tout à fait), des images de DVD contanant plusieurs systèmes de fichiers, …

On a un moment réfléchi à tenter d'utiliser CMake mais il ne semble pas vraiment assez flexible pour ça. Je crois qu'à l'époque on en avait discuté avec ReactOS, ils utilisent CMake, mais en fait ils avaient une version patchée pour pouvoir faire tout ce qu'ils voulaient.

Maintenant, si un développeur de Boost.Jam se mettait en tête d'intégrer tout ce dont on a besoin dans Boost.Jam, on serait très content de leur refiler la maintenance du système de build et de plus avoir besoin de le faire nous-même. Mais jusqu'à maintenant, ce n'est pas arrivé.

On me signale une faute de frappe: il fallait bien sûr lire mkfs et pas mkds pour le nom de l'outil pour formater un disque.

C'est déjà pas mal, non?

La principale limitation pour l'instant est que seuls les exécutables 64bit sont utilisables. Mais il y a d'autres limitations, par exemple il y a des morceaux pas implémentés pour la 3D (j'ai essayé de lancer MAME par exemple et ça ne fonctionne pas à cause de ça). Il semble y avoir un travail en cours pour implémenter l'accélération 3D avec Vulkan et peut-être de l'accélération matérielle (j'ai du mal à suivre le grand nombre de projets en cours de X512 qui travaille sur beaucoup de sujets à la fois!)

Il y a des exemples d'applications avec des captures d'écrans dans ce sujet sur le forum de Haiku: https://discuss.haiku-os.org/t/my-progress-in-porting-wine/11741/169

Première raison:

Notre version de Jam a beaucoup divergé de l'original avec des fonctionnalités supplémentaires. En particulier les "build profiles" qui permettent de compiler différentes configurations facilement. Dans notre cas: jam @nightly-raw pour compiler une image de type "nightly build", jam @release-raw pour compiler une image de type "release" (qui contient plus de choses), etc. Un profil permet de customiser pas mal de choses au moment de la compilation.

Dans d'autres projets ces profils pourraient être utilisés pour compiler le même exécutable en release ou en debug, par exemple.

Il faudrait donc reporter ces changements dans Boost.Jam, ce qui est compliqué à faire directement parce qu'ils ont énormément retravaillé l'architecture du code (je le sais parce que j'ai porté des patchs dans l'autre sens, par exemple pour pouvoir générer un compile_commands.json).

C'est un exemple d'incompatibilité, mais il y en a plusieurs autres y compris sur la syntaxe du langage Jam. Ham prévoit à terme de savoir lire les Jamfiles des différentes variantes existantes (Haiku, Boost, Perforce original, et peut-être Freetype Jam).

La deuxième raison:

Ham n'est pas seulement un exécutable, il y a une bibliothèque partagée qui pourrait par exemple être utilisée dans un IDE. Ainsi l'IDE n'aurait pas besoin d'un fichier "projet" séparé mais pourrait utiliser (et modifier) directement les Jamfiles et lancer la compilation sans devoir passer par le lancement d'un outil en ligne de commande. Ce qui permettrait par exemple de recompiler directement juste les fichiers concernés quand on enregistre un fichier .cpp ou .h, en tâche de fond. Sans avoir à re-lire et parser tous les Jamfiles à chaque fois comme quand on lance l'outil en ligne de commande. Ou encore d'avoir un outil en tâche de fond qui fait ça même sans IDE.

Troisième raison:

La coordination entre plusieurs projets (Boost et Haiku par exemple) est souvent compliquée. Ils apprécierait pas forcément qu'on ajoute tous nos trucs dans leur version. Et si le résultat c'est remplacer un fork de Jam par un fork de Boost.Jam, on aura pas gagné grand chose.

Dans la GPL v2 il y a 3 façons de faire dans ce cas:

.3. You may copy and distribute the Program (or a work based on it, under Section 2) in object code or executable form under the terms of Sections 1 and 2 above provided that you also do one of the following:

a) Accompany it with the complete corresponding machine-readable source code, which must be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or,

b) Accompany it with a written offer, valid for at least three years, to give any third party, for a charge no more than your cost of physically performing source distribution, a complete machine-readable copy of the corresponding source code, to be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or,

c) Accompany it with the information you received as to the offer to distribute corresponding source code. (This alternative is allowed only for noncommercial distribution and only if you received the program in object code or executable form with such an offer, in accord with Subsection b above.)

Donc en effet, on peut donner le lien vers les sources originales, mais seulement dans le cas d'une distribution non-commerciale ET si on a nous-même reçu l'exécutable de cette façon (c'est l'option C). Ce qui n'est pas notre cas puisqu'on l'a compilé nous-même et qu'on collecte des dons pour le projet en échange de nos DVD.

Donc on a pris l'option A.

Dans la GPL3 des nouvelles possibilités ont été ajoutées:

.6. Conveying Non-Source Forms.

You may convey a covered work in object code form under the terms of sections 4 and 5, provided that you also convey the machine-readable Corresponding Source under the terms of this License, in one of these ways:

a) Convey the object code in, or embodied in, a physical product (including a physical distribution medium), accompanied by the Corresponding Source fixed on a durable physical medium customarily used for software interchange.

b) Convey the object code in, or embodied in, a physical product (including a physical distribution medium), accompanied by a written offer, valid for at least three years and valid for as long as you offer spare parts or customer support for that product model, to give anyone who possesses the object code either (1) a copy of the Corresponding Source for all the software in the product that is covered by this License, on a durable physical medium customarily used for software interchange, for a price no more than your reasonable cost of physically performing this conveying of source, or (2) access to copy the Corresponding Source from a network server at no charge.

c) Convey individual copies of the object code with a copy of the written offer to provide the Corresponding Source. This alternative is allowed only occasionally and noncommercially, and only if you received the object code with such an offer, in accord with subsection 6b.

d) Convey the object code by offering access from a designated place (gratis or for a charge), and offer equivalent access to the Corresponding Source in the same way through the same place at no further charge. You need not require recipients to copy the Corresponding Source along with the object code. If the place to copy the object code is a network server, the Corresponding Source may be on a different server (operated by you or a third party) that supports equivalent copying facilities, provided you maintain clear directions next to the object code saying where to find the Corresponding Source. Regardless of what server hosts the Corresponding Source, you remain obligated to ensure that it is available for as long as needed to satisfy these requirements.

e) Convey the object code using peer-to-peer transmission, provided you inform other peers where the object code and Corresponding Source of the work are being offered to the general public at no charge under subsection 6d.

L'option B a été pas mal modifiée et maintenant elle permet de fournir un lien de téléchargement. Mais toujours à garder en ligne pendant au moins 3 ans.

Les nouvelles options D et E ne nous concernent pas (pour les DVD en tout cas) puisqu'il s'agit de téléchargement depuis un serveur ou de diffusion en P2P.

D'ailleurs ces clauses sont un peu mal fichues, puisque la D parle d'une durée de distribution, mais en fait la durée dont il est question n'a l'air de s'appliquer que dans le cas B?

Et inversement, dans le cas B il n'est pas précisé si on doit héberger nous-même le code source ou s'il suffit de donner un lien pointant chez quelqu'un d'autre. Alors que l'option D dit explicitement que c'est possible. Cela dit, puisqu'il faut garantir que les données seront disponibles pendant 3 ans, on ne peut pas le faire en pointant sur le serveur FTP du projet GNU, qu'ils pourraient très bien décider de fermer / supprimer des vieux fichiers.

Non mais il y a des gens qui ne souhaitent pas redistribuer des versions, même non modifiées.

Par exemple, moi!

Sur les DVDs du système d'exploitation Haiku, on inclut un certain nombre d'outils de développement, dont, par exemple, GNU make. Comme il est sous licence GPL, si j'envoie un tel DVD à quelqu'un (par la poste, sur un stand au FOSDEM, …) je m'engage à rester à sa disposition pendant 3 ou 5 ans (si je dis pas de bêtise) pour lui donner, par le même moyen, les sources correspondantes.

La licence a été un peu améliorée sur ce point dans la version 3 et maintenant, fournir un lien pour télécharger les sources (qui doit rester valable pendant la même durée) est suffisant.

Au final, pour Haiku, on a mis les sources des applications sous licenses GPL fournies, directement sur le DVD. Ce qui nous empêche de pouvoir faire rentrer notre distribution sur un CD au lieu d'un DVD. Ce qui fait que les DVD coûtent un peu plus cher à produire et donc on récolte moins d'argent par ce moyen (on passe de 87c à 1€ pièce sur un lot de 500 disques). Donc la conformité à la GPL nous a coûté environ 65€.

Ça peut marcher aussi. Ça m'arrive souvent de mélanger du code MIT et GPL dans un projet. L'ensemble est alors soumis aux contraintes de redistribution de la GPL (ou alors il faut réécrire et remplacer les morceaux qui sont sous cette license), mais on peut extraire des parties du code qui sont en MIT pour les réutiliser ailleurs.