[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.3)



On Fri, 2003-01-17 at 01:05, Anders Feder wrote:
> v 0.1: Første udkast
> v 0.2: Sproglige rettelser (Jens Peter Secher)
>        Inddeling i overordnede afsnit (Carsten Svaneborg)
>        Uddybning af afsnit om åbne standarder (Carsten Svaneborg)
> v 0.3: Præcis definition af åbne standarder (Carsten Svaneborg)
>        Afsnit om totalomkostninger (Carsten Svaneborg)
>        Afsnit Open vs. Shared Source (Carsten Svaneborg)
>        Fokus på kontrol fremfor hemmeligholdelse (Daniel Udsen)
>        Afsnit om statens standardkontrakt (Carsten Svaneborg)

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ØR UAFHÆNGIGEGRÆ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.
---------------------------------------------------------------------------------------------------------

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.

VÆKSTFREMMENDE MARKEDSVILKÅR
I regeringens vækststrategi “Vækst med vilje” fra maj 2002 hedder det
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.

[mere om softwarepatenter]

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.

[mere om Open Source]

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.

* 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 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 for langsom til at rette kendte
sikkerhedshuller risikerer man at de i mellemtiden misbruges af
kriminelle. 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.

* Åbne standarder
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 sikrer garantien at enhver har mulighed for
at kræve adgang til standardernes fuldstændige specifikationer og
offentliggøre dem for at åbne dem på den måde i stedet.

Påstår Microsoft f.eks. at den nyeste version af Word version anvender
å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 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 i stedet for Word uden derved at krænke Microsofts
patentrettigheder.

Dette krav er vigtigt for at undgå en udvanding af begrebet “åben
standard”. Borgerne bør have adgang til sådan en “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.

* Softwarepatenter
Vi foreslår at staten tager ansvaret for softwarepatent krænkelse ved
brugen af Open Source programmer.

En Open Source service virksomhed 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 service virksomhed gøre
baseret på leverandør-ejet software.

Den store forskel er at Open Source service virksomheden ikke har nogen
mulighed for at undersøge om softwaren krænker softwarepatenter,
hvorimod service virksomheden der sælger IT-løsninger baseret på
leverandørejet software kan få sådan en garenti 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?

OPEN SOURCE-BEGREBET
Open Source Software er meget populært 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.

Open Source betyder bogstaveligt at kildekoden er tilgængelig. Men det
at kildekoden til et softwareprodukt er tilgængeligt er ikke nok til at
gøre det til Open Source, fordi det kræves også blandt andet at
brugeren/forbrugeren har retten til at ændre kildekoden og at
distribuere ændret kildekode.

Open source er egentligt mere omkring kontrol end offentligørelse af
kildekode. 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, der giver institutioner lov til at læse kildekoden, men den
påkrævet non-disclosure aftaler betyder at Microsoft ikke giver brugeren
nogle af de rettigheder som Open Source gør. Derved er sikrer Microsoft
at afhængigshedsforholdet er uændret.

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. [mere]

[sammenfatning af øvrige afsnit]

-- 
Anders Feder <sslug@sslug>



 
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] *