-
Jeg overvar i dag FADs pressepresentasjon av arbeidet med ny
-programvare for skriving av
-reiseregninger, som de gir ut som fri programvare. Den gode
-nyheten er at FAD med dette prosjektet demonstrerer vilje til å gå
-foran i å etablere en delingskultur i offentlig sektor, og denne gang
-har hatt fokus på å lage en løsning som fungerer på flere platformer,
-konkret Linux, MacOS X og Windows. Løsningen er utviklet av
-Making Waves på oppdrag fra FAD, og
-kildekoden er tilgjengelig fra
-CodeResort.
-En får lesetilgang til kode og dokumentasjon uten å registrere seg,
-men må registrere seg for f.eks. å melde inn feil og skrive i wikien.
-FAD håper å få erfaring med fri programvareprosjekter vha. dette
-prosjektet, som er første gang de gir ut kildekode fra et
-"egenutviklet" prosjekt.
-
-
Løsningen er BSD-lisensiert, og basert på Adobe Flash, konkret
-Adobe Flex. Den bruker Flash 9, og fungerer ikke med Gnash. I
-tillegg til at selve flash-binæren ikke fungerer med Gnash, så er det
-lagt JavaScript-kode foran web-programmet som nekter å starte
-flash-programmet hvis ikke Adobe Flash 9 er installert. Det var
-irriterende, og jeg måtte hente ut URL til Flash-binæren fra
-HTML-siden og lage min egen testside for å sjekke om den fungerte med
-gnash. Fikk bare en blank flate der programmet skulle startet. Laget
-en side med følgende HTML-snutt for å laste programmet
-
<object
- data="http://213.225.125.209/kunder/dss/Reiseregningen.swf"
- width="100%"
- height="100%"
->
-
-
Bruken av Adobe Flash er spesielt problematisk da Adobes
-Flash-utgave har en lisens som ikke tillater andre en Adobe å
-distribuere deres programpakke. Det gjør det umulig for
-linux-distribusjoner som Debian, Ubuntu og RedHat å legge ved Adobes
-Flash i sine distribusjoner. Adobe Flash er ikke fri programvare.
-Det finnes noen ikke-komplette Flash-implementasjoner som er fri
-programvare, som Gnash og
-swfdec. Jeg spurte
-utviklerne om de hadde testet med alternative utgaver av Flash som
-Gnash og swfdec, men utviklerne hadde ikke hørt om alternativer og
-heller ikke testet løsningen mot disse.
-
-
Videreutvikling av reiseregningsprogrammet vil kreve aksept for
-lisensen til Adobe Flex. I følge Adobe finnes Adobe Flax som
-Eclipse-utvidelse i
-en
-betautgave for Linux, men jeg vet ikke om denne er tilstrekkelig
-for å bygge reiseregningsprogrammet. Jeg mistenker at valg av
-teknologi gjør at svært få fri programvareutviklere ser det som
-interessant å involvere seg i videreutvikling av dette prosjektet.
-Personlig begrenser jeg meg til å jobbe med prosjekter som kan bygges
-og videreutvikles ved hjelp av fri programvare. Andre utviklere av
-fri programvare ser det åpenbart annerledes, da det jo finnes fri
-programvare på Windows. Vi får se om det er tilstrekkelig mange av
-dem til at FAD får bidragsytere utenfra. Prosjektet bærer litt preg
-av "kast det over gjerdet"-metoden for deling, der en legger ut koden
-men det ikke er klart hvem som skal skape fellesskapet som trengs for
-å få et fungerende fri programvareutviklingsmiljø.
-
-
Systemet viser fram et dynamisk skjema som fylles ut fortløpende,
-og der tidligere svar styrer hvilke alternativer en må fylle ut
-senere. Det henter informasjon om takster og regler fra FADs sider,
-der informasjonen skal være lagt ut i maskinlesbart format. Når en er
-ferdig med å fylle ut kan en hente ut en PDF og en XML-fil for
-utskrift eller videre lagring/behandling. Skjemaet er kun
-klientbiten, og eventuell integrering mot økonomisystemer følger ikke
-med. FAD lovte at de skulle bidra til at takster og regelfilene
-skulle holdes oppdatert. Konvertering til PDF var visst .NET-basert.
-Utviklerne hadde ingen idé om dette fungerte med fri
-programvareutgaver som Mono. .NET-utgaven skulle være en begrenset
-del av løsningen, og visstnok ble .NET valgt for å integreres med FADs
-eksisterende tjenerløsning. Løsningen kunne gjenbruke
-personinformasjon vha. XML-filer lagret lokalt på brukerens maskin,
-slik at en slapp å skrive inn samme informasjon hver gang. Sentralt
-lagring var ikke ønsket for å unngå personvernspørsmål, selv om dette
-gjorde det litt vanskeligere for brukeren.
+
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.