Concours de développement autour de SourceSquare

Posté par (page perso) . Édité par Florent Zara, NeoX et Benoît Sibaud. Modéré par patrick_g. Licence CC by-sa
Tags :
9
29
mai
2012
Communauté

Nous avons déjà parlé de SourceSquare précedemment sur LinuxFr.org. Pour rappel, il s'agit d'un logiciel sous licence AGPLv3 permettant de scanner un répertoire de son disque dur pour identifier les composants Open Source présents, en se servant de la base Antepedia en back-office.
Logo SourceSquare
Antelink lance un concours de développement autour de SourceSquare afin d'inciter le fork (le projet est sur GitHub) et d'aider à son adoption et intégration par les projets. En effet, le but de concours est de développer un greffon reliant SourceSquare à des outils de développement ou d'intégration continue type Jenkins/Hudson, Sonar, Bamboo, Eclipse ou encore IntelliJ, mais d'autres sont envisageables.

Plus de détails dans la suite de la dépêche

Bon codage !

Parmi les autres principes, le greffon doit être sous une licence reconnue par l'OSI, hébergé sur GitHub, SourceForge ou Google Code. Aucune cession de droit n'est demandée. Le gagnant est choisi par un jury externe à l'organisateur. Par contre, là où le bas blesse un peu, c'est le prix pour le gagnant : un iPad 3 :-( Une fois entre vos mains, vous pourrez toujours enfermer le revendre à un Apple fanboy qui ne l'aurait pas encore et faire un don à votre projet libre préféré. Et si vous ne pouvez ou voulez pas choisir un projet, il reste toujours l'option des associations qui défendent votre liberté : le « Pack Liberté » n'est plus, mais l'April, Framasoft et la Quadrature du Net ont toujours besoin de votre soutien ! Mise à jour (30 mai) : a priori, l'iPad pourra être transformé en tablette Android à la discrétion du gagnant.

Pour terminer sur les détails pratiques, la date limite de soumission est le 15 juin, mais à priori, quelques jours de codage devraient suffire étant donné que le code de SourceSquare n'est pas volumineux et que beaucoup d'outils cibles proposent des API publiques généralement bien documentées.

Enfin, sachez que le code LinuxFr.org a enfin été intégré dans la base d'Antepedia.

  • # Défendez-vous contre la contamination du logiciel libre.

    Posté par . Évalué à 0.

    Our solutions enable our customers to reduce software development costs, limit the legal risks linked to the use of open source components, and secure their applications.
    
    

    Vu sur le site de l'entreprise Antelink (à l'origine d'Antelink et SourceSquare).

    • [^] # Re: Défendez-vous contre la contamination du logiciel libre.

      Posté par . Évalué à 1.

      Personnellement, je trouve que l'open source contaminant c'est très bien. Source Square est sous AGPL V3, donc contaminant :-)

      • [^] # Re: Défendez-vous contre la contamination du logiciel libre.

        Posté par . Évalué à 1.

        Je ne dis pas si c'est bien ou mal, je dis juste que cette entreprise vent son produit comme un moyen de se défendre du logiciel libre.

        • [^] # Re: Défendez-vous contre la contamination du logiciel libre.

          Posté par . Évalué à 1.

          Intéressant. Il y a probablement des clients de ce type d'outils qui cherchent à s'assurer qu'il n'y a pas d'open source dans leur code. Mais la plupart, et ceux d'Antelink en tout cas ;-), cherchent plutôt à respecter les obligations du logiciel libre dont ils sont les premiers à vanter les qualités. Je vois plutôt ces outils comme un moyen de défendre le logiciel libre.

          • [^] # Re: Vaccinez-vous contre les licences du logiciel propriétaire

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

            un message plus exact serait de bénéficier des vaccins (que l'on choisit de s'inoculer) proposés par le logiciel libre, plutôt que de jouer sur du FUD (il n'y a pas de contamination dans le libre : les licences sont mêmes souvent dans le code source, il y aurait contamination si c'était à l'insu du développeur ou que les conditions changeaient après coup ; le développeur choisit son code, la licence vient avec, c'est transparent).

            Il est tout de même plus simple de s'y retrouver dans les licences du libre qui sont peu ou prou unifiées (avec 2 grandes familles on va dire), plutôt que dans les licences à foison du logiciel propriétaire, qui changent souvent d'une version à l'autre. Dans les deux cas, les licences doivent être gérées, cela me semble plus simple dans le libre pour autant ;-) (moins de lourdeur contractuelle notamment).

        • [^] # Re: Défendez-vous contre la contamination du logiciel libre.

          Posté par (page perso) . Évalué à 3. Dernière modification le 31/05/12 à 00:22.

          Personnellement, je ne pense pas que ce soit le cas, ou alors c'est vraiment restreindre son marché et ne voir qu'une toute petite partie du problème comme tu sembles le faire.

          Même pour quelqu'un développant un logiciel sous licence libre, la compatibilité des licences Open Source/libre entre elles peut tourner au cauchemar. En fonction de la licence sous laquelle tu distribues ton projet, tu ne pourras pas forcément réutiliser du code open source sous une autre licence incompatible. Et réciproquement, les composants que tu réutilises peuvent fortement conditionner le choix de ta licence. Voici un post pris (presque) au hasard sur StackOverflow d'un développeur libriste dans ce cas.

          Pour te donner une (petite) idée du problème,

          • même les licences les plus connues du projet GNU (et juste elles) ont de fortes incompatibilités (cf. le schéma) entre elles : par exemple, la GPLv2 n'est pas directement compatible avec la v3.
          • Apache consacre une page à la compatibilité avec la GPL
          • quand on recherche la compatibilité entre licences, on arrive toujours à trouver une réponse (ou à peu près) dès que cette compatibilité concerne la GPL. Après, ca devient du sport de haut niveau ! Qu'en est-il de la compatibilité de la MPL avec l'EPL, avec l'Apache v2 ? avec l'EuPL, avec CeciLL ? etc, Doctorat de droit requis, avec options droit international, droit de la PI et art divinatoires indispensables
          • certains projets changent de licence avec des implications non négligeables. pas la peine de chercher plus loin que Samba qui est passé de la GPLv2 à la v3 .

          Mais d'ailleurs, que veut dire compatible ?

          Le cas est tout aussi valable pour les industriels qui souhaitent réutiliser, modifier, distribuer du code libre. Avec toute la meilleure volonté du monde, ils pourraient tout de même se retrouver dans un imbriglio concernant la compatibilité des licences. On en arrive à faire des architectures juridiques… Certains ont déjà du mal à avoir un état des lieux à peu près précis de leurs applications en interne, alors imagine le fait d'avoir à maintenir une base de composants FLOSS utilisés, où, dans quel contexte, distribués ou non, dans quelle version, quelle licence applicable, etc. Et ensuite de déterminer les actions à entreprendre pour être en conformité avec les licences : mettre à disposition le code source (sous quelle forme ? où ? etc.), inclure les mentions légales (pareil : sous quelle forme ? où ? etc.), etc.

          De la même manière qu'il existe des outils d'aide à l'analyse et la revue de code pour les aspects de qualité, performance, sécurité, etc., ce type de base (Antepédia) et d'outils (Antelink, Blackduck, Palamida, Protecode, etc.) permettent d'aider à gérer les problématiques liées aux licences FLOSS et justement profiter du libre tout en le respectant.

          Deux lectures que je conseille :

Suivre le flux des commentaires

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