Petter Reinholdtsen

I går publiserte Universitas, Dagens-IT og Computerworld Norge en sak om at de ansatte ved Universitetet i Oslo ikke følger regjeringens pålegg om å publisere i HTML, PDF eller ODF. Det er bra at det kommer litt fokus på dette, og jeg håper noen journalister tar en titt på de andre statlige instansene også.

Skulle ønske det var en enkel måte å sjekke om ODF-dokumenter er i henholdt til ODF-spesifikasjonen, og en måte å teste om programmer som hevder å støtte ODF forstår alle delene av ODF-spesifikasjonen. Kjenner kun til ufullstendige løsninger for slikt.

Jeg møter alle slags interessante mennesker på min vei, og et møte jeg lærte mye av var å treffe på en svært kompetent IT-fyr som benektet ting jeg anser som åpenbart og selvfølgelig når det gjelder standarder. Det var interessant, da det fikk meg til å tenke litt nøyere på hvilke mekanismer som ligger til grunn for at noe oppfattes som en standard. Det hele startet med arbeid rundt integrering av NSS LDAP mot Active Directory, og problemer som oppstår pga. at Active Directory ikke følger LDAP-spesifikasjonen som dokumentert i RFCer fra IETF (konkret, AD returnerer kun et subset av attributter hvis det er mer enn 1500 atributter av en gitt type i et LDAP-objekt, og en må be om resten i bolker av 1500). Jeg hevdet måten dette ble gjort på brøt med LDAP-spesifikasjonen, og henviste til hvor i LDAP-spesifikasjonen fra IETF det sto at oppførselen til AD ikke fulgte LDAP-spesifikasjonen. AD-spesialisten overrasket meg da ved å fortelle at IETF var ikke de som definerte LDAP-spesifikasjonen, og at Active Directory ikke brøt den virkelige LDAP-spesifikasjonen som han mente lå til grunn. Jeg ble spesielt overrasket over denne tilnærmingen til problemstillingen, da til og med Microsoft så vidt jeg kan se anerkjenner IETF som organisasjonen som definerer LDAP-spesifikasjonen. Jeg fikk aldri spurt hvem han mente sto bak den egentlige LDAP-spesifikasjonen, da det var irrelevant for problemet vi måtte løse (få Linux og AD til å fungere sammen). Dette møtet fortalte meg uansett at det ikke er gitt at alle aktører er enige om hva en standard er, og hva som er kilden til en gitt standard. Det er vanskelig å enes om felles standarder før en først enes om hvem som bestemmer hva en gitt standard innebærer.

Hva er så en standard? I sin abstrakte form er det noe å samles om. På engelsk er en av betydningene fane brukt i krig, du vet, den type fane en samlet seg rundt på kamplassen i riddertiden. En standard definerer altså et felleskap, noen som har noe felles. Det er naturligvis mange måter å utgjøre et felleskap på. En kan f.eks. enes om å gjøre alt slik som Ole gjør det, og dermed si at Oles oppførsel er standard. Hver gang Ole endrer oppførsel endrer også standarden seg uten noe mer organisering og prosedyre. En variant av dette er å gjøre slik som Ole har gjort det i stedet for slik Ole til enhver til gjør noe. Dette er ofte litt enklere å forholde seg til, da en slipper å sjekke med Ole hver gang for å vite hvordan ting skal gjøres nå, men hvis det Ole gjorde noe dumt den gang en bestemte seg for å følge Ole, så er det vanskeligere å få endret oppførsel for å unngå dette dumme.

En kan også ta det et skritt videre, og istedet for å basere seg på enkeltpersoners oppførsel sette seg ned og bli enige om hvordan en skal gjøre ting, dvs. lage et felleskap basert på konsensus. Dette tar naturligvis litt mer tid (en må diskutere ting i forkant før en kan sette igang), men det kan bidra til at den oppførselen en planlegger å benytte seg av er mer gjennomtenkt. Det ender også typisk opp med en beskrivelse av ønsket oppførsel som flere kan forstå - da flere har vært involvert i å utarbeide beskrivelsen.

Dette er dessverre ikke alt som trengs for å forstå hva en åpen standard er for noe. Der alle kan se på hvordan folk oppfører seg, og dermed har valget om de vil oppføre seg likt eller ikke, så er det endel juridiske faktorer som gjør det hele mer komplisert - opphavsretten og patentlovgivningen for å være helt konkret. For å gi et eksempel. Hvis noen blir enige om å alltid plystre en bestemt melodi når de møtes, for å identifisere hverandre, så kan opphavsretten brukes til å styre hvem som får lov til å gjøre dette. De har standardisert hvordan de kjenner igjen alle som følger denne standarden, men ikke alle har nødvendigvis lov til å følge den. Musikk er opphavsrettsbeskyttet, og fremføring av musikk i offentligheten er opphavsmannens enerett (dvs. et monopol). Det vil i sin ytterste konsekvens si at alle som skal plystre en opphavsrettsbeskyttet melodi i det offentlige rom må ha godkjenning fra opphavsmannen. Har en ikke dette, så bryter en loven og kan straffes. Det er dermed mulig for opphavsmannen å kontrollere hvem som får lov til å benytte seg av denne standarden. En annen variant er hvis en standard er dokumentert, så er dokumentet som definerer standarden (spesifikasjonen) beskyttet av opphavsretten, og det er dermed mulig for rettighetsinnehaver å begrense tilgang til spesifikasjonen, og slik styre hvem som kan ta i bruk standarden på den måten.

Der opphavsretten innvilger et monopol på kunstneriske uttrykk med verkshøyde, innvilger patentlovgivningen monopol på ideer. Hvis en slik patentert idé (fortrinnsvis uttrykt i en teknisk innretning, men det er kompliserende faktorer som gjør at det ikke er et krav) trengs for å ta i bruk en standard, så vil den som innehar patent kunne styre hvem som får ta i bruk standarden. Det er dermed ikke gitt at alle kan delta i et standard-felleskap, og hvis de kan delta, så er det ikke sikkert at det er på like vilkår. F.eks. kan rettighetsinnehaver sette vilkår som gjør at noen faller utenfor, det være seg av finansielle, avtalemessige eller prinsipielle årsaker. Vanlige slike vilkår er "må betale litt for hver kunde/bruker" som utelukker de som gir bort en løsning gratis og "må gi fra seg retten til å håndheve sine egne patentrettigheter ovenfor rettighetshaver" som utelukker alle som ønsker å beholde den muligheten.

En åpen standard innebærer for meg at alle kan få innsikt i en komplett beskrivelse av oppførsel som standarden skal dekke, og at ingen kan nektes å benytte seg av standarden. Noen mener at det holder at alle med tilstrekkelig finansiering kan få tilgang til spesifikasjonen og at en kun har finansielle krav til bruk. Pga. denne konflikten har et nytt begrep spredt seg de siste årene, nemlig fri og åpen standard, der en har gjort det klart at alle må ha komplett og lik tilgang til spesifikasjoner og retten til å gjøre bruk av en standard for at en standard skal kunne kalles fri og åpen.

Where I work at the University of Oslo, one decision stand out as a very good one to form a long lived computer infrastructure. It is the simple one, lost by many in todays computer industry: Standardize on open network protocols and open exchange/storage formats, not applications. Applications come and go, while protocols and files tend to stay, and thus one want to make it easy to change application and vendor, while avoiding conversion costs and locking users to a specific platform or application.

This approach make it possible to replace the client applications independently of the server applications. One can even allow users to use several different applications as long as they handle the selected protocol and format. In the normal case, only one client application is recommended and users only get help if they choose to use this application, but those that want to deviate from the easy path are not blocked from doing so.

It also allow us to replace the server side without forcing the users to replace their applications, and thus allow us to select the best server implementation at any moment, when scale and resouce requirements change.

I strongly recommend standardizing - on open network protocols and open formats, but I would never recommend standardizing on a single application that do not use open network protocol or open formats.

Telenors annonsering om å kreve 35 kroner i gebyr fra alle som ønsker papirfaktura har satt sinnene i kok, og pressedekningen så langt snakker om at eldre og folk som ikke behersker data vil få en urimelig ekstrakostnad. Jeg tror ikke jeg passer inn i noen av de kategoriene, men velger å holde meg unna eFaktura - som er det Telenor ønsker å få folk over på - pga. systemets egenskaper.

Slik jeg har sett eFaktura til forbrukere så langt, så sender selger en elektronisk beskjed til kundens bank, som legger ut informasjon om fakturaen i nettbanken for godkjenning. Personlig ville jeg sett det som mer naturlig at det gikk en elektronisk beskjed fra selger til kunde, dvs meg, og at jeg så kunne bruke den videre mot banken eller andre hvis jeg ønsket dette. Mine innkjøp og regninger er jo en sak mellom meg og mine leverandører, ikke en sak mellom min bank og mine leverandører. Kun hvis jeg ønsker å betale fakturaen skal banken involveres. En faktura bør jo inn i regnskapet, og jeg ønsker mulighet til å legge det inn der. Når fakturaen sendes til banken i stedet for meg, blir det vanskeligere. Hele eFaktura-modellen virker på meg som en umyndiggjøring av meg som kunde.

I tillegg har jeg ikke vært i stand til å finne eFaktura-formatets spesifikasjon, og det ser ut til at utsending av slike krever dyre avtaler med bankene for å få lov til å sende ut eFaktura til kunder. Jeg ser vel helst at fakturering på elektroniske formater kan gjøres f.eks. via epost eller HTTP uten å måtte betale mellommenn for retten til å lever ut en faktura, og liker rett og slett ikke dagens faktureringsmodeller.

En standard er noe man samler seg rundt, ut fra ideen om at en får fordeler når mange står sammen. Jo flere som står sammen, jo bedre. Når en vet dette, blir det litt merkelig å lese noen av uttalelsene som er kommet inn til høringen om versjon 2 av statens referansekatalog over standarder. Blant annet Abelia, NHO og Microsoft tror det er lurt med flere standarder innenfor samme område. Det blir som å si at det er fint om Norge standardiserte både på A4- og Letter-størrelser på arkene, ulik sporvidde på jernbaneskinnene, meter og fot som lengemål, eller høyre- og venstrekjøring - slik at en kan konkurrere på hvilken standard som er best. De fleste forstår heldigvis at dette ikke bidrar positivt.

I Microsoft sin høringsuttalelse til forslag til versjon 2 av statens referansekatalog over standarder, lirer de av seg følgende FUD-perle:

"Vorbis, OGG, Theora og FLAC er alle tekniske spesifikasjoner overordnet styrt av xiph.org, som er en ikke-kommersiell organisasjon. Etablerte og anerkjente standardiseringsorganisasjoner, som Oasis, W3C og Ecma, har en godt innarbeidet vedlikeholds- og forvaltningsprosess av en standard. Det er derimot helt opp til hver enkelt organisasjon å bestemme hvordan tekniske spesifikasjoner videreutvikles og endres, og disse spesifikasjonene bør derfor ikke defineres som åpne standarder."

De vokter seg vel for å nevne den anerkjente standardiseringsorganisasjonen IETF, som er organisasjonen bak HTTP, IP og det meste av protokoller på Internet, og RFC-standardene som IETF står bak. Ogg er spesifisert i RFC 3533, og er uten tvil å anse som en åpen standard. Vorbis er RFC 5215. Theora er under standardisering via IETF, med siste utkast publisert 2006-07-21 (riktignok er dermed teksten ikke skrevet i stein ennå, men det blir neppe endringer som ikke er bakoverkompatibel). De kan være inne på noe når det gjelder FLAC da jeg ikke finner tegn til at spesifikasjonen tilgjengelig på web er på tur via noen standardiseringsorganisasjon, men i og med at folkene bak Ogg, Theora og Vorbis også har involvert seg i Flac siden 2003, så ser jeg ikke bort fra at også den organiseres via IETF. Jeg kjenner personlig lite til FLAC.

Uredelig argumentasjon bør en holde seg for god til å komme med, spesielt når det er så enkelt i dagens Internet-hverdag å gå misvisende påstander etter i sømmene.

Jeg ble glad da regjeringen annonserte versjon 2 av statens referansekatalog over standarder, men trist da jeg leste hva som faktisk var vedtatt etter høringen. De fleste av de valgte åpne standardene er gode og vil bidra til at alle kan delta på like vilkår i å lage løsninger for staten, men noen av dem blokkerer for de som ikke har anledning til å benytte spesifikasjoner som krever betaling for bruk (såkalt royalty-betaling). Det gjelder spesifikt for H.264 for video og MP3 for lyd. Så lenge bruk av disse var valgfritt mens Ogg Theora og Ogg Vorbis var påkrevd, kunne alle som ønsket å spille av video og lyd fra statens websider gjøre dette uten å måtte bruke programmer der betaling for bruk var nødvendig. Når det nå er gjort valgfritt for de statlige etatene å bruke enten H.264 eller Theora (og MP3 eler Vorbis), så vil en bli tvunget til å forholde seg til royalty-belastede standarder for å få tilgang til videoen og lyden.

Det gjør meg veldig trist at regjeringen har forlatt prinsippet om at alle standarder som ble valgt til å være påkrevd i katalogen skulle være uten royalty-betaling. Jeg håper det ikke betyr at en har mistet all forståelse for hvilke prinsipper som må følges for å oppnå likeverdig konkurranse mellom aktørene i IT-bransjen. NUUG advarte mot dette i sin høringsuttalelse, men ser ut til å ha blitt ignorert.

For å forstå mer om hvorfor standardkatalogens versjon 2 ble som den ble, har jeg bedt om kopi fra FAD av dokumentene som ble lagt frem for regjeringen da de tok sin avgjørelse. De er nå lagt ut på NUUGs wiki, direkte tilgjengelig via "Referansekatalogen v2.0 - Oppsummering av høring" og "Referansekatalog for IT-standarder i offentlig sektor Versjon 2.0, dd.mm.åååå - UTKAST".

Det er tre ting jeg merker meg i oppsummeringen fra høringsuttalelsen da jeg skummet igjennom den. Det første er at forståelsen av hvordan programvarepatenter påvirker fri programvareutvikling også i Norge når en argumenterer med at royalty-betaling ikke er et relevant problem i Norge. Det andre er at FAD ikke har en prinsipiell forståelse av verdien av en enkelt standard innenfor hvert område. Det siste er at påstander i høringsuttalelsene ikke blir etterprøvd (f.eks. påstanden fra Microsoft om hvordan Ogg blir standardisert og påstanden fra politidirektoratet om patentproblemer i Theora).

According to a blog post from Torsten Werner, the current defect report for ISO 29500 (ISO OOXML) is 809 pages. His interesting point is that the defect report is 71 pages more than the full ODF 1.1 specification. Personally I find it more interesting that ISO still believe ISO OOXML can be fixed in ISO. Personally, I believe it is broken beyon repair, and I completely lack any trust in ISO for being able to get anywhere close to solving the problems. I was part of the Norwegian committee involved in the OOXML fast track process, and was not impressed with Standard Norway and ISO in how they handled it.

These days I focus on ODF instead, which seem like a specification with the future ahead of it. We are working in NUUG to organise a ODF seminar this autumn.

Just for fun, I did a search right now on Google for a few file ODF and MS Office based formats (not to be mistaken for ISO or ECMA OOXML), to get an idea of their relative usage. I searched using 'filetype:odt' and equvalent terms, and got these results:

Next, I added a 'site:no' limit to get the numbers for Norway, and got these numbers:

I wonder how these numbers change over time.

I am aware of Google returning different results and numbers based on where the search is done, so I guess these numbers will differ if they are conduced in another country. Because of this, I did the same search from a machine in California, USA, a few minutes after the search done from a machine here in Norway.

And with 'site:no':

Interesting difference, not sure what to conclude from these numbers.

Ble nettopp gjort oppmerksom på en nyhet fra Version2 fra Danmark, der det hevdes at Folketinget har vedtatt at ODF skal brukes som dokumentutvekslingsformat i Staten.

Hyggelig lesning, spesielt hvis det viser seg at de av vedtatt kravlisten for hva som skal aksepteres som referert i kommentarfeltet til artikkelen og en annen artikkel i samme nett-avis. Liker spesielt godt denne:

Det skal demonstreres, at standarden i sin helhed kan implementeres af alle direkte i sin helhed på flere platforme.

Noe slikt burde være et krav også i Norge.