taler-merchant-demos

free-doc.html (10989B)

---

 <!--#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" -->
 
 <!--#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: 2021/05/31 09:06:19 $
 
 <!-- timestamp end -->
 </p>
 </div>
 </div>
 </body>
 </html>