taler-merchant-demos

Python-based Frontends for the Demonstration Web site
Log | Files | Refs | Submodules | README | LICENSE

udi.html (10174B)


      1 <!--#set var="ENGLISH_PAGE" value="/philosophy/udi.en.html" -->
      2 
      3 <!--#include virtual="/server/header.nl.html" -->
      4 <!-- Parent-Version: 1.96 -->
      5 <!-- This page is derived from /server/standards/boilerplate.html -->
      6 <!--#set var="TAGS" value="essays aboutfs free-nonfree" -->
      7 <!--#set var="DISABLE_TOP_ADDENDUM" value="yes" -->
      8 
      9 <!-- This file is automatically generated by GNUnited Nations! -->
     10 <title>De vrije software beweging en UDI - GNU-project - Free Software Foundation</title>
     11 
     12 <!--#include virtual="/philosophy/po/udi.translist" -->
     13 <!--#include virtual="/server/banner.nl.html" -->
     14 <!--#include virtual="/philosophy/ph-breadcrumb.nl.html" -->
     15 <!--GNUN: OUT-OF-DATE NOTICE-->
     16 <!--#include virtual="/server/top-addendum.nl.html" -->
     17 <div class="article reduced-width">
     18 <h2>De vrije software beweging en UDI</h2>
     19 
     20 <address class="byline">door Richard Stallman</address>
     21 
     22 <p>
     23 Een project met de naam UDI (Universal Driver Interface - Universele
     24 koppeling voor stuurprogramma's) probeert &eacute;&eacute;n koppeling te
     25 defini&euml;ren tussen besturingssystemen en stuurprogramma's voor het
     26 aansturen van apparaten.  Wat moet de vrije software beweging hiervan
     27 denken?</p>
     28 <p>
     29 Wanneer we ons een situatie voorstellen waarbij een aantal
     30 besturingssystemen en ontwikkelaars van hardware op gelijke voet gaan
     31 samenwerken, dan zou UDI (wanneer het technisch haalbaar is) een heel goed
     32 idee zijn. Het zou ons in staat stellen slechts &eacute;&eacute;n
     33 stuurprogramma te ontwikkelen voor allerlei apparaten om die vervolgens te
     34 delen. Het zou een hoger niveau van samenwerking mogelijk maken.</p>
     35 <p>
     36 Wanneer we ons op de realiteit gaan richten van de wereld met daarin vrije
     37 software ontwikkelaars die graag samenwerken en private software
     38 ontwikkelaars die graag domineren, dan ziet het plaatje er ineens anders
     39 uit. Geen enkele wijze van UDI-toepassing zal de vrije software beweging tot
     40 voordeel strekken.  Als het al iets doet dan zal het ons verdelen en
     41 verzwakken.</p>
     42 <p>
     43 Wanneer Linux UDI zou ondersteunen en we zouden nieuwe stuurprogramma's gaan
     44 ontwerpen om via UDI met Linux te communiceren, wat zouden daarvan de
     45 gevolgen zijn?</p>
     46 
     47 <ul>
     48 <li> Mensen zouden vrije Linux stuurprogramma's -onder de GPL- kunnen gebruiken
     49 met Windows systemen.
     50 <p>
     51 Dit zou alleen gebruikers van Windows helpen: het heeft geen enkel effect
     52 voor ons als gebruikers van vrije besturingssystemen. Het zou ons ook niet
     53 direct schaden; maar de ontwikkelaars van vrije stuurprogramma's onder de
     54 GPL zouden ontmoedigd kunnen raken wanneer ze het zo gebruikt zien worden,
     55 en dat zou heel slecht zijn. Het kan ook een overtreding van de GPL zijn
     56 door de stuurprogramma's te koppelen aan private besturingssystemen. De
     57 verleiding vergroten om dit toch te doen is vragen om problemen.</p></li>
     58 
     59 <li> Mensen zouden niet-vrije Windows stuurprogramma's kunnen draaien op <a href=
     60 "/gnu/linux-and-gnu.html">GNU/Linux</a> systemen.
     61 <p>
     62 Dit zou geen directe gevolgen hebben voor het aantal apparaten dat wordt
     63 ondersteund door vrije software. Indirect echter zou dit kunnen verminderen
     64 door een verleiding te vormen voor miljoenen GNU/Linux gebruikers die nog
     65 niet geleerd hebben vrijheid te waarderen voor wat het is. Tot aan een punt
     66 waarop men in zou gaan op de verleiding en we langzamerhand zouden
     67 verschuiven naar het gebruik van niet-vrije stuurprogramma's in plaats van
     68 het maken van vrije versies.</p>
     69 <p>
     70 UDI zou op zich niet de ontwikkeling van vrije stuurprogramma's
     71 tegenhouden. Dus wanneer voldoende mensen de verleiding zouden weerstaan,
     72 zouden er nog steeds vrije stuurprogramma's worden ontwikkeld, net als nu
     73 zonder UDI.</p>
     74 <p>
     75 Maar waarom zouden we de gemeenschap willen verzwakken? Waarom de toekomst
     76 van vrije software op het spel zetten? Omdat UDI ons niet verder helpt
     77 kunnen we UDI beter afwijzen.</p></li>
     78 </ul>
     79 
     80 <p>
     81 Gezien dit alles is het geen verrassing dat Intel, een voorstander van UDI,
     82 zich &ldquo;tot de Linux gemeenschap heeft gericht voor hulp met
     83 UDI&rdquo;. Hoe richt een rijk en ego&iuml;stisch bedrijf zich tot een
     84 samenwerkende gemeenschap? Door om een voorkeursbehandeling te vragen
     85 natuurlijk. Ze hebben daarin niets te verliezen en wij zouden wel eens
     86 verrast kunnen worden en onbedoeld ja zeggen.</p>
     87 <p>
     88 Samenwerking met UDI is niet uitgesloten. We zouden UDI, Intel of wie dan
     89 ook niet gelijk voor de Duivel uit moeten maken. Maar voordat we op dit
     90 soort voorstellen ingaan moeten we die grondig bestuderen om er zeker van te
     91 zijn dat het in het voordeel is van de vrije software gemeenschap en niet
     92 alleen in het voordeel van de private software ontwikkelaars. Voor wat
     93 betreft dit onderwerp betekent het dat we samenwerking willen die ons een
     94 stap verder brengt op de weg naar het ultieme doel voor vrije
     95 besturingssystemen en stuurprogramma's: de ondersteuning van <em>alle</em>
     96 relevante apparaten met vrije stuurprogramma's.</p>
     97 <p>
     98 Om dit een goede overeenkomst te laten zijn zou men het UDI project kunnen
     99 wijzigen. Eric Raymond heeft voorgesteld dat een vereiste voor UDI is dat
    100 het stuurprogramma vrije software zal zijn. Dat zou ideaal zijn maar er zijn
    101 ook goede alternatieven. Alleen maar vereisen dat de broncode van het
    102 stuurprogramma openbaar wordt gemaakt en geen bedrijfsgeheim zou al genoeg
    103 zijn&mdash;want ook als is het stuurprogramma dan niet vrij, het zou in
    104 ieder geval genoeg informatie bevatten om een vrije versie hiervan te kunnen
    105 maken.</p>
    106 <p>
    107 Intel zou de vrije software gemeenschap ook buiten UDI nog van dienst kunnen
    108 zijn met dit probleem. Er is bijvoorbeeld een soort van certificering die
    109 ontwikkelaars van hardware willen hebben en die Intel uitreikt. Intel zou
    110 dan bijvoorbeeld de certificering moeilijker kunnen maken voor fabrikanten
    111 die hun specificaties geheim willen houden. Dat is misschien geen complete
    112 oplossing maar zou behoorlijk kunnen helpen.</p>
    113 <p>
    114 Een mogelijk probleem bij een overeenkomst met Intel over UDI is dat wij ons
    115 deel van de overeenkomst meteen zouden moeten inwilligen maar het deel van
    116 Intel zich zou uitstrekken over een zeer lange tijd. We zouden Intel dus in
    117 principe krediet verstrekken. Zal Intel daarbij zijn schuld blijven
    118 inlossen? Waarschijnlijk wel, wanneer we het zwart op wit krijgen en de
    119 overeenkomst waterdicht is; anders kunnen we hier niet van uit
    120 gaan. Bedrijven zijn berucht om hun onbetrouwbaarheid: de mensen waarmee we
    121 zaken doen mogen dan integer zijn maar zij kunnen van hogerhand weer worden
    122 teruggeroepen worden of zelfs vervangen door anderen. Zelfs een CEO met de
    123 meeste aandelen in handen kan altijd nog worden uitgekocht. Wanneer je een
    124 overeenkomst sluit met een bedrijf, verzeker je er dan van dat dit goed op
    125 papier staat.</p>
    126 <p>
    127 Het lijkt er niet op dat Intel uit is op een overeenkomst die ons geeft wat
    128 wij willen. Feitelijk lijkt UDI juist ontworpen zodat specificaties
    129 makkelijker geheim gehouden kunnen worden.</p>
    130 <p>
    131 Het kan natuurlijk geen kwaad de deur op een kier te houden, zolang we maar
    132 oppassen wie we binnen laten.</p>
    133 </div>
    134 
    135 <div class="translators-notes">
    136 
    137 <!--TRANSLATORS: Use space (SPC) as msgstr if you don't have notes.-->
    138  </div>
    139 </div>
    140 
    141 <!-- for id="content", starts in the include above -->
    142 <!--#include virtual="/server/footer.nl.html" -->
    143 <div id="footer" role="contentinfo">
    144 <div class="unprintable">
    145 
    146 <p>Gelieve algemene vragen over FSF &amp; GNU te sturen naar <a
    147 href="mailto:gnu@gnu.org">&lt;gnu@gnu.org&gt;</a>. Er zijn ook nog <a
    148 href="/contact/">andere manieren om in contact te komen</a> met de
    149 FSF. Foute links en andere correcties graag sturen aan <a
    150 href="mailto:webmasters@gnu.org">&lt;webmasters@gnu.org&gt;</a>.</p>
    151 
    152 <p>
    153 <!-- TRANSLATORS: Ignore the original text in this paragraph,
    154         replace it with the translation of these two:
    155 
    156         We work hard and do our best to provide accurate, good quality
    157         translations.  However, we are not exempt from imperfection.
    158         Please send your comments and general suggestions in this regard
    159         to <a href="mailto:web-translators@gnu.org">
    160 
    161         &lt;web-translators@gnu.org&gt;</a>.</p>
    162 
    163         <p>For information on coordinating and contributing translations of
    164         our web pages, see <a
    165         href="/server/standards/README.translations.html">Translations
    166         README</a>. -->
    167 We doen ons best om goede vertalingen te maken maar staan altijd open voor
    168 verbeteringen. Suggesties, op- en aanmerkingen sturen aan: <a
    169 href="mailto:web-translators@gnu.org">&lt;web-translators@gnu.org&gt;</a>.</p>
    170 <p>Zie <a href="/server/standards/README.translations.html"> Translations
    171 README</a> voor informatie over het onderhoud van vertalingen op deze
    172 website.</p>
    173 </div>
    174 
    175 <!-- Regarding copyright, in general, standalone pages (as opposed to
    176      files generated as part of manuals) on the GNU web server should
    177      be under CC BY-ND 4.0.  Please do NOT change or remove this
    178      without talking with the webmasters or licensing team first.
    179      Please make sure the copyright date is consistent with the
    180      document.  For web pages, it is ok to list just the latest year the
    181      document was modified, or published.
    182      
    183      If you wish to list earlier years, that is ok too.
    184      Either "2001, 2002, 2003" or "2001-2003" are ok for specifying
    185      years, as long as each year in the range is in fact a copyrightable
    186      year, i.e., a year in which the document was published (including
    187      being publicly visible on the web or in a revision control system).
    188      
    189      There is more detail about copyright years in the GNU Maintainers
    190      Information document, www.gnu.org/prep/maintain. -->
    191 <p>Copyright &copy; 1998, 2021 Richard Stallman</p>
    192 
    193 <p>Deze pagina is uitgebracht onder de <a rel="license"
    194 href="http://creativecommons.org/licenses/by-nd/4.0/deed.nl">Creative
    195 Commons Naamsvermelding-GeenAfgeleideWerken 4.0 Internationaal licentie</a>.</p>
    196 
    197 <!--#include virtual="/server/bottom-notes.nl.html" -->
    198 <div class="translators-credits">
    199 
    200 <!--TRANSLATORS: Use space (SPC) as msgstr if you don't want credits.-->
    201  </div>
    202 
    203 <p class="unprintable"><!-- timestamp start -->
    204 Bijgewerkt:
    205 
    206 $Date: 2021/10/04 08:33:50 $
    207 
    208 <!-- timestamp end -->
    209 </p>
    210 </div>
    211 </div>
    212 <!-- for class="inner", starts in the banner include -->
    213 </body>
    214 </html>