-<p>Min mormor har intet dypt forhold til opphavsrettsloven. Hun eier
-ingen kopimaskin eller datamaskin. Hun kan ikke bruke videoopptaker,
-og er generelt sjelden i en situasjon der hun kunne tenkes å kopiere
-noe som er opphavsrettslig vernet. Da jeg en gang forklarte at jeg
-var involvert i
-<a href="http://www.openstreetmap.org/">OpenStreetmap-prosjektet</a>
-(hun lurte på hvorfor jeg kjørte rundt i nabolaget med GPS), var
-"hvorfor ikke bruke de offisielle kartene fra kartverket " det første
-hun spurte om. Jeg er usikker på om svaret ga mening, i og med at
-hun aldri har tenkt nøye over bruksrettigheter og slikt. Hva skulle
-hun med retten til videredistribusjon av nye kartkopier, som ikke
-kopierer kart? Hva skulle hun med retten til å publisere endrede
-utgaver som aldri har hatt behov for annet enn å notere litt på en
-kartkopi? Det er altså mulig å gå igjennom livet (og det har vært
-et langt og innholdsrikt liv for min mormor) uten å forholde seg til
-opphavsrettsloven.</p>
-
-<p>Andre igjen trenger solid kunnskap om konsekvensene av paragrafene
-i opphavsrettsloven i sitt daglige virke, men har av ulike årsaker
-ikke satt seg nøye inn i lovens konsekvens. Denne teksten er tiltenkt
-slike lesere.</p>
-
-<p>Når en publiserer programvare eller annet opphavsrettsbeskyttet
-materiale (eller "verk" som loven kaller det), så er det endel ting
-som er lurt å tenke på. Hvis en ikke sier noe spesifikt om vilkårene
-for publiseringen, så er det opphavsrettens grunnregler som gjelder.
-De sier blant annet at ingen andre enn rettighetshaver kan publisere,
-kopiere og endre verket. Hvis en ønsker å publisere noe uten
-bruksbegrensninger for mottaker (f.eks. fri programvare eller fritt
-tilgjengelige data), så må en altså eksplisitt gi tillatelse for andre
-til å gjøre disse tingene. Slike eksplisitte tillatelser kalles
-gjerne lisenser. Det er en god del å tenke på når en lager lisenser,
-og det er enkelt å gjøre feil, slik at lisensen ikke uttrykker
-intensjonen med publiseringen. Det er derfor lurt å gjenbruke en
-eksisterende lisenstekst hvis det er mulig.</p>
-
-<p>Av flere årsaker er det lurt å ikke finne på sin egen lisenstekst.
-For det første gir det jobb for de som ønsker å bruke verket å sette
-seg inn i, forstå og vurdere hver enkelt lisens, for å finne ut om den
-dekker bruksbehovet. Hver ny lisensvariant gir dermed ekstra arbeide
-for de organisasjoner og individer som vurderer å ta i bruk et
-opphavsrettsbeskyttet verk. Gjenbruk forutsetter gjerne bruk sammen
-med andre verk, f.eks. programmer og biblioteker skal settes sammen
-til et hele, eller datafiler skal brukes sammen med programmer. Det
-er fort gjort å lage en hjemmesnekret lisens som ikke tillater bruk
-sammen med andre komponenter hvis en ikke er påpasselig med
-utformingen av lisensen (såkalte inkompatible lisenser), spesielt hvis
-det ikke er intensjonen ved publisering. Og for det andre, så er det
-fort gjort å glemme noe når en lager lisensteksten, slik at
-rettigheter en ønsket å gi til brukerne ikke blir nevnt og lovens
-begresninger gjelder.. <strong>Første regel ved lisensvalg er derfor
-å unngå å lage sin egen, men forsøke så langt som mulig å bruke en av
-de utallige eksisterende lisensene.</strong></p>
-
-<p>Et lite eksempel på problemer som kan oppstå er
-<a href="http://api.met.no/lisens.html">betingelsene som Meteorologisk
-institutt har gjort sine data tilgjengelig under</a>. De ser pr. i
-dag slik ut (kopiert hit for å sikre at framtidige lesere kjenner
-innholdet hvis de endres):</p>
-
-<blockquote><p>Betingelser for bruk av data
-<br/>Meteorologisk institutt innehar immaterielle- og
-eiendomsrettigheter til data og produkter produsert av instituttet
-(heretter omtalt som PRODUKTER/PRODUKTENE). Selv om et utvalg
-PRODUKTER er tilgjengelige her for nedlasting og bruk, medfører ikke
-dette på noen måte overdragelse av disse rettighetene. PRODUKTENE kan
-brukes til ethvert formål som ikke er i strid med norsk lov. Dersom
-PRODUKTENE videreformidles i opprinnelig form eller i en form hvor de
-opprinnelige PRODUKTENE utgjør en vesentlig og/eller en lett
-gjenkjennelig del, skal Meteorologisk institutt oppgies som
-kilde. Dette må gjøres på en godt synlig måte. Meteorologisk institutt
-kan ikke holdes ansvarlig for eventuelle konsekvenser av bruken av
-PRODUKTENE. Meteorologisk institutt garanterer ikke regelmessighet i
-oppdateringen av PRODUKTENE, og endringer i PRODUKTENE kan forekomme
-uten varsel. For direkte leveranse av spesifisert produktsett,
-vennligst kontakt Meteorologisk institutt.</p></blockquote>
-
-<p>Meteorologisk institutt hevder at dette skal gjøre dem "fritt
-tilgjengelige", og det gjør at jeg mistenker at betingelsene ikke
-reflekterer intensjonen bak publiseringen. I lisensen står det ikke
-at en har rett til å endre dataene og publisere det endrede
-resultatet. Det står heller ingenting om hvorvidt en har rett til
-videredistribusjon. Mangelen på tillatelse til slik bruk gjør at jeg
-ikke ville omtale datagrunnlaget som fritt tilgjengelig. Det er i
-strid med kriteriene for Free Software
-<a href="http://www.fsf.org/licensing/essays/free-sw.html">publisert
-av FSF</a>,
-<a href="http://www.debian.org/social_contract#guidelines">Debian Free
-Software Guidelines</a> og NUUGs beskrivelse av fri programvare
-publisert i
-<a href="http://www.nuug.no/dokumenter/folder-friprogramvare.pdf">NUUGs
-folder om dette</a>. Jeg lurer på hvorfor Meteorologisk institutt
-ikke valgte noen kjent lisens? Skulle tro at en Creative
-Commons-lisens eller en av de mest brukte fri programvarelisensene som
-GPL og BSD kunne duge. Jeg håper Meteorologisk institutt revurderer
-og endrer på betingelsene.</p>
+<p>There are two software projects that have had huge influence on the
+quality of free software, and I wanted to mention both in case someone
+do not yet know them.</p>
+
+<p>The first one is <a href="http://valgrind.org/">valgrind</a>, a
+tool to detect and expose errors in the memory handling of programs.
+It is easy to use, all one need to do is to run 'valgrind program',
+and it will report any problems on stdout. It is even better if the
+program include debug information. With debug information, it is able
+to report the source file name and line number where the problem
+occurs. It can report things like 'reading past memory block in file
+X line N, the memory block was allocated in file Y, line M', and
+'using uninitialised value in control logic'. This tool has made it
+trivial to investigate reproducible crash bugs in programs, and have
+reduced the number of this kind of bugs in free software a lot.
+
+<p>The second one is
+<a href="http://en.wikipedia.org/wiki/Coverity">Coverity</a> which is
+a source code checker. It is able to process the source of a program
+and find problems in the logic without running the program. It
+started out as the Stanford Checker and became well known when it was
+used to find bugs in the Linux kernel. It is now a commercial tool
+and the company behind it is running
+<a href="http://www.scan.coverity.com/">a community service</a> for the
+free software community, where a lot of free software projects get
+their source checked for free. Several thousand defects have been
+found and fixed so far. It can find errors like 'lock L taken in file
+X line N is never released if exiting in line M', or 'the code in file
+Y lines O to P can never be executed'. The projects included in the
+community service project have managed to get rid of a lot of
+reliability problems thanks to Coverity.</p>
+
+<p>I believe tools like this, that are able to automatically find
+errors in the source, are vital to improve the quality of software and
+make sure we can get rid of the crashing and failing software we are
+surrounded by today.</p>
projects / homepage.git / blobdiff