Les critères utilisés renvoient à quatre types de libertés pour les utilisateurs du logiciel :
Ceci est de RichardStallman, qui a créé le GnuProject quand son modèle pour l'informatique collaborative --le MitAiLab (cf. IncompatibleTimesharingSystem)--a perdu ses meilleurs programmeurs pour l'industrie, et que des systèmes fermés "non-réparables" ont commencé à remplacer des systèmes ouverts "réparables".
La FreeSoftwareFoundation maintient une liste intéressante de licences pour les logiciels, incluant des commentaires :
"Je peux décrire l'idée du logiciel libre en trois mots :"
Richard Stallman, Extrait d'une conférence à l'université de Paris 8 (novembre 1998)
Contributeurs : SunirShah, CliffordAdams, AlexSchroeder. Traduction en cours : ChristopheDucamp (merci de réviser cette version sur FreeSoftware seul lien de référence)
Il existe certainement une distinction entre les deux groupes, et ce n'est pas simplement Stallman et la FSF sur la "pure" dimension LogicielLibre.
La licence actuelle BSD est surtout du LogicielLibre. Du point de vue de Stallman, elle ne protège pas solidement les liberté comme le fait la GPL, mais elle certainement libre dans la forme pure BSD. Le problème que certaines personnes ont avec la licence BSD est qu'elle permet des descendants non libres et des variantes du code original libre. Par exemple, un vendeur pourrait prendre un des systèmes Unix licenciés BSD, le modifier légèrement et le ressortir sous une licence propriétaire complètement fermée (par ex pas de CopyLeft). Un problème encore plus grave est que les personnes pourraient contribuer à des extensions et de nouvelles fonctionnalités sous des licences semi-fermées ou non claires, menant à de plus en plus de restrictions sur le code.
D'un autre côté, parfois la "pureté" des visions de Stalllman (et la politique FSF qui est actuellement en accord avec elles) engendre des problèmes avec plus de gens "pragmatiques" disposés à accepter des systèmes moins-que-totalement "libres". Des conflits récents ont concerné le projet de bureau KDE et la licence du langage Python. L'exemple Python est un bon -- le seul conflit-GPL est que la licence dit que toute action légale sur Python doit être prise dans le contexte de la loi de Virginie (USA). Pour la plupart des gens, c'est une interprétation parfaitement acceptable, qui pourrait probablement éviter des problèmes comme les auteurs étant poursuivis sous des systèmes légaux russes, chinois ou sud-africains. Pour la FSF, la licence Python installerait un mauvais précédent, menant possiblement à beaucoup d'autres restrictions apparemment innocentes, et pour conclure à plus de restrictions substantielles.
Il y a quelques années, j'ai été temporairement impliqué dans un de ces conflits : les discussions sur le RIPEM/GMP/free-MP. L'auteur du système de cryptage d'e-mail RIPEM a sorti son code avec la seule restriction étant que l'utilisateur devait être d'accord pour supporter les lois de contrôle à l'exportation (qui étaient prises très au sérieux dans les années 1990). Son programme utilisait la librairie GNU Multi-Precision pour accélérer énorméent la vitesse des grands nombres de calculs demandés par le programme. Pour résumer une longue discussion, la FSF croyait (et croit encore) que les principes du logiciel libre sont plus importants que la disponibilité réelle de logiciels de cryptographie. (Cela semblait plus important du temps de propositions du comme le ClipperChip? ou même la régulation gouvernementale de toute la cryptographie. Les batailles ne sont même pas encore terminées à cette heure). Ce fût le moment où je divergeais avec la FSF.
Même aujourd'hui, j'ai toujours des sentiments très mitigés à propos de la GPL et des moyens du FSF de sécuriser le logiciel libre. Sur beaucoup de points, la FSF a fourni un grand service, particulièrement en rationalisant un énorme micèmace des licences ""libres" en concurrence. Par exemple, vers la fin des années 80 et au début des années 90 il y avait beaucoup de programmes publiés sous des licences "anti-commerciales", qui ont permis l'utilisation libre, mais interdisait tous les types d'utilisations "commerciales" (ou profitables) du programme. J'ai travaillé sur la famille du lecteur de nouvelles UseNet "rn/trn/strn" qui a été gênée avec une telle licence Aujourd'hui même , elle n'est pas incluse dans les principales distributions "libres" d'Unix (par défaut), partiellement en raison de sa licence non-libre. Dans d'autres cas les actions de la FSF ont été importantes par l'ouverture de grandes quantités de code qui auraient été sinon fermées au GPL.
D'un autre côté, j'ai licencié à contrecoeur le moteur UseModWiki sous la GPL. (J'ai même essayé d'utiliser la LGPL moins restrictive, mais la licence LGPL ne colle pas très bien avec les langages de "scripting" languages qui ne sont pas des librairies liées). Ma préférence aurait été de mettre UseModWiki sous une double licence avec une version principale GPL et une alternative BSD-like pour toutes les exceptions qui en vaudraient la peine. Parce que les dérivatifs des legs GPL sont à moins de 10% du UseModWiki, je peux même récrire ces sections un de ces jours. --CliffordAdams
Les personnes qui prennent du code sous licence BSD et le transforment en produits propriétaires n'est pas qu'une théorie - cela arrive régulièrement. Les personnes ne faisant simplement que poser des questions sur la liste OpenBSD le font tout à fait régulièrement. Que vous pensiez que ce soit mal, ou tout autre bienfait des problèmes plus importants que cela puisse provoquer est la raison de choisir une licence par rapport à une autre. Je pense que Theo et le reste de l'équipe d'OpenBSD veulent rendre le logiciel sécurisé possible - et pensent que rendre les leurs disponibles comme un bloc de construction pour la fermeture et les systèmes commerciaux sont un bon moyen pour faire cela. D'autres personnes pourraient être désolées si elles voyaient leur code (qu'elles ont essentiellement donné) utilisé pour produire beaucoup d'argent pour quelqu'un d'autre (fréquemment sans quelque sorte d'attribution). Personnellement, j'ai une préférence pour la GPL - si je fais quelque chose d'"ouvert", j'aimerais continuer à le faire en ce sens. Cependant, la LGPL semble offrir cela, sans être tout à fait aussi "sticky". Tout dépend probablement de la nature du logiciel que vous êtes en train de distribuer. --ErikDeBill
L'expression est un raccourci établi parmi la communauté du logiciel libre pour opérer la distinction :
Le terme "free beer" à une dette en quelque chose, peut-être à la farce que la bande qui s'appelait elle-même "Free Beer" pour pour le "marquee appeal" du nom. I've certainly been at parties where the beer was free to at least *some* of the people attending--I filled plastic Dixie cups, wrestled kegs, and changed the taps at a few, even.
The kicker of this term is that, though it's OK to sweeten the offer a little, you don't want to attract people who are only there for free drinks (or canapes, for the more highbrow). Conversely, if you are going to an event just because they are handing out goodies, then you're interest is otherwise shallow to non-existent.
"The continued freedom to create and use free software is always in danger. Unfortunately, some interests seem to use the tragic events of September 11, 2001 as an excuse for wide-ranging infringement on civil liberties, some of which may threaten the very ability to create free software at all." - from http://kernel.org