Quels sont les éléments open-source / closed-source de Sailfish OS ?

open-source-swNous le savons tous, Sailfish OS n’est pas un système d’exploitation complètement « ouvert ». En effet, Jolla se réserve quelques parties en closed-source, des applications, pilotes, traductions…

Carsten Munk, ingénieur chez Jolla, a mis en ligne deux graphiques, l’un avec les noms des paquets OSS, l’autres avec ceux NON-OSS (image à ouvrir dans un nouvel onglet) :

oss-vs-nonoss

A noter que Jolla libère un peu à la fois quelques-unes de ses applications avec dernièrement :

Pensez-vous qu’il est possible / imaginable de créer une système d’exploitation pour smartphone totalement open-source ?

Source

A propos de Nicolas SUFFYS

Co-fondateur de JollaFr.org et Nokians.fr. Linuxien de longue date et possesseur de Nokia N900, N9, N950, Jolla, Oneplus One, Lumia 830.

42 commentaires à propos de “Quels sont les éléments open-source / closed-source de Sailfish OS ?

  1. Fondamentalement, oui, c’est possible.

    Concrètement, j’y crois de moins en moins…
    Sur PC, on a eu une époque où il était possible d’installer plein de systèmes poussés par des communautés diverses…. Aujourd’hui, on dirait bien que ces communautés ont fondu. La faute à la crise qui tue le bénévolat?
    Je ne sais pas.
    Mais une partie de la cause revient aux fabricants de matériels qui ne libèrent plus rien, les drivers….
    Quand on voit les BIOS de plus en plus verrouillés, ça ne va pas en s’arrangeant. Installer Ubuntu redevient une tâche d’ingénieur.
    Pour installer un FreeBSD, il faut faire une enquête de plusieurs moi pour trouver la matériel supporté.
    Ca se comprend, ceux qui développent des OS, verrouillent leur marché: tu veux l’OS, tu payes le matériel. Tu veux le matériel, tu paies l’OS. Et ça se comprend d’autant plus que les fabricants et les OS se rapprochent de plus en plus.

    Bref, mon pavé est indigeste, ma réflexion aussi. Tout ça pour dire que vu comment ça évolue dans le monde pc, je n’y crois pas pour le monde mobile…

    • « Bref, mon pavé est indigeste, ma réflexion aussi. »

      Non, bien au contraire je compatis. L’arrivée des EFI / UEFI fait beaucoup de mal aux OS autres que Windows 8+. Tout le monde veut faire du Apple et c’est le consommateur qui y perd.

      Déjà ce n’est plus possible de récupérer correctement la licence Windows 8 acheté avec le PC. Il vaut mieux ne pas y toucher si tu veux garder Windows sinon t’es bon pour passer à la caisse (ou pirater selon ta mentalité). Ensuite il faut faire sauter les verrous au niveau du BIOS mais c’est le Windows 8 OEM qui commence à faire des siennes.

      Tu parles d’Ubuntu et c’est bien que Canonical ait réagi assez rapidement en permettant d’installer Ubuntu à peu près comme on pourrait installer un Windows. Canonical a été réactif là où les libristes se sont enlisés dans questions éthiques et bureaucratiques au niveau de certaines clés.

      Bref un vrai casse-tête. J’ai changé récemment de PC et si on m’avait dit que je devrais à nouveau suivre un tuto pour installer Ubuntu. 😯 On marche sur la tête. Vivement l’arrivée de Windows 10, comme ça je me prendrai une licence Windows neuve avec le dernier Windows en date et j’en profiterai pour refaire un truc clean au possible.

      « Mais une partie de la cause revient aux fabricants de matériels qui ne libèrent plus rien, les drivers…. »

      Tu confonds open source et compatibilité entre plateformes. Le problème n’est pas la liberté des drivers mais le fait qu’il n’y ait souvent que des versions pour Windows. Perso j’ai un Lenovo récent et c’est un vrai problème sur Ubuntu, notamment au niveau du Wifi. Je sais que certains me diront que Linux et bon Wifi font deux mais c’est la première fois en plusieurs machines que j’ai des problèmes de Wifi avec Ubuntu (en dehors de la « barrière des 50% »).

  2. N’oublions pas l’essentiel. Le plus important n’est pas la liberté du code mais qu’il marche. Il vaut mieux quelque chose de propriétaire et de fonctionnel qu’open source et buggué.

    Sinon il est compréhensible que Jolla veuille garder certains éléments pour eux. Que feront-ils si un jour Sailfish OS est amené à être utilisé par d’autres constructeurs que Jolla ? Je ne pense pas que l’argent des licences OEMs suffise à faire vivre nos chers marins. Par exemple Android ne rapporterait quasiment rien à Google en licences malgré sa popularité. Je ne râlerai donc pas si Jolla veut garder de la valeur ajoutée en ne libérant pas sa surcouche Sailfish et laisser les autres se débrouiller pour leurs futures surcouches Sailfish personnelles.

    « Pensez-vous qu’il est possible / imaginable de créer une système d’exploitation pour smartphone totalement open-source ? »

    Tizen serait 100% open-source.

    • « N’oublions pas l’essentiel. Le plus important n’est pas la liberté du code mais qu’il marche. Il vaut mieux quelque chose de propriétaire et de fonctionnel qu’open source et buggué. »

      Je ne suis pas d’accord, et on est nombreux à ne pas l’être. Tous les gens qui ont contribué bénévolement à faire de linux ce qu’il est aujourd’hui ont utilisé du code buggué, des hacks dans tous les sens, en partie pour le challenge techno certes, mais surtout parce qu’ils pensaient qu’un système open source est important.

      • Oui le FOSS est important, mais ça ne sert à rien si ça plante au démarrage. Le noyau Linux fonctionne et c’est bien là l’essentiel. Mieux, il fonctionne et en plus il a la chance d’être open source. 😉 😀

        • Dans ce cas là pourquoi ne pas installer Open-Solaris, Aiku (Open BeOS), Open BSD, minix64, Hurd, etc … Justement paske la communauté linux étant la plus importante, il s’est trouvé suffisemment de passionné qui ont bien voulu prendre sur leur temps de reproduction la rétro-ingéniérie les drivers Windows . C’est une chance pour les linuxiens, c’est un calvaire pour les autres ; et à défaut de sources libres diffusés par les fabricants de perifs, il faudrait pouvoir exiger pour le moins des spec complètes pour pouvoir les faire écrire …
          Et le « closed source » qui marche a ses propres limites : va ‘recompiler’ un driver Nvidia un tant soit peu ancien pour un kernel récent : le gros binaire « .o » tout fermé caché dans leur « source » ne se « linke » plus, les entrées prévues à l »époque sur le kernel n’existant plus … Et quand on voit les progrès de Nouveau (les sources libre de Nvidia), on sent bien qu’il n’est pas trivial de rétro-ingénier. Mais c’est pas grave, il suffit de racheter une carte récente, c’est pas le bout du monde ; sauf que sur un portable … Or un « vieux » portable peut encore rendre d’immense services …

    • Du propriétaire non buggé, faut pas rêver non plus. Dans le propriétaire, le bon fonctionnement n’est l’objectif 1er. Dans le libre, l’objectif est plus tourné vers le fonctionnement. D’ailleurs la célérité des mises à jour dans le libre est caractéristique de cette vision.

      • Je ne dis pas que le code propriétaire n’est jamais bogué et que le code libre l’est tout le temps. Je dis juste que l’essentiel est que « ça marche » et que la liberté du code passe après. La liberté du code n’est qu’un plus, c’est tout.

        • Si deux codes équivalents existent, l’un libre l’autre pas, et qui fonctionnent, il est préférable d’utiliser celui qui est libre car on sait exactement ce qu’il fait contrairement au code fermé. De plus, il est possible de l’améliorer ou d’y corriger un bug sans dépendre de son créateur.

        • Je ne partage pas ton point de vue :
          NVidia, suite à une pression des linuxiens (ils ont envoyé un fac-similés des factures des cartes graphiques achetées supportant le kernel linux en précisant qu’initialement ils souhaitaient acheter une NVidia), a pris en compte le kernel linux (et solaris) en délivrant une source essentiellement composée d’un gros binaire qui se linke au kernel, mais aucune Doc pour écrire des drivers. Et comme le support de Nvidia n’est pas à vie (de l’entreprise), les cartes qui ne sont plus supportées ont accés à des « sources » binairement associées à une version du kernel … Quand celui-ci évolue trop, ces sources ne se compilent plus.
          Les fabricants de SOC ARM procèdent de la même façon : tu as des sources pour les extensions embarquées sur le SOC, mais ôh bizarrerie, toujours associé à une version du kernel : quand celui-ci évolue, de moins en moins de truc arrivent à être compilé ; et croit moi, un smartphone, affichage framebuffer avec aucun perif (tactil écran), sans aucun clavier physique, c’est super « chaud » à utiliser : on est bien alors privé de la jouissance d’un bien que l’on a pourtant acheté : le closed source (même s’il marche à un moment donné) est et reste à terme « privateur ».
          Or vu les investissements nécessaires, les SOC ou juste les processeurs open-source (open sparc T1, LowRISC : http://www.lowrisc.org/ , open risc) sont obsolètes avant même d’être gravés en test.

    • Pourquoi, à votre avis par exemple Samsung et d’autres fabricants de téléphones mobiles sous Androîd doivent-ils payer 5 euros par licence (ou par téléphone) à Micro$ ???
      Pourquoi la guerre des brevets autour des téléphones mobiles ?

      • Parce que les brevets logiciels sont parfois plus que problématiques. Certains décrivent des fonctionnement on ne peut plus basique (c’est comme si quelqu’un avait breveté le double clic), et cela amène des guerres juridique sans fin.

        Aux dernières nouvelles, Samsung refuse de payer Microsoft du fait qu’ils sont entrés en concurrence. L’accord des 5$ semblait prévoir une clause de non concurrence.

  3. Sailfish ne peut pas être 100% open source sinon qu’est-ce qui m’empecherait de l’installer sur une Nokia N1 et finalement de donner mon argent à Nokia/FoxConn au lieu de Jolla?

    • C’est loin d’être aussi simple. Porter un OS, même entièrement libre, sur un autre matériel est un boulot de dingue.

      J’ai du mal à comprendre qu’en 2014 on en soit encore à des réflexions du type « Pourquoi ils mettraient leur code en Libre, si c’est pour que les concurrents en profitent? » alors que tous les grands groupes (même MS) y ont vu leur intérêt. Même chose pour la remarque sur la sécurité de l’OpenSource. Il a été prouvé des centaines de fois que le code Open Source, par la rapidité des fixs quand les failles sont trouvées et la quantité de testeurs et relecteurs de code bénévoles dont il dispose, est bien plus secure que le code proprio.

      Arrêtons le FUD. Merci.

    • paske la tablet N1 n’a même pas de capteur GPS, un port USB reversible mais pas OTG, et ressemble trop à un iPad : la Jolla lui est immédiatement superieur

  4. Sailfish repose sur Mer, qui est libre. Le problème se pose aux 2 extrémités :
    – les pilotes
    – l’interface graphique

    Pour le second, c’est plus facile, Qt étant libre, « suffit » de se retrousser les manches, et ça roule. C’est l’objectif de Nemo Mobile et son interface Glacier.

    Le problème se pose donc pour les pilotes. Mais là, il y a libHybris qui aide beaucoup.

    Donc un OS totalement libre n’est possible que si vous maîtrisez le matériel sur lequel il tourne…ou si les fabricants sont assez gentils pour libérer le code source des pilotes, ce qu’ils ne font pas.

    On peut donc avoir un OS mobile libre, fonctionnant sur des pilotes propriétaires…D’ailleurs, quelqu’un sait si les pilotes utilisés par FirefoxOS sont libres ?

    Je ne sais pas non plus comment va faire l’équipe de EndlessMobile avec ce problème.

  5. En fait ta question recouvre principalement 3 aspects du problème :
    – Open Source pour le matériel,
    – Open Source pour le software
    et dans le cas qui nous préoccuppe
    – Quel peut -être le business model d’un Sailfish 100%Open Source ?

    je vais détailler sur 3 posts afin que cela puisse rester clair.

    • Open Source pour le materiel

      A/ Coté matériel, le monde ARM a montré que même avec un kernel 100% Open source, on pouvait avoir de mauvaises pratiques (pressenties/dénoncées par ces cons de libristes intégristes des premières heures) : à cause de « devices » en modules « closed sources », on peut avoir un kernel 100% opérationnel et pourtant in-recompilable ; le myopes clameront que c’est pas grave puisque ça marche … Les libristes leurs feront remarquer que c’est la cause principale de l’abandon de terminaux par l’équipe cyanogen : on a AOSP (100%opérationnel), on a un kernel à jour mais les sources des drivers étant inaccessibles, il est impossible de faire le « make build world » qu’autorise un matériel 100% Open source et donc juste impossible de faire évoluer ne serait-ce que le Kernel (juste pour profiter des dernieres optimisations de conso d’énergie).
      De la même manière, il devient impossible d’installer facilement Firefox OS/Sailfish/Ubuntu touch sur un terminal quelconque, même avec un bootloader unlocked. Sony pousse la démonstration encore plus loin : à cause d’appli proprio (qui marche, donc cela se suffit en soi) associée au traitement d’image de l’APN, et alors que Sony fournit les sources open et les binaires idoines, la partie photo est et restera sous AOSP équivalent pourries (avec un 20MPx exmore, c’est un peu dommage) ; et dés que l’on voudra upgrader le kernel, les binaires des modules deviendront incompatibles … Mais bon c’est pas comme si ces cons de libristes intégristes ne nous avaient pas prévenus depuis le début …
      L’experience Neomobile montre également que concevoir un termila hardware Open source est une réelle gageure : le temps de trouver des chipset acceptant le defi Open-source (donc marginaux), généralement ceux-ci sont abandonné par leurs fondeurs … Et quand ils sont encore disponibles, on apprend que leur utilisation est soumises à royalties (non comprises dans le prix d’achat) …

      Donc le Matos avec des perifs proprio est un premier frein, frein d’autant plus efficaces que la plupart des « consommateurs avertis » sont convaincus que puisque ça marche, on a pas vraiment besoin d’un truc 100% libre : 20ans de lavage de cerveau M$/Nvidia/etc semble les laisser imperméable à la seule observation des faits.

      Mais bon, c’est pas comme si ces cons de libriste empêtrés dans leur stériles et ridicules questions d’éthiques ne nous avaient pas prévenu, dés le début.

    • Open Source pour le software

      B/ open source software
      d’abord il faut arrêter de confondre OS et interface graphique. Si Sailfish OS existe c’est justement parce que le monde unix (en général) continue à dissocier les deux : pendant que Jolla développe son Interface home/machine, il confie à d’autre la réalisation d’un kernel efficace, moderne et économe, et donc profite d’une synergie de moyens.

      Sur un bouzin où tout est confondu, ils se seraient contenté d’une surcouche pour se différencier. Le monde windows est plein de ses surcouches pour rendre Windows plus conviviales, surcouche immédiatement inutilisable dès la mise à jours de quelques broutilles : toutes ces surcouches ont disparues : qui se souvient de New Wave (1990), la surcouche d’HP pour Windows 3 (qui en avait bien besoin). Et encore pak’a l »époque, le bouzin était suffisamment documenté : va virer juste l’UI metro de WP8.1 d’un Lumia1020 pour mettre un truc qui te plait ! Non c’est pas possible, c’est le tyran M$ qui sait mieux que toi ce que tu aimes … Et si tu n’aimes pas, on te fait bien comprendre que tu n’es qu’un con rétrograde, passéiste, incapable de t’adapter à la laideur obligatoire.
      Sur Unix, tu as des desktops et chacun pioche selon ses goûts, ses besoin ou les limites de la machine (LXDE/Linux sur un Acer Aspire V5 fait réaliser que Windows 8.1 n’est qu’un sale truc imbitable, mal foutu et tyrannique et LENT). D’ailleurs si l’UI du Jolla-phone ne te convient pas, techniquement tu peux la remplacer, sans avoir à toucher à rien d’autre qu’au « desktop » embarqué par Sailfish.

      Inversement à cause du closed source tu ne pourras pas l’adopter sur ton firefox phone ; à supposer que firefox soit un immense succès et que Jolla parte vers d’autres aventures, il sera encore possible de migrer ton Jolla-phone vers ubuntu-touch ou firefox OS, juste en recompilant les brique des UI qui t’interessent (enfin « juste », c’est déjà un vrai boulot, mais c’est réalisable).
      Par contre quel est l’avantage pour Jolla de garder toute son UI en closed sources ? NUUUULLL !!!
      Je m’explique : tous les petits bugs ou petits manque ne peuvent être corrigé que par Jolla, impactant sa réactivité; je fourni un exemple idiot : en mode BT (dans ta voiture) quand tu rappelle un correspondant, le Jolla n’utilise pas le N° du correspondant (qu’il connait puisque c’est ce qu’il fait quand il n’est pas connecté en BT), mais le premier entré à son nom dans le carnet d’adresse. Donc si celui-ci, vous appelle de son portable, quand vous le rappelez de votre voiture en mode BT, vous appelez chez lui sur son fixe. C’est rien à corriger, il suffit juste d’avoir les sources pour le écrire le patch et le proposer à Jolla. Autre exemple : impossible d’avoir l’UI en mode paysage alors que les icone sont carrés (malin il suffit de les tourner sur place, de 90°, pour les positionner en mode paysage). les pochettes articulées le pose dans ce mode et il reste inutilisable (pourri le clavier de déverrouillage en mode portrait quand ton Jolla est posé en mode paysage, pourri l’UI de sailfish quand le jolla est posé en mode paysage), etc, etc. Et dans toute l’UI de Jolla c’est pareil : des points de détails qu’un groupe passionné et actif pourrait traiter (cf CodeRus) ; et point n’est besoin d’avoir une communauté de 100.000 développeurs pour ça : une dizaine de gars avec un turnover de 6 mois suffiraient a corriger l’UI de manière efficace, laissant à Jolla la maîtrise d’oeuvre, la vision d’avenir. et le soin des validations (imaginez où en serait le kernel linux si en 1992 Linus avait écrit : j’ai un truc marrant, qui marche, mais je le garde pour moi, je ne vous livre que les binaires).
      Alors oui, c’est une vraie connerie que ce closed sources sur des trucs que n’importe qui peut réécrire (Mer, Open Moko, Ubuntu, Firefox, Sony ou samsung).

    • Alors ,
      – Quel peut -être le business model d’un Sailfish 100%Open Source ?

      -équipe logicielles : proposer une distribution prête à l’emplois sur quelques flagship et ou appareils très populaires. Vendre du service aux fabricants : DIstrib et mise à jour (demandez à One+ s’ils n’est pas prêt à payer pour avoir Jolla sur son One+one), ce qui réglerait les soucis du closed source des drivers des terminaux supportés (il n’est pas indispensable que Jolla développe pour toutes la production : 3 ou 4 marques et 2 smartphone assez proche est parfaitement maintenable°) et viser la synergie avec Firefox, Ubuntu, etc pour avoir une plateforme commune d’applications.
      Et probablement racheter Myriad, pour pouvoir continuer à squatter les stores Android, les applications Java n’ayant pas besoin d’être recompilée quand on change de plareforme.

      Vendre de la confidentialité et de la sécurité (abonnement cloud, etc)

      équipe hardwares :
      Les plus pragmatiques se contenteraient d’un
      – probablement d’arrêter de faire des smartphones ou des tablettes (la concurrence fait mieux et moins cher).
      Mais il y a là une vraie expertise qu’il serait dommage de brader : probablement tenter des rapprochements avec des marques exclusives (Vertu, Porsche, Cartier, etc) pour imaginer des terminaux exclusifs et intemporels (Comme Le Jolla : il n’a pas encore besoin d’être remplacé), tenter des coups à la Jolla Tablet (sondage sur la tablette/smartwatch/SmartTV/SmarttOwnCloud/Smartphone/Smart-Truc que vous attendez, quels sont vos moyen et lancer une action en CF), le tout sous sailfishOS/MyriadAlien.
      Reconnait que s’ils nous avaient proposer un Lauta en version TOH, Oled et octocore en CF beaucoup auraient craqué …

      °) on peut même envisager un Jollacloud qui fourniraient les binaires recompilés des matéreiels supportés, afin de continuer à faire évoluer le matériel (ancien kernel avec les nouvelle lib, nouveau kernel avec les anciennes lib, etc) …

  6. On sera tous d’accord, je pense, pour considérer que l’open source est un véritable gage de transparence vis-à-vis de l’utilisateur final.

    Après, je peux comprendre que Jolla conserve une partie de son code fermé, temporairement tout du moins. Officiellement, peut parler de ne pas filer son super code qui risque de leur faire perdre des parts de marché, les arguments fournis au dessus démontent complètement ce point de vue.

    Par contre, fournir un code source pas forcément parfaitement abouti, c’est aussi vite contre-productif. En mon sens, un code source libre est vite jugé comme judicieux ou non, efficace ou pas, faillible ou non. Ces considérations sont difficiles à lier avec des contraintes industrielles et souvent, comme dans bien des métiers, l’on ne montre pas ce qu’on ne veut pas montrer, pour une raison x ou y.
    Jolla libère du code, dont certains sont au cœur de leur OS. C’est, je pense, parce que d’une part ils pensent avoir obtenu une certaine maturité (la base est là, fiable, cohérente vis-à-vis de leur propre exigence) et que les fonctionnalités supplémentaires peuvent être intégrées en suivant l’abaque mis en place.
    C’est une justification qui pour moi aurait du sens, sans chercher la moindre discrimination vis à vis de l’équipe Jolla, bien au contraire.

    Car au final, l’open source, c’est un peu une sorte de but à atteindre: On sait ce qu’on a fait, on connait parfaitement le fonctionnement, donc on peut le montrer à tout le monde, que cela puisse profiter à tous, et/ou que, le cas échéant, certains rebondissent dessus, trouvent des erreurs, les corrigent, apportent des améliorations auxquelles on n’avait pas pensé.

    On sait aussi que les équipes Jolla sont actives pour les projets liés à Jolla, Mer en premier lieu. C’est dans leur intérêt, et forcément, cela impacte les projets au-delà de l’OSpadon. Et là, on est pile poil dans l’open source.

    Pour la question des pilotes open source, comment cela se passe au niveau de LibHybris? Je serai curieux de savoir si le passage à des pilotes open source aurait un impact particulier sur le fonctionnement de l’OS.

    • On peut penser que des drivers open source permettrait d’être plus efficace vu que libhybris sert d’intermédiaire entre les drivers d’android et l’OS.

      • on peur surtout réaliser que l’on aurait plus besoin de LibHydris, vu que du coup, les drivers seraient directement compilé pour le Kernel et donc encore plus performant …
        Mais on peut aussi voir le problème dans l’autre sens : Comme la LibHydris sait utiliser des drivers Android (plus attachés à VM dalvik qu’au kernel linux),on a là le début d’un process pour écrire des drivers « indépendant » de la version du Kernel, ce qui pourrait être le Graal de ceux qui prônent le « du moment que ça marche ». Certes insatisfaisant, mais qui garantiraient la pérennité » de tous ces vieux truc abandonnés, même par le kernel linux …Il y-a là une piste qu’il serait sot de ne pas explorer.
        Le fin du fin serait que les constructeur livrent des drivers « LibHydris compliant », et qui tournent sous Android. Mais là il faut carrément monter une fondation pour écrire et stabiliser des spec LibHydris, maintenir et développer la lib, et démarcher les constructeurs … Et convaincre Google d’être LibHydris Friendly 😉

        • @bandix400 !
          Merci beaucoup pour vos éclairages ; car, pas facile de rendre compréhensibles des points techniques ! Merci aussi à @Nicolas SUFFYS qui a initié la discussion sur ce (ces) point. Les matelots savent désormais dans quelles directions vogue le Bateau Sailfish OS !

          Cldt

    • « Par contre, fournir un code source pas forcément parfaitement abouti, c’est aussi vite contre-productif.  »
      Il ne faut pas être aussi catégorique ; regarde le cas microsoft, lorsqu’il a voulu intégrer dans le Kernel linux le support de son hyperviseur : son code était si pourri et ses pratiques si désinvoltes, limites arrogantes qu’il à du s’y reprendre à plus de 120 fois pour faire accepter son patch (ce trimestre là M$ fut le plus gros contributeur, pour son un seul patch, du kernel linux) ; finalement grace à la communauté kernel-linux, les développeurs M$ ont appris à coder proprement, découvert comment on écrivait un driver stable, et l’humilité … Le bilan est plutôt positif, ne trouves tu pas ?

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

*