1 <?xml version=
"1.0" encoding=
"utf-8"?>
2 <rss version='
2.0' xmlns:lj='http://www.livejournal.org/rss/lj/
1.0/' xmlns:
atom=
"http://www.w3.org/2005/Atom">
4 <title>Petter Reinholdtsen
</title>
5 <description></description>
7 <atom:link href=
"index.rss" rel=
"self" type=
"application/rss+xml" />
10 <title>Jeg vil ikke ha BankID
</title>
11 <link>Jeg_vil_ikke_ha_BankID.html
</link>
12 <guid isPermaLink=
"true">Jeg_vil_ikke_ha_BankID.html
</guid>
13 <pubDate>Fri,
30 Oct
2009 13:
05:
00 +
0100</pubDate>
15 <p
>Min hovedbankforbindelse,
16 <a href=
"http://www.postbanken.no/
">Postbanken
</a
>, har fra
1. oktober
17 blokkert tilgangen min til nettbanken hvis jeg ikke godtar vilkårene
18 for
<a href=
"https://www.bankid.no/
">BankID
</a
> og går over til å
19 bruke BankID for tilgangskontroll. Tidligere kunne jeg bruke en
20 kodekalkulator som ga tilgang til nettbanken, men nå er dette ikke
21 lenger mulig. Jeg blokkeres ute fra nettbanken og mine egne penger
22 hvis jeg ikke godtar det jeg anser som urimelige vilkår i
23 BankID-avtalen.
</p
>
25 <p
>BankID er en løsning der banken gis rett til å handle på vegne av
26 meg, med avtalemessig forutsetning at jeg i hvert enkelt tilfelle har
27 bedt banken gjøre dette. BankID kan brukes til å signere avtaler,
28 oppta lån og andre handlinger som har alvorlige følger for meg.
29 Problemet slik jeg ser det er at BankID er lagt opp slik at banken har
30 all informasjon og tilgang som den trenger for å bruke BankID, også
31 uten at jeg er involvert. Avtalemessing og juridisk skal de kun bruke
32 min BankID når jeg har oppgitt pinkode og passord, men praktisk og
33 konkret kan de gjøre dette også uten at min pinkode eller mitt passord
34 er oppgitt, da de allerede har min pinkode og passord tilgjengelig hos
35 seg for å kunne sjekke at riktig pinkode og passord er oppgitt av meg
36 (eller kan skaffe seg det ved behov). Jeg ønsker ikke å gi banken
37 rett til å inngå avtaler på vegne av meg.
</p
>
39 <p
>Rent teknisk er BankID et offentlig nøkkelpar, en privat og en
40 offentlig nøkkel, der den private nøkkelen er nødvendig for å
41 "signere
" på vegne av den nøkkelen gjelder for, og den offentlige
42 nøkkelen er nødvendig for å sjekke hvem som har signert. Banken
43 sitter på både den private og den offentlige nøkkelen, og sier de kun
44 skal bruke den private hvis kunden ber dem om det og oppgir pinkode og
48 <p
>I postbankens
49 <a href=
"https://www.postbanken.no//portalfront/nedlast/no/person/avtaler/BankID_avtale.pdf
">vilkår
50 for BankID
</a
> står følgende:
</p
>
53 <p
>"6. Anvendelsesområdet for BankID
</p
>
55 <p
>PersonBankID kan benyttes fra en datamaskin, eller etter nærmere
56 avtale fra en mobiltelefon/SIM-kort, for pålogging i nettbank og til
57 identifisering og signering i forbindelse med elektronisk
58 meldingsforsendelse, avtaleinngåelse og annen form for nettbasert
59 elektronisk kommunikasjon med Banken og andre brukersteder som har
60 tilrettelagt for bruk av BankID. Dette forutsetter at brukerstedet
61 har inngått avtale med bank om bruk av BankID.
"</p
>
64 <p
>Det er spesielt retten til
"avtaleinngåelse
" jeg synes er urimelig
65 å kreve for at jeg skal få tilgang til mine penger via nettbanken, men
66 også retten til å kommunsere på vegne av meg med andre brukersteder og
67 signering av meldigner synes jeg er problematisk. Jeg må godta at
68 banken skal kunne signere for meg på avtaler og annen kommunikasjon
69 for å få BankID.
</p
>
71 <p
>På spørsmål om hvordan jeg kan få tilgang til nettbank uten å gi
72 banken rett til å inngå avtaler på vegne av meg svarer Postbankens
73 kundestøtte at
"Postbanken har valgt BankID for bl.a. pålogging i
74 nettbank , så her må du nok ha hele denne løsningen
". Jeg nektes
75 altså tilgang til nettbanken inntil jeg godtar at Postbanken kan
76 signere avtaler på vegne av meg.
</p
>
78 <p
>Postbankens kundestøtte sier videre at
"Det har blitt et krav til
79 alle norske banker om å innføre BankID, bl.a på grunn av
80 sikkerhet
", uten at jeg her helt sikker på hvem som har framsatt
81 dette kravet. [Oppdatering: Postbankens kundestøtte sier kravet er
82 fastsatt av
<a href=
"http://www.kredittilsynet.no/
">kreditttilsynet
</a
>
83 og
<a href=
"http://www.bbs.no/
">BBS
</a
>.] Det som er situasjonen er
84 dog at det er svært få banker igjen som ikke bruker BankID, og jeg
85 vet ikke hvilken bank som er et godt alternativ for meg som ikke vil
86 gi banken rett til å signere avtaler på mine vegne.
</p
>
88 <p
>Jeg ønsker mulighet til å reservere meg mot at min BankID brukes
89 til annet enn å identifisere meg overfor nettbanken før jeg vil ta i
90 bruk BankID. Ved nettbankbruk er det begrenset hvor store skader som
91 kan oppstå ved misbruk, mens avtaleinngåelse ikke har tilsvarende
94 <p
>Jeg har klaget vilkårene inn for
<a
95 href=
"http://www.forbrukerombudet.no/
">forbrukerombudet
</a
>, men
96 regner ikke med at de vil kunne bidra til en rask løsning som gir meg
97 nettbankkontroll over egne midler. :(
102 <title>Internet-sensur skal i retten på mandag
</title>
103 <link>Internet_sensur_skal_i_retten_p___mandag.html
</link>
104 <guid isPermaLink=
"true">Internet_sensur_skal_i_retten_p___mandag.html
</guid>
105 <pubDate>Sat,
10 Oct
2009 22:
00:
00 +
0200</pubDate>
107 <p
><a href=
"http://www.dagensit.no/bransje/article1757755.ece
">DagensIT
</a
>
108 melder at Telenor og Tono skal i retten på mandag for å diskutere
109 hvorvidt Tonos krav om at Telenor skal blokkere for tilgang til The
110 Pirate Bay er i tråd med norsk rett. Det blir interessant å se
111 resultatet fra den rettsaken.
</p
>
113 <p
>Jeg bet meg dog merke i en av påstandene fra Tonos advokat Cato
114 Strøm, som forteller at
"Pirate Bay inneholder
95 prosent ulovlig
115 utlagt materiale, og å stanse tilgangen til det kan ikke kalles
116 sensur
". Jeg tok en titt på
117 <a href=
"http://thepiratebay.org/
">forsiden til The Pirate Bay
</a
>,
118 som forteller at det pr. i dag er
1 884 694 torrenter på trackeren.
119 Dette tilsvarer antall filer en kan søke blant og hente ned ved hjelp
120 av The Pirate Bay.
5% av dette antallet er
94 235. Det kan dermed
121 virke som om Tonos advokat mener at det ikke er sensur å blokkere for
122 tilgang til nesten
100 000 lovlige filer. Jeg lurer på om han er
123 korrekt sitert.
</p
>
125 <p
>Lurer også på hvor
95%-tallet kommer fram. Er det seriøs og
126 etterprøvbar forskning på området som viser at dette er andelen
127 ulovlige filer tilgjengelig via The Pirate Bay, eller er det
128 musikkbransjenes egne tall? De har
129 <a href=
"http://www.guardian.co.uk/music/
2009/oct/
06/edwyn-collins-sharing-music
">jo
130 demonstrert
</a
> at de ikke er i stand til å skille lovlig og ulovlig
131 bruk av musikk.
</p
>
136 <title>MVA på bøker med DRM, ikke MVA på bøker uten DRM?
</title>
137 <link>MVA_p___b__ker_med_DRM__ikke_MVA_p___b__ker_uten_DRM_.html
</link>
138 <guid isPermaLink=
"true">MVA_p___b__ker_med_DRM__ikke_MVA_p___b__ker_uten_DRM_.html
</guid>
139 <pubDate>Wed,
23 Sep
2009 10:
00:
00 +
0200</pubDate>
141 <p
>Elektroniske bøker diskuteres for tiden, etter at
142 <a href=
"http://www.aftenposten.no/kul_und/litteratur/article3280914.ece
">bokbransjen
143 hevder
</a
> det er usikkert om de kommer til å gi ut elektroniske
144 bøker så lenge det er merverdiavgift på elektroniske bøker og ikke
145 på papirbøker. I den forbindelse så jeg et interessant forslag i
147 <a href=
"http://www.digi.no/php/ny_debatt.php?id=
823912">digi-debatt
</a
>
148 jeg hadde sans for.
"einarr
" foreslo at DRM-infiserte elektroniske
149 bøker bør ha merverdiavgift, da
"de ikke bidrar til
150 kunnskapsspredning på samme måte
" som papirbøker og dermed går
151 imot intensjonene bak mva-fritaket. Bøker uten DRM derimot bør ha
152 mva-fritak da de
"kan overføres mellom enheter, leses på ulike
153 plattformer, lånes ut og siteres og kopieres fra
" slik en kan med
154 papirbøker.
</p
>
156 <p
>En oppfølgerkommentar sier seg enig i dette, da DRM-infisert
157 materiale må anses som leid og dermed en tjeneste, mens materiale uten
158 DRM må anses som et kjøp.
</p
>
163 <title>Sikkerhet til sjøs trenger sjøkart uten bruksbegresninger
</title>
164 <link>Sikkerhet_til_sj__s_trenger_sj__kart_uten_bruksbegresninger.html
</link>
165 <guid isPermaLink=
"true">Sikkerhet_til_sj__s_trenger_sj__kart_uten_bruksbegresninger.html
</guid>
166 <pubDate>Sun,
23 Aug
2009 10:
00:
00 +
0200</pubDate>
168 <p
>Sikkerhet til sjøs burde være noe som opptar mange etter den siste
169 oljeutslippsulykken med Full City, som har drept mye liv langs sjøen.
170 En viktig faktor for å bedre sikkerheten til sjøs er at alle som
171 ferdes på sjøen har tilgang til oppdaterte sjøkart som forteller hvor
172 det grunner og annet en må ta hensyn til på sjøen.
</p
>
174 <p
>Hvis en er enig i at tilgang til oppdaterte sjøkart er viktig for
175 sikkerheten på sjøen, så er det godt å vite at det i dag er teknisk
176 mulig å sikre alle enkel tilgang til oppdaterte digitale kart over
177 Internet. Det trenger heller ikke være spesielt kostbart.
</p
>
179 <p
>Både ved Rocknes-ulykken i Vatlestraumen, der
18 mennesker mistet
180 livet, og ved Full City-ulykken utenfor Langesund, der mange tonn olje
181 lekket ut i havet, var det registrert problemer relatert til
182 oppdaterte sjøkart. Ved Rocknes-ulykken var de elektroniske kartene
183 som ble brukt ikke oppdatert med informasjon om nyoppdagede grunner og
184 losen kjente visst ikke til disse nye grunnene. Papirkartene var dog
185 oppdaterte. Ved Full City-ulykken hadde en kontroll av skipet noen
186 uker tidligere konstatert manglende sjøkart.
</p
>
188 <p
>Jeg tror en løsning der digitale sjøkart kunne lastes ned direkte
189 fra sjøkartverket av alle som ønsket oppdaterte sjøkart, uten
190 brukerbetaling og uten bruksbegresninger knyttet til kartene, vil
191 gjøre at flere folk på sjøen vil holde seg med oppdaterte sjøkart,
192 eller sjøkart i det hele tatt. Resultatet av dette vil være økt
193 sikkerhet på sjøen. En undersøkelse gjennomført av Opinion for
194 Gjensidige i
2008 fortalte at halvparten av alle båteierne i landet
195 ikke har sjøkart i båten.
</p
>
197 <p
>Formatet på de digitale sjøkartene som gjøræs tilgjengelig fra
198 sjøkartverket må være i henhold til en fri og åpen standard, slik at
199 en ikke er låst til enkeltaktørers godvilje når datafilene skal tolkes
200 og forstås, men trenger ikke publiseres fra sjøkartverket i alle
201 formatene til verdens skips-GPS-er i tillegg. Hvis det ikke er
202 kostbart for sjøkartverket bør de gjerne gjøre det selv, men slik
203 konvertering kan andre ta seg av hvis det er et marked for det.
</p
>
205 <p
>Hvis staten mener alvor med å forbedre sikkerheten til sjøs, må de
206 gjøre sitt for at alle båteiere har oppdaterte kart, ikke bare snakke
207 om hvor viktig det er at de har oppdaterte kart. Det bør være
208 viktigere for staten at båtene
<strong
>har
</strong
> oppdaterte kart
209 enn at de er pålagt å ha oppdaterte kart.
</p
>
211 <p
>Sjøkartene er
<a href=
"http://kart.kystverket.no/
">tilgjengelig på web
212 fra kystverket
</a
>, men så vidt jeg har klart å finne, uten
213 bruksvilkår som muliggjør gjenbruk uten bruksbegresninger.
</p
>
215 <p
>OpenStreetmap.org-folk er lei av mangel på sjøkart, og har startet
216 på et dugnadsbasert fribrukskart for havet,
217 <a href=
"http://openseamap.org/
">OpenSeaMap
</a
>. Datagrunnlaget er
218 OpenStreetmap, mens framvisningen er tilpasset bruk på sjøen. Det
219 gjenstår mye før en kan bruke dette til å seile sikkert på havet, men
220 det viser at behovet for fribruks-sjøkart er til stedet.
</p
>
225 <title>Relative popularity of document formats (MS Office vs. ODF)
</title>
226 <link>Relative_popularity_of_document_formats__MS_Office_vs__ODF_.html
</link>
227 <guid isPermaLink=
"true">Relative_popularity_of_document_formats__MS_Office_vs__ODF_.html
</guid>
228 <pubDate>Wed,
12 Aug
2009 15:
50:
00 +
0200</pubDate>
230 <p
>Just for fun, I did a search right now on Google for a few file ODF
231 and MS Office based formats (not to be mistaken for ISO or ECMA
232 OOXML), to get an idea of their relative usage. I searched using
233 'filetype:odt
' and equvalent terms, and got these results:
</P
>
236 <tr
><th
>Type
</th
><th
>ODF
</th
><th
>MS Office
</th
></tr
>
237 <tr
><td
>Tekst
</td
> <td
>odt:
282000</td
> <td
>docx:
308000</td
></tr
>
238 <tr
><td
>Presentasjon
</td
> <td
>odp:
75600</td
> <td
>pptx:
183000</td
></tr
>
239 <tr
><td
>Regneark
</td
> <td
>ods:
26500 </td
> <td
>xlsx:
145000</td
></tr
>
242 <p
>Next, I added a
'site:no
' limit to get the numbers for Norway, and
243 got these numbers:
</p
>
246 <tr
><th
>Type
</th
><th
>ODF
</th
><th
>MS Office
</th
></tr
>
247 <tr
><td
>Tekst
</td
> <td
>odt:
2480 </td
> <td
>docx:
4460</td
></tr
>
248 <tr
><td
>Presentasjon
</td
> <td
>odp:
299 </td
> <td
>pptx:
741</td
></tr
>
249 <tr
><td
>Regneark
</td
> <td
>ods:
187 </td
> <td
>xlsx:
372</td
></tr
>
252 <p
>I wonder how these numbers change over time.
</p
>
254 <p
>I am aware of Google returning different results and numbers based
255 on where the search is done, so I guess these numbers will differ if
256 they are conduced in another country. Because of this, I did the same
257 search from a machine in California, USA, a few minutes after the
258 search done from a machine here in Norway.
</p
>
262 <tr
><th
>Type
</th
><th
>ODF
</th
><th
>MS Office
</th
></tr
>
263 <tr
><td
>Tekst
</td
> <td
>odt:
129000</td
> <td
>docx:
308000</td
></tr
>
264 <tr
><td
>Presentasjon
</td
> <td
>odp:
44200</td
> <td
>pptx:
93900</td
></tr
>
265 <tr
><td
>Regneark
</td
> <td
>ods:
26500 </td
> <td
>xlsx:
82400</td
></tr
>
268 <p
>And with
'site:no
':
271 <tr
><th
>Type
</th
><th
>ODF
</th
><th
>MS Office
</th
></tr
>
272 <tr
><td
>Tekst
</td
> <td
>odt:
2480</td
> <td
>docx:
3410</td
></tr
>
273 <tr
><td
>Presentasjon
</td
> <td
>odp:
175</td
> <td
>pptx:
604</td
></tr
>
274 <tr
><td
>Regneark
</td
> <td
>ods:
186 </td
> <td
>xlsx:
296</td
></tr
>
277 <p
>Interesting difference, not sure what to conclude from these
283 <title>ISO still hope to fix OOXML
</title>
284 <link>ISO_still_hope_to_fix_OOXML.html
</link>
285 <guid isPermaLink=
"true">ISO_still_hope_to_fix_OOXML.html
</guid>
286 <pubDate>Sat,
8 Aug
2009 14:
00:
00 +
0200</pubDate>
288 <p
>According to
<a
289 href=
"http://twerner.blogspot.com/
2009/
08/defects-of-office-open-xml.html
">a
290 blog post from Torsten Werner
</a
>, the current defect report for ISO
291 29500 (ISO OOXML) is
809 pages. His interesting point is that the
292 defect report is
71 pages more than the full ODF
1.1 specification.
293 Personally I find it more interesting that ISO still believe ISO OOXML
294 can be fixed in ISO. Personally, I believe it is broken beyon repair,
295 and I completely lack any trust in ISO for being able to get anywhere
296 close to solving the problems. I was part of the Norwegian committee
297 involved in the OOXML fast track process, and was not impressed with
298 Standard Norway and ISO in how they handled it.
</p
>
300 <p
>These days I focus on ODF instead, which seem like a specification
301 with the future ahead of it. We are working in NUUG to organise a ODF
302 seminar this autumn.
</p
>
307 <title>Debian has switched to dependency based boot sequencing
</title>
308 <link>Debian_has_switched_to_dependency_based_boot_sequencing.html
</link>
309 <guid isPermaLink=
"true">Debian_has_switched_to_dependency_based_boot_sequencing.html
</guid>
310 <pubDate>Mon,
27 Jul
2009 23:
50:
00 +
0200</pubDate>
312 <p
>Since this evening, with the upload of sysvinit version
2.87dsf-
2,
313 and the upload of insserv version
1.12.0-
10 yesterday, Debian unstable
314 have been migrated to using dependency based boot sequencing. This
315 conclude work me and others have been doing for the last three days.
316 It feels great to see this finally part of the default Debian
317 installation. Now we just need to weed out the last few problems that
318 are bound to show up, to get everything ready for Squeeze.
</p
>
320 <p
>The next step is migrating /sbin/init from sysvinit to upstart, and
321 fixing the more fundamental problem of handing the event based
322 non-predictable kernel in the early boot.
</p
>
327 <title>Taking over sysvinit development
</title>
328 <link>Taking_over_sysvinit_development.html
</link>
329 <guid isPermaLink=
"true">Taking_over_sysvinit_development.html
</guid>
330 <pubDate>Wed,
22 Jul
2009 23:
00:
00 +
0200</pubDate>
332 <p
>After several years of frustration with the lack of activity from
333 the existing sysvinit upstream developer, I decided a few weeks ago to
334 take over the package and become the new upstream. The number of
335 patches to track for the Debian package was becoming a burden, and the
336 lack of synchronization between the distribution made it hard to keep
337 the package up to date.
</p
>
339 <p
>On the new sysvinit team is the SuSe maintainer Dr. Werner Fink,
340 and my Debian co-maintainer Kel Modderman. About
10 days ago, I made
341 a new upstream tarball with version number
2.87dsf (for Debian, SuSe
342 and Fedora), based on the patches currently in use in these
343 distributions. We Debian maintainers plan to move to this tarball as
344 the new upstream as soon as we find time to do the merge. Since the
345 new tarball was created, we agreed with Werner at SuSe to make a new
346 upstream project at
<a href=
"http://savannah.nongnu.org/
">Savannah
</a
>, and continue
347 development there. The project is registered and currently waiting
348 for approval by the Savannah administrators, and as soon as it is
349 approved, we will import the old versions from svn and continue
350 working on the future release.
</p
>
352 <p
>It is a bit ironic that this is done now, when some of the involved
353 distributions are moving to upstart as a syvinit replacement.
</p
>
358 <title>Regjerningens oppsummering av høringen om standardkatalogen versjon
2</title>
359 <link>Regjerningens_oppsummering_av_h__ringen_om_standardkatalogen_versjon_2.html
</link>
360 <guid isPermaLink=
"true">Regjerningens_oppsummering_av_h__ringen_om_standardkatalogen_versjon_2.html
</guid>
361 <pubDate>Thu,
9 Jul
2009 14:
40:
00 +
0200</pubDate>
363 <p
>For å forstå mer om hvorfor standardkatalogens versjon
2 ble som
364 den ble, har jeg bedt om kopi fra FAD av dokumentene som ble lagt frem
365 for regjeringen da de tok sin avgjørelse. De er nå lagt ut på NUUGs
366 wiki, direkte tilgjengelig via
"<a
367 href=
"http://wiki.nuug.no/uttalelser/
200901-standardkatalog-v2?action=AttachFile
&do=get
&target=kongelig-resolusjon.pdf
">Referansekatalogen
368 v2.0 - Oppsummering av høring
</a
>" og
"<a
369 href=
"http://wiki.nuug.no/uttalelser/
200901-standardkatalog-v2?action=AttachFile
&do=get
&target=kongelig-resolusjon-katalogutkast.pdf
">Referansekatalog
370 for IT-standarder i offentlig sektor Versjon
2.0, dd.mm.åååå -
371 UTKAST
</a
>".
</p
>
373 <p
>Det er tre ting jeg merker meg i oppsummeringen fra
374 høringsuttalelsen da jeg skummet igjennom den. Det første er at
375 forståelsen av hvordan programvarepatenter påvirker fri
376 programvareutvikling også i Norge når en argumenterer med at
377 royalty-betaling ikke er et relevant problem i Norge. Det andre er at
378 FAD ikke har en prinsipiell forståelse av verdien av en enkelt
379 standard innenfor hvert område. Det siste er at påstander i
380 høringsuttalelsene ikke blir etterprøvd (f.eks. påstanden fra
381 Microsoft om hvordan Ogg blir standardisert og påstanden fra
382 politidirektoratet om patentproblemer i Theora).
</p
>
387 <title>Regjerningen forlater prinsippet om ingen royalty-betaling i standardkatalogen versjon
2</title>
388 <link>Regjerningen_forlater_prinsippet_om_ingen_royalty_betaling_i_standardkatalogen_versjon_2.html
</link>
389 <guid isPermaLink=
"true">Regjerningen_forlater_prinsippet_om_ingen_royalty_betaling_i_standardkatalogen_versjon_2.html
</guid>
390 <pubDate>Mon,
6 Jul
2009 21:
00:
00 +
0200</pubDate>
392 <p
>Jeg ble glad da regjeringen
393 <a href=
"http://www.digi.no/
817635/her-er-statens-nye-it-standarder
">annonserte
</a
>
395 <a href=
"http://www.regjeringen.no/upload/FAD/Vedlegg/IKT-politikk/Referansekatalogen_versjon2.pdf
">statens
396 referansekatalog over standarder
</a
>, men trist da jeg leste hva som
397 faktisk var vedtatt etter
398 <a href=
"http://www.regjeringen.no/nb/dep/fad/dok/horinger/horingsdokumenter/
2009/horing---referansekatalog-versjon-
2.html
">høringen
</a
>.
399 De fleste av de valgte åpne standardene er gode og vil bidra til at
400 alle kan delta på like vilkår i å lage løsninger for staten, men
401 noen av dem blokkerer for de som ikke har anledning til å benytte
402 spesifikasjoner som krever betaling for bruk (såkalt
403 royalty-betaling). Det gjelder spesifikt for H
.264 for video og MP3
404 for lyd. Så lenge bruk av disse var valgfritt mens Ogg Theora og Ogg
405 Vorbis var påkrevd, kunne alle som ønsket å spille av video og lyd
406 fra statens websider gjøre dette uten å måtte bruke programmer der
407 betaling for bruk var nødvendig. Når det nå er gjort valgfritt for
408 de statlige etatene å bruke enten H
.264 eller Theora (og MP3 eler
409 Vorbis), så vil en bli tvunget til å forholde seg til
410 royalty-belastede standarder for å få tilgang til videoen og
413 <p
>Det gjør meg veldig trist at regjeringen har forlatt prinsippet om
414 at alle standarder som ble valgt til å være påkrevd i katalogen skulle
415 være uten royalty-betaling. Jeg håper det ikke betyr at en har mistet
416 all forståelse for hvilke prinsipper som må følges for å oppnå
417 likeverdig konkurranse mellom aktørene i IT-bransjen. NUUG advarte
419 <a href=
"http://wiki.nuug.no/uttalelser/
200901-standardkatalog-v2
">sin
420 høringsuttalelse
</a
>, men ser ut til å ha blitt ignorert.
</p
>