blog/index.rss

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