L'accord à l'amiable entre BSDi et USL (AT&T) enfin public.

Posté par  . Modéré par Mouns.
Étiquettes :
0
29
nov.
2004
FreeBSD
Excellente nouvelle ! Un internaute du nom de D. Burns a obtenu légalement une copie de cet accord secret conclu en 1994, qui concluait la guerre juridique entre AT&T et Berkeley.

Copie et commentaires sont disponibles sur le site de Groklaw.

En 1994, USL (un successeur d'AT&T pour les droits d'Unix) et BSDi (une entreprise/laboratoire de l'université de Californie/Berkeley) finissaient leur procès-marathon sur les droits concernant BSD et Unix par un accord à l'amiable.

L'une des caractéristiques majeures de cet accord était le secret l'entourant, aucune des parties n'ayant le droit de le publier ni le commenter. Le public ne pouvait donc pas savoir quelle était la situation légale exacte du code contenu dans FreeBSD, par exemple. On supposait jusqu'alors que les "copyrights" de la plupart des lignes de code appartenaient à Berkeley, et étaient sous licence libre BSD, mais certains doutes demeuraient. Cette incertitude est sans doute l'un des facteurs ayant favorisé l'éclosion de Linux, bien plus indépendant du code d'AT&T.

Grâce à une loi californienne spécifique (Public Records Law), un internaute américain a réussi à obtenir en toute légalité une copie de cet accord, et l'a mise en ligne.

La publication de cet accord lève enfin un voile sur cette affaire scabreuse. L'université de Californie/Berkeley est largement disculpée, a le droit de distribuer son code et de permettre sa redistribution sous licence libre. On apprécie par exemple : "USL agrees that it shall take no action based on the use or distribution by any person of material contained in the Unrestricted Files".

Nul doute aussi qu'il y aura une incidence sur les autres procès majeurs autour de The SCO Group. Les termes de l'accord à l'amiable s'appliquent en effet aux successeurs d'AT&T pour les "droits" d'Unix. À supposer qu'il y ait du code Unix dans Linux (et que TSG en soit vraiment le propriétaire), il faudrait ensuite démontrer qu'il s'agit de code "non-BSD", dont la redistribution est autorisée. Or, il y aurait plus de 50% de code BSD dans Unix...

Ceci explique aussi la propension de TSG à n'attaquer que les entreprises qui ont signé un contrat avec eux, les autres étant largement couvertes par l'accord à l'amiable.

Aller plus loin

  • # Argl

    Posté par  . Évalué à 8.

    Quelqu'un peut faire une analyse (encore) plus compréhensible pour moi SVP ?

    Mon cerveau fait dans les 700cm³...
    • [^] # Re: Argl

      Posté par  . Évalué à 5.

      Je dois avouer également que malgré l'effort du rédacteur et des modérateurs, ça n'est pas très clair pour moi non plus... si j'ai bien compris, AT&T détenait des droits sur UNIX et voulait les faire jouer dans un procès contre Berkeley (qui avait créé BSDi ?), procès qui s'est achevé en 1994 sur un accord amiable dont on nous dévoile aujourd'hui les arcanes. C'est bien ça ?

      Si oui, je ne comprends pas le lien avec Free/Open/Net BSD, et par extension Linux. Tous ces projets sont issus de BSDi ? Et si oui, reste-t-il trois lignes de code identiques ? Est-ce que ça touche la licence BSD (a priori non mais bon mieux vaut demander :)

      Merci.
      • [^] # Re: Argl

        Posté par  . Évalué à 5.

        Pour ceux qui veulent un peu apercevoir le bordel qu'est l'histoire d'Unix & des dérivés un ch'tit coup d'oeil à : http://www.levenez.com/unix/(...)
      • [^] # Re: Argl

        Posté par  . Évalué à 10.

        Ce sont des questions pas simples à répondre :-((

        Pour autant que je me souvienne : UNIX vient d'AT&T (ou des Bell Labs, puis est passé sous contrôle d'AT&T). Dans les années 80, AT&T a donné pas mal de licences et encouragé les différentes versions de Unix, articulées autour d'un standard.

        L'université de Californie/Berkeley a crée sa propre version, avec le nom générique BSD (Berkeley Software Distribution). De là viennent les dérivés BSD Net2 (l'objet du procès), 386 BSD, FreeBSD, NetBSD, OpenBSD, etc... L'université avait "incubé" BSDi pour s'occuper de la commercialisation de BSD.

        Ils ont distribué BSD Net2 sous licence libre et gratuite BSD. Ils se sont permis cela car BSD Net/2 avait fait l'objet d'une réécriture complète, en comparaison des versions précédentes, qui avaient toutes encore du code original de AT&T.
        Avant BSD Net/2, pour utiliser un BSD, il fallait en gros avoir une licence de BSD + une licence d'AT&T pour Unix (gratuite pour l'éducation, je crois). La même chose valait pour les Unix commerciaux, sauf qu'en général, le prix de la licence AT&T était inclus dans celui de ta licence AIX/HPUX/Solaris/etc...

        AT&T (ou sa filiale USL) étaient encore propriétaires des divers droits sur Unix début des années 1990, et n'ont pas vu d'un bon oeil l'émergence de BSD Net2, OS compatible Unix, et sans licence AT&T obligatoire. Cela signifiait la fin de leur "Business Modell".

        Réaction : procès, sur divers thèmes (vol de code, violation de Trademark, etc...).

        Résultat : on découvre que AT&T Unix a beaucoup beaucoup plus emprunté à BSD que l'inverse, et aurait en plus effacé les copyrights de Berkeley, etc...

        Conclusion : AT&T se dépêche d'acheter le silence de BSDi et des Regents of the University of California - Berkeley, par ce fameux accord à l'amiable. 3 fichiers seront supprimés de BSD : on peut supposer que ce sont les seuls "oublis" de BSD Net2 dans leur réécriture. Comparés aux milliers de fichiers "volés" par AT&T... Oui, le silence est d'or.

        Le procès aura duré quelques années, endommagé l'image de BSD, fait peur aux utilisateurs et développeurs, et retardé le développement des divers BSD libres. Toute la force du FUD, quoi. Mais en 1994, il y a une alternative complètement indépendante du code d'AT&T qui pointe le bout de son nez : Linux !


        Pour tes questions du 2ème paragraphe :les *BSD sont des dérivés directs ou indirects des productions de Berkeley. Linux a très probablement des portions de code *BSD modifiées ici et là. Les divers produits ont tous du code trivial semblabe (lignes avec #include, #define, for(;;), etc..), ou tiré de livres de référence.

        La licence BSD est une licence. Elle n'est pas touchée car elle est indépendante du code. Tu peux utiliser cette licence pour ton code autant que tu veux. Le seul problème, c'était si BSDi avait le droit de publier du code (qu'AT&T pretendait sien) sous cette licence. L'accord à l'amiable répond positivement à cette question.
        • [^] # Re: Argl

          Posté par  (site web personnel) . Évalué à 4.

          Bravo pour ce magnifique résumé. Peut-être est-ce aussi le bon endroit pour rapeller l'existence du site d'Eric Lévénez qui fait référence en matière de généalogie Unixienne:
          http://www.levenez.com/unix/(...)
          En plus du célèbre poster et d'une liste impressionnante d'Unix exotiques plus inconnus les uns que les autres, on peut aussi y trouver de nombreux liens forts interessants dont certains traitent justement des différents procès en cours. Parmi les liens, celui-ci qui non seulement retrace l'hitorique de cette affaire, et termine en mentionnant Burns et Groklaw: la boucle est bouclée.
          http://cm.bell-labs.com/cm/cs/who/dmr/bsdi/bsdisuit.html(...)
          • [^] # Re: Argl

            Posté par  . Évalué à 3.

            Le lien était dans le commentaire de gabuzo juste avant le mien.

            Sinon, ya plein d'erreurs et d'approximations, mais j'ai pas le temps d'écrire un roman de 500 pages avec 2000 pages d'annexes et de références. ;-)
            • [^] # Re: Argl

              Posté par  (site web personnel) . Évalué à 3.

              > Le lien était dans le commentaire de gabuzo juste avant le mien.

              Oups, m'en vais demander trois pâtés et un aber à mon ophtalmo. :)

              > mais j'ai pas le temps d'écrire un roman de 500 pages avec 2000 pages d'annexes et de références.

              D'autant qu'il faudrait en faire un deuxième tome d'ici quelques années avec les évolutions prévisibles et la disparition annoncée de quelques ténors...
    • [^] # Re: Argl

      Posté par  . Évalué à 10.

      Un internaute a récuperé les accords entre AT&T et BSD sur la licence Unix, et ca dit (long suspense pour les BSDistes qui n'avaient pas accés au rapport de ce jugement , d'ou l'actualité) que BSD a le droit d'utiliser son code.


      Savoir que TSG == The Sco Group : (a quand un div pour les acronymes sur linuxfr ?)


      La deuxieme bonne nouvelle c'est que ca affaiblit aussi les arguments de SCO :

      Avec des patates ca serait clair, enfin bon : si SCO arrive à montrer qu'il y a bien une partie de son code dans linux il faudra verifier que cette partie ne se retrouve pas aussi dans BSD puisque (c'est le but de la news) cette partie est libre, justement ...
      • [^] # Re: Argl

        Posté par  (site web personnel) . Évalué à 3.

        A noter que le site sur lequel l'accord est rendu public est groklaw, LE site qui suit les développement de l'affaire SCO vs /.*/ (IBM, Red hat, Autozone, Daimler Chrisler, etc...) et commente aussi les sujets d'actus en rapport avec le libre (brevets logiciels, propriété intellectuelle, Microsoft, Sun, etc...)

        Si vous n'etes pas anglophobes, bien sur, car c'est tout en anglais.
        • [^] # Re: Argl

          Posté par  (site web personnel) . Évalué à 2.

          … et si vous êtes anglophobes, des traducs sont disponibles sur [http://frenchgroklaw.net/(...)] (enfin, étaient, car là je viens d'y aller et le site semble temporairement suspendu par l'hébergeur, bande passante dépassée je suppose). Précisons que si je me souviens bien, c'est un Canadien qui fait ça, d'où des traductions peut-être un poil exotiques parfois.

          Envoyé depuis mon PDP 11/70

  • # Sigles

    Posté par  (site web personnel) . Évalué à 9.

    Ce serait bien que l'article se termine par une liste de définitions des sigles.
    TSG = ?
    USL = ?
    • [^] # Re: Sigles

      Posté par  (site web personnel, Mastodon) . Évalué à 10.

      TSG = The SCO Group
      USL = Unix System Laboratories (détenteurs des droits UNIX plus tard acheté par Novell puis objet d'une transaction avec SCO)

      Ne m'en demandez pas plus :)
      • [^] # Re: Sigles

        Posté par  . Évalué à 2.

        mettre juste SCO aurait été plus clair que TSG je pense
        • [^] # Re: Sigles

          Posté par  . Évalué à 10.

          Je n'aime pas particulièrement le terme "SCO", car il prête à confusion. Il y avait une entreprise qui s'appellait Santa Cruz Operation (SCO, parfois appelée OldSCO sur le net) qui éditait SCO Unix, et qui l'a revendu avec certains droits à Caldera, avant de se renommer Tarentella.

          Caldera s'est renommée The SCO Group (TSG) Inc, avec abbréviation SCOX à Wall Street.

          La confusion est apparemment voulue par TSG. Quand on dit, par exemple, "SCO a acheté xxxx en 1996", ca fait référence à OldSCO. Ca ne veut pas dire que TSG en est l'actuel propriétaire, mais ils ont le plaisir de faire comme si. Ca embrouille les journalistes, les analystes, le public, et avec un peu de chance les avocats adverses et les juges aussi.
          De même, peu ont fait la relation entre TSG et Caldera, qui, notoirement, distribuait Linux il y a quelques années.

          Bref, la précision s'impose, et il faut éliminer une à une toutes les incertitudes. Seulement comme ca, on fera la lumière.
          • [^] # Caldera

            Posté par  . Évalué à 4.

            Je me rappelle d'un troll sur linuxfr lorsque Caldera attaquait déjà la GPL en 2001 :
            Pour son P-DG, Ransom Love, la philosophie de la GPL constitue un frein à l'activité économique de l'entreprise. « Microsoft a attaqué le principe de la source ouverte sur son point le plus faible : la GPL », affirmait Love lors d'un entretien avec l'hebdomadaire eWeek..

            Et Stallman de répondre : Caldera n'est pas du tout une entreprise du logiciel libre. C'est juste un parasite.

            http://linuxfr.org/2001/10/30/5702.html(...)
            http://mon.zdnet.fr/actualites/business/0,39020715,2088227,00.htm(...)

            Avec le recul des évenements récents certains doivent certainement le trouver tout d'un coup moins "intégriste anarcho-stalino-communniste" notre barbu ...
  • # Précisions

    Posté par  . Évalué à 4.

    Article sur BSD:
    http://en.wikipedia.org/wiki/Berkeley_Software_Distribution(...)

    Article sur les poursuites en question:
    http://en.wikipedia.org/wiki/USL_v._BSDi(...)

    Bon c'est en anglais mais ça peut aider à y voir clair.
  • # Jurisprudence ?

    Posté par  (site web personnel) . Évalué à 6.

    Il est dit dans l'article :
    "Nul doute aussi qu'il y aura une incidence sur les autres procès majeurs autour de The SCO Group. Les termes de l'accord à l'amiable s'appliquent en effet aux successeurs d'AT&T pour les "droits" d'Unix."

    Est-ce que un accord à l'amiable compte comme un jugement (même si là il semble que ce fut jugé comme un accord à l'amiable) ?

    Et si c'est un jugement qui dit que BSD détient légalement les droits sur ses lignes de codes, est-ce que cela pourra servir de "jurisprudence" pour les procés contre SCO ?

    Et est-ce correct d'employer le terme jurisprudence dans ce cas ?

    De toute facons, si cet accort secret pouvait servir dans le procés "SCO IBM truc machin", c'est étonant que les avocats ne se le soit pas procurés comme un simple citoyen le pouvait.
    • [^] # Re: Jurisprudence ?

      Posté par  . Évalué à 3.

      Pas besoin que cela compte comme un jugement : cet accord stipule que l'universite de Berkely pouvait redistribuer le code sous licence libre (de la meme facon qu'aucun jugement n'est necessaire pour qu'un developpeur redistribue son code sous GPL, BSD ou autre licence). Au yeux de la loi ca a valeur de licence d'utilisation comme n'importe quelle autre licence.
      Maintenant SCO pourrait essayer d'attaquer cet accord, mais il faudrait demontrer que les termes de cet accord etaient illegaux, et c'est tres peu probable.
    • [^] # Re: Jurisprudence ?

      Posté par  . Évalué à 2.

      > Est-ce que un accord à l'amiable compte comme un jugement

      non

      puisque du point de vue de la justice ce qui figure dans le jugement c'est : " affaire classée suite a accord amiable entre les parties" .

      La justice n'a pas a savoir ce que contient l'accord et elle ne le sait pas. Donc elle ne peut pas en faire une jurisprudence.

      C'est seulement si quelqu'un avait contesté cet accord amiable que la justice aurait eu connaissance de son contenu.
      • [^] # Re: Jurisprudence ?

        Posté par  . Évalué à 3.

        La justice n'a pas a savoir ce que contient l'accord et elle ne le sait pas. Donc elle ne peut pas en faire une jurisprudence.

        En fait si, la justice a accès à ce texte et c'ets même comme celà que Groklaw a pu avoir accès à celui ci. En fait l'accord n'engage bien que les deux parties qui l'ont passé (il ne peut pas avoir valeur de jurisprudence en effet puisque ce n'est pas une décision de justice), il n'en reste pas moins que c'est un acte de justice tout à fait valable et qu'il peut servir de référence dans d'autres procés (même si le but premier des dits autres procès n'est pas de contester la valeur de l'accord).

        En fait SCO qui à peut-être racheté les droits Unix est tenu à cet accord légalement et ne peut s'en défaire. Maintenant qu'il a été rendu public IBM peut parfaitement se défendre contre SCO en utilisant les articles de cet accord comme référence.
        • [^] # Re: Jurisprudence ?

          Posté par  (site web personnel) . Évalué à 6.

          > En fait si, la justice a accès à ce texte et c'ets même comme celà que Groklaw a pu avoir accès à celui ci.

          Non, le lecteur de GL l'a demandé aux avocats de l'UCB qui ne l'avaient pas transmis à la Cour (« the confidential 1994 settlement agreement […] was not filed with the court »). Il a été demandé en accord avec le California Public Records Act, et je pense qu'il l'a obtenu parce que l'UC est une institution publique, donc soumise à cette loi (« The University of California shall constitute a public trust […] », [http://universityofcalifornia.edu/regents/bylaws/bl5.html(...)]).

          > c'est un acte de justice tout à fait valable

          À la base, c'est surtout un contrat où les parties affirment qu'elles arrêtent de se mettre sur la gueule si chacun y met du sien (efface/corrige les fichiers qui posent problème). Ce n'est pas comme un jugement qui, une fois entériné en appel, ne peut plus être discuté.

          > il peut servir de référence dans d'autres procés

          Ça oui, certainement. En fait, c'est, je pense, la seule raison qu'on ait de mettre des trucs par écrit : avoir quelque chose de tangible à montrer à un juge lorsque ça se passe mal.

          > En fait SCO […] à peut-être racheté les droits Unix

          Il faudrait déjà savoir ce que SCO/Caldera a racheté. Novell pense qu'ils ont surtout racheté le droit d'encaisser les royalties sur Unix (à condition d'en reverser une partie), et le cas échéant, certains droits d'auteur (mais il faut qu'ils montrent en avoir besoin dans le cadre de leur accord d'achat avec Novell). D'où d'ailleurs le second procès entre SCO/Caldera et Novell, qui est en train de finir en eau de boudin (le juge va probablement déclarer irrecevable la plainte de SCO).

          > IBM peut parfaitement se défendre contre SCO en utilisant les articles de cet accord

          Reste à savoir si SCO prétend qu'ils aient piqué du code libéré par cet accord. Je ne suis pas sûr de ce qu'ils avancent réellement, tellement leurs documents sont emberlificotés, mais IBM avait accès (dans le cadre du projet Monterey) a bien plus que le code indiqué dans cet accord, donc peut-être SCO veut-il les accuser d'avoir pris du code postérieur à celui-ci (UnixWare ?), je ne sais pas. Ceci dit, la dernière fois que SCO avait mis des fichiers soi-disant pompés dans un document, ça avait fait rire tout le monde (ils avaient entre autres cité des fichiers aussi secrets que signal.h ou errno.h). Si tout est de la même veine, SCO va se faire jeter du tribunal à coups de pieds, accord ou pas accord. Sans compter qu'IBM les accuse à son tour d'avoir violé des brevets IBM, ainsi que les droits d'auteur sur du code GPL de chez IBM pour leur distribution du noyau Linux. La marrade continue.

          Envoyé depuis mon PDP 11/70

    • [^] # Re: Jurisprudence ?

      Posté par  . Évalué à 8.

      Un accord à l'amiable peut être considéré comme un contrat. Aux USA, tu es assez fortement lié par les termes des contrats que tu signes. Tu peux même avoir des clauses abusives ou illégales ("je deviens propriétaire de tout ton code si jamais tu as le malheur de respirer l'air d'une pièce où le mien est stocké", par ex.) : la loi aux USA ne l'empêche que dans de rares cas.

      [ En aparté : ceci permet de comprendre la tendance de The SCO Group (TSG) à attaquer ceux qui ont un contrat avec eux. Un contrat trop vite lu et signé, et le mec en face se retrouve avec moins de droits qu'il n'en avait avant de signer le contrat. Miam miam ! ]

      Ce n'est pas une jurisprudence, car un accord à l'amiable ne concerne que les parties en question. C'est même le but de tels accords que d'éviter qu'une jurisprudence ne se crée, en gardant la chose la plus secrete possible. Ca s'appelle acheter le silence, et c'est assez courant aux USA : un accord coûte moins cher (ou rapporte plus, selon les cas) qu'un jugement, où les frais d'avocat ne sont quasiment jamais remboursés.

      Cependant, les successeurs en intérêt d'AT&T et de l'université de Berkeley sont liés par les termes du contrat. The SCO Group (TSG) prétend être le successeur des droits d'Unix. Quant à ceux qui ont eu du code et une licence BSD entre les mains, s'ils peuvent redistribuer le code ou en créer des dérivés, ils peuvent être considérés un peu comme des successeurs de BSDi.
      Il y a des différences, bien sûr : on ne peut pas les obliger à se conformer à des restrictions (+ ou - illégales) d'un accord à l'amiable où ils ne sont pas partie. Mais ils peuvent être protégés par ce même accord, à condition qu'ils le sachent.

      Conclusion : si TSG t'avait attaqué la semaine dernière pour utilisation/redistribution de FreeBSD, tu n'aurais pas pu faire grand chose pour te défendre, car ne connaissant pas tes droits. Mais maintenant, il suffira de montrer que tu as une licence tout à fait officielle provenant de Berkeley ; et que Berkeley avait le droit de te tranmettre (directement ou indirectement) le code et l'OS en question, vu l'accord à l'amiable, etc... Imparable. [ Sauf si tu as pris une licence SCOsource, signé un NDA ou autre joyeuseté de SCO. ]

      Sinon, le simple citoyen en question a mis un assez long temps avant d'obtenir cet accord, en exploitant les quelques subtilités de la "Public Records Law". Il fallait être un convaincu pour vouloir absolument le voir. Il fallait savoir que cet accord pouvait être divulgé légalement. Et il fallait savoir que cela pouvait avoir un intérêt pour les affaires en cours. Ca se comprend que les avocats d'IBM ou autres n'aient pas tenté le coup.
  • # Clarifications diverses et rapides.

    Posté par  . Évalué à 10.

    Pour ceux qui se demandent de quoi ce texte peut bien parler mais dont les connaissances en anglais ne permettent pas une lecture approfondie du texte voici un petit résumé.

    Résumé des épisodes précédents :

    L'univeristé de Berkley avait pris une license "code plus binaires" chez AT&T pour leur Unix.
    Un peu plus tard AT&T revend les droits Unix à USL et Berkley sort un Unix maison sous le nom de Net2.
    USL qui aime bien Berkley mais qui trouve un peu louche que l'université sorte un Unix Like fait à partir de rien alors qu'ils possèdent le code source de l'Unix original attaque en justice.
    En 1990 un accord secret est passé entre USL et Berkley, tout ce qu'on en sait c'est que Berkley arrête de distribuer Net2 et encourage vivement tout les utilisateurs de Net2 à passer sous 4.4BSD(lite), de son coté USL déclare uen période de grace pendant laquelle les persones ayant des licences Unix sont vivement invités à faire le ménage chez eux et à retirer tosu les produits Berkley (Net2 et 4.4BSD).
    Beaucoup plus tard Groklaw récupére le texte de l'accord et décrypte.

    Le texte en question.

    Le texte découpe les fichiers en 4 groupes distincts listés dans 3 adendums :
    - Les fichiers à accès limités ("restricted")
    - Les fichiers dérivés d'Unix mais autorisés librement à la distribution
    - Les fichiers venant de Berkley poru BSD ou dérivés de BSD. ces derniers sont également distribuables librement.

    Grosso modo le texte de l'accord ets un cessez le feu plus qu'une paix durable. Berkley et USL, sans vraiment reconnaitre que l'autre à raison, se mettent d'accord pour arréter les hostilités.

    En bref : L'université de Berkley s'engage à ne plus distribuer les fichiers "restricted", à signaler qu'il existe un contentieux avec USL selon lequel ces fichiers pourraient être la propriété au moins partiellement la propriété d'USL et à inciter les gens sous NET2 à migrer en 4.4BSD(lite).
    On admire l'enchevètrement de conditionnels

    De son coté USL déclare qu'il ne fera pas de procès à Berkley si les accords sont tenus, ni à qui que ce soit qui aurait eu accès à du code, des algorithmes, ou des methodes Unix qui auraient été portés à la connaissance du public à cet date autrement que par Berkley, ses étudiants ou employés. Par contre USL se reserve le droit de porter plainte contre ceux qui ont des licences Unix.
    Ceci veut dire que USL avait déjà relaché du code et des techniques dans la nature, ou alors que des méthodes "Unix" avait été publiées. USL s'engage ici à ne pas attaquer les personnes faisant usage de ces codes et techniques sauf si :
    - Ce code a été relaché par Berkley (les fameux fichiers "restricted" )
    - La personne qui utilise ces codes et méthodes à une licence Unix qu'elle ne respecte pas.

    De plus dans le cas ou USL intente un procès à un des possesseurs de licence Unix, Berkley n'est pas autorisé à apporter son aide.

    Cerise sur le gateau : l'ensemble des fichiers de 4.4BSD(Lite) peut être distribué et redistribué librement sans même qu'il y soit apposé les mentions sur la propriété d'USL.

    Au final les seuls fichiers qui restent à Unix et que l'on a pas le droit de distribuer librement sont les suivant :

    sys/kern/init_main.c
    sys/kern/kern_clock.c
    sys/kern/kern_exec.c
    sys/kern/kern_exit.c
    sys/kern/kern_physio.c
    sys/kern/kern_sig.c
    sys/kern/kern_synch.c
    sys/kern/subr_rmap.c
    sys/kern/sys_generic.c
    sys/kern/sys_process.c
    sys/kern/sysv_shm.c
    sys/kern/tty.c
    sys/kern/tty_subr.c
    sys/kern/vfs_bio.c
    sys/kern/vfs_syscalls.c
    sys/sys/buf.h
    sys/sys/proc.h
    sys/sys/shm.h
    sys/sys/tty.h
    sys/ufs/dinode.h
    sys/ufs/inode.h
    sys/ufs/ufs_bmap.c
    sys/ufs/ufs_disksubr.c
    sys/ufs/ufs_inode.c
    sys/ufs/ufs_vnops.c
    usr.bin/cpio/cpio.c

    Dans leur version BSD Network Release 2 (NET2)

    Il existe également 91 fichier dans la NET2 que l'on peut redistribuer seulement en mettant un entête de propriété pour USL.

    Dans nos prochains épisodes :

    Ce que l'on apprend dans ce texte est assez informatif pour le futur (notamment vis à vis de SCO ou d'autres problèmes de propriété intellectuelle) :

    Tout d'abord quoi que vous ayiez fait avec du code venant de 4.4BSD(Lite) c'est bon. Les projets *.BSD sont donc quasiment hors de danger.
    Ensuite si vous avez une licence Unix (j'imagine qu'il faut comprendre uen licence groupe avec le code source) ce texte ne s'applique pas à vous. Ou au moins les restrictions de la licence Unix s'appliquent d'abord.
    Au final il n'y a que 26 fichiers qui sont potentiellement interdits (Berkley a arrété de les distribuer parcequ'il y avait peut-être des bouts de codes Unix dedans.) Mais rien ne prouve qeu si vous vous amusiez à les distribuer quand même vous seriez en tort.
    Il existe de même 91 fichiers avec un entête de propriété USL que l'on peut redistribuer si on conserve l'entête. Mais une fois de plus rien ne dit dans le texte que si vous enleviez l'entête vous seriez en tort.

    Au final ce texte affirme de façon très nette la validité de nombreux projets et ne fait que laisser entendre qu'il y aurait peut-être un risque au niveau légal à faire n'importe quoi avec 117 fichiers duement repérés et nommés.
    Pour tous les autres fichiers de NET2 et 4.4BSD(Lite) pas de problème, USL à accorder à Berkley le droit de faire ce qu'il en voulait y compris accorder le droit de redistribuer.
    • [^] # Re: Clarifications diverses et rapides.

      Posté par  . Évalué à 5.

      Au final il n'y a que 26 fichiers qui sont potentiellement interdits (Berkley a arrété de les distribuer parcequ'il y avait peut-être des bouts de codes Unix dedans.)

      Il y avait bien des bouts de code de la version 32V, mais c'était assez négligeable, mis à part le fichier cpio.c qui était directement extrait de System V (et même inclus dans BSD à la demande expresse d'AT&T).
    • [^] # Re: Clarifications diverses et rapides.

      Posté par  (site web personnel) . Évalué à 4.

      Après avoir lu tous les commentaires, je me dis que le modèle du logiciel propriétaire avec ses licences et ses droits divers n'est pas viable car d'un point de vue légal le produit devient de plus en plus complexe avec le temps.
      Pour savoir à qui appartiennent les bouts de code, ça devient un joli bordel. Il n'y a que les juristes qui y trouvent leur intérêt.

      Finalement Stallman avait vu juste en 1984 : travailler avec du code libre c'est tellement simple et confortable !
      • [^] # Re: Clarifications diverses et rapides.

        Posté par  . Évalué à 10.

        oui enfin...

        cette histoire (et bien d'autres, tellement d'autres...) tend à montrer que les entreprises "propriétaires" informatique (qui vivent pour et par le monopole d'une ressource, d'une connaissance) en arrivent à se battre les unes les autres dans des procès quasi stérile ou à empiler les contrats tordus, les accords hypocrites ou les licences compliquées et obscure qui font que toute RE-utilisation de leur code est quasi impossible.

        On peut justifier ces dérives par la sur-protection juridique, par des pratiques hérités de décennies (siècles ?) commerciales, par une non-compréhension de ce qu'est véritablement le "code" (tout sauf un objet physique qu'on range dans un coffre) et par des impératifs légaux (les entreprises ont tout de même des responsabilités à défendre, tous leurs agissements ne sont pas le fruits de leur amour du Mal)

        D'un point de vue "ingénieur", c'est souvent stérile : des tonnes de très bon travaux se retrouvent enfermés ou sous-utilisés (beaucoup de gens sont encore traumatisés par Beos, par exemple)

        D'un point de vue commercial et propriété intellectuelle, les choses sont parfois justifiées, mais avec le temps, on arrive à des catastrophes judiciaires, presque quasi systématiquement. A ma connaissance, les seules sociétés informatiques qui ont évité des années de procès sur un produit sont celles qui ont soigneusement isolé leur code source de toute influence extérieure (au sens : aucun accord croisé avec une autre entreprise, aucun usage de brevet sous licence, aucun "achat" de code externe, etc). c'est rare.

        Plus les avocats ont senti le filon, plus ils ont poussé en avant le besoin "financier" de protéger sa "propriété", plus ils ont accentué le "risque", le "besoin", etc etc. Au point de maintenir être une part essentielle de toute activité informatique commerciale et grosso modo d'une hégémonie du droit de la propriété intellectuelle.

        L'industrie propriétaire, quand elle en arrive à ses derniers retranchements en devient contre-productive. Plus le code est secret et obscure et verrouillé, moins il est connu ou devenu "fondamental", moins les gens en ont besoin, moins il a de valeur marchande et surtout il devient inutilisable. De l'autre coté, plus le code devient banal, répandu et "commodisé" et compris, plus sa valeur _marchande_ devient nulle aussi mais il est fortement utilisé. Pour une _entreprise commerciale_, c'est le juste milieu qui est important. Manifestement il a échappé à pas mal de décideurs.

        Pour nous, développeurs ou utilisateurs, que la valeur marchande d'un code source ne nous appartenant pas soit nulle ou non n'est pas notre soucis immédiat. Le code ultra-verrouillé, par contre, devient un obstacle.

        Voilà les problèmes du "propriétaire" à outrance.



        Cela dit :

        dans le monde 'open source / logiciel libre", il n'y a pas qu'une seule licence. il y en a de multiples et cela peut provoquer de sacrées migraines (hello Php / Mysql 4 ).

        Mais le but étant quand même de promouvoir l'usage du code, on est toujours arrivé à des solutions, relativement rapidement et sans dégainer son avocat maison.

        Avec le temps, on voit que les juristes et autres avocats ont très bien compris qu'il y a un marché de "consultant" et de "négociateur" juteux. On voit de plus en plus de cabinets spécialisés en droit intellectuel se proposer pour "estimer" l'usage possible d'un projet libre, pour mettre en place l'ouverture d'un code source propriétaire sans se faire manger , etc etc.

        au final, dire "le propriétaire n'est pas viable" est un peu exagéré. J'aurais tendance à dire que c'est relativement vrai sur un plan strictement "ingénierie" (obtenir le Meilleur Outil pour l'Humanité , nom d'un petit schtroumpf !). Mais le logiciel opensource peut tout autant accoucher d'un embriaglo juridique si les gens se "cristallisent" obstinément sur des licences totalement contradictoires portant sur des logiciels "fondamentaux".

        On a évité cela pour le moment : les rares cas conflictuels ayant toujours étant négocié à coup d'exceptions "toi t'es gentil aussi, donc ze t'autorise à utiliser mon code, même si c'est pas tout à fait mon truc". Plus les "professionnels" et entreprises se mêlent au monde opensource/libre, plus on voit de cas obstinés à la " sun vs apache".


        On s'inquiète guère. Si des sociétés veulent se pourrir l'existence, étouffer des produits et standards, c'est leur problème. Internet semble permettre de fédérer suffisamment de bonne volonté pour presque toujours recréer une alternative de qualité qui satisfasse la grande partie des besoins.

        N'oublions pas que le but "premier" de presque toutes les associations, organisations ou particuliers de libre et dans une moindre mesure du opensource, jusqu'à présent, est de faciliter et répandre l'usage du code source et des connaissances associés. Evidemment, par conséquent, on a vu moins de procès et de plans tordus. Des entreprises comme redhat ou ibm ou novell y voient leur intérêt.
        • [^] # Re: Clarifications diverses et rapides.

          Posté par  . Évalué à 6.

          Sans vouloir être trop méchant il ne faut pas oublier que l'un des avantages de la "surprotection" du code est de permettre aux grands de se protéger contre l'innovation de petits qui n'ont généralement pas l'infrastructure juridique ni moyens financiers de se lancer dans un procès.
        • [^] # Re: Clarifications diverses et rapides.

          Posté par  (site web personnel) . Évalué à 3.

          Pour une _entreprise commerciale_, c'est le juste milieu qui est important. Manifestement il a échappé à pas mal de décideurs.
          Le modèle de vente de licences d'utilisation de logiciels est un modèle foireux justement parce que ça dérive sur ce que l'on peut constater de nos jours : plus d'argent injecté dans le droit et la pub que dans la recherche et développement.

          Je pense que plus ça va aller dans ce sens, plus une la survie d'une petite société éditrice deviendra difficile puisqu'elle n'a pas les ressources nécessaires pour investir dans le droit. Et comme elle "vole" forcément la "propriété" des autres sociétés (le clic, la fenetre, le nom, etc) et dès qu'elle grossit un peu trop, elle est devient la cible de procédures judiciaires ce qu'elle ne peut pas se permettre....

          Le juste milieu du marché du soft c'est la vente de services, et ça, ça prend du temps a être compris, mais ça viendra bien un jour : il n'y a pas d'autre choix :)
      • [^] # Re: Clarifications diverses et rapides.

        Posté par  . Évalué à 3.

        Après avoir lu tous les commentaires, je me dis que le modèle du logiciel propriétaire avec ses licences et ses droits divers n'est pas viable car d'un point de vue légal le produit devient de plus en plus complexe avec le temps.

        C'est justement l'inverse. Vu qu'avec le logiciel proprio tu ne donnes les sources a personne, tu ne risques pas de donner des sources qui ne t'appartiennent pas.

        Finalement Stallman avait vu juste en 1984 : travailler avec du code libre c'est tellement simple et confortable !

        Ca serait simple et confortable si il y avait un minimum de doc avec les sources des projets, je me souviens encore des cauchemards que j'ai eu quand j'ai eu a modifier une version beta de Mozilla il y a qqe annees de cela pour l'ecole ou je bossais, j'ai hesite a me jeter par la fenetre tellement c'etait impossible de comprendre les sources.
        Si il y a bien _un_ truc que les projets de LL devraient faire pour augmenter le nombre de contributeurs c'est bien ca, parce que demarrer dans un projet un minimum consequent sans doc c'est du suicide psychologique.
        • [^] # Re: Clarifications diverses et rapides.

          Posté par  . Évalué à 7.

          C'est justement l'inverse. Vu qu'avec le logiciel proprio tu ne donnes les sources a personne, tu ne risques pas de donner des sources qui ne t'appartiennent pas.

          Dans un sens, tu n'as pas tout à fait tort : tu ne "donnes" pas les sources aux simples utilisateurs. Mais à tes partenaires commerciaux, contractants, stagiaires, employés qui vont passer quelques mois plus tard à la concurrence, etc...

          L'histoire des Unix commerciaux en est l'exemple le plus flagrant. Des bouts de code sont passé d'une entreprise à l'autre dans tous les sens, sans contrôle exact. Et hop, un petit graphique pour les incrédules : http://www.levenez.com/unix/history.html#08(...)

          Un exemple simple : A achète du code à B, pour l'intégrer dans le module M du produit P, qui va vivre plusieurs versions. Quand A revend une partie du code de (P-M) à C, il y a parfois des restes de code de B, par copier-coller du module M ou autre, etc... Bref, embrouillamini total.

          Comme le dit Michell Galle un peu plus haut : A ma connaissance, les seules sociétés informatiques qui ont évité des années de procès sur un produit sont celles qui ont soigneusement isolé leur code source de toute influence extérieure (au sens : aucun accord croisé avec une autre entreprise, aucun usage de brevet sous licence, aucun "achat" de code externe, etc). c'est rare.

          Or même Microsoft a racheté et intégré du code d'autres entreprises, par exemple pour le DOS (il y a plein d'exemples plus récents aussi). Est-ce que tous ces bouts de code étaient la propriété entière des vendeurs ? Pas forcément, même s'ils étaient de bonne foi et ont fait des contrôles stricts.

          Le logiciel propriétaire n'a qu'un seul avantage de ce point de vue : on peut cacher plus longtemps que du code a été copié illégalement.

          Pour les LL, ca peut arriver qu'un développeur indélicat copie du code de sa boîte sans autorisation (avec la même probabilité qu'il copie du code du module M dans le reste du produit P, d'ailleurs !), mais dès que l'entreprise le découvre, on peut retracer l'origine, qui est responsable, et les codeurs du LL se feront un plaisir d'éradiquer les lignes en question, pour les remplacer par du vrai code libre. Et en pratique, ca fonctionne très bien comme ca.


          Quant au problème du manque de documentation, il est valable pour tout le monde. J'ai bossé sur des projets propriétaires avec peu, pas, ou de la très mauvaise, documentation. Rien de meilleur ni de pire dans l'ensemble, ca dépend de la politique de l'entreprise. La tienne a une politique dans ce sens, la mienne aussi et c'est bien. Mais il y a des projets libres qui sont très bien documentés aussi.

          Et pour Mozilla, tu as pris pile le mauvais exemple : il y a quelques années, comme tu dis, le code du projet venait tout de Netscape, propriétaire à 100%. Le manque de docu et la mauvaise qualité du code sont entièrement de leur faute. Tu n'espérais quand même pas qu'en quelques mois, les développeurs libres fassent tout le (sale) boulot de réécriture et de docu par miracle ?

          Le projet a eu besoin de plusieurs années pour repartir sur de bonnes bases, et arriver aux versions actuelles de Mozilla et Firefox, considérées de qualité acceptable (ou plus). Si tu veux de la docu pour comprendre et développer sur le projet, en voilà !
          http://www.mozilla.org/docs/(...)
          http://www.mozilla.org/hacking/(...)
          http://www.mozilla.org/contribute/writing/(...)
        • [^] # Re: Clarifications diverses et rapides.

          Posté par  (site web personnel) . Évalué à 3.

          C'est justement l'inverse. Vu qu'avec le logiciel proprio tu ne donnes les sources a personne, tu ne risques pas de donner des sources qui ne t'appartiennent pas.
          Et ça c'est quoi : http://www.sigmadesigns.com/products/RMP4_video_codec.htm(...) ? MS a rencontré des problèmes avec un logiciel de softimage qu'ils ont racheté : http://www.zdnet.fr/actualites/technologie/0,39020809,2136648,00.ht(...) . Eux mêmes ont été dégagés de toute responsabilité mais softimage a perdu le procès : http://www.zdnet.fr/actualites/business/0,39020715,39127587,00.htm(...) .

          Les gens qui font du proprio piquent aussi, volontairement (sigma) ou non (MS), du source chez les autres, et sont tout aussi exposés au procés et autres complications juridiques.
          Bref, tu es emmerdé pareil sinon pire, vu que tu risques nettement moins si tu pompes du source libre pour produire du libre : la puissance du copyleft en action :)

Suivre le flux des commentaires

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