[an error occurred while processing this directive] [an error occurred while processing this directive][an error occurred while processing this directive] [an error occurred while processing this directive] [an error occurred while processing this directive] [an error occurred while processing this directive] (none) [an error occurred while processing this directive] [an error occurred while processing this directive] [an error occurred while processing this directive] [an error occurred while processing this directive] [an error occurred while processing this directive][an error occurred while processing this directive] [an error occurred while processing this directive][an error occurred while processing this directive] [an error occurred while processing this directive][an error occurred while processing this directive] [an error occurred while processing this directive] [an error occurred while processing this directive] [an error occurred while processing this directive] (none) [an error occurred while processing this directive] [an error occurred while processing this directive] [an error occurred while processing this directive][an error occurred while processing this directive]
 
[an error occurred while processing this directive] [an error occurred while processing this directive]
Skåne Sjælland Linux User Group - http://www.sslug.dk Home   Subscribe   Mail Archive   Forum   Calendar   Search
MhonArc Date: [Date Prev] [Date Index] [Date Next]   Thread: [Date Prev] [Thread Index] [Date Next]   MhonArc
 

Re: [ITPOLITIK] B 27: Udkast til udvalgshenvendelse (v 0.4)



On Sat, Jan 25, 2003 at 03:18:23PM +0100, Anders Feder wrote:
> Her er så v0.4 af B 27-svaret. changelog kommer senere.
> 
> Det er en rå ASCII-konvertering fra OpenOffice så små afvigelser kan
> forekomme.
> 
> --
> Kære medlemmer af Udvalget for Videnskab og Teknologi,
> 
> Som [soundbite] har vi læst SF's forslag til folketingsbeslutning om en
> offensiv konkurrencestrategi, der udnytter open source-software og åbne
> standarder (B 27) med stor interesse. Vi er glade for at se at
> Folketinget er opmærksomme på implikationerne af den softwarepolitik
> staten fører. Vi vil her forsøge at redegøre for vores syn på de forhold
> forslaget berører.
> 
> Liberalisering af softwaremarkedet
> Det blev under førstebehandlingen flere gange nævnt at man ikke ønsker
> at pålægge regeringen en bestemt leverandør eller et bestemt produkt.
> Lad os derfor en gang for alle understrege at noget sådant lægger
> hverken forslaget eller Open Source-modellens natur op til. Det er helt
> klart at den informationsteknologiske udvikling, i såvel stat som
> udenfor, på lang sigt gavner bedst ved at det offentlige vælger de
> løsninger der bedst imødekommer statens behov.
> 
> Men der er en lang række forudsætninger der skal opfyldes før end
> markedsmekanismen kan fungere. Videnskabsministeren nævner selv at
> indkøbsprisen ikke altid giver et reelt billede af de samlede
> omkostninger ved at skifte softwareplatform. Det burde i sig selv få
> advarselslamperne til at blinke, for det medfører at når de offentlige
> beslutningstagere én gang har valgt softwareplatform, så binder de sig
> faktisk til den. Derfor risikerer man, som vi mener at det i meget høj
> grad er tilfældet i dag, at statens penge ikke tilfalder den teknologisk
> bedste leverandør men derimod den leverandør som man af historiske
> årsager har låst sig fast på.
> 
> Leverandøruafhængige grænseflader
> Denne såkaldte lock-in effekt er ikke teknisk betinget. Den skyldes
> derimod i vid udstrækning at visse softwareleverandører i dag ikke ser
> det i deres interesse at give brugeren mulighed for at skifte til en
> konkurrende platform. I stedet forhindrer man brugeren i at foretage
> sådant et skift ved at benytte lukkede filformater og protokoller som
> konkurrende, og potentielt bedre, softwareprodukter ikke har mulighed
> for at anvende. Der er altså tale om praksis, ikke en teknisk
> nødvendighed.
> 
> Ved at benytte systemer der anvender lukkede dokument- og
> kommunikationsstandarder graver man en grav for sig selv idet et senere
> behov for at skifte til en bedre softwareplatform gøres unødigt
> omfangsrigt og omkostningsfuldt. Således stilles fremtidens offentlige
> forvaltning i et konstant dilemma mellem at enten spilde ressourcer på
> selve omstillingen eller falde bagefter den teknologiske udvikling.
> 
> Derfor vil vi kraftigt fraråde staten at indkøbe software udviklet efter
> denne praksis fremover. Det bør blive et klart krav at alt software til
> brug i det offentlige baserer sig på åbne standarder der defineres som
> følger:
> 
>   Ved en åben standard forstås en standard, hvis fuldstændige
>   specifikationer frit stilles tilgængelig for enhver, og som ikke er
>   omfattet af resktriktioner på implementering og anvendelse.

Husk nu: "og som er udviklet i en åben proces."
Du sagde du ville tage dette med.

> Det betyder at en enkelt leverandør ikke kan kontrollere standardens
> anvendelse, eller skabe hindringer for konkurrenter, ved f.eks. at holde
> dele af standarden hemmelig, eller ved at kræve licenser til
> softwarepatenter, der dækker metoder som er nødvendige for at
> implementere eller anvende standarden.

Det betyder også at enkelte aktører ikke kan bestemme standarden, men at
alle kan have en rimelig indflydelse på den åbne standards udforming.
> 
> Vækstfremmende markedsvilkår
> I regeringens vækststrategi ???Vækst med vilje??? fra maj 2002 hedder det
> bl.a. at:
> 
> ???Innovation og dynamik er en forudsætning for, at dansk erhvervsliv i
> fremtiden kan være konkurrencedygtigt og fleksibelt. Iværksættere er en
> vigtig kilde til innovation og dynamik i økonomien.???1
> 
> I dag er vilkårene for unge danske softwarevirksomheder imidlertid
> trange.
> 
> I patentkapløbet om at få mest "krydslicenseringskapital" er taberne de
> små og mellemstore virksomheder, fordi deres udgifter til at markedsføre
> innovative softwareprodukter påvirkes stærkt af licensbetingelserne til
> de store virsomheders patentporteføljer. De små risikerer at blive kvalt
> af innovationsskatten. Dette kaldes i den økonomiske litteratur for et
> ???patent hold-up???.
> 
> De små og mellemstore virksomheder har typisk ikke kompetencer til at
> udtage softwarepatenter, eller økonomiske og juridiske ressourcer til at
> finde patentkrænkere og retsforfølge dem, hvis det er nødvendigt. De er
> magtesløse i forsøget på at forhindre at deres patenter krænkes.
> Patentbeskyttelse er ikke økonomisk rationelt for mange små og
> mellemstore virksomheder. At små og mellemstore virksomheder ikke
> patenterer er således ikke et problem, der kan løses med en PR kampagne.
> 
> Dette betyder dog ikke at små og mellemstore virksomheders innovationer
> er ubeskyttede. Undersøgelser viser at de gør brug af en lang række
> alternative beskyttelsesmetoder f.eks. copyright og time-to-market.
> 
> En dynamisk IT-infrastruktur
> Ligesom lukkede standarder binder forvaltningens data til de få
> leverandører der har mulighed for at implementere standarderne, så
> binder lukkede kildekoder servicering og videreudvikling af statens
> IT-infrastruktur til de få leverandører der har mulighed for at gennemse
> og rette kildekoden.
> 
> Situationen minder om tilstandende på telemarkedet for et par år siden
> hvor kun én enkelt virksomhed havde kontrol over hele Danmarks
> teleinfrastruktur. Derfor manglede det økonomiske incitament til at
> udvikle teknologien så den kunne imødekomme det kraftigt stigende og
> varierede kommunikationsbehov IT-samfundet bragte med sig.
> 
> Ligesom teleinfrastrukturens ydelser hele tiden skal videreudvikles og
> tilpasses de enkelte kunders skiftende behov, så kræver en
> IT-infrastruktur løbende opdatering og servicering for at hele tiden at
> passe til brugerens arbejdsopgaver. Situationen i dag hvor langt den
> overvejende del af den software der anvendes i det offentlige er
> leverandørejet betyder imidlertid at disse serviceringsopgaver kun kan
> udføres af den oprindelige udvikler. Markedets udvikling har altså reelt
> ingen inflydelse på kvaliteten og prisen af de serviceydelser der
> foretages indenfor statens IT-infrastruktur.
> 
> [Statens IT-infrastruktur bør være åben for markedskræfterne]
> 
> Open Source-begrebet
> Tankerne bag Open Source software bliver stadig mere populære og derfor
> er Open Source-begrebet god reklame for et softwareprodukt. Af samme
> årsag er det vigtigt at forstå præcist hvad begrebet går ud på, og undgå
> at begrebet bliver udvandet i reklameøjemed.
> 
> Begrebet er defineret som følger:
> 
>   Ved Open Source software forstås software som distribueres under en
>   Open Source licens godkendt af organisationen Open Source Initiative
>   (http://www.opensource.org)
> 
> Karakteristisk for Open Source licenser er at de sikrer forbrugeren
> fri og ubegrænset adgang til softwarens kildekode,
> retten til at rette, forbedre og videreudvikle denne, samt
> retten til at videredistributere både den originale og den forbedrede
> software og dennes kildekode.
> 
> Det er ikke et krav til Open Source programmer at de skal være gratis.
> 
> Bogstaveligt talt betyder Open Source at kildekoden er tilgængelig men
> det er altså ikke nok til at gøre et program til Open Source, idet det
> bl.a. også kræves at brugeren har ret til at ændre kildekoden og
> viderdistributere denne.
> 
> Open Source handler således mere om kontrol af kildekoden end dens
> offentligørelse. Det men den offentlige tilgængelige kode er egentligt
> bare en bivirkning ved det oprindelige mål "At ingen skal nagte
> slutbrugeren at modificere værket i samarbejde med andre slutbrugre" med
> stort tryk på samarbejde. Det der er problemet med den model hvor man
> kun offenligør kildekode er at de begrenser slutbrugerens mugligheder
> for at søge samrabejdspartnere ofte er det sådan at slutbruger kun må
> samarbejde med leverendør.
> 
> Et godt eksempel på et bastardiseret Open Source er Microsofts Shared
> Source-koncept, der lader store kunder lov læse kildekoden, men kun
> efter indgåelse af en non-disclosure aftale som fravrister kunden en
> lang række af de rettigheder Open Source tilbyder. Derved sikrer
> Microsoft at afhængigshedsforholdet er uændret.
> 
> Statens standardkontrakt
> Når det offentlige søger softwareleverandører bør der i
> handelsbetingelserne ikke indgå formkrav der stiller bestemte
> teknologier bedre end andre. Vi foreslår at statens standardkontrakt for
> standardiserede edb-systemer (K 18) ændres på en række punkter for at
> sikre lige konkurrence mellem leverandørejet software og Open Source. 
> 
> Statens standardkontrakt er ikke kun en snæver kontrakt mellem en
> statslig indkøber og en software leverandør. Den er også en aftale
> mellem leverandøren og danske borgere og virksomheder, fordi softwaren
> bruges som et digitalt grænselag mellem staten på den ene side og
> borgere og virksomheder på den anden side.
> 
> Leverandører skal således sikre at borgere og virksomheder kan
> kommunikere frit og uhæmmet med staten. Ligeledes har staten et ansvar
> for at datalevetiden sikres, så data ikke forgår fordi de er gemt i
> lukkede dataformater, der ikke længere kan læses. Det er f.eks. ironisk
> at 500 år gamle kirkebøger stadig kan læses i dag, mens Microsoft
> Word-filer gemt for blot ganske få år siden i dag er ulæselige. Staten
> har også en særlig pligt til at holde data fra borgere og virksomheder
> fortroligt, og leverandører bør derfor ikke kunne frasige sig et ansvar
> for konsekvenserne af sikkerhedsfejl i den software de leverer.
> 
> Statens indkøb betales med skattepenge, og der er derfor vigtigt at få
> den bedste software for pengene set i et samfundsøkonomisk perspektiv,
> og ikke blot et snævert perspektiv, der kan lede til kassetænkning.
> 
> Open Source software der udvikles til staten kan genbruges af borgere og
> virksomheder og på den måde reducere samfundets samlede udgifter i
> forbindelse med digital kommunikation med staten. Ligeledes kan adgang
> til Open Source software også sikre at virksomheder hurtigt kan
> digitalisere deres kommunikation med staten.
> 
> Brugen af åbne standarder sikrer åbenhed og valgfrihed af
> kommunikationssoftware mellem borgere, virskomheder og staten, og undgår
> at kommunikationsteknologien monopoliseres. Adgang til Open Source
> software udviklet for staten kan lede til spill-over effekter, hvor
> virksomheder og borgere lettere og billigere kan kommunikere digitalt
> med det offentlige og hinanden.
> 
> En sammenligning af totalomkostninger ved bestemte softwareprodukter vil
> derfor ikke altid være et optimalt mål for den samfundsøkonomiske effekt
> der følger af valget af et softwareprodukt.
> 
> Følgende er et tænkt eksempel om digital signatur.
> 
> En digital signaturteknologi baseret på en åben standard sikrer at ingen
> virksomhed kan monopolisere markedet for software til
> signaturteknologien, og derved bygge en mur mellem stat, borgere og
> virksomheder. En åben standard sikrer også at brugen ikke  forudsætter
> indkøb af patentlicenser (der findes en række europæiske
> softwarepatenter på digitale signaturer) hvorfor danske signaturer også
> skulle kunne anvendes i udlandet. Derved undgår virksomheder at skulle
> betale licens til tredjepart for at kommunikere med staten. Endeligt
> sikrer en Open Source implementation af signaturteknologien at borgere
> og virksomheder omkostningsfrit kan anvende de digitale signaturer,
> uafhængigt af valget af IT-platform, ligesom virksomheder
> omkostningsfrit får afgang til software der gør det muligt at læse
> kundernes digitale signature.
> 
> Det er umiddelbart indlysende at en Open Source implementation af
> digitale signaturer baseret på åbne standarder har en væsentlig positiv
> samfundsøkonomisk effekt sammenlignet med en implementation baseret på
> leverandørejet software og lukkede standarder. Statens samlede udgifter
> ved hver af de to licensformer udgør i denne sammenhæng et relativt
> irrelevant sammenligningsgrundlag.
> 
> I det følgende fremsætter vi en række forslag til hvordan statens
> standardkontrakt K 18, kan ændres for at sikre en ligevægtig konkurrence
> mellem Open Source software og leverandørejet software, for at sikre
> leverandøren incitamenter til at levere sikker software, samt
> definitioner af åbne standarder og Open Source, og krav til
> leverandører, der sikrer at de samfundsøkonomiske fordele diskuteret
> ovenover realiseres, og ikke forhindres ved en udhulning af begreberne
> Open Source og åbne standarder.
> 
> Definitioner
> Vi anbefaler at vores definitioner af åbne standarder og Open Source
> indføjes i K 18, for at sikre at disse begreber ikke undermineres med
> vagere og mere uklare definitioner.
> 
>   Ved en åben standard forstås en standard, hvis fuldstændige
>   specifikationer frit stilles tilgængelig for enhver, og som ikke er
>   omfattet af resktriktioner på implementering og anvendelse.
> 
> Vi anbefaler at standardkontrakten ændres så den pålægger leverandøren
> at garantere at softwaren baserer sig på åbne standarder. Dette
> indebærer at leverandøren skal stille standardernes fuldstændige
> specifikationer frit til rådighed for enhver der beder om det, og
> garantere at enhver kan implementere og anvende standarderne uden derved
> at krænke softwarepatenter eller andre immaterielle rettigheder.
> 
> Påstår levandøren at deres software er baseret på åbne standarder uden
> dette faktisk er tilfældet skal garantien sikre at enhver har mulighed
> for at kræve adgang til standardernes fuldstændige specifikationer og
> offentliggøre dem for at tvangsåbne dem på den måde i stedet.
> 
> Påstår Microsoft f.eks. at den nyeste version af
> tekstbehandlingsprogrammet Word er baseret på åbne standarder bør
> virksomheden naturligvis kunne pege på disse standarders fuldstændige og
> frit tilgængelige specifikationer, således at f.eks. Open
> Source-udviklere kan sætte software såsom OpenOffice.org i stand til
> fuldstændigt at erstatte Microsoft Word-produktet. Dette er ikke muligt
> med mindre den fulde dokumentation til dokumentstandarden er offentlig
> tilgængeligt. Ligeledes bør en leverandør, der baserer en IT-løsning på
> f.eks. Microsoft Word kunne garantere brugerene at de kan anvende
> OpenOffice.org i stedet for Word uden derved at krænke Microsofts
> immaterielle rettigheder.
> 
> Dette krav er vigtigt for at undgå en udvanding af begrebet ???åben
> standard???. Borgere og virksomheder bør have adgang til en sådan
> ???dåseåbner??? til forvaltningens evt. lukkede standarder for altid at
> kunne kommunikere med staten uden at være tvunget til at købe samme
> softwareplatform.
> 
>   Ved Open Source software forstås software som distribueres under en
>   Open Source licens godkendt af organisationen Open Source Initiative
>   (http://www.opensource.org)
> 
> Vi anbefaler at standardkontrakten ændres så den pålægger leverandører
> af Open Source software at garantere at den tilhørende kildekode er
> tilgængeligt for enhver der beder om det under en Open Source licens
> godkendt af Open Source Initiative.
> 
> Disse to krav garanterer at en leverandør ikke kan kalde et produkt for
> Open Source eller påstå at det er baseret på åbne standarder uden dette
> er tilfældet. Fordi de giver enhver borger eller virksomhed retten til
> kræve kildekoden udleveret, således at den kan genanvendes og forbedres,
> eller fuld dokumentation og frihed til at bruge en standard således at
> borgeres kommunikation med staten sikres.
> 
> Typisk vil de kunne opfyldes ved at leverandøren på sin hjemmeside
> poster et link til en standardorganisation, hvor dokumentation kan
> findes, samt et link hvor kildekoden til softwaren kan hentes. En
> leverandør af Open Source vil allerede på forhånd opfylde disse krav, og
> kravet vil derfor være omkostningsfrit for en levandør. 
> 
> Sikkerhed
> Vi anbefaler at standardkontrakten ændres således at leverandøren skal
> betale erstatning for skader forårsaget af sikkerhedsfejl som
> leverandøren har haft kendskab til men ikke har rettet inden for en
> rimelig tid. På grund af sikkerhedsfejlenes konsekvenser for
> IT-samfundet og den digitale forvaltning bør der skabes stærke
> incitamenter for leverandøren til at få dem rettet hurtigst muligt.
> 
> Softwarefejl findes i alle programmer, hvad enten de er leverandørejede
> eller Open Source. Men er leverandøren langsom til at rette kendte
> sikkerhedshuller risikerer man at de misbruges af kriminelle i
> mellemtiden. Levandøren bør derfor informere kunderne hurtigst muligt
> efter at blive gjort opmærksom på sikkerhedsfejl, og bør efter en
> periode på 1-2 uger bære det økonomiske ansvar for de skader fejlene har
> forårsaget. Leverandøren kan ikke gøres ansvarlig for problemer, der
> skyldes forkert konfigureret software, manglende opdateringer, fejlbrug
> af software eller fejl som leverandøren ikke er informeret om, men kun
> problemer der skyldes for langsomme rettelser.
> 
> Softwarepatenter
> Vi foreslår at staten tager ansvaret for softwarepatentkrænkelse ved
> brugen af Open Source programmer.
> 
> En Open Source servicevirksomhed kan tage eksisterende Open Source
> programmer fra nettet og tilpasse dem for at skabe en IT-løsning, der
> kan sælges til det offentlige. Det samme kan en servicevirksomhed gøre
> med leverandørejet software.
> 
> Open Source servicevirksomheden har imidlertid ikke nogen mulighed for
> at undersøge om softwaren krænker softwarepatenter, hvorimod
> servicevirksomheden der sælger IT-løsninger baseret på leverandørejet
> software kan få sådan en garanti fra sin leverandør.
> 
> Samme problem gælder hvis en offentlig institution vælger at hente Open
> Source programmer direkte fra nettet, og bruge dem uden tilpasning,
> f.eks. OpenOffice.org tekstbehandlings programmet. Hvem tager så
> ansvaret for krænkelse af softwarepatenter?
> 
> Totalomkostninger
> De samlede omkostninger et softwareprodukt afstedfører i løbet af hele
> dets levetid (Total Cost of Ownership, TCO) bruges ofte som mål når der
> skal vælges softwareløsninger.
> 
> Det er dog vigtigt at være opmærksom på at et sådant tal aldrig kan være
> mere end et groft estimat, idet ikke kun softwaren, men også markeds- og
> teknologiudviklingen over tid og IT-infrastrukturen i den institution
> hvor softwaren anvendes er vigtige faktorer i lignelsen. Man kan derfor
> ikke sammenligne estimater for totaludgifter uden at kende
> usikkerhederne og antagelserne der indgår i at udarbejde disse
> estimater.
> 
> Nogle få eksempler på de mange usikre elementer estimatet bygger på:
> 
> estimeringen af udgifter til løbende opdatering af softwaren, der
> prissættes af leverandøren undervejs,
> estimeringen af indtægtstigninger pga. øget effektivitet efterhånden som
> arbejdsgange tilpasses den indkøbte software,
> estimeringen af stordriftsfordele, herunder muligheden for at dele
> erfaringer og udviklingsprojekter mellem flere institutioner der
> anvender samme produkt,
> estimeringen af udgifter til ekspert- og konsulentbistand efterhånden
> som konkurrenceforhold ændres pga. markedssammensætningen,
> estimeringen af udgifter til vedvarende softwaredesignfejl, f.eks. i
> form af virus og orme, der skaber udgifter til anti-virus software og
> dets vedligeholdelse,
> estimeringen af transitionsudgifter ved enden af programmets levetid.
> 
> For blot at fremhæve ét konkret eksempel kan det nævnes at en
> undersøgelse foretaget af ITIC/Sunbelt Software i 20022 viste at
> Microsofts reviderede licensbetingelser betød at udgifterne ved at
> anvende teksbehandlingsprogrammet Word (?) steg 200-300% for knap en
> femtedel af de adspurgte virksomheder.
> 
> Vi foreslår at der nedsættes en arbejdsgruppe, der påtager sig at
> definere saglige ???best  practice???-kriterier for hvordan
> totalomkostningerne ved software anslås på basis af erfaringer med både
> leverandørejet software og Open Source Software, således at en objektiv
> økonomisk sammenligning tilstræbes.
> 
> Opgør med tryghedskulturen
> Endelig må det være en helt åbenlys forudsætning for den digitale
> forvaltnings success at de offentlige IT-chefer rundt omkring i landet
> vitterligt vælger den bedste løsning når de skal indkøbe software. Det
> syntes ikke nødvendigvis at være tilfældet i dag. I et debatindlæg under
> overskriften "Open source handler om tryghed" i ComputerWorld d. 5.
> november 2002 beretter direktør Jørgen Kunter Pedersen og projektchef
> Esben Wolf, Teknologisk Institut om hvordan den offentlige forvaltning
> har en tendens til at vælge den software man kender i forvejen fremfor
> for den software der er den mest økonomisk forsvarlige.
> 
> Det betyder at man fra regeringens side, og indirekte Folketingets i
> kraft af dets kontrolfunktion, skal være bedre til at holde de
> offentlige IT-chefer ansvarlige for deres softwarepolitik end man er i
> dag og ikke acceptere en henvisning til hvad andre plejer at gøre som et
> sagligt beslutningsgrundlag. 
> 
> Som debatindlægget udtrykker det så må man også være parat til at hjælpe
> med at levere den ???tryghed??? som visse andre softwareprodukter er
> omfattet af. Det kan f.eks. ske ved at iværksætte pilotprojekter som
> både SF's beslutningsforslag og Teknologirådets rapport fra oktober
> lægger op til.
> 
> Sammenfatning
> I et samfund med et frit marked bestemmer leverandørerne selv om de ved
> at anvende åbne standarder vil gøre det muligt for kunden at skifte
> softwareplatform eller ej. Derfor er der kun én aktør der kan redde
> staten ud af den ???lock-in??? situation den står i nu og det er staten
> selv. Vi anbefaler derfor at gøre det til et krav at al software anvendt
> i det offentlige baserer sig på åbne standarder.
> 
> I dag udsteder staten reelt eneretter til servicering og vedligeholdelse
> af den offentlige IT-infrastruktur idet kun nogle ganske få dominerende
> leverandører har mulighed for at servicere og viderudvikle den
> leverandørejede software der anvendes i forvaltningen.
> 
> [sammenfatning af øvrige afsnit]
> 
> -- 
> Anders Feder <sslug@sslug>
> 
> 
> sslug-itpolitik er, som SSLUGs ?vrige emaillister, et frit debatforum 
> hvor hvert enkelt medlem er ansvarlig for sine egne indl?g. Indl?g #12032
> 


 
Home   Subscribe   Mail Archive   Index   Calendar   Search

 
 
Questions about the web-pages to <www_admin>. Last modified 2005-08-10, 20:20 CEST [an error occurred while processing this directive]
This page is maintained by [an error occurred while processing this directive]MHonArc [an error occurred while processing this directive] # [an error occurred while processing this directive] *