K E N D E L S E

Klagenævnet for Udbud	X.xx.: 21/10232
(Xxxxx X. Xxxxxxxxxxx, Xxxxxxx Xxxxxxx)	21. juni 2022

K E N D E L S E

Inlead ApS

(advokat Xxxxxx Xxxxxxxxx, Hellerup) mod

Det Digitale Folkebibliotek

(advokat Xxxxxx Xxxxx og advokat Xxxxxx Xxxxxxxx Xxxxxx, Hellerup)

Ved udbudsbekendtgørelse nr. 2021/S 136-362842 offentliggjorde Det Digi- tale Folkebibliotek (”DDF”) den 16. juli 2021 en bekendtgørelse med henblik på frivillig forudgående gennemsigtighed (profylaksebekendtgørelse) vedrø- rende en kontrakt om udvikling af basisplatformen til DDB CMS Next, som DDF ønskede at indgå med Reload A/S (”Reload”).

Den 10. august 2021 indgik DDF kontrakt med Reload. Kontraktindgåelsen blev offentliggjort ved udbudsbekendtgørelse nr. 2021/S 156-414042 den 13. august 2021.

Den 9. september 2021 indgav Inlead ApS (”Inlead”) klage til Klagenævnet for Udbud over DDF. Inlead fremsatte ved klagens indgivelse anmodning om, at klagenævnet i medfør af lov om Klagenævnet for Udbud § 12, stk. 1, skulle beslutte, at klagen skulle have opsættende virkning. Den 15. oktober 2021 besluttede klagenævnet ikke at tillægge klagen opsættende virkning. Klagen har været behandlet skriftligt.

Inlead har nedlagt følgende påstande:

Påstand 1

Klagenævnet for Udbud skal konstatere, at Det Digitale Folkebibliotek har handlet i strid med ligebehandlings- og gennemsigtighedsprincippet i ud- budslovens § 2 og § 6 ved at have indgået en aftale med Reload A/S om udvikling af basisplatformen til DDB CMS Next uden forudgående offent- liggørelse af en udbudsbekendtgørelse, idet betingelserne i udbudslovens § 80, stk. 3, ikke er opfyldt.

Påstand 2

Klagenævnet for Udbud skal annullere Det Digitale Folkebiblioteks beslut- ning af 12. juli 2021 om at tildele kontrakt om udvikling af basisplatformen til DDB CMS Next til Reload A/S.

Påstand 3

Klagenævnet for Udbud skal erklære aftalen mellem Det Digitale Folkebib- liotek og Reload A/S om udvikling af basisplatformen til DDB CMS Next for uden virkning, jf. lov om Klagenævnet for Udbud § 17.

Påstand 4

Klagenævnet for Udbud skal idømme Det Digitale Folkebibliotek en økono- misk sanktion i den udstrækning kontrakten med Reload A/S om udvikling af basisplatformen til DDB CMS Next ikke erklæres for uden virkning, jf. lov om Klagenævnet for Udbud § 18 og 19, subsidiært indgive politianmel- delse i henhold til lov om Klagenævnet for Udbud § 18, stk. 2, og § 20.

Påstand 5 (subsidiær til påstand 3)

Klagenævnet skal komme med en foreløbig, ikke bindende udtalelse om, at der ikke foreligger særlige forhold, der tilsiger, at kontrakten videreføres, jf. lov om Klagenævnet for Udbud § 14a.

DDF har vedrørende påstand 1 - 4 nedlagt påstand om, at klagen ikke tages til følge, og vedrørende påstand 5 nedlagt påstand om afvisning.

Klagenævnet har den 10. september 2021 meddelt DDF’s kontraktpart, Reload, at det er muligt at intervenere i sagen, jf. lov om Klagenævnet for Udbud § 6, stk. 5.

Reload har ikke besvaret klagenævnets henvendelse.

Sagens nærmere omstændigheder:

Af punkt II.I.4) i profylaksebekendtgørelsen (udbudsbekendtgørelse nr. 2021/S 136-362842) fremgår, at udbuddet havde til formål at danne grundla- get for udviklingen af brugergrænsefladen til bibliotekernes fælles hjemme- sider (DDB CMS) ved at etablere fundamentet og de værktøjer, som udvik- lingen af brugergrænsefladen tager udgangspunkt i.

Af bekendtgørelsens punkt II.1.7) fremgår, at udbuddets samlede værdi er opgjort til 1.091.239 kr.

Bekendtgørelsens punkt II.2.4) indeholder følgende beskrivelse af udbuddet:

”Det Digitale Folkebibliotek der varetager opgaver, der primært omhand- ler bibliotekernes digitale brugergrænseflader og digitale tilbud til bor- gerne, har igangsat Next Projektet. Projektet skal med fem (5) indbyrdes forbundne opgaver opgradere bibliotekernes hjemmesideløsning. Ud- buddet af kontrakten om udvikling af basisplatformen til DDB CMS Next er den første kontrakt i Next projektet. Formålet med kontrakten er at danne grundlaget for udviklingen af brugergrænsefladen ved etablering af det fundament og de værktøjer, som udviklingen af brugergrænsefla- den tager udgangspunkt i, samt dokumentation af samme, så andre aktø- rer kan involveres i udviklingsarbejdet. Opgaven omfatter bl.a. oprettel- sen af kode- og design repositorier, og byggeværktøjer, som udviklerne skal bruge for opsætning af lokale udviklingsmiljøer, så de kan bidrage til kodebasen, samt en build-pipeline, som skal muliggøre continuous de- ployment af miljøer. Det er ønsket at en installationsprofil med Drupal 9 og React etableres med grundlæggende service integrationer som kan danne grundlaget for udviklingen af brugergrænsefladen i de øvrige del- kontrakter i Next Projektet. Basisplatformen skal lette arbejdet med at udføre og kvalitetssikre efterfølgende delprojekter.”

Bekendtgørelsens punkt IV.1.1) indeholder følgende beskrivelse af procedu- ren:

”Proceduretype:

Udbud med forhandling uden forudgående offentliggørelse

• Kun en bestemt økonomisk aktør kan levere de pågældende bygge- og anlægsarbejder, varer eller tjenesteydelser af følgende årsag:

• manglende konkurrence af tekniske årsager Forklaring:

Det følger af udbudslovens § 80, stk. 3, nr. 2, at en ordregiver kan an- vende udbud med forhandling uden forudgående offentliggørelse, når:

i) bygge- og anlægsarbejderne, varerne eller tjenesteydelserne kun kan leveres af en bestemt økonomisk aktør og

ii) den manglende konkurrence skyldes tekniske årsager.

Adgangen til at gennemføre udbud med forhandling uden forudgående offentliggørelse gælder således i situationer, hvor det er objektivt udeluk- ket, at andre aktører vil kunne levere anskaffelsen. Det pågældende af- grænsede opgave og opfyldelse af kontrakten udvikling af basisplatfor- men kræver specialistviden i meget høj grad. Der kan ikke kun peges på en enkelt teknisk årsag, men en række tekniske årsager der med sikkerhed samlet kan begrunde, at der må antages at være manglende konkurrence, ligesom enkelte tekniske årsager isoleret set muligvis også selvstændigt kan begrunde denne antagelse. Leverandøren skal have indsigt i it-bibli- oteksinfrastrukturens opbygning og de datastrukturer, der benyttes i sek- toren, fx biblioteksdatafelter mv. For at kunne løse opgaven kræves der viden om det eksisterende CMS og den eksisterende build pipeline, her- under bestående uhensigtsmæssigheder, erfaring med at bygge cloudba- seret drift set up og specialistkompetencer i forhold til at foretage inte- grationer til biblioteksinfrastrukturen og bibliotekssystemet. Der er end- videre tale om en unik national it-struktur med DBC-Databrønden som et centralt værktøj bestående af diverse poster, herunder Nationalbibliogra- fien, med integrationer til de lokale systemer. Det Digitale Folkebibliotek har også opdelt opgaverne under Next projektet i 5 delkontrakter for at fremme konkurrencen om opgaverne. Således at det kun er nærværende afgrænsede opgave om udvikling af basisplatformen som den tekniske årsag er knyttet til, og som anvender udbud med forhandling uden forud- gående offentliggørelse, mens de øvrige dele af Next projektet udbydes separat.”

Inden offentliggørelsen af bekendtgørelsen havde DDF udarbejdet ”Notat om DDB CMS Next opgaver og basisplatformen”. Af notatet fremgår bl.a.:

”BAGGRUND:

DDF’s brugerteam og jurateam har på en række møder drøftet, hvordan opgaverne vedrørende den sammenhængende digitale bibliotekstjeneste NEXT konkurrenceudsættes/udbydes i overensstemmelse med de ud- budsretlige regler, herunder navnlig om det er berettiget at anvende ud- budslovens § 80, stk. 3, nr. 2 om udbud med forhandling uden forudgå- ende offentliggørelse ”på grund af manglende konkurrence af tekniske årsager.”

I dette notat opsummeres disse drøftelser i en vurdering af retsstillingen efter de udbudsretlige regler for NEXT-opgaverne og særligt for gennemførelse af opgaven med basisplatformen.

1. GENNEMFØRELSE AF BASISPLATFORMEN ER AF HAST- ENDE OG NØDVENDIG KARAKTER

Jurateamet har nøje gransket Drupal Community og diverse andre open source-udviklingssamarbejders vurderinger af konsekvenserne for it-sik- kerheden af manglende opgradering ved Drupal 7 end-of-life (EOL). Der er helt overvejende enighed om, Drupal 7- og 8-websites efter EOL vil blive eksponeret for hacking og sikkerhedsbrud. Websites, der ikke er opgraderede, vil endvidere efter EOL blive markeret som ”usikkert” for tredjepart, der tilgår websitet. DDF, der er databehandler for samtlige kommuner vedrørende alle behandlinger af personoplysninger i folkebib- liotekernes fælles brugergrænseflader mv. med en række underdatabe- handlere, kan ikke løbe en risiko ved ikke hurtigt at foretage opgradering af den fælles CMS-løsning, der endvidere ikke kan vurderes i den risiko- vurdering, der løbende skal foretages og kontrolleres indgående af den årlige it-revision. Opgaven med basisplatformen har således hastende ka- rakter.

2. NEXT-OPGAVERNE

Det er intentionen, at NEXT-opgaverne konkurrenceudsættes i overens- stemmelse med det tidligere DDB’s flerleverandørstrategi. Til gennem- førelse af opgaverne set samlet under et kræves der i videre udstrækning specialistviden og -kompetencer vedrørende dansk it-biblioteksinfra- struktur, bibliografiske data og sammenhængen mellem de bestående it- tekniske løsninger og anvendte it-teknologier. Der er på markedet en lille kreds af leverandører, som vil kunne byde kvalificeret ind på opgaver på de forskellige områder. Gennem samarbejdet med leverandørkredsen i regi af DDB har DDF indgående indsigt i, hvilke kompetencer og hvilken viden de enkelte leverandører i leverandørkredsen besidder.

3. AFGRÆNSNING AF NEXT-OPGAVERNE OG VALG AF UD- BUDSFORM

Brugerteamet ved projektledelsen har identificeret nogle områder eller opgavekategorier, hvor opgaverne er indbyrdes forbundne og bedst kan gennemføres samlet, og flere leverandører i konkurrence vil kunne byde ind på opgaver. Områderne er på nuværende tidspunkt afgrænset i kate- gorierne ”Lånerstatus og brugerprofil”, ”Søgning”, ”Biblioteksinforma- tion”, ”Biblioteksfilialer og åbningstider” og ”Udvidet visning af arran- gementer”. Brugerteamet gør imidlertid opmærksom på, at denne afgræs- ning ikke er endelig, idet tidsfaktoren kan bevirke, at opgaver fra en ka- tegori må overføres til en anden kategori, eller at nogle områder må slås sammen. Der er imidlertid et væsentligt problem med opgaven vedrø- rende etablering af basisplatformen, idet kun en enkelt leverandør, it-

virksomheden Reload, inden for de givne tidsmæssige rammer vil kunne sikre gennemførelse af opgaven efter de krav, der må stilles hertil. Hvis alle NEXT-opgaverne derfor konkurrenceudsættes samlet, vil kun Reload teknisk kunne opfylde udbudskravene.

Jurateamet bemærker, at opgaverne i så fald må udbydes i delkontrakter, jf. hertil udbudslovens § 49, der finder anvendelse på udbud i henhold til udbudslovens afsnit II. (…)

4. GENNEMFØRELSE AF BASISPLATFORMEN

Basisplatformen skal integreres og arbejde sammen med andre af DDF’s tjenester og med systemer på andre områder af it-biblioteksinfrastruktu- ren, som DDF ikke er bestiller eller ejer af eller leverandør til i overens- stemmelse med den bestående forretningsmodel eller de investeringer, som DDF gennem en periode har foretaget. Til gennemførelse af opgaven kræves specifik indsigt i it-biblioteksinfrastrukturens opbygning og de datastrukturer, der benyttes i bibliotekssektoren, det kræver viden om det eksisterende-CMS og den eksisterende build pipeline samt erfaring med at bygge cloudbaseret drift set up. Endvidere kræver det specialiserede kompetencer i forhold til at foretage integrationer til biblioteksinfrastruk- turen og bibliotekssystemet. Brugerteamet finder, at det kun it-teknisk vil være muligt for it-virksomheden Reload at gennemføre opgaven med etablering af basisplatformen.

AD SPECIFIK INDSIGT I IT-BIBLIOTEKSINFRASTRUKTURENS OPBYGNING OG DATA STRUKTURER:

- Reload har udarbejdet API-specifikationen til FBS CMS-API’et med udgangspunkt i det tidligere bibliotekssystem DDELibra.

- Reload har rådgivet om og udarbejdet ”Openformat-rapporten” ved- rørende integration til FBS (Det Fælles Bibliotekssystem) og har stor erfaring med arbejde med React-komponenter fra client-side i den Fælles Biblioteksinfrastruktur.

AD VIDEN OM DET EKSISTERENDE CMS OG DEN EKSISTE- RENDE BUILD PIPELINE SAMT ERFARING MED AT BYGGE CLOUDBASERET DRIFT SET-UP:

- Reload har udviklet store dele af den eksisterende build pipeline ved- rørende Github, Circle C1 og Xxxxxxxx.xx.

- Reload har stor og indgående erfaring med automatiske test suit til testning af kode, tilgængelighed mv.

- Reload har ydet væsentlig bistand med CMS-designsystem – kode- base, strukturelt i Github mv.

- Reload har udviklet applikationsarkitekturen til Ding2, der danner ba- sis for eksisterende DDB CMS som underleverandør til DBC.

- Reload har rådgivet om udvikling af de dataformater, som DBC nu er ved at implementere i Fælles Biblioteksinfrastruktur, på grundlag af erfaringer fra DDB CMS.

- Reload har udviklet de første webservices i overensstemmelse med Det Digitale Folkebiblioteks GDPR- og forretningsstrategi for etab- lering af hosting-platform i Microsoft Azure set up, hvor DDF har investeret betydelige ressourcer i at træffe sikkerhedsforanstaltninger (brug af GUID) mod risikoen for, at personoplysninger overføres til USA fra amerikansk ejet hosting-leverandør, der hoster personoplys- ningerne i Europa.

AD SPECIALISEREDE KOMPETENCER I FORHOLD TIL AT FO- RETAGE INTEGRATIONER TIL BIBLIOTEKSINFRASTRUKTU- REN:

- Reload har stor erfaring med Kubernetes, som i Azure-drift set up svarer til andre af DDF’s digitale services.

- Reload har erfaring med Lagoon, som er Apache 2-licenseret og ReactJS, som er på en MIT-licens. Lagoon kan være den eneste løs- ning, der imødekommer DDF’s GDPR-krav.

- Reload arbejder med Azure-løsninger.

- Reload har udviklet det første proof of concept på de produktionsklare client-side React-komponenter, som er i drift på nuværende DDB CMS. Proof of concept er centralt for gennemførelse af basisplatfor- men, da det er bevis på at der kan integreres til de bagvedliggende webservices fra client side React komponenter. Komponenterne un- derstøtter flere forskellige funktioner i Drupal fx oversættelse, brug ad administrationsgrænseflade mv.

5. ER OPGAVEN MED BASISPLATFORMEN UDBUDSPLIGTIG? Jurateamet er i tvivl om, hvorvidt opgaven med basisplatformen må an- tages at være udbudspligtig som en selvstændig opgave. Det bemærkes herved, at den økonomiske ramme, der er fastsat for gennemførelse af basisplatformen, ligger væsentligt under tærskelværdien for udbud af tje- nesteydelser for offentlige organer efter afsnit II i udbudsloven. Det be- mærkes endvidere, at etablering af basisplatformen udgør grundlaget for den efterfølgende udvikling på de andre områder, fx lånerstatus og bru- gerprofil samt søgning. Hvis ikke basisplatformen fungerer, og alt den udviklede kode med tilhørende dokumentation er publiceret i Github, kan de øvrige opgaver under NEXT ikke gennemføres. Der er således med opgaven vedrørende basisplatformen tale om en selvstændig opgave, og det er helt indlysende, at der ikke foretages en kunstig opdeling af fortlø- bende opgaver hos samme leverandør e.l. Den fælles hjemmesideløsning DDB CMS har ikke tidligere har været i udbud. Den er udviklet i et digi- talt samarbejde (Ding-samarbejdet) mellem en række biblioteker og DBC.

Jurateamet ved ikke, om der vil kunne anvendes en profylaksebekendt- gørelse til offentliggørelse af tildeling af en opgave med en økonomisk værdi under tærskelværdien, hvis der er tvivl om, hvorvidt opgaven skal betragtes som en del af et større samlet udbud eller ej.

6. ANVENDELSE AF UDBUDSLOVENS § 80, STK. 3, NR. 2 (”MANGLENDE KONKURRENCE AF TEKNISKE ÅRSAGER”)

Det bemærkes, at udbudslovens § 80, stk. 3, nr. 2 som en undtagelse til de almindelige udbudsregler skal fortolkes indskrænkende. Fortolknin- gen må imidlertid gøre det muligt at sikre undtagelsens effektive virkning i overensstemmelse med dens formål. Hvis bestemmelsen fx ikke skal ses inden for visse tidsmæssige rammer, ville de fleste leverandører it-tek- nisk på et tidspunkt blive i stand til at gennemføre enhver nok så kompli- ceret it-teknisk opgave, og udbudslovens § 80, stk. 3, nr. 2, ville i givet fald ikke have noget reelt anvendelsesområde.

It-virksomheden Reload findes at være den eneste leverandør, det er mu- ligt for at gennemføre opgaven med basisplatformen inden for de mini- mumstidsfrister, der er fastsat i udbudslovens bestemmelser, hvorved be- mærkes, at opgaven med basisplatformen er af hastende karakter. Der findes ikke et marked for tjenesteydelser bestående i etablering af en ba- sisplatform til en sammenhængende digital bibliotekstjeneste og fælles national hjemmesideløsning med over 100 lokale websites. Der er en kreds af leverandører, hvis kompetencer og viden DDF har indgående kendskab til, der kvalificeret vil kunne byde ind på NEXT-opgaverne på de forskellige områder. Men det er kun Reload, der af de anførte tekniske grunde vil kunne løfte opgaven med basisplatformen.

Det bemærkes, at de tekniske årsager til at Reload agtes tildelt opgaven med basisplatformen, også begrundes i krav om specifik interoperabilitet. Det bemærkes herved, at vurderingen af hvorvidt de tekniske årsager som anført i udbudslovens § 80, stk. 3, nr. 2, er til stede i det konkrete tilfælde må bero på DDF’s it-tekniske indsigt og viden om Reload og den øvrige leverandørkreds og overblik over sammenhængen og samspillet mellem DDF’s mange brugergrænseflader og basisplatformens integration med it-biblioteksinfrastrukturen i øvrigt. Der kan ikke indhentes en sagkyndig uafhængig udtalelse om DDF’s vurdering, idet de enkelte leverandører i leverandørkredsen vil være inhabile.

Det skal desuden endelig påpeges, at der vil blive foretaget en opdeling af de samlede NEXT-opgaver i delkontrakter, således at de andre NEXT- opgaver udbydes efter de sædvanlige regler.

Det må på den anførte baggrund antages, at udbudslovens § 80, stk. 3, nr. 2, kan finde anvendelse på opgaven med basisplatformen.”

Af kontrakten indgået med Reload fremgår bl.a.:

”Bibliotekernes lokale hjemmesider udgør sammen med bibliotekets fæl- les app-løsning ”Biblioteket” brugernes digitale indgang til langt største- delen af bibliotekernes tilbud. Bibliotekernes fælles hjemmeside (be- nævnt ”DDB CMS”) blev rullet ud til de første biblioteker i 2014 og byg- ger på Drupal 7 CMS (Drupal 7 har EOL i november 2021, hvor den officielle community-support og Drupal Associations support ophører). Derfor skal DDB CMS genetableres, hvilket realiseres med projektpro- grammet ”DDB CMS NEXT”.

DDB CMS NEXT skal opgradere hjemmesideløsningen og realisere de projekter, der ligger i folkebibliotekernes fælles vision og handleplan, der danner ramme om det fremtidige arbejde med bibliotekernes fælles CMS og app som en samlet biblioteksservice. Målet med projektet er en gene- rel genetablering af den forretningsfunktionalitet, bibliotekerne har prio- riteret i DDB CMS med særligt fokus på søge- og formidlingsgrænsefla- den.

Denne genetablering af forretningsfunktionalitet forudsætter en etable- ring af basisplatformen. Formålet med basisplatformen er at danne grund- laget for udviklingen af brugergrænsefladen. Gennem udvikling af basis- platformen etableres en installationsprofil med grundlæggende service- integrationer med Drupal 9 og Reactkomponenter samt dokumentation heraf.

Basisplatformen skal understøtte leverancer fra flere eksterne leverandø- rer og biblioteker, ligesom den samlede applikation skal kunne udrulles til medlemmerne af foreningen Det Digitale Folkebibliotek der på nuvæ- rende tidspunkt omfatter de 98 danske folkebiblioteker samt biblioteker på Færøerne, Grønland og Sydslesvig.”

DDF har oplyst, at kontrakten indgået med Reload om basisplatformen er udført og afsluttet, og at sidste rate af vederlaget ifølge kontrakten er faktu- reret den 17. december 2021 og betalt af DDF den 6. januar 2022. I alt er der faktureret 1.091.230 kr. for det udførte arbejde med basisplatformen i over- ensstemmelse med den aftalte kontraktsum.

Inlead har i klageskriftet oplyst følgende om sig selv:

”2.1.1 Inlead ApS

Inlead ApS er et digitalt kommunikationsbureau og softwarevirksomhed, der siden 1999 har leveret digitale løsninger, og som siden 2005 har spe- cialiseret sig i levering af løsninger til folkebiblioteker i Danmark og ud- landet.

Inlead råder over betydelige kompetencer inden for og erfaring med ud- vikling af digitale løsninger til biblioteker.

Inlead har således gennem en årrække leveret ydelser til Det Digitale Fol- kebibliotek (”DDF”) og har herunder – ligesom flere andre leverandører, herunder Reload A/S – medvirket til at udvikle DDF’s CMS/hjemme- side-platform, som Inlead således er indgående bekendt med.

I dag driver Inlead 16% af de danske folkebibliotekers hjemmesider. Denne drift sker baseret på Det Digitale Folkebiblioteks CMS/hjemme- side platform, der bygger på såkaldte ”Open Source”-teknologier.

Inlead har i forhold til sine kunder udvidet Det Digitale Folkebiblioteks CMS/hjemmeside-platform med egne tekniske og forretningsmæssige forbedringer. Inlead har via dette arbejde opnået yderligere indgående kendskab til Det Digitale Folkebiblioteks platform.

Inlead fungerer også som systemintegrator. Inlead har således løbende gennem en årrække arbejdet med den danske biblioteksinfrastruktur, her- under leveret løsninger til hovedparten af aktørerne i den danske biblio- tekssektor, bl.a. som underleverandør til Systematic, der leverer Biblio- tekssystemet (ILS) til alle danske folkebiblioteker, og som underleveran- dør til DBC, der leverer den grundlæggende databrønd til sektoren.

Udover hjemmesider leverer Inlead skærm-, mail- og special-løsninger til danske biblioteker, og samlet set betjener Inlead ca. 30% af de danske folkebiblioteker med it-løsninger.

…”

DDF har i svarskriftet oplyst følgende om sig selv: ”2.1 Kort om Det Digitale Folkebibliotek

DDF blev etableret som en forening i maj 2020 med det formål at stille

digitale services, tilbud og materialer til rådighed for folkebiblioteker og borgere i Danmark. DDF er en videreførelse og udvikling af tidligere samarbejder, således at opgaver fra Danskernes Digitale Bibliotek (DDB) og eReolen nu hører under DDF’s ansvar.

DDF driver dermed public service-virksomhed ved at arbejde for at fremme oplysning, uddannelse og kulturel aktivitet via udvikling og drift af folkebibliotekernes digitale tilbud og services til kommunernes bor- gere. For at imødekomme disse formål har bestyrelsen i DDF besluttet, at DDF skal udvikle og drive services og tilbud i forhold til it-bruger- grænseflader mv. samt indkøb af e-litteratur og licenser.

…”

Parternes anbringender

Ad påstand 1

Inlead har gjort gældende, at DDF retsstridigt har indgået kontrakt med Reload uden forudgående gennemførelse af et udbud.

Indgåelse af en udbudspligtig kontrakt uden forudgående gennemførelse af et udbud er en åbenbar og grov overtrædelse af ligebehandlings- og gennem- sigtighedsprincippet i udbudslovens § 2, og efter EU-Domstolens faste prak- sis den alvorligste form for overtrædelse af udbudsreglerne, jf. bl.a. EU- Domstolens dom af 11. januar 2005 i sag C-26/03, Stadt Halle og RPL Lochau. En sådan ulovlig kontraktindgåelse er også en tilsidesættelse af for- pligtelsen i henhold til udbudslovens § 6, der foreskriver, at ordregiver skal følge de procedurer, der er fastlagt i udbudslovens afsnit II.

Inlead har endvidere vedrørende spørgsmålet, om basisplatformen er ud- budspligtig, anført, at kontrakten med Reload om basisplatformen indgår som et af flere indbyrdes forbundne delelementer af DDF’s anskaffelse af en ny hjemmesideløsning. Der er således tale om en samlet anskaffelse af en ny hjemmesideløsning, som DDF har valgt at opdele i flere ”indbyrdes for- bundne” ”delkontrakter”/”delprojekter”.

Det er ud fra de foreliggende oplysninger åbenbart, at kontrakten udgør en delkontrakt, som repræsenterer udførelsen af en del af en større, samlet an- skaffelse af en ny hjemmesideløsning til DDF (Next-projektet). At DDF har valgt som led i sin angivelige ”flerleverandørstrategi” at opdele opgaven i flere delkontrakter, der udbydes hver for sig, ændrer ikke på, at der ved af- gørelse af udbudspligten skal tages udgangspunkt i værdien af den samlede anskaffelse.

Værdien af den samlede anskaffelse vil overstige tærskelværdien, når henses til, at den første af de 5 delkontrakter i sig selv mindst beløber sig til 1,1 mio. kr., og det er da heller ikke bestridt af DDF, at værdien af det samlede IT- projekt overstiger tærskelværdien for EU-udbud.

DDF’s ”Notat om DDB CMS Next opgaver og basisplatformen” og profy- laksebekendtgørelsen viser i øvrigt klart, at DDF har været af den opfattelse, at kontrakten som udgangspunkt var udbudspligtig. Profylaksebekendtgørel- sen fastlægger således i pkt. IV.1.1, at DDF har valgt udbudsproceduren ”ud- bud med forhandling” med henvisning til udbudslovens § 80, stk. 3, nr. 2. Hvis kontrakten slet ikke var udbudspligtig, ville § 80, stk. 3, nr. 2, ikke finde anvendelse, idet der i så fald ville have været tale om en anskaffelse omfattet af udbudslovens afsnit IV eller V. Der ville i så fald heller ikke være behov for overhovedet at offentliggøre en profylaksebekendtgørelse.

Inlead har endvidere vedrørende udbudslovens § 80, stk. 3, nr. 2, gjort gæl- dende, at udbudslovens § 80, stk. 3, nr. 2, er en undtagelse til det generelle krav i udbudslovens afsnit II om, at indgåelse af offentlige kontrakter kun kan ske efter forudgående gennemførelse af et udbud. Da bestemmelsen er en undtagelse, skal den efter EU-Domstolens og klagenævnets faste praksis fortolkes indskrænkende, og der påhviler ordregiver en streng bevisbyrde for, at betingelserne for at anvende undtagelsen er opfyldt.

Det fremgår udtrykkeligt af udbudslovens § 80, stk. 4, at undtagelsen i § 80, stk. 3, nr. 2, kun kan anvendes, ”når der ikke findes et rimeligt alternativ eller erstatning og den manglende konkurrence ikke er et resultat af en kunstig indskrænkning af udbudsvilkårene”.

Af udbudsdirektivets præambel 50, som også er gentaget i lovbemærknin- gerne, fremgår, at undtagelsen kun kan ”anvendes under helt ekstraordinære omstændigheder”, at ”kun situationer med objektiv eksklusivitet kan beret- tige anvendelsen af udbud med forhandling uden offentliggørelse, hvor situ- ationen med eksklusivitet ikke er skabt af den ordregivende myndighed selv med henblik på den fremtidige udbudsprocedure”, at ”ordregivende myndig- heder, som gør brug af denne undtagelse, bør angive grundene til, at der ikke er rimelige alternativer eller erstatninger”, og at ”hvis situationen med eks- klusivitet skyldes tekniske årsager, bør de defineres nøje og dokumenteres i hvert enkelt tilfælde. De kunne f.eks. bestå i, at det vil være noget nær teknisk umuligt for en anden økonomisk aktør at sikre den krævede gennemførelse,

eller at det er nødvendigt at anvende specifik knowhow, specifikke værktøjer eller midler, som kun en enkelt økonomisk aktør har til sin rådighed.”

Det forhold, at opgaven kræver specialistviden i meget høj grad kan ikke be- grunde, at der ikke gennemføres udbud. Det vil således være tilfældet for et meget betydeligt antal opgaver, herunder også inden for it-området.

Det skal objektivt kunne påvises, at kun én bestemt aktør har eller kan tilve- jebringe den pågældende specialistviden.

DDF har ikke på tilstrækkelig måde godtgjort, at it-virksomheden Reload var den eneste virksomhed, der kunne løse opgaven.

DDF eller DDF’s brugerteam havde ikke et sådant ”indgående kendskab” til den mulige leverandørkreds, at DDF kunne basere sin beslutning på dette kendskab alene. DDF’s brugerteams it-tekniske kompetencer er på et meget begrænset niveau, og det er nærliggende at antage, at brugerteamets vurde- ring i væsentlig udstrækning har været påvirket af rådgivning, som DDF har modtaget fra Reload. DDF’s kendskab til Inleads kompetencer og forudsæt- ninger har været helt utilstrækkeligt til at danne grundlag for den foretagne vurdering.

Inlead har et omfattende markedskendskab, en betydelig indsigt og kompe- tence inden for biblioteksløsninger og har arbejdet indgående med DDF’s CMS/hjemmeside-platform. Inlead har således i betydelig grad medvirket til udviklingen af DDF’s CMS/hjemmeside-platform, ligesom Inlead leverer supplerende ydelser hertil, hvorfor Inlead er fuldt bekendt med DDF’s nuvæ- rende løsning. Inlead er f.eks. den eneste virksomhed i Danmark, der vareta- ger alle facetter vedrørende det DDB CMS-system, som opgaven knytter sig til, herunder udvikling, vedligehold, opdateringer, opsætning af drifts- og staging miljø, server, OS, mittleware og applikationsdrift, overvågning, kunde-support, kundeudvikling m.v.

Inlead har 1) arbejdet med biblioteksinfrastrukturen og tilhørende datamo- deller i mere end 10 år, 2) drevet og udviklet på DDB CMS og dets forgæn- gere i mere end 10 år, 3) udbudt DDB CMS som cloud løsning i mere end 10 år og 4) integreret DDB CMS til mere end 5 bibliotekssystemer og forskellige versioner af infrastrukturen i løbet af denne periode. Inlead leverer allerede i dag et CMS-system til ca. 16% af markedet for CMS på biblioteksområdet

(16 af DDF’s medlemmer), udvikler en CMS-platform til professionshøjsko- lerne, driver løsninger til danske fagbiblioteker og driver en CMS-platform til ca. 15 % af det norske folkebiblioteksmarked.

Kravene om ”indsigt i it-biblioteksinfrastrukturens opbygning og de data- strukturer, der benyttes i sektoren, fx biblioteksdatafelter mv.” og ”viden om det eksisterende CMS og den eksisterende build pipeline, herunder bestående uhensigtsmæssigheder” udelukker ikke, at der gennemføres et udbud.

Inlead har omfattende indsigt i it-biblioteksinfrastrukturens opbygning og de datastrukturer, der benyttes i sektoren, herunder biblioteksdatafelter m.v. In- lead har således fungeret som leverandør af løsninger til førende aktører in- den for den danske biblioteksinfrastruktur, ligesom Inlead har medvirket til udviklingen af DDF’s CMS/hjemmeside-platform. Inlead har også et særde- les indgående kendskab til DDF’s CMS/hjemmeside-platform, og kravet om viden om det eksisterende CMS og build pipeline kan også opfyldes af In- lead. Inlead har erfaring med at bygge et cloudbaseret drift set-up, idet det netop er det, Inlead har gjort i forhold til de ca. 16% af de danske biblioteker, som Inlead leverer driftsydelser til.

Det er ikke nærmere begrundet, hvorfor ”specialistkompetencer i forhold til at foretage integrationer til biblioteksinfrastrukturen og bibliotekssystemet” skulle være afgørende. Selv hvis sådanne specialistkompetencer skulle være afgørende, er Inlead netop via sit mangeårige virke – dels som leverandør til danske biblioteker, dels som leverandør til førende aktører inden for den dan- ske biblioteksinfrastruktur (eks. Systematic og DBC) og dels som leverandør til DDF i relation til DDF’s CMS/hjemmeside-platform – i besiddelse af så- danne specialistkompetencer. DDF har under alle omstændigheder ikke godt- gjort, at Reload er den objektivt set eneste leverandør, der kan foretage så- danne integrationer.

Udsagnet om, at der er ”tale om en unik national it-struktur med DBC-Data- brønden som et centralt værktøj bestående af diverse poster, herunder Natio- nalbibliografien, med integrationer til de lokale systemer”, er et generelt, fak- tuelt udsagn, som ikke indeholder nogen nærmere begrundelse for, hvorfor Reload objektivt set skulle kunne være den eneste mulige leverandør af den tildelte opgave. Inlead har i øvrigt betydelig indsigt i og erfaring med DBC- databrønden og integrationer til de lokale systemer, idet Inlead i en årrække har optrådt som leverandør til bl.a. DBC.

Det er misvisende, når DDF giver indtryk af, at DDF besidder et indgående kendskab til Inleads kompetencer via et løbende forretningssamarbejde, idet Inlead ikke har haft større tekniske leverancer til DDF i de seneste år. Der- imod har Inlead i de seneste år udbygget sine kompetencer betydeligt, dels ved udvikling af egne proprietære løsninger, som baserer sig på DDF’s løs- ning (DDB CMS), dels som hovedudvikler på Filmstriben, et biblioteks stre- amingunivers, der i kompleksitet er meget lig DDB CMS, og for øvrigt drevet på et azure server-setup. Inlead er også hovedleverandør af Atesis’ løsning, som er en løsning med samme funktionalitet som DDB CMS, rettet imod fag- og forskningsbiblioteker.

Begrebet ”specifik interoperabilitet” henviser til to forskellige systemers mu- lighed for at arbejde sammen. Hvis man f.eks. har et system A og vil tilkøbe et system B, som skal kunne fungere sammen med A, skal der være interope- rabilitet mellem disse systemer. Når forarbejderne til udbudslovens § 80 taler om, at kravet om specifik interoperabilitet i særlige tilfælde kan begrunde undladelse af at gennemføre udbud, er det denne sammenhæng mellem for- skellige systemer, der henvises til, navnlig fordi f.eks. immaterielle rettighe- der til system A kan bevirke, at kun indehaveren af disse immaterielle ret- tigheder vil kunne levere system B. Det er derfor helt ved siden af, når DDF anfører, at Inleads ”manglende tekniske viden [….] kommer til udtryk i manglende interoperabilitet”. Hverken Inlead eller Reload skal således som led i den omtvistede kontrakt levere bestående systemer eller udstyr, der skal kunne opfylde et krav om ”specifik interoperabilitet” med DDF’s bestående system. Opgaven er derimod en forberedende udviklingsopgave, hvor kravet om ”specifik interoperabilitet” slet ikke er relevant.

DDF påstår, at Inlead har ”manglende tekniske viden om biblioteksinfra- strukturen, datastrukturer og sammenhængen til den eksisterende CMS setup”. Denne påstand er ubegrundet, og der er ikke fremlagt nogen form for dokumentation for påstanden eller redegjort for nogen form for faktiske un- dersøgelser eller henvist til nogen form for konkrete bevisligheder, der un- derstøtter dette udsagn. Det mest konkrete, der er henvist til af DDF, er, at der har været nogle diskussioner mellem Inleads og DDF’s medarbejdere, som har angået nogle strukturelle forhold, der intet har med den konkrete opgave at gøre.

Generelt er softwarevirksomheder og digitale kommunikationsbureauer m.v. vant til, at de for at kunne løse deres opgaver skal sætte sig ind i komplekse bestående forhold, og der er ikke påvist omstændigheder, der begrunder, at alene Reload skulle være i besiddelse af eller skulle kunne tilegne sig en så- dan indsigt.

Det er således åbenbart ukorrekt, at Reload objektivt set skulle være den ene- ste, der har en sådan erfaring.

Den indgåede kontrakt fremtræder som en helt sædvanlig kontrakt, hvad an- går de beskrevne ydelser. Kontrakten indeholder således ikke nogen antyd- ning af, at Reload har haft særlige rettigheder eller særlig knowhow, som har været af afgørende betydning for Reloads leverance.

Det følger af det anførte, at der ikke ved DDF’s angivelser i profylaksebe- kendtgørelsen er påvist nogen begrundelse for, at Reload objektivt set er den eneste mulige leverandør. Det forhold, at Reload muligvis som tidligere eller bestående leverandør vil have en konkurrencemæssig fordel i et udbud af den tildelte opgave, kan ikke i sig selv begrunde, at der ikke gennemføres udbud. Det er heller ikke en begrundelse, at det muligt vil være nemmere eller hur- tigere for DDF at indgå kontrakt direkte med Reload uden udbud. Det udgør heller ikke nogen begrundelse for at undlade udbud, at kontrakten tilvejebrin- ger forudsætningerne for senere konkurrence om andre kontrakter.

DDF skal påvise, at det objektivt set ikke vil være muligt for andre at løse opgaven, og bevisbyrden herfor har DDF ikke løftet. Betingelserne for at bruge undtagelsen i § 80, stk. 3, er således ikke opfyldt i den konkrete sag, herunder henset til den strenge praksis der gælder efter såvel EU-Domstolens som klagenævnets praksis.

Opgavens eventuelle hastende karakter kan heller ikke begrunde, at der kan indgås kontrakt med Reload efter udbudslovens § 80, stk. 3, nr. 2.

End-of-life (EOL) for Drupal 7 er blevet forlænget, senest til 28. november 2022, og samtidig er der etableret mulighed for, at organisationer, der benyt- ter sig af Drupal 7, kan købe sig til ”extended support” frem til november 2025, hvilket reelt indebærer, at EOL for Drupal 7 først er i november 2025.

Globalt er der mellem ca. 300.000 til 550.000 aktive Drupal 7 websites (af- hængig af kilde). I Danmark er der mindst 3.100 websites baseret på Drupal 7, herunder flere kommuner og mange andre store løsninger. Der er forment- lig en del flere. Med så mange websites baseret på Drupal 7 vil der utvivlsomt være mange, der fortsætter efter den officielle EOL-dato, og der vil derfor også være et kommercielt marked for virksomheder, der tilbyder extended support. Til illustration kan nævnes, at i dag er der Drupal 6 support hos kommercielle virksomheder frem til og med november 2023. Officiel support af Drupal 6 stoppede februar 2016. Dvs. Drupal 6, som var langt mindre end Drupal 7, er der kommerciel extended support på i mere end 7,5 år efter EOL- datoen. For den langt større Drupal 7, vil der derfor givetvis være extended support i længere tid end for Drupal 6.

Som eksempel på en af de mange kommercielle operatører, som tilbyder sup- port på Drupal 6 og Drupal 7, kan henvises til xxxxxxXxxxxxx.xxx (”MDW”). MDW’s supportmuligheder dækker sikkerhedsopdatering af alle moduler, som DDF ikke selv har produceret. Byrden med den løbende sik- kerhedsopdatering vil således efter EOL ikke være større for DDF end den er i dag, hvis man fx køber support fra MDW til ca. 99 USD per måned for den grundlæggende ”Security Updates Plan”. MDW vil ikke skulle behandle DDF’s personoplysninger for at kunne levere ”extended support”, og det er derfor uden betydning for muligheden for at erhverve ”extended support” af Drupal 7, om MDW har henvist til EU-US Privacy Shield. Alle it-virksom- heder har i hvert fald frem til EU-Domstolens dom af 16. juli 2020 i Xxxxxxx XX-sagen haft fuld anledning til at tro, at EU-US Privacy Shield var det kor- rekte og valide retlige grundlag for udveksling af personoplysninger mellem USA og EU, og at det i dag fortsat er uklart, hvad der gælder som retligt grundlag. Der er derfor ikke noget mærkeligt i, at MDW har henvist hertil. At MDW har henvist hertil i sine generelle forretningsbetingelser betyder i øvrigt ikke, at MDW rent faktisk behandler personoplysninger i forbindelse med levering af ”extended support”, eller at en sådan behandling i øvrigt vil ske i USA. DDF har heller ikke undersøgt, om MDW i forbindelse med le- veringen af ”extended support” ville skulle foretage nogen behandling af per- sonoplysninger i USA, eller om dette – selv hvis det skulle være tilfældet – kunne løses på en anden måde. Der er da heller intet i DDF’s ”Notat om DDB CMS Next opgaver og basisplatformen”, som antyder, at DDF har været i dialog med MDW eller andre leverandører af ”extended support” med hen- blik på reelle undersøgelser af muligheden for at købe ”extended support” i

den kortere overgangsperiode, som ville være nødvendig, indtil et udbud kunne være gennemført.

Det fremgår i øvrigt af Drupals hjemmeside, at Drupal-organisationens Se- curity Team fortsat vil bistå leverandørerne af ”extended support”.

Realiteten er, at der er intet i ”Notat om DDB CMS Next opgaver og basis- platformen”, som på mindste måde antyder, at DDF har foretaget en reel og dybdegående vurdering af, om DDF’s behov kunne løses ved ”extended sup- port”, indtil et udbud kunne være gennemført.

Der er således ingen anledning til at tro, at det skulle være afgørende, om basisplatformen er tilvejebragt primo december 2021 eller de måneder se- nere, som et udbud af basisplatformen eventuelt ville bevirke.

Det bemærkes i den forbindelse også, at det fremgår af kontrakten, at de af- leveringstidspunkter, som er aftalt med Reload, alene er ”vejledende”, hvil- ket på ingen måde understøtter, at det tidsmæssige aspekt skulle være afgø- rende for valget af Reload.

Derudover følger det af EU-Domstolens faste praksis, at hvis en ordregiver vil påberåbe sig hastende omstændigheder som begrundelse for at undlade udbud, må den hastende karakter på ingen måde kunne henføres til ordregi- vers egne forhold. EOL for Drupal 7 og Drupal 8 har været kendt gennem meget lang tid. På Xxxxxxx egen hjemmeside kan man uden videre finde op- slag tilbage til i hvert fald 25. februar 2019, hvoraf den oprindelige EOL fremgår.

DDF har bevisbyrden for, at DDF ikke ved rettidig omhu kunne have und- gået, at forholdet fik den hastende karakter, som forholdet nu påstås at have fået, f.eks. ved at have iværksat et udbud før. Heller ikke det forhold, at no- tatet er dateret 13. april 2021, men at kontrakten først er indgået ca. 4 måne- der senere understøtter, at der reelt har været tale om hastende omstændighe- der.

Sammenfattende er det således klart, at DDF ikke har løftet sin strenge be- visbyrde for, at betingelserne for at undlade udbud efter udbudslovens § 80 har været opfyldt.

DDF har gjort gældende, at DDF ikke har handlet i strid med ligebehand- lingsprincippet og gennemsigtighedsprincippet i udbudslovens § 2, idet DDF har skabt mest mulig gennemsigtighed om kontraktindgåelsen, idet der blev offentliggjort en profylaksebekendtgørelse, og idet kontrakten blev indgået efter udløbet af 10-dages perioden efter profylaksebekendtgørelsens offent- liggørelse i EU-tidende. DDF har derudover i videst muligt omfang tilstræbt at tildele kontrakten på markedsvilkår for derved at kunne iagttage ligebe- handlingsprincippet.

DDF har vedrørende spørgsmålet, om basisplatformen er udbudspligtig, gjort gældende, at kontrakten om basisplatformen ikke er udbudspligtig. Kontrakten har, som det fremgår af profylaksebekendtgørelsen, en værdi på knap 1,1 mio. kr., dvs. væsentligt under tærskelværdien på ca. 1,6 mio. kr., og er derfor slet ikke omfattet af udbudslovens afsnit II, jf. § 6, stk. 1, nr. 3. Det er derfor uden betydning, om betingelserne i udbudslovens § 80, stk. 3, nr. 2, er opfyldt eller ej.

Next-projektet består af i alt seks leverancer, hvoraf de fem skal udbydes senere i separate udbud. Kontrakten om basisplatformen er omvendt allerede indgået og bliver gennemført uafhængigt af efterfølgende kontrakter, uanset hvordan disse kontrakter måtte blive udbudt. Det er ikke således, at værdien af alle indkøb, en ordregiver foretager, skal sammenlægges, når det vurderes, om en række selvstændige kontrakter tilsammen har en værdi, så hver enkelt kontrakt er udbudspligtig. Det forhold, at der i et projekt er en lang række forudsætninger, der skal være opfyldt, for at projektet kan gennemføres, be- tyder ikke, at alle dele af disse forudsætninger skal indgå i beregningen af den anslåede kontraktværdi. Basisplatformen har til formål at være bindeled mellem eksisterende biblioteksinfrastruktur og kommende leverancer. De øvrige Next-projekter har forretningskarakter, idet projekterne digitalt vil un- derstøtte de opgaver, som DDF har til ansvar at løse. Basisplatformen adskil- ler sig derfor væsentligt indholdsmæssigt i forhold til de øvrige leverancer under Next-projektet.

Basisplatformen er ikke en del af de fem delprojekter. Tværtimod er virke- ligheden den, at først når basisplatformen er implementeret, kan de fem pro- jekter, der ganske rigtigt er indbyrdes forbundne i udbudslovens forstand, gennemføres.

Kontrakten om basisplatformen er indgået tidsmæssigt forskudt fra de øvrige kontrakter, og da leverancerne under kontrakten om basisplatformen ind- holdsmæssigt er uafhængig af de efterfølgende leverancer, er der tale om en selvstændig kontrakt, der ikke værdimæssigt skal lægges sammen med vær- dien af de øvrige og efterfølgende kontrakter om leverancer i Next-projektet.

Der er desuden tale om en situation, hvor alene én leverandør kan løse opga- ven, mens der for de øvrige leverancer i Next-projektet er en bred vifte af leverandører, der kan byde ind på opgaverne. Der er dermed ikke sammen- fald i forhold til, hvilke leverandører der kan løse de forskellige opgaver.

Kontrakten om basisplatformen skal derfor betragtes som en enkeltstående kontrakt, da der hverken er formålsmæssigt, indholdsmæssigt, tidsmæssigt eller leverandørmæssigt sammenfald mellem basisplatformen og de øvrige leverancer i Next-projektet.

DDF har ganske rigtigt været i tvivl om, hvordan tildelingen af kontrakten om basisplatformen skulle håndteres i forhold til tærskelværdien, og profy- laksebekendtgørelsen er netop udtryk for et ønske om at skabe forudgående frivillig gennemsigtighed om kontraktindgåelsen.

DDF har vedrørende betingelserne i udbudslovens § 80, stk. 3, nr. 2, gjort gældende, at DDF i profylaksebekendtgørelsen har beskrevet alle relevante detaljer i forbindelse med den påtænkte kontraktindgåelse med stor omhu. Dette gælder både detaljer om DDF som organisation, formålet med kontrak- ten, de øvrige kontrakter der skal bringes i udbud, og ikke mindst hvorfor den valgte leverandør er tildelt kontrakten. DDF har således i bekendtgørelsen detaljeret beskrevet baggrunden for at tildele kontrakten til Reload i henhold til udbudslovens § 80, stk. 3, nr. 2.

DDF har som led i sin flerleverandørstrategi et formål om at sikre bedst mulig konkurrence i et smalt leverandørfelt. Når DDF har valgt at undtage basis- platformen fra udbud og tildele kontrakten direkte til Reload, er det sket efter grundige overvejelser og netop med henblik på at sikre konkurrence om de øvrige kontrakter i Next-projektet. Hvis ikke DDF havde etableret en kon- trakt på basisplatformen, der kunne danne grundlag for de efterfølgende ud- bud, ville det være udsigtsløst at skabe konkurrence i et i forvejen snævert leverandørmarked.

DDF bestrider ikke Inleads synspunkt om, at § 80, stk. 3, nr. 2, er en undta- gelsesbestemmelse, der alene kan finde anvendelse i visse særlige situationer. I DDF’s overvejelser har realiteten i markedet for levering af ydelser til bib- lioteksinfrastrukturen spillet en afgørende rolle. At der alene har været en forventning om op til fire relevante leverandører til de væsentligste dele af Next-projekterne, har således haft den praktiske betydning, at DDF har set sig nødsaget til at påvirke muligheden for at modtage konkurrencedygtige tilbud. Helt konkret er basisplatformen skabt, så der kunne dannes konkur- rence om de øvrige leverancer i Next-projekterne. Ved at skabe basisplatfor- men er den væsentligste begrænsende faktor for at opnå konkurrence om de øvrige kontrakter derfor imødegået af DDF. I forhold til DDF’s vurdering af at kunne tildele kontrakten direkte til Reload har det således været afgørende, at det ville være noget nær teknisk umuligt for andre leverandører end Reload at gennemføre kontrakten, at alene Reload har haft den fornødne specifikke knowhow, og at et udbud dermed ville være meningsløst og i hvert fald ikke udløse mere konkurrence eller give et bedre indkøbsresultat.

Når en ordregiver således tilrettelægger et indkøb efter § 80, stk. 3, nr. 2, må der gælde en forpligtelse til at tage hensyn til markedet, herunder at opdele kontrakten i relevante delkontrakter, jf. også udbudslovens § 49, stk. 2.

Der har på trods af den offentliggjorte profylaksebekendtgørelse ikke været henvendelser fra andre interesserede leverandører, og Inlead har utvivlsomt ikke selv den specifikke knowhow til sin rådighed for at kunne gennemføre kontrakten om etablering af basisplatformen.

Som det er beskrevet i Notat om DDB CMS Next opgaver og basisplatfor- men, har DDF mere konkret vurderet, at blandt andet den specifikke viden om biblioteksinfrastrukturen og datastrukturen, som er afgørende for at le- vere basisplatformen, alene findes hos virksomheden Reload. Inlead ville derfor aldrig være i stand til at udføre kontrakten uden at blive behørigt in- strueret af Reload, selv forudsat at Inlead til gennemførelsen af kontrakten kunne hyre medarbejdere med den relevante tekniske baggrund. Dette er selvsagt et ikke-ønskværdigt scenarium og dermed kernen af den del af und- tagelsesbestemmelsen, som DDF har påberåbt sig.

DDF bestrider ikke, at Inlead som softwareudvikler har et relevant erfarings- grundlag for udførelsen af visse typer af opgaver og også erfaringer med værktøjer, som er relevante i sammenhæng med basisplatformen. Det er dog

væsentligt at fremhæve, at basisplatformen ikke er et almindeligt udviklings- projekt, men derimod et integrationsprojekt, og derfor er viden om det eksi- sterende setup altafgørende og netop det, der gør Reload unik i forhold til at løse opgaven.

Inlead er en kendt aktør i biblioteksverdenen, og at hævde, at DDF ikke skulle kende til Inleads styrker og svagheder, er ganske enkelt misvisende. DDF har ved flere lejligheder drøftet forskellige problemstillinger med Inlead, og flere af DDF’s medlemskommuner er kunder hos Inlead, hvorfor DDF er fuld- stændig klar over, hvad Inlead kan og ikke kan. Inlead er i al væsentlighed leverandør af en række proprietære løsninger, dvs. licensbaserede løsninger, som Inlead derfor har sin udvikling og produktvidereudvikling centreret om- kring. Den knowhow og viden, der er nødvendig for at kunne etablere basis- platformen, har dog intet med Inleads grundlæggende it-viden at gøre. At Inlead ikke har været en mulig leverandør af basisplatformen, skyldes derfor i hovedsagen manglende viden og indsigt i en række forudsætninger for ba- sisplatformen.

DDF bestrider Inleads synspunkt om, at Inlead alene skulle have en ”endog særdeles begrænset forbindelse til indklagede de seneste par år”. Inleads di- rektør har jævnligt gennem en længere periode rettet henvendelse til DDF’s medarbejdere og ledelse og udtrykt tvivl om den retning, som Inlead mener, at DDF har anlagt med Next-projektet. Denne uoverensstemmelse omkring DDF’s strategivalg ændrer dog ikke ved, at DDF har meget detaljeret viden om, hvorvidt en leverandør, herunder Inlead, er i stand til at levere den øn- skede teknologi i overensstemmelse med den valgte strategi. Som det frem- går ovenfor, har det været DDF’s vurdering, at Inlead ikke er egnet som le- verandør af basisplatformen – dels fordi Inlead ikke besidder de tekniske for- udsætninger til at løfte opgaven, dels fordi Inlead ikke deler DDF’s opfattelse i relation til de strategiske valg i relation til basisplatformen.

Når en ordregiver i medfør af udbudslovens § 80, stk. 4, er forpligtet til at vurdere, om der foreligger rimelige alternativer, må der heri ligge, at ordre- giveren ikke er forpligtet til at acceptere ethvert tænkeligt udfald og alterna- tiv. Det forhold, at fx Inlead med ubegrænset tid og midler i ryggen potentielt kunne opnå samme vidensniveau som Reload, kan efter DDF’s opfattelse ikke betragtes som et rimeligt alternativ.

Det tidsmæssige perspektiv i vurderingen af rimelige alternativer har også spillet ind i forhold til persondatabeskyttelse. Den hastende karakter har be- stået i, at der har været et behov for sikre en opgradering fra ældre versioner af Drupal til nyere versioner for at undgå, at manglende vedligehold af de gamle versioner af Drupal skulle lede til sikkerhedsbrist. Da DDF er databe- handler og dermed håndterer store mængder personoplysninger, ville det set fra de registreredes side være uacceptabelt, såfremt der ikke i rette tid og med de rette kompetencer blev opsat relevante og passende sikkerhedsforanstalt- ninger. Et sikkerhedsbrud opstået, fordi DDF havde undladt at gennemføre en opgradering i tide, ville dermed have betydelig skadevirkning. Der er fun- damental uenighed mellem DDF og Inlead om vigtigheden af at få imple- menteret Drupal 9 i basisplatformen fra det nuværende Drupal 7. Det forhold, at EOL for Drupal 7 er blevet udskudt som følge af Covid-19, ændrer ikke på DDF’s ønske om hurtigst muligt at overgå til Drupal 9. At forestille sig en situation, hvor DDF skulle købe sig til extended support til Drupal 7, når Drupal 9 for længst er gængs standard, udstiller hvor forskelligt Inlead og DDF ser på behovet for opgraderingen.

Når DDF har valgt en Drupal-løsning til at starte med, skyldes det blandt andet, at Drupal er Open Source software, hvilket blandt andet indebærer, at en stor del af vedligehold og opgraderingen af softwaren sker på basis af de brugere, der anvender Drupal (”Drupal Community”). Idet Drupal 9 allerede er taget i brug, sker der løbende og hastigt en strømning af brugere fra Drupal 7 til Drupal 9, hvilket betyder, at Drupal Community for Drupal 9 bliver stær- kere, for hver dag der går, på bekostning af Drupal 7.

Extended support er betalt support fra tredjemand, når Drupal Security Team ikke længere forestår vedligehold, og dermed en absolut nødløsning, der stri- der mod hele formålet med det strategiske valg af Drupal.

Inlead er med sin manglende forståelse for Drupal slet ikke i stand til at løfte den opgave, der består i etablering af basisplatformen. I tillæg hertil forelig- ger der en situation, hvor Inleads og andre leverandørers manglende viden om biblioteksinfrastrukturen kommer til udtryk i form af manglende specifik interoperabilitet. Specifik interoperabilitet skal i denne sammenhæng anses som viden om biblioteksinfrastrukturen og datastrukturer og sammenhængen til det eksisterende CMS setup. DDF bør ikke være forpligtet til at tage en leverandør i betragtning, der ikke har de tekniske forudsætninger og know- how i forhold til at kunne levere det ønskede, og som derudover i øvrigt er

åbenlyst og dokumenterbart uenig i nødvendigheden af den ønskede tekno- logi og den valgte strategi.

Omfanget af kontrakten er afgrænset til det allermest nødvendige, både i ind- hold, men også i udstrækning, idet kontrakten indholdsmæssigt og tidsmæs- sigt er skarpt afgrænset, ikke indeholder fx drifts- og vedligeholdselementer, der ville være helt normalt i en tilsvarende kontrakt. DDF har på denne vis bestræbt sig på at begrænse brugen af undtagelsesbestemmelsen i udbudslo- vens § 80, stk. 3, nr. 2, til det akkurat nødvendige. I den sammenhæng er det ligeledes vigtigt at understrege, at anvendelsen af udbudslovens § 80, stk. 3, nr. 2, ikke er sket for at begrænse konkurrencen og tilgodese en specifik le- verandør – tværtimod. For at skabe grundlaget for en reel konkurrence om Next-projekterne har DDF ud fra sin flerleverandørstrategi valgt at etablere en basisplatform, der herefter kan udgøre grundlaget for den efterfølgende konkurrence.

Tilfældene med teknisk eksklusivitet er alle dokumenteret, da DDF dels i Notat om DDB CMS Next opgaver og basisplatformen grundigt har analyse- ret og redegjort for eksklusiviteten og de bagvedliggende tekniske årsager, dels i den offentliggjorte profylaksebekendtgørelse har beskrevet baggrun- den for tildelingen af kontrakten.

Dertil kommer, at Inlead helt konkret har været afskåret fra at løse opgaven med basisplatformen, da Inlead ikke har den fornødne tekniske indsigt og viden vedrørende it-sikkerhed i forbindelse med behandling af personoplys- ninger. Efter Inleads opfattelse foreligger der en mulighed for support i for- bindelse med EOL af Drupal 7, eksempelvis hos en leverandør som myDropWizzard (”MDW”). Som det fremgår af MDW’s egne vilkår for be- handling af personoplysninger, sker databehandlingen hos MDW i henhold til EU-US Privacy Shield, som var en ordning, hvorved der kunne ske sikker overførsel af personlysninger fra EU til USA. Denne ordning blev kendt ulovlig ved EU-Domstolens dom af 16. juli 2020 i Schrems II-sagen. At In- lead henviser til en leverandør, der åbenlyst ikke er i stand til at levere sine ydelser i overensstemmelse med gældende lovgivning, viser, at Inlead ikke har forstået og anerkender problemstillingen med en manglende opgradering fra Drupal 7 til Drupal 9 i rette tid. Korrekt og lovlig behandling af person- oplysninger er af helt afgørende betydning for DDF, men er et område, hvor Inlead efter DDF’s vurdering ikke besidder de nødvendige kompetencer.

DDF’s Jura- og GDPR-team holder sig løbende opdateret, på hvilke virksom- heder der bliver anbefalet til at yde extended support. Dette var således til- fældet, da notatet af 13. april 2021 blev udarbejdet, og sidenhen også ved klagens indgivelse til klagenævnet. Der var og er fortsat ikke – efter DDF’s vurdering – tilfredsstillende muligheder for extended support i relation til Drupal 7.

DDF havde forud for udsendelsen af profylaksebekendtgørelsen analyseret leverandørmarkedet nøje, ligesom Next-delprojekterne er skåret til på en måde, så der kan sikres konkurrence herom, når basisplatformen er imple- menteret.

Sammenfattende er det derfor DDF’s opfattelse, at DDF inden for udbudslo- vens rammer og på baggrund af en grundig analyse af markedets aktører, med henblik på at skabe et efterfølgende gunstigt miljø for konkurrence, og uden reelle alternativer, valgte at tildele en skarpt afgrænset kontrakt til den aktør, der på grund af sin tekniske knowhow reelt er den eneste, der har forudsæt- ningerne for at opfylde kontrakten.

DDF har på intet tidspunkt påberåbt sig udbudslovens § 80, stk. 5. En opgave kan i sagens natur godt have hastende karakter, selv om betingelserne for anvendelse af § 80, stk. 5, ikke er opfyldt. DDF har da også ageret hurtigt i forhold til realiseringen af basisplatformen, fra analyser af problemstillin- gerne i foråret 2021 til kontraktstart i sommeren 2021 og endelig levering ultimo 2021. Denne eksekveringsplan er efter alle kendte målestokke udtryk for et hastigt gennemført it-projekt.

Der ligger et betydeligt sikkerhedsmæssigt perspektiv i at få implementeret basisplatformen hurtigst muligt. En ordregiver er ikke forpligtet til at designe et udbud på en måde, så alle med den mindste interesse i projektet kan del- tage. Det ville simpelthen blive for dyrt og for risikofyldt. Af samme grund har DDF vurderet, at der ikke har været rimelige alternativer til den valgte fremgangsmåde.

Som denne klagesag har vist, er der ikke kun tale om en situation, hvor In- leads manglende tekniske viden om biblioteksinfrastrukturen, datastrukturer og sammenhængen til den eksisterende CMS setup kommer til udtryk i manglende interoperabilitet. Der er også tale om, at Inlead har en fundamen- tal manglende forståelse for persondatabeskyttelse og de væsentlige regler,

der gælder i henhold til GDPR, som indebærer, at Inlead ikke de facto kan levere en ydelse til DDF, som vil kunne anvendes i forbindelse med imple- menteringen af basisplatformen.

Ad påstand 2

Inlead har gjort gældende, at betingelserne for, at DDF kunne indgå kontrakt med Reload uden udbud, ikke har været opfyldt, jf. det ad påstand 1 anførte, og at DDF’s beslutning om at tildele kontrakten til Reload uden udbud skal annulleres.

DDF har gjort gældende, at der ikke er grundlag for at annullere DDF’s be- slutning om at tildele kontrakten om basisplatformen til Reload. Der har ikke været tale om en udbudspligtig kontrakt omfattet af udbudslovens afsnit II henset til kontraktens værdi, der ligger klart under tærskelværdien. Selv hvis kontrakten har været udbudspligtig i henhold til udbudslovens afsnit II, har DDF været berettiget til at tildele kontrakten efter udbudsproceduren udbud med forhandling uden forudgående bekendtgørelse i henhold til udbudslo- vens § 80, stk. 3, nr. 2. Der er således ikke grundlag for at annullere DDF’s tildelingsbeslutning.

Ad påstand 3

Inlead har gjort gældende, at udgangspunktet er, at en kontrakt skal erklæres uden virkning, såfremt den skulle have været genstand for udbud, men ikke har været det, jf. lov om Klagenævnet for Udbud § 17, stk. 1, nr. 1.

Betingelsen i lov om Klagenævnet for Udbud § 4, stk. 1, nr. 3, er ikke opfyldt. Det fremgår af praksis fra klagenævnet, jf. kendelse af 4. maj 2016, CGI Danmark A/S mod Moderniseringsstyrelsen, at betingelsen alene er opfyldt, hvis ordregiver har udvist den ”fornødne omhu” ved sin vurdering, jf. herved også EU-Domstolens dom i sag C-19/13, Fastweb. Klagenævnet stiller rela- tivt høje krav til ordregivers dokumentation for, at der er udvist den fornødne omhu. Med henvisning til det, som er anført ad påstand 1, har DDF ikke ud- vist den fornødne omhu ved sin vurdering, der tværtimod må anses som åben- bart urigtig.

DDF var fuldt bekendt med, at der var i hvert fald fire leverandører, der kunne være relevante som leverandører af hele eller dele af Next-projektet. Allerede

henset hertil kunne og burde DDF have iværksat et udbud. DDF kunne som minimum nemt og enkelt have rettet direkte henvendelse til disse leverandø- rer som led i en markedsdialog eller lignende med henblik på at sikre en nær- mere afklaring af, om disse leverandører ville kunne afgive bud på basisplat- formen, eller hvordan et eventuelt udbud, der inkluderede basisplatformen, ville skulle struktureres, hvis et udbud skulle gennemføres.

Det kan ikke ved vurderingen af, om DDF har udvist den fornødne omhu, tillægges betydning, om kontrakten har større eller mindre værdi. Kontrakten indgår som et element blandt flere i Next-projektet, som angår en afgørende del af DDF’s virksomhed. Der er derfor tværtimod grund til at forvente en skærpet omhu.

Det kan heller ikke tillægges betydning, om gennemførelse af kontrakten kan bevirke større eller mindre konkurrence om senere udbudte kontrakter, alle- rede fordi der ikke er grund til at tro, at kontrakten ville have skabt mindre konkurrence om senere udbudte kontrakter, hvis den var blevet indgået efter gennemførelse af et udbud. Der er ikke hjemmel til at tillægge det betydning, om klage er indgivet før eller efter standstill-perioden, så længe klagen dog er indgivet inden for den lovbestemte klagefrist.

DDF henviser til risikoen for ”et væsentligt værdispild”. Der er imidlertid ikke godtgjort noget værdispild, og det gøres gældende, at værdispild kun under helt særlige omstændigheder, hvor det er af meget betydelig samfunds- mæssig karakter, kan begrunde, at en kontrakt ikke erklæres uden virkning.

Det anførte bør give Klagenævnets for Udbud anledning til at ændre den fo- reløbige vurdering som anført i nævnets kendelse af 15. oktober 2021, såle- des at klagenævnet i sin endelige kendelse kan konkludere, at DDF ikke har udvist den fornødne omhu, og at kontrakten derfor skal erklæres uden virk- ning.

Dette skal i henhold til lov om Klagenævnet for Udbud § 18 ske med omgå- ende, fremtidig virkning. Der er således ingen hensyn, der kan bevirke, at DDF skal have en nærmere periode til afvikling af kontrakten eller gennem- førelse af et udbud m.v.

DDF har gjort gældende, at det fremgår af lov om Klagenævnet for Udbud § 4, at en kontrakt, der falder ind under bestemmelsen i lovens § 17, stk. 1, ikke

kan erklæres for uden virkning, hvis ordregiver forud for kontraktindgåelsen har offentliggjort en bekendtgørelse med henblik på frivillig forudgående gennemsigtighed (profylaksebekendtgørelse) i Den Europæiske Unions Ti- dende og har iagttaget procedurereglerne forbundet hermed.

I den konkrete sag har DDF offentliggjort en profylaksebekendtgørelse i Den Europæiske Unions Tidende forud for kontraktindgåelsen. Betingelsen i lov om Klagenævnet for Udbud § 4, stk. 1, nr. 1, er således opfyldt.

Der er ligeledes tale om, at DDF har undladt at indgå kontrakten inden udlø- bet af 10 kalenderdage regnet fra dagen efter den dag, hvor bekendtgørelsen blev offentliggjort. Betingelsen i lov om Klagenævnet for Udbud § 4, stk. 1, nr. 2, er således ligeledes opfyldt.

Der er endelig tale om, at betingelsen i lov om Klagenævnet for Udbud § 4, stk. 1, nr. 3, er opfyldt, idet DDF utvivlsomt har været i god tro omkring det faktum, at kontrakten lovligt kunne indgås efter udbudsproceduren udbud med forhandling uden forudgående offentliggørelse i henhold til udbudslo- vens § 80, stk. 3, nr. 2.

DDF vurderede nøje, om betingelserne for at anvende undtagelsesbestem- melsen var opfyldt og dokumenterede den vurdering, der blev foretaget, jf. Notat om DDB CMS Next opgaver og basisplatformen. Spørgsmålet om- kring DDF’s gode tro og dokumentationen for den foretagne vurdering må i øvrigt skulle vurderes i lyset af den yderst begrænsede værdi af kontrakten samt det faktum, at formålet med indgåelsen af kontrakten omkring basis- platformen har været at skabe fundamentet for at kunne konkurrenceudsætte efterfølgende kontrakter på et gennemsigtigt og ligebehandlende grundlag.

Det fremgår af ordlyden af den 3. betingelse i lov om Klagenævnet for Udbud

§ 4, stk. 1, at det blot er afgørende, om ”ordregiveren finder”, at kontraktind- gåelsen uden udbud er tilladt i henhold til udbudsloven. Der må således være tale om, at der skal været foretaget en åbenlys urigtig vurdering af mulighe- den for at kunne indgå kontrakt uden udbud, førend klagenævnet kan statu- ere, at den 3. betingelse ikke er opfyldt.

Selv hvis klagenævnet måtte nå frem til, at DDF ikke opfyldte betingelserne for at anvende udbudsproceduren udbud med forhandling uden forudgående

offentliggørelse, er der således ikke tale om, at DDF har foretaget en åbenlys urigtig vurdering, og kontrakten skal derfor ikke erklæres for uden virkning.

Vurderingen af, om betingelserne for at anvende udbudsproceduren udbud med forhandling uden forudgående offentliggørelse var opfyldt, blev foreta- get af en arbejdsgruppe bestående af ansatte hos DDF med såvel udbudsret- lig, biblioteksfaglig som it-faglig indsigt. Det udarbejdede notat med vurde- ringen i forhold til udbudslovens § 80, stk. 3, nr. 2, er således udtryk for en gennemarbejdet vurdering, der har omfattet alle relevante aspekter af kon- trakten.

Trods offentliggørelsen af profylaksebekendtgørelsen i Den Europæiske Unions Tidende kom der ikke indsigelser eller klager over den beskrevne fremgangsmåde i 10 dages standstill-perioden, og der er heller ikke efterføl- gende kommet klager eller indsigelser fra andre end Inlead.

DDF’s profylaksebekendtgørelse beskrev udførligt og præcist indholdet og omfanget af kontrakten vedrørende basisplatformen, og den indeholdt en ud- førlig begrundelse for, hvorfor DDF vurderede, at kontrakten kunne indgås på baggrund af udbudsformen udbud med forhandling uden forudgående ud- budsbekendtgørelse. Der er således ingen særlige omstændigheder, der har begrundet, at Inlead ikke kunne indgive klage til klagenævnet i 10-dages pe- rioden efter offentliggørelsen af profylaksebekendtgørelsen i EU-tidende.

De indholdsmæssige krav til profylaksebekendtgørelsen, jf. lov om Klage- nævnet for Udbud § 4, stk. 2, er utvivlsomt opfyldt.

DDF har opfyldt alle betingelser i forhold til virkningen af den offentliggjorte profylaksebekendtgørelse, og der er således ikke grundlag for at erklære DDF’s kontrakt med Reload for uden virkning.

Ad påstand 4

Inlead har gjort gældende, at der skal fastsættes en alternativ sanktion, hvis ikke den fulde kontrakt med Reload erklæres for uden virkning. Såfremt In- lead får medhold i påstand 3, skal klagenævnet fastsætte en sanktion for så vidt angår den del af kontrakten, som opretholdes. Får Inlead ikke medhold i påstand 3, skal klagenævnet fastsætte en sanktion for den fulde kontrakt.

Subsidiært skal klagenævnet indgive politianmeldelse i henhold til lov om Klagenævnet for Udbud § 18, stk. 2, og § 20.

Det er tvivlsomt, om DDF i klagenævnslovens forstand er etableret på pri- vatretligt grundlag, herunder hvad der i givet fald ville være hjemlen hertil. Det anses mere sandsynligt, at der er tale om en simpel sammenslutning af kommuner, hvorved indklagede fortsat kan pålægges en økonomisk sanktion af klagenævnet.

DDF har gjort gældende, at en særskilt påstand om økonomisk sanktion/po- litianmeldelse er unødvendig, idet det er klagenævnet, der af egen drift fast- sætter en alternativ sanktion/indgiver politianmeldelse for det tilfælde, at kontrakten ikke i sin helhed erklæres for uden virkning.

DDF er som forening etableret på et privatretligt grundlag ikke en del af den offentlige forvaltning, og der er således ikke grundlag for, at klagenævnet kan pålægge DDF en økonomisk sanktion.

Påstand 5

Inlead har gjort gældende, at hvis påstand 3 ikke tages til følge, bliver kon- trakten ikke erklæret uden virkning.

Hvis klageren imidlertid får medhold i påstand 2, finder udbudslovens § 185, stk. 2, anvendelse, og det bevirker, at DDF skal bringe den med Reload ind- gåede kontrakt til ophør med et passende varsel. På grund af kontraktens ka- rakter vil et passende varsel være straks, idet der ikke er særlige hensyn, der begrunder, at det skulle være nødvendigt med en overgangsordning eller lig- nende.

Der foreligger ikke særlige forhold, der tilsiger, at kontrakten videreføres. DDF vil således kunne foretage udbud af den pågældende ydelse. Kontrakten angår udviklingsopgaver m.v., og det forhold, at der skal gennemføres et ud- bud, vil således ikke påvirke den aktuelle drift af DDF på nogen måde, der kan begrunde, at kontrakten med Reload ikke skal bringes til ophør.

Det er korrekt, at det fremgår af § 185, stk. 2, at bestemmelsen ikke finder anvendelse, hvor §§ 16 eller 17 om uden virkning i lov om Klagenævnet for

Udbud finder anvendelse. Det fremgår af lovbemærkningerne, at dette skyl- des, at bestemmelsens formål alene er at sikre effektiv håndhævelse af ud- budsreglerne, og dette formål er allerede varetaget i de nævnte tilfælde.

I de tilfælde, hvor en kontrakt imidlertid ikke erklæres uden virkning, og hvor der ikke idømmes en økonomisk sanktion, er formålet med at sikre en effek- tiv håndhævelse ikke varetaget, og ordregiver må derfor være forpligtet til at bringe kontrakten til ophør.

DDF har gjort gældende, at der ikke er grundlag for, at klagenævnet kan fremkomme med en sådan udtalelse. Det fremgår eksplicit af udbudslovens

§ 185, stk. 2, 2. pkt., at bestemmelsen ikke finder anvendelse, hvor §§ 16 eller 17 om uden virkning i lov om Klagenævnet for Udbud finder anven- delse.

Det er tydeliggjort i lovforarbejderne, at pligten til at bringe en kontrakt til ophør i tilfælde af klagenævnets annullation af tildelingsbeslutningen ikke finder anvendelse, når ”uden virkning regimet” i lov om Klagenævnet for Udbud finder anvendelse.

Det ville i øvrigt udgøre en fuldstændig udhuling af det lovfastsatte system med profylaksebekendtgørelser, hvis en ordregiver, der opfylder alle betin- gelser i forhold til at opnå beskyttelse af en profylaksebekendtgørelse, skulle være forpligtet til at bringe en kontrakt til ophør i medfør af udbudslovens § 185, stk. 2, i en situation, hvor tildelingsbeslutningen i relation til en direkte tildeling annulleres af klagenævnet.

Det bestrides således, at udbudslovens § 185, stk. 2, finder anvendelse i den konkrete situation, og følgelig er der ikke grundlag for, at klagenævnet kan afgive en udtalelse i henhold til lov om Klagenævnet for Udbud § 14 a.

Klagenævnet udtaler:

Ad påstand 1

Klagenævnet har i kendelse af 15. oktober 2021 udtalt bl.a. følgende:

”Den udbudte kontrakt er i udbudsbekendtgørelsen angivet til at have en værdi på 1.091.239 kr., hvilket ligger under tærskelværdien i udbudslo- vens § 6, stk. 1, nr. 3.

Kontrakten om udvikling af basisplatformen er imidlertid en del af Next- projektet. Det fremgår således af udbudsbekendtgørelsen, at udbuddet af kontrakten om udvikling af basisplatformen er den første kontrakt i Next- projektet. Det fremgår endvidere af selve kontrakten, at målet med pro- jektet er en generel genetablering af den forretningsfunktionalitet, bibli- otekerne har prioriteret i DDB CMS med særligt fokus på søge- og for- midlingsgrænsefladen, at genetableringen forudsætter en etablering af basisplatformen, og at formålet med basisplatformen er at danne grund- laget for udviklingen af brugergrænsefladen. I DDF’s notat omtales ”den sammenhængende digitale bibliotekstjeneste Next”.

Klagenævnet finder på dette foreløbige grundlag, der foreligger, at der er en sådan sammenhæng mellem kontrakten om udvikling af basisplatfor- men og de øvrige dele af Next-projektet, at der ved afgørelsen af, om den udbudte kontrakt er omfattet af udbudslovens afsnit II, skal tages ud- gangspunkt i den samlede værdi af Next-projektet.

Da værdien af det samlede Next-projekt ubestridt overstiger tærskelvær- dien i udbudslovens § 6, stk. 1, nr. 3, gælder reglerne i udbudslovens af- snit II.

DDF har derfor som udgangspunkt pligt til at offentliggøre en udbudsbe- kendtgørelse med henblik på at indhente tilbud.

…”

Der er under den efterfølgende behandling af sagen ikke fremkommet nye oplysninger eller fremført nye anbringender, som fører til en anden vurde- ring.

På denne baggrund finder klagenævnet fortsat, at DDF som udgangspunkt havde pligt til at offentliggøre en udbudsbekendtgørelse med henblik på at indhente tilbud, idet kontrakten var omfattet af udbudslovens afsnit II, jf. ud- budslovens § 128, stk. 1.

DDF foretog imidlertid en direkte tildeling uden forudgående offentliggø- relse af en udbudsbekendtgørelse og indgik på baggrund heraf kontrakt med Reload.

Som begrundelse for at foretage en direkte tildeling uden forudgående of- fentliggørelse af en udbudsbekendtgørelse anførte DDF i profylaksebekendt- gørelsen med henvisning til udbudslovens § 80, stk. 3, nr. 2, bl.a., at opfyl- delsen af kontrakten om udvikling af basisplatformen krævede specialistvi- den i meget høj grad, og at leverandøren skulle have indsigt i it-biblioteksin- frastrukturens opbygning og de datastrukturer, der benyttes i sektoren, fx bib- lioteksdatafelter mv., samt viden om det eksisterende CMS og den eksiste- rende build pipeline, herunder bestående uhensigtsmæssigheder, erfaring med at bygge cloudbaseret drift set up og specialistkompetencer i forhold til at foretage integrationer til biblioteksinfrastrukturen og bibliotekssystemet.

Det påhviler DDF at løfte bevisbyrden for, at betingelserne for at foretage en direkte tildeling uden forudgående offentliggørelse af en udbudsbekendtgø- relse er opfyldt, herunder bevisbyrden for, at ydelserne som påberåbt af DDF efter kontrakten kun kan leveres af en bestemt økonomisk aktør på grund af manglende konkurrence af tekniske årsager, jf. udbudslovens § 80, stk. 2, nr. 3.

Inlead har for klagenævnet redegjort indgående for Inleads kompetencer og indsigt i it-biblioteksinfrastrukturens opbygning og de datastrukturer, der be- nyttes i sektoren, herunder biblioteksdatafelter m.v., samt viden om det eksi- sterende CMS og den eksisterende build pipeline m.v.

Klagenævnet finder på den baggrund, at DDF ikke har løftet bevisbyrden for, at Reload var den eneste virksomhed, der havde en sådan specialistviden og indsigt i it-biblioteksinfrastrukturens opbygning og de datastrukturer, der be- nyttes i sektoren, samt viden om det eksisterende CMS og den eksisterende build pipeline m.v., som var krævet til kontraktens gennemførelse, og at det ville være noget nær teknisk umuligt for Inlead at sikre den krævede gen- nemførelse.

DDF kunne således ikke anvende proceduren udbud med forhandling uden forudgående offentliggørelse af en udbudsbekendtgørelse på grund af mang- lende konkurrence af tekniske årsager, jf. udbudslovens § 80, stk. 3, nr. 2.

DDF har gjort gældende bl.a., at indgåelse af kontrakten var af hastende ka- rakter, og at Inlead ikke skulle være i stand til at løfte opgaven på grund af manglende specifik interoperabilitet.

Klagenævnet bemærker hertil, at oplysninger om opgavens eventuelt ha- stende karakter, og oplysninger om der foreligger specifik interoperabilitet, ikke fremgår af den offentliggjorte profylaksebekendtgørelse men alene er nærmere beskrevet i DDF’s ”Notat om DDB CMS Next opgaver og basis- platformen”. Heraf fremgår det bl.a., at DDF vurderede, at ”Opgaven med basisplatformen har således hastende karakter.”, og at ”…kun en enkelt leve- randør, it-virksomheden Reload, [vil] inden for de givne tidsmæssige rammer (…) kunne sikre gennemførelse af opgaven efter de krav, der må stilles her- til.”

Begrundelsen for at anse opgaven med basisplatformen som værende af ha- stende karakter var ifølge DDF bl.a., at den eksisterende løsning ville blive eksponeret for hacking og sikkerhedsbrud ved Drupal 7 end-of-life (EOL). Ifølge kontraktudkastet havde Xxxxxx 7 EOL i november 2021.

Inlead har imidlertid oplyst, at EOL for Drupal 7 er blevet forlænget, senest til den 28. november 2022, og samtidig er der etableret mulighed for, at or- ganisationer, der benytter sig af Drupal 7, kan købe sig til ”extended support” frem til november 2025. Derudover har Inlead oplyst, at Drupal på sin hjem- meside har oplyst om den oprindelige EOL fra i hvert fald 25. februar 2019. DDF har ikke bestridt dette.

Klagenævnet finder, at DDF på den baggrund ikke har løftet bevisbyrden for, at opgaven var af hastende karakter. DDF har derfor været uberettiget til at lægge vægt herpå ved vurderingen af, om betingelserne for direkte tildeling i udbudslovens § 80, stk. 3, nr. 2, var opfyldt.

DDF har heller ikke løftet bevisbyrden for, at der foreligger en sådan specifik interoperabilitet, at Inlead skulle være afskåret fra at kunne opfylde kontrak- ten.

Det, som DDF har anført om kontraktens hastende karakter og om specifik interoperabilitet, kan derfor ikke føre til et andet resultat.

Herefter er betingelserne for at foretage en direkte tildeling uden forudgående offentliggørelse af en udbudsbekendtgørelse ikke opfyldt.

Ved at foretage en direkte tildeling af kontrakten uden forudgående offent- liggørelse af en udbudsbekendtgørelse har DDF handlet i strid med ligebe- handlings- og gennemsigtighedsprincippet i udbudslovens § 2 og § 6, jf. § 128, stk. 1, idet betingelserne i udbudslovens § 80, stk. 3, ikke er opfyldt.

Klagenævnet tager derfor påstand 1 til følge. Ad påstand 2

Det følger af det anførte ad påstand 1, at betingelserne for annullation af til- delingsbeslutningen er opfyldt.

Klagenævnet tager derfor påstand 2 til følge. Ad påstand 3

Som anført ad påstand 1 er betingelserne for at anvende udbud med forhand- ling uden forudgående offentliggørelse ikke opfyldt.

Det følge herefter af § 17, stk. 1, nr. 1, i lov om Klagenævnet for Udbud, at kontrakten skal erklæres for uden virkning. En ordregiver har dog i medfør af § 4, stk. 1, mulighed for at sikre, at en kontrakt i de tilfælde, der er nævnt i § 17, stk. 1, nr. 1, ikke erklæres for uden virkning, hvis 1) ordregiveren forud for kontraktindgåelsen i Den Europæiske Unions Tidende har offent- liggjort en bekendtgørelse, hvoraf det fremgår, at ordregiveren agter at indgå kontrakten, 2) kontrakten ikke er indgået inden udløbet af 10 kalenderdage regnet fra dagen efter den dag, hvor bekendtgørelsen er blevet offentliggjort, og 3) ordregiveren finder, at indgåelsen af kontrakten uden forudgående of- fentliggørelse af en udbudsbekendtgørelse i Den Europæiske Unions Tidende er tilladt i henhold til udbudsloven eller EU-udbudsreglerne. Bekendtgørel- sen skal i medfør af § 4, stk. 2, nr. 3, indeholde begrundelsen for ordregive- rens beslutning om at tildele kontrakten uden forudgående offentliggørelse af en udbudsbekendtgørelse.

EU-Domstolen har i sag C-19/13, Fastweb, præmis 47 og 48, udtalt, at pro- fylaksebekendtgørelsen skal ”indeholde begrundelsen for ordregiverens be- slutning om at tildele kontrakten uden forudgående offentliggørelse af en ud- budsbekendtgørelse”, og at ”den nævnte begrundelse klart og utvetydigt

[skal] angive de betragtninger, der ligger til grund for den ordregivende myn- digheds vurdering af, at den kunne indgå kontrakten uden forudgående of- fentliggørelse af en udbudsbekendtgørelse, med henblik på at gøre det muligt for de interesserede parter under fuldt kendskab til sagen at afgøre, om sagen skal indbringes for den instans, der er ansvarlig for klageproceduren, og for sidstnævnte at udøve en effektiv kontrol.”

EU-Domstolen har endvidere i præmis 50 udtalt, at den instans, der er an- svarlig for klageproceduren, i forbindelse med sin kontrol er forpligtet til ”at undersøge, om den ordregivende myndighed har udvist den fornødne omhu, og om den ordregivende myndighed kunne vurdere, at betingelserne for at tildele en kontrakt [uden forudgående offentliggørelse af en udbudsbekendt- gørelse] faktisk var opfyldt.”

DDF har den 16. juli 2021 indrykket en bekendtgørelse med henblik på fri- villig forudgående gennemsigtighed, indeholdende en begrundelse for DDF’s beslutning om at tildele kontrakten uden forudgåede offentliggørelse af en udbudsbekendtgørelse, og har først efter udløbet af 10 kalenderdage fra den dag, bekendtgørelsen blev offentliggjort, indgået kontrakt.

Inlead har gjort gældende, at DDF ikke har udvist den fornødne omhu. Klagenævnet har i kendelse af 15. oktober 2021 udtalt bl.a. følgende herom:

”Afgørelsen af, om DDF har udvist den fornødne omhu, skal foretages på baggrund af en vurdering af sagens samlede omstændigheder, hvori også indgår kontraktens genstand, herunder kompleksiteten i den tjene- steydelse, der indgås kontrakt om, og kontraktens værdi.

DDF har inden indgåelsen af kontrakten foretaget en vurdering af, om kontrakten var udbudspligtig. Hvordan denne vurdering er foretaget, fremgår af det af DDF udarbejdede Notat om DDB CMS Next opgaver og basisplatformen. Det fremgår heraf bl.a., at DDF’s brugerteam og ju- rateam på en række møder har drøftet, hvordan opgaverne vedrørende den sammenhængende digitale bibliotekstjeneste Next konkurrenceud- sættes/udbydes i overensstemmelse med de udbudsretlige regler, herun- der navnlig om det er berettiget at anvende udbudslovens § 80, stk. 3, nr. 2.

DDF’s brugerteam vurderede, at der til gennemførelsen af opgaven med udviklingen af basisplatformen krævedes specifik indsigt i it-biblioteks-

infrastrukturens opbygning og de datastrukturer, der benyttes i biblio- tekssektoren, viden om det eksisterende CMS og den eksisterende pipe- line samt erfaring med at bygge et cloudbaseret drift-setup. Endvidere krævedes specialiserede kompetencer i forhold til at foretage integratio- ner i biblioteksinfrastrukturen og bibliotekssystemet.

Brugerteamet vurderede på baggrund af et indgående kendskab til it-virk- somheden Reloads og de andre potentielle leverandørers kompetencer og viden, at det kun it-teknisk ville være muligt for it-virksomheden Reload at gennemføre opgaven med etablering af basisplatformen.”

Klagenævnet finder, at DDF henset til kontraktens genstand, herunder kom- pleksiteten i den tjenesteydelse, der indgås kontrakt om, og navnlig kontrak- tens mindre værdi, har foretaget de tilstrækkelige undersøgelser til at vurdere, om betingelserne i udbudslovens § 80, stk. 3, nr. 2, var opfyldt. DDF har på baggrund af de foretagne undersøgelser vurderet, at betingelserne i udbuds- lovens § 80, stk. 3, nr. 2, var opfyldt, men har for at sikre maksimal gennem- sigtighed offentliggjort en profylaksebekendtgørelse. Klagenævnet finder ef- ter en samlet vurdering, at DDF var berettiget til at anvende denne frem- gangsmåde, og at DDF i sin vurdering har udvist fornøden omhu.

Det forhold, at det nu er fastslået, at DDF’s vurdering var forkert, og at be- tingelserne for at foretage en direkte tildeling herefter ikke var opfyldt, med- fører ikke i sig selv, at DDF ikke kan anses for at have udvist fornøden omhu.

Herefter, og da de af Inlead nu fremkomne anbringender ikke kan føre til en anden vurdering, tages påstanden ikke til følge.

Ad påstand 4

Efter det, der er anført ad påstand 3, tages påstanden ikke til følge, idet der ikke er grundlag for at fastsætte en alternativ sanktion i medfør af lov om Klagenævnet for Udbud § 18, stk. 2, nr. 2.

Ad påstand 5

Klagenævnet lægger til grund, at kontrakten med Reload om basisplatformen er udført og afsluttet, og at sidste rate af vederlaget er faktureret og betalt.

Klagenævnet tager på denne baggrund ikke stilling til påstand 5, jf. lov om Klagenævnet for Udbud § 10, stk. 2.

Herefter bestemmes:

Det Digitale Folkebibliotek har handlet i strid med ligebehandlings- og gen- nemsigtighedsprincippet i udbudslovens § 2 og § 6, jf. § 128, stk. 1, ved at have indgået en aftale med Reload A/S om udvikling af basisplatformen til DDB CMS Next uden forudgående offentliggørelse af en udbudsbekendtgø- relse, idet betingelserne i udbudslovens § 80, stk. 3, ikke er opfyldt.

Det Digitale Folkebiblioteks beslutning af 12. juli 2021 om at tildele kontrakt om udvikling af basisplatformen til DDB CMS Next til Reload A/S annulle- res.

Det Digitale Folkebibliotek skal i sagsomkostninger til Inlead ApS betale

35.000 kr., der betales inden 14 dage efter modtagelsen af denne kendelse.

Klagegebyret tilbagebetales.

Klagen tages ikke til følge vedrørende påstand 3 og påstand 4. Klagenævnet tager ikke stilling til påstand 5.

Xxxxx X. Xxxxxxxxxxx

Genpartens rigtighed bekræftes.

Xxxxx Xxxxxxxxxxx Xxxxxxxxx Sekretær