Suport technique et veille technologique
Aujourd’hui, les grandes entreprises et administrations publiques hésitent entre continuer à utiliser des logiciels propriétaires ou basculer vers les Logiciels Libres. Pourtant, la plupart des logiciels libres sont capables de bien traiter les données issues des logiciels propriétaire, et parfois avec une meilleur compatibilité.
C’est alors la barrière de la prise en main qui fait peur, et pourtant...
Les logiciels libres
L’aspect « Logiciel Libre » permet une évolution rapide et une plus grande participation des utilisateurs. Les aides et tutoriels foisonnent sur Internet ou sont directement inclus dans le logiciel lui-même.
Enfin, les concepteurs sont plus proches des utilisateurs, ce qui rend les logiciels libres plus agréable à utiliser et conviviaux.
Grâce à la disponibilité des logiciels libres, vous trouverez facilement des services de support techniques et la licence n’est plus un frein à l’utilisation de ces logiciels par votre personnel.
Notre support technique concerne essentiellement les logiciels libres, que ce soit sous forme de services ponctuels ou de tutoriels.
- Février 2020 -
Une fois les droits de publication, et de modification, offerts
par le(s) auteur(s) d'un RFC à l'IETF trust, quels droits ce
dernier va-t-il transmettre aux lecteurs et lectrices d'un RFC ? Le RFC 5378 spécifie les droits « entrants » à
l'IETF trust, et notre RFC 8721
spécifie les droits sortants : que puis-je faire avec un RFC ?
Ai-je le droit de le lire ? De le redistribuer ? De le
traduire ? Ce RFC est une légère modification du RFC 5377, qu'il remplace. Le but de cette modification était
de s'adapter à la nouvelle structure administrative de
l'IETF, décrite dans le RFC 8711. Notamment, l'ancien IAOC (RFC 4071) disparait.
La section 1 du RFC rappelle un point important : c'est
l'IETF trust qui décide. Le RFC 8721, publié par l'IETF, n'est qu'indicatif et ne fixe que des
grands principes. Le texte exact de la licence des RFC est écrit
par l'IETF trust (http://trustee.ietf.org/license-info/
et il existe aussi
une FAQ sur
ces textes.) La section 2 revient d'ailleurs sur les raisons de ce
choix (pouvoir s'adapter aux changements légaux aux ÉUA, pays de
l'IETF trust et de l'ISOC).
On pourra trouver ce texte standard, ce
boilerplate, sur le site du
Trust dans la Trust Legal Provisions.
La section 2 du RFC décrit les buts que suit l'IETF en publiant
des RFC (cf. RFC 3935). Clairement, l'élaboration d'une
licence doit se faire en gardant ces buts à l'esprit : faire
fonctionner l'Internet le mieux possible, notamment en assurant
l'interopérabilité des mises en œuvres des protocoles
TCP/IP.
La section 3 explique l'articulation de ce RFC avec le RFC 5378 : les droits sortants (ceux que
l'IETF trust accorde aux utilisateurs) doivent
être inférieurs ou égaux aux droits entrants (ceux que l'auteur a
accordé à l'IETF trust). Autrement dit, l'IETF
ne peut pas donner de droits qu'elle n'a pas. Si l'auteur d'un RFC
interdit toute modification à son texte, le RFC publié ne
permettra pas de modifications (et ne pourra d'ailleurs pas être
publié sur le chemin des normes).
La section 4 s'attaque aux droits que l'IETF
trust devrait donner aux utilisateurs :
- Droit de publier et de republier (section 4.1), une très
ancienne politique de l'IETF,
- Droit (évidemment) d'implémenter la
technique décrite dans le RFC (section 4.3). C'est ici qu'apparait
la distinction entre code et texte. (Le code inclut également le
XML, l'ASN.1, etc.) Par un mécanisme non spécifié
dans le RFC (cela a été choisi par la suite comme une liste
publiée par l'IETF trust), le code est marqué
spécialement (entre
et
, comme défini dans la Trust
Legal Provisions) et l'implémenteur aura davantage de droits sur le
code, notamment le droit de modification. Cela ne résout pas, et
de loin, tous les problèmes. Par exemple, cela ne permet pas de
modifier du texte d'un RFC qui est inclus dans la documentation
d'un logiciel.
- Droit de modifier le texte ? Non, ce droit est exclu par la
section 4.4, en tout cas pour le texte (le code inclus dans les
RFC reste modifiable, pour permettre son intégration dans des
logiciels
libres.)
Comme indiqué plus haut, il n'y a pas de changements de fond
depuis le RFC 5377, uniquement la
suppression des références à l'ancien IAOC (IETF Administrative Oversight Committee).
RFC 9562: Universally Unique IDentifiers (UUIDs)
- 12 mai -
Ce RFC normalise les UUID, une famille d'identificateurs uniques, obtenus sans registre central. Il remplace l'ancienne norme, le RFC 4122, avec (...)
RFC 9490: Report from the IAB Workshop on Management Techniques in Encrypted Networks (M-TEN)
- 9 mai -
Aujourd'hui, l'essentiel du trafic sur l'Internet est chiffré, et pour d'excellentes raisons. Pas question de revenir là-dessus, mais, ceci dit, il (...)
RFC 9557: Date and Time on the Internet: Timestamps with Additional Information
- 29 avril -
Ce RFC modifie légèrement le format des estampilles temporelles du RFC 3339, changeant à la marge une définition et, surtout, permettant d'y attacher (...)
RFC 9567: DNS Error Reporting
- 27 avril -
Lorsqu'un résolveur DNS détecte un problème avec une zone, l'empêchant de résoudre les noms dans cette zone, il n'avait pas de moyen simple et (...)
RFC 9460: Service Binding and Parameter Specification via the DNS (SVCB and HTTPS Resource Records)
- 8 avril -
Ces deux nouveaux types d'enregistrement DNS, SVCB et sa variante HTTPS, permettent de donner des informations supplémentaires à un client réseau (...)