path: root/talermerchantdemos/blog/articles/nl/free-doc.html

<!--#set var="PO_FILE"
 value='<a href="/philosophy/po/free-doc.nl.po">
 https://www.gnu.org/philosophy/po/free-doc.nl.po</a>'
 --><!--#set var="ORIGINAL_FILE" value="/philosophy/free-doc.html"
 --><!--#set var="DIFF_FILE" value="/philosophy/po/free-doc.nl-diff.html"
 --><!--#set var="OUTDATED_SINCE" value="2019-12-27" --><!--#set var="ENGLISH_PAGE" value="/philosophy/free-doc.en.html" -->

<!--#include virtual="/server/header.nl.html" -->
<!-- Parent-Version: 1.79 -->

<!-- This file is automatically generated by GNUnited Nations! -->
<title>Waarom vrije software vrije handleidingen nodig heeft - GNU-project - Free
Software Foundation</title>

<!--#include virtual="/philosophy/po/free-doc.translist" -->
<!--#include virtual="/server/banner.nl.html" -->
<!--#include virtual="/server/outdated.nl.html" -->
<h2>Waarom vrije software vrije handleidingen nodig heeft</h2>

<blockquote class="announcement"><p>
<a href="http://defectivebydesign.org/ebooks.html">Meld je aan bij onze
mailinglist over de gevaren van e-boeken</a>.
</p></blockquote>

<ul>
<li><a href="/copyleft/fdl.html">De GNU Free Documentation License</a></li>
</ul>

<p>
De grootste tekortkoming bij vrije besturingssystemen zit niet in de
software maar in het gebrek aan goede handleidingen. Veel van onze
belangrijkste programma's hebben nauwelijks documentatie. Handleidingen zijn
een essentieel onderdeel van een softwarepakket; als een belangrijk stuk
vrije software geen bijbehorende vrije handleiding heeft is dat een grote
tekortkoming. Er zijn tegenwoordig aardig wat van die tekortkomingen.</p>

<p>
Een tijd geleden leek het me een goed idee om Perl te leren. Ik haalde
ergens een vrije handleiding vandaan maar vond deze moeilijk te lezen.  Toen
ik gebruikers van Perl vroeg om alternatieven, verwezen ze me naar betere
handleidingen&mdash;maar die waren niet vrij.</p>

<p>
Waarom? De auteurs van deze betere handleidingen hadden die voor O'Reilly
Associates geschreven, die de handleidingen met beperkingen
uitgeeft&mdash;mogen niet gekopieerd worden, niet aangepast, originele tekst
is niet beschikbaar&mdash;waardoor ze uitgesloten zijn van de
vrije-softwaregemeenschap.</p>

<p>
Dat was niet de eerste keer dat dit gebeurde en (helaas voor onze
gemeenschap) ook zeker niet de laatste. Particuliere uitgevers hebben al
vele schrijvers verleid tot het beperken van het gebruik van hun
handleidingen.  Al meerdere keren vertelde een enthousiaste GNU-gebruiker
mij over de handleiding die hij aan het schrijven was om daarmee het
GNU-project te helpen&mdash;om vervolgens alle hoop de grond in te boren
door er aan toe te voegen dat hij een contract had getekend bij een
uitgever, wat beperkingen zou opleggen aan het gebruik van de handleiding
waardoor het voor ons onbruikbaar werd.</p>

<p>
Gezien het feit dat goed kunnen documenteren een schaars goed is onder
programmeurs kunnen we het ons niet veroorloven om op deze manier
handleidingen te verliezen.</p>

<p>
Vrije documentatie gaat, net als vrije software, over vrijheid en niet over
prijs. Het probleem met de handleidingen is niet dat O'Reilly Associates
geld vraagt voor gedrukte handleidingen&mdash;dat is prima (De Free Software
Foundation <a href="http://shop.fsf.org/category/books/">verkoopt ook
gedrukte exemplaren</a> van vrije <a
href="/doc/doc.html">GNU-handleidingen</a>). Maar GNU-handleidingen zijn ook
verkrijgbaar in originele, elektronische vorm met broncode, de anderen
alleen op papier. GNU-handleidingen krijg je met  toestemming om te
kopi&euml;ren en wijzigen; de Perl-handleidingen niet. Die beperkingen
vormen het probleem.</p>

<p>
Criteria voor een vrije handleiding zijn ruwweg dezelfde als voor vrije
software: het gaat erom gebruikers bepaalde vrijheden te geven.  Heruitgeven
(ook commerci&euml;le heruitgave) moet zijn toegestaan, zodat de handleiding
bij iedere kopie van het programma bijgesloten kan worden, in elektronische
dan wel papieren vorm. De toestemming om te veranderen is ook belangrijk.</p>

<p>
Normaliter geloof ik niet dat het belangrijk is dat mensen de mogelijkheid
hebben om allerlei artikelen of boeken te veranderen. Schrijven is niet
noodzakelijkerwijs vergelijkbaar met software. Ik geloof bijvoorbeeld niet
dat het nodig is om toestemming te geven voor het veranderen van dit
artikel.  Het beschrijft slechts onze denkbeelden en doen en laten.</p>

<p>
Er is echter een reden waarom het belangrijk is dat we documentatie van
vrije software kunnen veranderen. Wanneer mensen het recht uitoefenen op het
veranderen van software, zullen ze, als ze enigszins nauwgezet zijn, ook de
handleiding veranderen&mdash;zodat ze actuele en bijgewerkte documentatie
kunnen leveren bij het gewijzigde programma.  Een handleiding die
programmeurs verbiedt nauwgezet te zijn en het werk af te ronden, of beter
gezegd ze dwingt een compleet nieuwe handleiding te schrijven, voldoet niet
aan de behoeften van onze gemeenschap.</p>

<p>
Hoewel een volledig verbod op het veranderen van handleidingen onacceptabel
is, zijn er een aantal beperkingen op de wijze van veranderen die geen
probleem zijn. Zoals de beperking dat de vermelding van de originele auteur
niet mag worden gewijzigd, alsook paragrafen over distributievoorwaarden of
de lijst van auteurs. Ook is het geen probleem om te vereisen dat veranderde
versies voorzien worden van een nota bene dat ze veranderd zijn of complete
secties van de documentatie uitsluiten van wijzigingen zolang deze secties
niet technisch van aard zijn (sommige GNU-handleidingen hebben die).</p>

<p>
Dit soort beperkingen vormen geen probleem omdat het, praktisch gesproken,
de nauwgezette programmeur niet verhindert zijn wijzigingen door te voeren
en het overeen te laten komen met het gewijzigde programma. Oftewel, het
verhindert de vrije-softwaregemeenschap niet om volledig gebruik te maken
van de handleiding.</p>

<p>
Het moet echter mogelijk zijn alle <em>technische</em> inhoud te kunnen
veranderen, om dit vervolgens opnieuw uit te geven via alle gebruikelijke
methoden.  Zo niet, dan hinderen deze beperkingen de gemeenschap en is de
handleiding dus niet vrij en hebben we een andere handleiding nodig.</p>

<p>
Probleem is dat het heel moeilijk is iemand te vinden die een andere
handleiding kan maken als er al een particuliere handleiding bestaat.  Punt
hier is dat veel gebruikers een particuliere handleiding goed genoeg
vinden&mdash;ze zien dus niet de noodzaak een vrije handleiding te maken.
Ze zien niet dat er iets ontbreekt aan het vrije besturingssysteem wat
aangevuld moet worden.</p>

<p>
Waarom vinden gebruikers particuliere handleidingen goed genoeg? Sommigen
hebben hier nog nooit over nagedacht. Ik hoop met dit artikel die mensen tot
nadenken te stemmen.</p>

<p>
Andere gebruikers vinden particuliere handleidingen acceptabel zoals ze ook
private (niet-vrije) software accepteren, uitgaande van puur praktische
beweegredenen, waarbij het begrip vrijheid geen rol speelt.  Eenieder heeft
recht op zijn mening maar aangezien deze niet gebaseerd zijn op vrijheid als
&eacute;&eacute;n van de uitgangspunten kan het geen leidraad zijn voor ons,
die hun vrijheid waarderen.</p>

<p>
Zegt het voort. We raken nog steeds handleidingen kwijt aan private
uitgevers.  Wanneer we meer propageren dat private handleidingen niet goed
genoeg zijn, wellicht dat dan de volgende persoon die ons wil helpen
documentatie te schrijven zich op tijd realiseert dat hij dit vooral vrij
moet houden.</p>

<p>
We kunnen ook commerci&euml;le uitgevers proberen te overtuigen vrije
documentatie te verkopen in plaats van private. Een mogelijke methode om
hierbij te helpen is om uit de beschikbare handleidingen bij voorkeur die
aan te schaffen die vrij is.</p>
<p>
[NB: We hebben een <a href="/doc/other-free-books.html">webpagina met een
lijst van vrije boeken door andere uitgevers</a>].</p>

<div class="translators-notes">

<!--TRANSLATORS: Use space (SPC) as msgstr if you don't have notes.-->
 </div>
</div>

<!-- for id="content", starts in the include above -->
<!--#include virtual="/server/footer.nl.html" -->
<div id="footer">
<div class="unprintable">

<p>Gelieve algemene vragen over FSF &amp; GNU te sturen naar <a
href="mailto:gnu@gnu.org">&lt;gnu@gnu.org&gt;</a>. Er zijn ook nog <a
href="/contact/">andere manieren om in contact te komen</a> met de
FSF. Foute links en andere correcties graag sturen aan <a
href="mailto:webmasters@gnu.org">&lt;webmasters@gnu.org&gt;</a>.</p>

<p>
<!-- TRANSLATORS: Ignore the original text in this paragraph,
        replace it with the translation of these two:

        We work hard and do our best to provide accurate, good quality
        translations.  However, we are not exempt from imperfection.
        Please send your comments and general suggestions in this regard
        to <a href="mailto:web-translators@gnu.org">

        &lt;web-translators@gnu.org&gt;</a>.</p>

        <p>For information on coordinating and submitting translations of
        our web pages, see <a
        href="/server/standards/README.translations.html">Translations
        README</a>. -->
We doen ons best om goede vertalingen te maken maar staan altijd open voor
verbeteringen. Suggesties, op- en aanmerkingen sturen aan: <a
href="mailto:web-translators@gnu.org">&lt;web-translators@gnu.org&gt;</a>.</p>
<p>Zie <a href="/server/standards/README.translations.html"> Translations
README</a> voor informatie over het onderhoud van vertalingen op deze
website.</p>
</div>

<!-- Regarding copyright, in general, standalone pages (as opposed to
     files generated as part of manuals) on the GNU web server should
     be under CC BY-ND 4.0.  Please do NOT change or remove this
     without talking with the webmasters or licensing team first.
     Please make sure the copyright date is consistent with the
     document.  For web pages, it is ok to list just the latest year the
     document was modified, or published.
     
     If you wish to list earlier years, that is ok too.
     Either "2001, 2002, 2003" or "2001-2003" are ok for specifying
     years, as long as each year in the range is in fact a copyrightable
     year, i.e., a year in which the document was published (including
     being publicly visible on the web or in a revision control system).
     
     There is more detail about copyright years in the GNU Maintainers
     Information document, www.gnu.org/prep/maintain. -->
<p>Copyright &copy; 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005,
2006, 2007, 2009, 2015, 2016 Free Software Foundation, Inc.</p>

<p>Deze pagina is uitgebracht onder een <a rel="license"
href="https://creativecommons.org/licenses/by-nd/4.0/deed.nl">Creative
Commons Naamsvermelding-GeenAfgeleideWerken 4.0 Internationaal licentie</a>.</p>

<!--#include virtual="/server/bottom-notes.nl.html" -->
<div class="translators-credits">

<!--TRANSLATORS: Use space (SPC) as msgstr if you don't want credits.-->
 </div>

<p class="unprintable"><!-- timestamp start -->
Bijgewerkt:

$Date: 2020/02/25 23:00:03 $

<!-- timestamp end -->
</p>
</div>
</div>
</body>
</html>