\documentclass[a4paper,12pt,dutch]{article}
\usepackage{url}
\usepackage{babel}
\usepackage[latin1]{inputenc}
\usepackage[a4paper]{geometry}
\setlength{\parindent}{0cm}
\setlength{\parskip}{0.2cm}
\begin{document}
\title{Waarom open standaarden? Waarom deze definitie?}
\maketitle
Zoals je elders op deze site kunt lezen, wil OpenStandaarden.be het
gebruik van open standaarden in de digitale communicatie bevorderen en
aanmoedigen. Waarom hebben we deze definitie zo opgesteld? Is het
gebruik van een standaardenorganisatie echt noodzakelijk? Waarom is een
open specificatie niet voldoende?

De uiteindelijke reden waarom OpenStandaarden.be zo hamert op het
gebruik van open standaarden is dat alleen open standaarden de garantie
kunnen geven dat de teksten, gegevens, en andere computerbestanden die u
vandaag aanmaakt, over twintig jaar nog gelezen kunnen worden, terwijl
ze terzelfdertijd door iedereen, onafhankelijk van zijn financiële
mogelijkheden, ook vandaag gelezen kunnen worden. De ervaring leert ons
dat dit met gesloten formaten en niet-open standaarden niet mogelijk is,
hoe wijd verspreid ze ook zijn. Immers, bedrijven kunnen failliet gaan,
overgenomen worden, of gewoon beslissen om een bepaald formaat niet
meer te ondersteunen. Zie ook TODO: interne referenties

Onze definitie van open standaarden garandeert u dat u uw bestanden niet
enkel met anderen kan uitwisselen, maar tevens met uzelf in de toekomst.

Laat ons de definitie eens stap voor stap overlopen:

\section*{Open specificatie}

Volgens de definitie:

\texttt{De specificatie moet gratis en online beschikbaar zijn, en vrij
implementeerbaar}

Dit is een absolute minimumvereiste. Wanneer er geen informatie
beschikbaar is over een documentformaat, een protocol, of een andere
manier om digitaal gegevens uit te wisselen, dan kan enkel het programma
dat \emph{op dit moment} beschikbaar is, gebruikt worden om het bestand
te lezen.

In een aantal gevallen is het zo dat er wél andere programma's
zijn die een bepaald documentformaat of protocol kunnen lezen en/of
begrijpen, hoewel het toch niet gaat om een open formaat; een voorbeeld
hiervan is het Microsoft Word-formaat. De reden hiervoor is tweeërlei:

Ten eerste is het niet \emph{helemaal} onmogelijk om een documentformaat
te ontcijferen aan de hand van een werkende implementatie van het
programma. Men kan een tekst in dat programma intikken, controleren hoe
het programma dat opslaat, dan een paar wijzigingen aanmaken, en
uitzoeken wat het gevolg is van die wijzigingen in het
bestand\footnote{dit proces noemt men \emph{reverse engineering}}. Op
deze manier kan men uiteindelijk wel uitvinden hoe het formaat of het
protocol functioneert, maar dit is een erg tijdrovend proces, terwijl
het voor gecompliceerde documentformaten of protocols niet gegarandeerd
succesvol of helemaal correct is; Het is ook op deze manier dat het
programma OpenOffice.org\footnote{\url{http://www.openoffice.org}} in
staat is om Microsoft Word-documenten te lezen, hoewel niet foutloos.

Een tweede reden is dat in sommige gevallen het documentformaat enkel
verkrijgbaar is na betaling\footnote{Dit lijkt op het eerste zicht een
oplossing voor het probleem, maar is het niet; ten eerste zijn
producenten gewoonlijk niet geneigd om gegevens aan concurrenten
te geven, hoe groot of hoe klein de betaalde som ook is; ten tweede kan
de producent van het documentformaat of protocol niet meer bestaan op
het ogenblik dat u een programma in staat wilt stellen om het
documentformaat of protocol te lezen; tot slot kan u ook gewoon niet
kapitaalkrachtig genoeg zijn om het documentformaat of protocol aan te
kopen.}, of via een door de producent van het documentformaat geleverde
in- of uitvoerfilter. Deze zijn echter allemaal lapmiddelen, omdat U
steeds afhangt van de willekeur van een---voor u---derde partij.

Door te vereisen dat de specificatie gratis en online beschikbaar is,
vermijdt de definitie van open specificatie deze willekeur.

Daarnaast vermeldt de definitie ook dat de specificatie \emph{vrij
implementeerbaar} moet zijn. Hiermee wordt bedoeld dat iedereen met de
vereiste programmatiekennis in staat moet zijn om aan de hand van de
specificatie een programma op te stellen dat gebruik kan maken van het
protocol of het documentformaat. Wanneer dat niet het geval zou zijn, is
de specificatie immers geen specificatie meer, maar een nutteloze tekst,
die hoogstens ter versiering kan functioneren...

Merk op dat de term ``vrij implementeerbaar'' niets te maken heeft met
``vrije software'', hoewel veel---maar niet alle---activisten van
OpenStandaarden.be ook voorstanders zijn van vrije software.

Een tweetal voorbeelden van open specificaties zijn mp3 en gif.

\section*{Vrije specificatie}

Volgens de definitie:

\texttt{De specificatie moet open zijn (zie hierboven) en moet vrij zijn
van juridische beperkingen (octrooien, licenties, ...)}

Hoewel de open specificatie de mogelijkheid openhoudt dat iemand anders
uw digitale correspondentie kan lezen, geeft zij geen garanties. Het is
immers mogelijk dat een bepaald deel van de specificatie door een octrooi
of een licentie bedreigd wordt, wat, hoewel software-octrooien in Europa
(nog) niet geldig zijn, de mogelijkheid tot het daadwerkelijk
implementeren van een programma dat van de specificatie gebruik maakt,
beperkt.

Om het anders te zeggen: het is niet de bedoeling dat je gevangenisstraf
riskeert omdat je een programma geschreven hebt waarmee blinden je
teksten makkelijker kunnen lezen, als een deel van de specificatie van
het formaat waarin die teksten geschreven zijn, toevallig in een octrooi
beschreven is. Het alternatief zou zijn dat je de octrooihouder betaalt
voor het mogen gebruiken van zijn octrooi, maar dat brengt ons terug bij
de willekeur van een derde partij.

Het vrij zijn van een bepaalde specificatie maakt dan ook dat mensen
minder terughoudend zullen zijn om gebruik te maken van die vrije
specificatie, wat de keuzevrijheid bevordert. Dit is uiteraard een
goede zaak.

TODO: is iedereen met de volgende paragraaf akkoord?
Vermits het door het aantal uitgegeven octrooien helaas onmogelijk is om
alle toegekende octrooien te controleren, om op die manier te
onderzoeken of ze niet toevallig een vrije specificatie zou reduceren
tot een open specificatie, beperken we ons hier tot de octrooien en
licenties die actief verdedigd worden, omdat het risico alleen daar
aanwezig is.

Om deze reden kunnen we mp3-bestanden en gif-bestanden niet als vrije
specificatie zien; immers, het mp3-formaat valt onder een octrooi van het
Fraunhofer-instituut, terwijl het gifbestand gebruik maakt van het
geoctrooieerde LZW-compressiealgoritme. Alternatieven met een vrije
specificatie voor deze formaten zijn beschikbaar in de vorm van het Ogg
Vorbis-formaat voor mp3, en het PNG-formaat voor gif.

Andere voorbeelden van vrije specificaties zijn de meeste protocols
gedefinieerd in RFC-documenten, zoals e-mailgerelateerde protocols,
het Internet Protocol, en andere.

Tot slot is het belangrijk op te merken dat octrooien een bepaalde tijd
nodig hebben om uitgebracht te worden, zodat betrekkelijk nieuwe vrije
specificaties na een aantal jaren (maximaal 3) tot open specificatie
gereduceerd kunnen worden.

\section*{Open standaard}

Volgens de definitie:

\texttt{De specificatie moet Vrij zijn (zie hierboven) en moet
goedgekeurd zijn door een standaardenorganisatie}

Een standaardenorganisatie waakt over de stabiliteit en de kwaliteit van
een standaard. Het is niet ondenkbaar dat iemand een documentformaat
opstelt, er voor zorgt dat het documentformaat vrij van octrooien en
licenties is, en deze online beschikbaar maakt, maar vervolgens het
document elke maand grondig aanpast.

Op die manier is er wel sprake van een vrije specificatie, maar niet van
een specificiatie die daadwerkelijk gebruikt kan worden. Hoewel een
extreme situatie als de in de paragraaf hierboven beschreven weinig
waarschijnlijk is, kunnen de gevolgen van een niet goed doordachte
wijziging aan een vrije specificatie desastreus zijn voor de
bruikbaarheid van toekomstige implementaties met oudere versies.

Daarnaast zal een standaardenorganisatie ook meerdere partijen uit het
domein waarin de standaard van toepassing is rond de tafel zetten, zodat
een standaard niet alleen bruikbaar is voor de personen die toevallig de
standaard uitgevonden hebben, maar ook voor anderen die het zelfde soort
gegevens willen uitwisselen.

De definitie van standaardenorganisatie werd overgenomen uit TODO: in te
vullen.

Het meest bekende voorbeeld van een open standaard is HTML, zoals
gedefinieerd door het W3C (het World Wide Web Consortium), maar ook MPEG
en JPEG (niet JPEG2000) vallen hieronder.

\end{document}
