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 één koppeling te |
25 |
definië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 éé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 “tot de Linux gemeenschap heeft gericht voor hulp met |
83 |
UDI”. Hoe richt een rijk en egoï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—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 & GNU te sturen naar <a |
147 |
href="mailto:gnu@gnu.org"><gnu@gnu.org></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"><webmasters@gnu.org></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 |
<web-translators@gnu.org></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"><web-translators@gnu.org></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 © 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/01 17:02:54 $ |
207 |
|
208 |
<!-- timestamp end --> |
209 |
</p> |
210 |
</div> |
211 |
</div> |
212 |
<!-- for class="inner", starts in the banner include --> |
213 |
</body> |
214 |
</html> |