path: root/danish/devel/constitution.1.2.wml

#use wml::debian::template title="Histroiske Debian-vedtægter version 1.2" BARETITLE="true"
#use wml::debian::translation-check translation="5a315ddb15a28dd0269d23be676be33d0f75f371"

<h1>Historisk udgave af Debian-projektets vedtægter (v1.2)</h1>

<p>Version 1.2 blev godkendt den 29. oktober 2003.</p>

<p>
Erstattet af
<a href="constitution.1.3">version 1.3</a> godkendt den 24. september 2006, 
<a href="constitution.1.4">version 1.4</a> godkendt den 7. oktober 2007, 
<a href="constitution.1.5">version 1.5</a> godkendt den 9. januar 2015, 
<a href="constitution.1.6">version 1.6</a> godkendt den 13. december 2015, 
<a href="constitution.1.7">version 1.7</a> godkendt den 14. august 2016 og den 
<a href="constitution">aktuelle version 1.8</a> godkendt den 28. januar 2022.
</p>

<p>Erstattede
<a href="constitution.1.1">version 1.1</a> godkendt den 21. juni 2003 og
<a href="constitution.1.0">version 1.0</a> godkendt den 2. december 1998,
</p>


<h2>§1. Introduktion</h2>

<cite>
  Debian-projektet er en sammenslutning af personer, som har det fælles mål at 
  udvikle et frit tilgængeligt styresystem.
</cite>

<p>
  Dette dokument beskriver organisationsstrukturen for formelle beslutninger i 
  projektet.  Det beskriver ikke projektets mål eller hvordan vi opfylder disse, 
  og indeholder ingen retningslinier, bortset fra de retningslinier som direkte 
  vedrører beslutningsprosessen.
</p>


<h2>§2. Beslutningsdygtige organer og -personer</h2>

<p>
  Enhver beslutning i projektet er omfattet af en eller flere af følgende:
</p>

<ol>
  <li>Udviklerne, via en fælles resolution eller et valg;</li>
  <li>Projektlederen;</li>
  <li>Den tekniske komité og/eller dennes formand;</li>
  <li>Den individuelle udvikler som arbejder med en bestemt opgave;</li>
  <li>Delegater udnævnt af projektlederen til at varetage særlige opgaver;</li>
  <li>Projektsekretæren.</li>
</ol>

<p>
  Resten af dette dokument vil primært beskrive disse organers fuldmagter, 
  deres sammensætning og udnævnelse, og procedurer for vedtagelser.  En persons 
  eller et organs fuldmagt kan i visse tilfælde blive genstand for gennemsyn af 
  andre; i så fald vil det fremgå af afsnittet om det organ, der står for dette.
  <cite>
    I listen ovenfor er hver person eller hvert organ stort set anført før de 
    personer eller organer de kan (hjælpe til med at) udnævne, og hvis 
    beslutninger de kan ophæve - men ikke alle, der er anført tidligere, kan 
    ophæve beslutninger fortaget af alle som er anført senere.
  </cite>
</p>


<h3>§2.1. Generelle regler</h3>

<ol>
  <li>
    <p>
      Intet i disse vedtægter forpligter nogen til at arbejde for projeket.
      En person, der ikke vil udføre en opgave, som er blevet uddelegeret eller
      pålagt vedkommende, behøver at gøre det.  Derimod kan man ikke aktivt
      modarbejde regler eller beslutninger, som er foretaget korrekt i henhold
      til reglerne.</p></li>

  <li>
    <p>
      En person kan bestride flere hverv, bortset fra at projektlederen, 
      projektsekretæren og formanden for den tekniske komité skal være 
      forskellige personer, og lederen kan ikke udnæve sig selv, som sin egen 
      delegat.
    </p>
  </li>

  <li>
    <p>
      En person kan til enhver tid forlade projektet eller fratræde et særskilt 
      hverv vedkommende har, ved offentligt at erklære dette.
    </p>
  </li>
</ol>


<h2>§3. Individuelle udviklere</h2>

<h3>§3.1. Fuldmagt</h3>

<p>En individuel udvikler kan</p>

<ol>
  <li>
    tage tekniske og ikke-tekniske beslutninger med hensyn til sit eget 
    arbejde;</li>

  <li>
    foreslå og støtte udkast til generelle resolutioner;</li>

  <li>
    foreslå sig selv som kandidat til projektleder i valg;</li>

  <li>
    stemme på generelle resolutioner og i ledervalg.</li>
</ol>

<h3>§3.2. Sammensætning og udnævnelse</h3>

<ol>
  <li>
    <p>
      Udviklere er frivillige som er enige om at fremme projektets mål for så 
      vidt som de deltager i det, og som vedligeholder pakke(r) for projektet 
      eller gør andet arbejde, som projeketlederens delegater anser for 
      værdifuldt.
    </p>
  </li>

  <li>
    <p>
      Projektlederens delegater kan vælge ikke at optage nye udviklere, eller 
      at ekskludere nuværende udviklere.
      <cite>
        Hvis udviklerne mener at delegaterne misbruger deres autoritet, kan de 
	selvfølgelig ophæve en beslutning via en generel resolution - se 
	§4.1(3) og §4.2.
      </cite>
    </p>

</ol>

<h3>§3.3. Fremgangsmåder</h3>

<p>Udviklerne kan foretage disse beslutninger efter eget skøn.</p>


<h2>§4. Udviklerne via generel resolution eller et valg</h2>

<h3>§4.1. Fuldmagt</h3>

<p>Udviklerne kan sammen:</p>

<ol>

  <li>
    <p>
      Udnævne eller afsætte projektlederen.</p></li>

  <li>
    <p>
      Ændre disse vedtægter med et 3:1-flertal.</p></li>

  <li>
    <p>
      Ophæve enhver beslutning taget af projektlederen eller en 
      delegat.</p></li>

  <li>
    <p>
      Ophæve enhver beslutning taget af den tekniske komité, såfremt de er 
      enige med et 2:1-flertal.</p></li>

  <li>
    <p>
      Udgive, erstatte og tilbagetrække ikke-tekniske retningslinier og 
      erklæringer.</p>

    <p>
      Dette inkluderer dokumenter som forklarer projektmål, dets forhold til 
      andre organer indenfor fri software, samt ikke-tekniske vejledninger som 
      de fri software-licensbetingelser, som Debians programmel skal leve op 
      til.</p>

    <p>
      Det kan også være stillingtagen til aktuelle emner.</p>

    <ol style="list-style: decimal;">	
      <li>Et grundlæggende dokument er et dokument eller en bekendtgørelse, der
          betragtes som kritisk for projekts arbejde og formål.</li>
      <li>De grundlæggende dokumenter er det arbejde som er udmundet i 
          <q>Debian sociale kontrake</q> og <q>Debians retningslinier for fri
	  software</q>.</li>
      <li>Et grundlæggende dokument kræver et 3:1-flertal for dets erstatning.
          Nye grundlæggende dokumenter udgives og eksisterende dokumenter 
	  trækkes tilbage ved at føje til listen over grundlæggende dokumenter
	  i disse vedtægter.</li>
    </oL>
  </li>

  <li>
    <p>
      Træffe beslutninger sammen med projektlederen og SPI om forvaltede
      ejendele til formål der har relation til Debian. (Se §9.1).</p></li>
</ol>

<h3>§4.2. Fremgangsmåde</h3>

<ol>

  <li>
    <p>
      Udviklerne følger de generelle resolutionsprocedurer beskrevet nedenfor.
      En resolution eller ændring betragtes som introduceret, hvis den er 
      foreslået af en hvilken som helst udvikler og mindst K andre udviklere 
      støtter den, eller hvis den er foreslået af projektlederen eller den 
      tekniske komité.</p></li>

  <li>
    <p>Udsættelse af en resolution foretaget af projektlederen eller dennes
    delegater:</p>

      <ol>
        <li>
          Hvis projektlederen, dennes delegater eller den tekniske komité har 
	  truffet en beslutning, kan udviklerne ophæve denne ved at vedtage en 
	  resolution derom, se §4.1(3).</li>

        <li>
          Hvis en sådan resolution støttes af mindst 2K udviklere eller hvis
          den er foreslået af den tekniske komité, vil resolutionen
          omgående tilsidesætte beslutningen (såfremt resolutionen selv
          siger dette).</li>

        <li>
          Hvis den oprindelige beslutning var at ændre en diskussionsperiode
          eller en stemmeperiode, eller hvis resolutionens formål er at ophæve 
	  en beslutning foretaget af den tekniske komité, behøver kun K
          udviklere at støtte resolutionen, for omgående at kunne
          tilsidesætte beslutningen.</li>

        <li>
          Hvis beslutningen er tilsidesat, holdes omgående en afstemning
          for at afgøre om beslutningen skal opretholdes indtil en fuldstændig
          afstemning om beslutningen kan holdes, eller om udførslen af den
          oprindelige beslutning skal udsættes indtil da.  Der findes ikke et
          beslutningsdygtigt antal stemmer i denne omgående, proceduriske
          afstemning.</li>

        <li>
          Hvis projektlederen (eller dennes delegater) trækker den oprindelige
          beslutning tilbage, bliver det uaktuelt at holde afstemningen og
          den vil ikke blive afholdt.</li>
      </ol>

    <li>
      <p>
        Stemmer indsamles af projektsekretæren.  Stemmerne og
        afstemningsresultatet offentliggøres ikke i stemmeperioden;
        efter afstemningen opremser projektsekretæren alle de afgivne stemmer,
        Afstemningsperioden er to uger, men projektlederen kan tilføje eller 
	fjerne op til en uge.</p></li>

    <li>
      <p>
        Minimumstiden for diskussion er to uger, men projektlederen kan tilføje 
	eller fjerne op til en uge.  Projektlederen har den afgørende stemme.  
	Det beslutningsdygtige antals stemmer er 3Q.</p></li>

    <li>
      <p>
        Forslag, støtte, ændringer, stemmeopråb og andre formelle handlinger
	foregår via erklæringer på en offentlig tilgængelig elektronisk 
	postliste udvalgt af projektlederens delegat(er); alle udviklere har
	skriveadgang til den.</p></li>

    <li>
      <p>
        Stemmer afgives via e-mail på en måde der bestemmes af sekretæren.
        Sekretæren bestemmer for hver afstemning hvorvidt vælgerne kan ændre 
	deres stemmer.</p></li>

    <li>
      <p>
        Q er halvdelen af kvadratroden af antallet af udviklere.  K er
        den mindste af Q og 5.  Q og K behøver ikke at være heltal, og de 
	afrundes ikke.</p></li>
</ol>


<h2>§5. Projektlederen</h2>

<h3>§5.1. Fuldmagt</h3>

<p><a href="leader">Projektlederen</a> kan:</p>

<ol>
  <li>
    <p>
      Udnævne delegater eller uddelegere beslutninger til den tekniske
      komité.</p>

    <p>
      Lederen kan beskrive en opgave med løbende ansvar eller en særskilt 
      beslutning.  I begge tilfælde overføres denne til en anden udvikler eller 
      til den tekniske komité.</p>

    <p>
      Efter en særskilt beslutning er blevet uddelegeret og afgjort, kan 
      projektlederen ikke trække uddelegeringen tilbage. derimod kan en løbende 
      uddelegerning til en bestemt opgave trækkes tilbage.</p></li>


  <li>
    <p>
      Give hjemmel til andre udviklere.</p>

    <p>
      Projektlederen kan udgive støtteerklæringer til andres synspunkter eller
      andre projektmedlemmer, uden at være blevet bedt om det.  Disse
      støtteerklæringer er gyldige, hvis, og kun hvis, lederen ville have haft 
      fuldmagt til at træffe den foreliggende beslutning.</p></li>

  <li>
    <p>
      Foretage beslutninger som kræver omgående handling.</p>

    <p>
      Dette gælder ikke beslutninger som gradvist er blevet påtrængende på grund 
      af manglende, relevant handling, med mindre der er en fastsat 
      frist.</p></li>

  <li>
    <p>
      Foretage beslutninger som ingen andre har ansvaret for.</p></li>

  <li>
    <p>
      Fremstille udkast til generelle resolutioner og ændringsforslag.</p></li>

  <li>
    <p>
      Sammen med den tekniske komité udpege nye medlemmer til komitéen. (Se 
      §6.2.)</p></li>

  <li>
    <p>
      Afgive en afgørende stemme i udviklernes afstemninger.</p>

    <p>
      Projektlederen har også almindelig stemmeret i sådanne
      afstemninger.</p></li>

  <li>
    <p>
      Ændre diskussionsperioden for udviklernes afstemninger (som beskrevet 
      ovenfor).</p></li>

  <li>
    <p>Lede diskussioner blandt udviklerne.</p>

    <p>
      Projektlederen bør prøve at deltage i diskussioner blandt udviklerne på en 
      hjælpsom måde, som søger at bringe diskussionen på rette kurs mod sagens 
      kerne.  Projektlederen bør ikke bruge lederpositionen til at fremme sine 
      egne personlige synspunkter.</p></li>

  <li>
    <p>
      Tage beslutninger sammen med SPI, der vedrører ejendele som administreres 
      til formål der vedrører Debian.  (Se §9.1.)</p></li>
</ol>


<h3>§5.2. Udnævnelse</h3>

<ol>
  <li>
    Projektlederen vælges af udviklerne.</li>

  <li>
    Valget begynder ni uger før lederpositionen bliver ledig eller (hvis det 
    ikke allerede er for sent) omgående.</li>

  <li>
    I de følgende tre uger kan enhver udvikler nominere sig selv som 
    projektlederkandidat.</li>

  <li>
    I de efterfølgende tre uger kan der ikke nomineres flere kandidater;
    kandiaterne bør anvende dette tidsrum til deres valgkamp (for at gøre 
    opmærksom på sig selv og sine synspunkter).  Hvis der ikke er nogen 
    kandidater efter nomineringsperioden er slut, bliver perioden udvidet med 
    yderligere tre uger, om nødvendigt gentagne gange.</li>

  <li>
    De næste tre uger er valgperioden, hvori udviklerene kan stemme.  
    Afstemningen i ledervalg er hemmelig, selv efter afstemningen er 
    afsluttet.</li>

  <li>
    Valget vil være mellem de kandidater, der har nomineret sig selv og som ikke 
    har trukket sig tilbage, samt <q>Ingen af ovenstående</q> (<q>None of the 
    Above</q>). Hvis <q>Ingen af ovenstående</q> vinder valget, bliver denne 
    procedure gentaget, om nødvendigt mange gange.</li>

  <li>
    Beslutningen træffes ved hjælp af den metode, som er beskrevet i afsnit §A.6 
    i de generelle resolutionsprocedurer.  Det beslutningsdygtige antal er det 
    samme, som ved en generel resolution (§4.2), og standardvalget er <q>Ingen 
    af de nævnte</q>.</li>

  <li>
    Projektlederen vælges for et år ad gangen.</li>
</ol>


<h3>§5.3. Fremgangsmåde</h3>

<p>
  Projektlederen bør prøve at træffe beslutninger som er i tråd med konsensus 
  blandt udviklerne.</p>

<p>
  Hvor det er praktisk bør projektlederen på en uformel måde bede om udviklernes 
  synspunkter.</p>

<p>
  Projektlederen bør undgå at lægge for megen vægt på sine egne synspunkter, når 
  der træffes beslutninger i vedkommendes egenskab af leder.</p>


<h2>§6. Teknisk komité</h2>

<h3>§6.1. Fuldmagt</h3>

<p>Den <a href="tech-ctte">tekniske komité</a> kan:</p>

<ol>
  <li>
    <p>
      Træffe beslutninger om tekniske retningslinier.</p>

    <p>
      Deriblandt også indholdet af de tekniske retningslinier, udviklernes 
      håndbogsmateriale, pakkeeksempler og hvordan ikke-eksperimentelle 
      pakkeopbygningsværktøjer skal fungere.  (I hvert tilfælde træffer den 
      almindelige pakkevedligeholder af programmellet eller dokumentationen, de 
      første beslutninger; se §6.3(5).)</p></li>

  <li>
    <p>
      Afgøre tekniske spørgsmål hvor udviklernes ansvarsområder overlapper.</p>

    <p>
      I tilfælde hvor udviklere skal implementere kompatible tekniske 
      retningslinier eller holdninger (for eksempel hvis de ikke er enige om 
      prioriteringerne ved uforenlige pakker, eller om ejerskab af et 
      kommandonavn, eller om hvilken pakke der er ansvarlig for en fejl som 
      begge pakkevedligeholdere er enige om er en fejl, eller om hvem der bør 
      være vedligeholder af en pakke), kan den tekniske komité afgøre sagen.</p></li>

  <li>
    <p>
      Træffe en beslutning når den bliver bedt om at gøre dette.</p>

    <p>
      Enhver person og ethvert organ kan uddelegere en af sine egne beslutninger 
      til den tekniske komité eller bede om råd fra den.</p></li>

  <li>
    <p>
      Tilsidesætte en udviklers beslutning (kræver et 3:1-flertal)</p>

    <p>
      Den tekniske komité kan bede en udvikler om at benytte en bestemt 
      fremgangsmåde, selvom udvikleren ikke ønsker det; dette kræver et 
      3:1-flertal.  For eksempel kan komitéen komme frem til at en klage 
      fremsat i en fejlrapport er gyldig og at indsenderens foreslåede løsning 
      bør iværksættes.</p></li>

  <li>
    <p>
      Give råd.</p>

    <p>
      Den tekniske komité kan give formelle erklæringer om sit syn på enhvert 
      emne.
      <cite>
        Individuelle medlemmer kan selvfølgelig give uformelle erklæringer
        om deres synspunkter og om komitéens sandsynlige 
        synspunkter.</cite></p></li>

  <li>
    <p>
      Sammen med projektlederen udnævne nye medlemmer til sig selv eller fjerne 
      nuværende medlemmer.  (Se §6.2.)</p></li>

  <li>
    <p>
      Udnævne formanden for den tekniske komité.</p>

    <p>
      Komitéen vælger formand blandt sine medlemmer.  Medlemmerne af komitéen 
      nomineres automatisk; valget starter en uge før stillingen bliver ledig 
      (eller omgående, hvis det allerede er for sent).  Medlemmerne kan stemme 
      via offentlig tilkendegivelse for hvilket som helst komitémedlem, også
      sig selv.  Der er intet standardvalg.
      Valget afsluttes når alle medlemmerne har stemt eller stemmeperioden er
      afsluttet.  Resultatet afgøres ved hjælp af den metode, som er angivet i 
      §A.6 i de generelle resolutionsprocedurer.</p></li>

  <li>
    <p>
      Formanden kan vikariere for lederen, sammen med sekretæren</p>

    <p>
      Som beskrevet i §7.1(2), kan formanden for den tekniske komité og 
      projektsekretæren i fællesskab vikariere for lederen, hvis der ikke er en 
      leder.</p></li>
</ol>


<h3>§6.2. Sammensætning</h3>

<ol>
  <li>
    <p>
      Den tekniske komité består af op til otte udviklere og bør normalt have 
      mindst fire medlemmer.</p></li>

  <li>
    <p>
      Hvis det er mindre end otte medlemmer, kan den tekniske komité anbefale 
      ny(e) medlem(mer) til projektlederen, som (på egen hånd) kan vælge at 
      udnævne dem eller ej.</p></li>

  <li>
    <p>
      Hvis der er fem eller færre medlemmer, kan den tekniske komité udnævne 
      ny(e) medlem(mer) indtil antallet af medlemmer når seks.</p></li>

  <li>
    <p>
      Når der har været fem eller færre medlemmer i mindst en uge, kan
      projektlederen udnævne nye medlem(mer) indtil antallet af medlemmer
      når seks, med mindst en uges mellemrum for hver udnævnelse.</p></li>

  <li>
    <p>
      Hvis den tekniske komité og projektlederen er enige kan de fjerne eller 
      erstatte et nuværende medlem af den tekniske komité.</p></li>
</ol>

<h3>§6.3. Fremgangsmåde</h3>

<ol>
  <li>
    <p>
      Den tekniske komité anvender den generelle resolutionsprocedure.</p>

    <p>
      Et udkast til en resolution eller ændring kan framsættes af ethvert 
      medlem af den tekniske komité.  Det er ingen minimumstid for diskussion; 
      valgperioden varer i op til en uge eller indtil der ikke længere kan være 
      nogen tvivl om resultatet.  Medlemmerne kan ændre deres stemmer.  Det 
      beslutningsdygtige antal er to.</p></li>

  <li>
    <p>
      Detaljerede afstemningoplysninger</p>

    <p>
      Formanden har den afgørende stemme.  Når den tekniske komité stemmer for 
      at afgøre, om de skal tilsidesætte en afgørelse taget af en udvikler, der 
      også er et medlem af komitéen, kan dette medlem ikke stemme (med mindre 
      det er formanden, som i dette tilfælde kun kan benytte sin afgørende 
      stemmeret).</p></li>

  <li>
    <p>
      Offentlig diskussion og afgørelser</p>

    <p>
      Diskussioner, udkast til resolutioner og ændringer og komitemedlemmernes 
      stemmer offentliggøres på den tekniske komités offentlige 
      diskussionsliste.  Der er ikke en særskilt sekretær for komitéen.</p></li>

  <li>
    <p>
      Fortrolighed ved udnævnelser</p>

    <p>
      Den tekniske komité kan holde fortrolige diskussioner via privat e-mail 
      eller en privat postliste, eller på andre måder diskutere udnævnelser til 
      komitéen.  Derimod skal stemmerne ved udnævnelser offentliggøres.</p></li>

  <li>
    <p>
      Ikke et detaljeret udviklingsarbejde</p>

    <p>
      Den tekniske komité giver sig ikke i kast med fremstilling af nye forslag 
      og retningslinier.  Sådant udviklingsarbejde bør foretages privat af 
      personer eller grupper, og diskuteres i almindelige tekniske og 
      udviklingsfora.</p>

    <p>
      Den tekniske komité begrænser sig selv til at vælge blandt, eller vælge et 
      kompromis mellem, løsninger og afgørelser, der er blevet foreslået og er 
      blevet drøftet tilpas meget andre steder.</p>

    <p>
      <cite>
        Medlemmer af den tekniske komité kan selvfølgelig deltage på egne vegne 
	i alle aspekter af udviklings- og retningsliniearbejde.</cite></p></li>


  <li>
    <p>
      Den teknisk komité træffer kun afgørelser som en sidste udvej</p>

    <p>
      Den tekniske komité træffer ikke en teknisk afgørelse før der uden held 
      har været gjort forsøg på at løse problemet ved konsensus, med mindre den 
      er blevet bedt om at træffe en afgørelse af personen eller organet, der 
      normalt ville have haft ansvar for at gøre dette.</p></li>
</ol>

<h2>§7. Projektsekretæren</h2>

<h3>§7.1. Fuldmagt</h3>

<p><a href="secretary">Sekretæren</a>:</p>
<ol>
  <li>
    <p>
      Indsamler stemmer fra udviklerne, finder ud af hvor mange udviklere der er 
      og hvem de er, når dette kræves af vedtægterne.</p></li>

  <li>
    <p>
      Kan vikariere for lederen, i fællesskab med formanden for den tekniske 
      komité.</p>

    <p>
      Hvis der ikke er en projektleder, kan formanden for den tekniske komité 
      og projektsekretæren træffe afgørelser ved enighed, hvis de mener at det 
      er vigtigt at gøre dette.</p></li>

  <li>
    <p>
      Dømmer i stridigheder om tolkning af vedtægterne.</p></li>

  <li>
    <p>
      Kan uddelegere dele af eller hele sin fuldmagt til andre, eller til enhver 
      tid trække en sådan uddelegering tilbage.</p></li>

</ol>

<h3>§7.2. Udnævnelse</h3>

<p>
  Projektsekretæren udnævnes af projektlederen og den forrige 
  projektsekretær.</p>

<p>
  Hvis projektlederen og den forrige projektsekretær ikke kan blive enige om en 
  ny udnævnelse, skal de bede SPI's bestyrelse (se §9.1) om at udnævne en ny 
  sekretær.</p>

<p>
  Hvis der ikke er en projektsekretær eller den forrige sekretær ikke kan 
  træffes og ikke har uddelegeret sin fuldmagt til en sådan beslutning, kan 
  beslutningen træffes eller uddelegeres af formanden for den tekniske komité, 
  som fungerende sekretær.</p>

<p>
  Projektsekretæren er valgt for et år ad gangen, hvorefter en ny 
  (gen)udnævnelse er nødvendig.</p>

<h3>§7.3. Fremgangsmåde</h3>

<p>
  Projektsekretæren bør træffe afgørelser som er retfærdige og rimelige, og 
  helst i overensstemmelse med konsensus blandt udviklerne.</p>

<p>
  Når projektsekretæren og formanden for den tekniske komité i fællesskab 
  vikarierer for en projektleder som ikke kan træffes, bør de kun træffe 
  beslutninger som er helt nødvendige og kun når det er i overensstemmelse med 
  konsensus blandt udviklerne.</p>


<h2>§8. Projektlederens delegater</h2>

<h3>§8.1. Fuldmagt</h3>

<p>Projektlederens delegater:</p>

<ol>
  <li>
    har fået uddelegeret en fuldmagt fra projektlederen;</li>

  <li>
    kan træffe visse afgørelser som lederen ikke kan tage på egen hånd, 
    deriblandt optagelse eller afvisning af udviklere, eller udnævne folk der 
    ikke håndterer pakker, som udviklere.
    <cite>
      Dette er for at undgå en magtkoncentration hos projektlederen, særligt med 
      hensyn til udviklermedlemskab.</cite></li>

</ol>


<h3>§8.2. Udnævnelse</h3>

<p>
  Delegaterne udnævnes af projektlederen, og lederen kan udskifte dem, som han 
  finder det passende.  Projektlederen kan ikke gøre udnævnelse betinget af at 
  delegaten træffer bestemte afgørelser, lederen kan heller ikke ophævne en 
  beslutning truffet af en delegat.</p>


<h3>§8.3. Fremgangsmåde</h3>

<p>
  Delegater kan til enhver tid træffe afgørelser, men bør prøve at opnå gode 
  tekniske vilkår og/eller følge konsensus.</p>

<h2>§9. Software in the Public Interest (<q>Software i offentlighedens interesse</q>)</h2>

<p>
  <a href="https://www.spi-inc.org/">SPI</a> og Debian er adskilte 
  organisationer, der har nogle fælles mål.  Debian er taknemlig for det 
  juridiske støtteapparat, som SPI tilbyder.
  <cite>
    Debians udviklere er pt. medlemmer af SPI i kraft af deres hverv som
    udviklere.</cite></p>


<h3>§9.1. Fuldmagt</h3>

<ol>
  <li>
    SPI har ingen fuldmagt hvad angår Debians tekniske eller ikke-tekniske 
    beslutninger, bortset fra at ingen beslutninger foretaget af Debian som 
    vedrører ejendele der administreres af SPI, kan kræve at SPI handler udenfor 
    sin juridiske fuldmagt, og Debians vedtægter kan af og til gøre SPI til en 
    afgørende myndighed, som en sidste udvej.</li>

  <li>
    Debian har ingen bestemmende kontrol over SPI, bortset fra anvendelse af 
    visse ejendele som beskrevet nedenfor, selvom Debians udviklere kan få 
    fuldmagt indenfor SPI efter SPI's regler.</li>

  <li>
    Debians udviklere er ikke repræsentanter for, eller ansat af, SPI, eller af 
    personer med fuldmagt i Debian-projektet.  En person der handler som 
    udvikler, gør dette som et individ på egne vegne.</li>
  </ol>

<h3>§9.2. Administration af ejendele til formål som vedrører Debian</h3>

<p>
  Da Debian ikke har fuldmagt til at forvalte penge eller ejendele, skal 
  donationer til Debian-projektet gives til SPI, som håndterer den slags.</p>

<p>
  SPI har påtaget sig følgende:</p>

  <ol>
    <li>
      SPI vil forvalte penge, varemærker, andre konkrete ejendele og 
      forretninger til formål som vedrører Debian.</li>

    <li>
      Sådanne ejendele vil der blive holdt særskilt regnskab for og blive 
      indsat i en fond med det formål, udvalgt af Debian og SPI i henhold til 
      denne paragraf.</li>

    <li>
      SPI vil ikke afhænde eller anvende ejendele, de administrerer for Debian, 
      uden samtykke med Debian, som kan gives af projektlederen eller via en 
      generel resolution blandt udviklerne.</li>

    <li>
      SPI vil overveje anvendelse og/eller afhændelse af ejendele de 
      administrerer for Debian, når de bliver bedt om det af 
      projektlederen.</li>

    <li>
      SPI vil anvende eller afhænde ejendele som administreres for Debian når de 
      bliver bedt om at gøre dette, via en generel resolution blandt udviklerne, 
      såfremt dette er foreneligt med SPI's juridiske fuldmagt.</li>

    <li>
      SPI vil via elektronisk post til en af Debian-projektets postlister, gør 
      opmærksom på når ejendele, der administreres for Debian, anvendes eller 
      afhændes.</li>
  </ol>


  <h2>A. Generel resolutionsprocedure</h2>

  <p>
    Disse regler gælder fælles beslutninger truffet af komitéer og ved
    afstemninger, som beskrevet ovenfor.</p>

  <h3>A.1. Forslag</h3>

  <p>
    Den formelle procedure begynder når et udkast til en beslutning er foreslået 
    og støttet, som krævet.</p>


  <h3>A.1. Diskussion og ændring</h3>

  <ol>
    <li>
      Efter forslaget er fremsat, kan resolutionen diskuteres.  Ændringsforslag 
      kan gøres formelle ved at fremsætte dem og skaffe støtter jævnfør kravene 
      for nye resolutioner, eller direkte af forslagsstilleren af det 
      oprindelige forslag.</li>

    <li>
      Et formelt ændringsforslag kan accepteres af resolutionens 
      forslagsstiller, hvorved det formelle resolutionsudkast omgående 
      ændres.</li>

    <li>
      Hvis et formelt ændringsforslag ikke accepteres, eller en af støtterne til 
      resolutionen ikke er enig med forslagsstillerens accept af et formelt 
      ændringsforslag, holdes en særskilt afstemning om dette.</li>

    <li>
      Hvis andre ikke kan lide et ændringsforslag, som er accepteret af den 
      oprindelige forslagsstiller, kan de foreslå en anden ændring for at 
      fjerne den tidligere ændring (igen skal de leve op til kravene om 
      forslagsstiller og støtte(r).)</li>

    <li>
      Forslagsstilleren af en resolution kan foreslå revideringer af 
      formuleringen af ændringensforslaget; disse træder i kraft hvis 
      forslagsstilleren af ændringsforslaget er enig og ingen af støtterne 
      protesterer.  I så fald stemmes der om det reviderede ændringsforslag i 
      stedet for det oprindelige.</li>

    <li>
      Forslagsstilleren af en resolution kan foretage ændringer for at rette 
      mindre fejl (for eksempel stavefejl eller selvmodsigelser) eller ændringer 
      som ikke forandrer meningen, såfremt ingen protesterer indenfor 24 timer.  
      I disse tilfælde starter minimumsdiskussionsperioden ikke igen.</li>
  </ol>

  <h3>A.2. Afstemning</h3>

  <ol>
    <li>
      Forslagsstilleren eller en støtte til en resolution eller et 
      ændringsforslag kan bede om afstemning efter at minimumstiden for 
      diskussion (hvis en sådan findes) er gået.</li>

    <li>
      Foreslagsstilleren eller en støtte til en resolution kan bede om en 
      afstemning vedrørende resolutionen eller alle beslægtede 
      ændringsforslag.</li>

    <li>
      Personen, der beder om en afstemning, fremsætter hvad vedkommende mener 
      resolutionens og alle relevante ændringsforslags ordlyd skal være, og 
      dermed hvilken udformning afstemningen skal have.  Dog er det 
      projektsekretæren som træffer den endelige beslutning - se §§ 7.1(1), 
      7.1(3), og A.3(4).</li>

    <li>
      Den minimale diskussionsperiode regnes fra det tidspunkt, det sidste 
      formelle ændringsforslag blev accepteret eller fra det tidspunkt hele 
      resolutionen blev fremsat, hvis ingen ændringer er blevet foreslået og 
      accepteret.</li>
  </ol>


  <h3>A.3. Afstemningsprocedure</h3>

  <ol>
    <li>
      Der stemmes på hver resolution og dennes beslægtede ændringsforslag i en 
      enkelt afstemning, der indeholder en valgmulighed som er den originale 
      resolution, hvert ændringsforslag, samt et standardvalg (hvor det er 
      muligt).</li>
      
    <li>
      Standardvalget må ikke have krav om et absolut flertal.  Valgmuligheder
      som ikke eksplicit har krav om absolut flertal, har et 1:1-krav.</li>
     
    <li>
      Stemmerne tælles jf. reglerne i A.6.  Standardvalget er <q>Yderligere
      diskussion</q> (<q>Further Discussion</q>), med mindre andet er angivet.</li>

    <li>
      I tvivlstilfælde skal projektsekretæren afgøre procedurespørgsmål.</li>
  </ol>

  <h3>A.4. Tilbagetrukne resolutioner og ikke-accepterede ændringsforslag</h3>

  <p>
    Foreslagsstilleren af en resolution eller et ændringsforslag som ikke er 
    accepteret, kan trække disse tilbage.  I så fald kan andre foreslagsstillere 
    overtage og holde resolutionen eller ændringsforslaget i live, dermed bliver 
    den første person der gør dette, den nye foreslagsstiller og de andre bliver 
    støtter, hvis de ikke allerede er det.</p>

  <p>
    En støtte til en resolution eller en ændring kan trække sig tilbage (med 
    mindre resolutionen allerede er blevet accepteret).</p>

  <p>
    Hvis foreslagsstillers og/eller støttes tilbagetrækning betyder at 
    resolutionen ikke har en foreslagsstiller eller der ikke er støtter nok, 
    holdes der ikke en afstemning, med mindre dette udredes før resolutionen 
    udløber.</p>


  <h3>A.5. Udløb</h3>

  <p>
    Hvis en foreslået resolution ikke er blevet diskuteret, ændret, stemt på 
    eller på anden måde taget hånd om i fire uger, kan sekretæren udsende en 
    besked om, at den betragtes som tilbagetrukket.  Hvis ingen af foreslagets 
    støtter har indvendiger, trækkes foreslaget tilbage.</p>
    
  <p>
    Sekretæren kan også vedlægge forslag til hvordan man fortsætter, hvis det 
    er relevat.</p>
    

<H3>A.6. Stemmeoptælling</H3>

<ol>
   <li> Hver vælgers stemme prioriterer valgmulighederne.  Man behøver ikke at 
	prioritere alle valgmulighederne.  Prioriterede valgmuligheder betragtes 
	som foretrukne fremfor valgmuligheder, der ikke er prioriteret.  Vælgere 
	kan give valgmuligheder samme prioritet.  Valgmuligheder, der ikke er 
	prioriteret, betragtes som ligestillede med hinanden.  Nærmere 
	oplysninger om hvordan stemmesedlerne skal udfyldes, vil være vedlagt 
	valgindkaldelsen.
   </li>
   <li> Hvis det beslutningsdygtige antal er R, vil enhver valgmulighed som ikke 
	er standardvalget og som ikke modtager mindst R stemmer, der prioriterer 
	den mulighed højere end standardvalget, vil ikke blivetaget i 
	betragtning.
   </li>
   <li> Alle (ikke-standard-) valgmuligheder, der ikke overgår
	standardvalgmuligheden med dens krævede flertalsgrad, tages ikke i
	betragtning.
        <ol>
             <li> 
                  Med de to valgmuligheder A og B, er V(A,B) antallet af 
		  vælgere der foretrækker mulighed A fremfor mulighed B.
             </li> 
             <li> 
                  Valgmulighed A overgår standardvalgmulighed D med 
		  flertalsgraden N, hvis V(A,D) er større end N * V(D,A).
             </li> 
             <li> 
                  Hvis et absolut flertal på S:1 er krævet af A, er dennes
		  flertalsgrad S; ellers er flertalsgraden 1.
             </li> 
        </ol>
   </li>
   <li> Ud fra listen over valgmuligheder der tages i betragtning, genereres 
	en liste over parvise nederlag.
        <ol>
             <li>
                  Valgmulighed A overgår mulighed B, hvis V(A,B) er større
		  end V(B,A).
             </li> 
        </ol>
   </li>
   <li> Ud fra en liste over parvise nederlag (som tages i betragtning), 
	genereres en liste over transitive nederlag.
        <ol>
             <li> 
                  Valgmulighed A overgår transitivt mulighed C, hvis A overgår
		  C eller hvis der er en en mulighed B, hvor A overgår B OG
		  B transitivt overgår C.
             </li> 
        </ol>
   </li>
   <li> Ud fra sættet af transitive nederlag konstruere et Schwartz-sæt.
        <ol>
             <li> 
                  Valgmulighed A er i Schwartz-sættet hvis, for alle 
		  B-muligheders vedkommende, A transitivt overgår B, eller
		  B ikke overgår A transitivt.
             </li> 
        </ol>
   </li>
   <li> Hvis der er nederlag mellem valgmuligheder i Schwartz-sættet, ses der
	bort fra de svageste af sådanne nederlag i listen over parvise nederlag, 
	og man springer tilbage til trin 5.
        <ol>
             <li> 
                  Nederlaget (A,X) er svagere end nederlaget (B,Y), hvis V(A,X)
		  er mindre end V(B,Y).  Hvis (A,X) desuden er svagere end 
		  (B,Y), hvis V(A,X) er lig med V(B,Y) og V(X,A) er større end
		  V(Y,B).
             </li> 
             <li> 
                  Et svageste nederlag, er et nederlag hvortil der ikke er et
		  svagere nederlag.  Der kan være mere end et af sådanne
		  nederlag.
             </li> 
        </ol>
   </li>
   <li> Hvis der ikke nogen nederlag i Schwartz-sættet, tages vinderen fra
	valgmulighederne i Schwartz-sættet.  Hvis der kun er en af disse
	valgmuligheder, er den vinderen.  Hvis der er flere valgmuligheder,
	afgørerer vælgeren med den afgørende stemme, hvem af disse 
	valgmuligheder, der er vinderen.
   </li>
</ol>

<p>
 <strong>Bemærk:</strong> Valgmuligheder, som vælgerne prioriterer over 
 standardvalgmuligheden, er muligheder de betragter som acceptable.
 Valgmuligheder, der prioriteres under standardvalgmuligheder, er 
 muligheder, der betragtes som uacceptable.
</p>

  <p>
    <cite>
      Når den generelle resolutionsprocedure anvendes, skal teksten som
      henviser til denne, fastsætte hvad der er tilstrækkeligt for at få
      et udkast til en resolution foreslået og/eller støttet, hvad 
      minimumstiden for diskussion er, og hvad afstemningsperioden er.  Den 
      skal også fastsætte det eventuelle kvalificerede flertal og 
      beslutningsdygtige antal, som skal anvendes.</cite></p>


  <h2>B. Brug af sprog og typografi</h2>

  <p>
    Nutid (<q>er</q>, for eksempel) betyder at udtrykket er en regel i disse 
    vedtægter.  <q>Kan</q> og <q>skal</q> indikerer at personen eller organet kan 
    anvende skøn.  <q>Bør</q> betyder at det vil anses som en god ting om hvis 
    sætningen følges, men den er ikke bindende.
    <cite>
      Tekst markeret som et citat, som dette, er baggrundsmateriale og udgør 
      ikke en del af vedtægterne.  Den kan kun anvendes til at hjælpe med at 
      tolke teksten i tvivlstilfælde.</cite>
  </p>

<p><strong>Bemærk:</strong> Dette er en oversættelse af det 
<a href="constitution.1.2.en.html">originale</a> engelsksprogede dokument.  Brug
altid originalen i diskussioner om vedtægterne, da denne dansksprogede udgave 
er oversætterens fortolkning, som desuden kan indeholde fejl og 
misforståelser.</p>