1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
|
<!--#set var="ENGLISH_PAGE" value="/philosophy/udi.en.html" -->
<!--#include virtual="/server/header.nl.html" -->
<!-- Parent-Version: 1.77 -->
<!-- This file is automatically generated by GNUnited Nations! -->
<title>De Vrije Software Beweging en UDI - GNU Project - Free Software Foundation</title>
<!--#include virtual="/philosophy/po/udi.translist" -->
<!--#include virtual="/server/banner.nl.html" -->
<h2>De Vrije Software Beweging en UDI</h2>
<p>
Een project met de naam UDI (Universal Driver Interface - Universele
koppeling voor stuurprogramma's) probeert één koppeling te
definiëren tussen besturingssystemen en stuurprogramma's voor het
aansturen van apparaten. Wat moet de vrije software beweging hiervan
denken?</p>
<p>
Wanneer we ons een situatie voorstellen waarbij een aantal
besturingssystemen en ontwikkelaars van hardware op gelijke voet gaan
samenwerken, dan zou UDI (wanneer het technisch haalbaar is) een heel goed
idee zijn. Het zou ons in staat stellen slechts één
stuurprogramma te ontwikkelen voor allerlei apparaten om die vervolgens te
delen. Het zou een hoger niveau van samenwerking mogelijk maken.</p>
<p>
Wanneer we ons op de realiteit gaan richten van de wereld met daarin vrije
software ontwikkelaars die graag samenwerken en private software
ontwikkelaars die graag domineren, dan ziet het plaatje er ineens anders
uit. Geen enkele wijze van UDI-toepassing zal de vrije software beweging tot
voordeel strekken. Als het al iets doet dan zal het ons verdelen en
verzwakken.</p>
<p>
Wanneer Linux UDI zou ondersteunen en we zouden nieuwe stuurprogramma's gaan
ontwerpen om via UDI met Linux te communiceren, wat zouden daarvan de
gevolgen zijn?</p>
<ul>
<li> Mensen zouden vrije Linux stuurprogramma's -onder de GPL- kunnen gebruiken
met Windows systemen.
<p>
Dit zou alleen gebruikers van Windows helpen: het heeft geen enkel effect
voor ons als gebruikers van vrije besturingssystemen. Het zou ons ook niet
direct schaden; maar de ontwikkelaars van vrije stuurprogramma's onder de
GPL zouden ontmoedigd kunnen raken wanneer ze het zo gebruikt zien worden,
en dat zou heel slecht zijn. Het kan ook een overtreding van de GPL zijn
door de stuurprogramma's te koppelen aan private besturingssystemen. De
verleiding vergroten om dit toch te doen is vragen om problemen.</p></li>
<li> Mensen zouden niet-vrije Windows stuurprogramma's kunnen draaien op <a href=
"/gnu/linux-and-gnu.html">GNU/Linux</a> systemen.
<p>
Dit zou geen directe gevolgen hebben voor het aantal apparaten dat wordt
ondersteund door vrije software. Indirect echter zou dit kunnen verminderen
door een verleiding te vormen voor miljoenen GNU/Linux gebruikers die nog
niet geleerd hebben vrijheid te waarderen voor wat het is. Tot aan een punt
waarop men in zou gaan op de verleiding en we langzamerhand zouden
verschuiven naar het gebruik van niet-vrije stuurprogramma's in plaats van
het maken van vrije versies.</p>
<p>
UDI zou op zich niet de ontwikkeling van vrije stuurprogramma's
tegenhouden. Dus wanneer voldoende mensen de verleiding zouden weerstaan,
zouden er nog steeds vrije stuurprogramma's worden ontwikkeld, net als nu
zonder UDI.</p>
<p>
Maar waarom zouden we de gemeenschap willen verzwakken? Waarom de toekomst
van vrije software op het spel zetten? Omdat UDI ons niet verder helpt
kunnen we UDI beter afwijzen.</p></li>
</ul>
<p>
Gezien dit alles is het geen verrassing dat Intel, een voorstander van UDI,
zich “tot de Linux gemeenschap heeft gericht voor hulp met
UDI”. Hoe richt een rijk en egoïstisch bedrijf zich tot een
samenwerkende gemeenschap? Door om een voorkeursbehandeling te vragen
natuurlijk. Ze hebben daarin niets te verliezen en wij zouden wel eens
verrast kunnen worden en onbedoeld ja zeggen.</p>
<p>
Samenwerking met UDI is niet uitgesloten. We zouden UDI, Intel of wie dan
ook niet gelijk voor de Duivel uit moeten maken. Maar voordat we op dit
soort voorstellen ingaan moeten we die grondig bestuderen om er zeker van te
zijn dat het in het voordeel is van de vrije software gemeenschap en niet
alleen in het voordeel van de private software ontwikkelaars. Voor wat
betreft dit onderwerp betekent het dat we samenwerking willen die ons een
stap verder brengt op de weg naar het ultieme doel voor vrije
besturingssystemen en stuurprogramma's: de ondersteuning van <em>alle</em>
relevante apparaten met vrije stuurprogramma's.</p>
<p>
Om dit een goede overeenkomst te laten zijn zou men het UDI project kunnen
wijzigen. Eric Raymond heeft voorgesteld dat een vereiste voor UDI is dat
het stuurprogramma vrije software zal zijn. Dat zou ideaal zijn maar er zijn
ook goede alternatieven. Alleen maar vereisen dat de broncode van het
stuurprogramma openbaar wordt gemaakt en geen bedrijfsgeheim zou al genoeg
zijn—want ook als is het stuurprogramma dan niet vrij, het zou in
ieder geval genoeg informatie bevatten om een vrije versie hiervan te kunnen
maken.</p>
<p>
Intel zou de vrije software gemeenschap ook buiten UDI nog van dienst kunnen
zijn met dit probleem. Er is bijvoorbeeld een soort van certificering die
ontwikkelaars van hardware willen hebben en die Intel uitreikt. Intel zou
dan bijvoorbeeld de certificering moeilijker kunnen maken voor fabrikanten
die hun specificaties geheim willen houden. Dat is misschien geen complete
oplossing maar zou behoorlijk kunnen helpen.</p>
<p>
Een mogelijk probleem bij een overeenkomst met Intel over UDI is dat wij ons
deel van de overeenkomst meteen zouden moeten inwilligen maar het deel van
Intel zich zou uitstrekken over een zeer lange tijd. We zouden Intel dus in
principe krediet verstrekken. Zal Intel daarbij zijn schuld blijven
inlossen? Waarschijnlijk wel, wanneer we het zwart op wit krijgen en de
overeenkomst waterdicht is; anders kunnen we hier niet van uit
gaan. Bedrijven zijn berucht om hun onbetrouwbaarheid: de mensen waarmee we
zaken doen mogen dan integer zijn maar zij kunnen van hogerhand weer worden
teruggeroepen worden of zelfs vervangen door anderen. Zelfs een CEO met de
meeste aandelen in handen kan altijd nog worden uitgekocht. Wanneer je een
overeenkomst sluit met een bedrijf, verzeker je er dan van dat dit goed op
papier staat.</p>
<p>
Het lijkt er niet op dat Intel uit is op een overeenkomst die ons geeft wat
wij willen. Feitelijk lijkt UDI juist ontworpen zodat specificaties
makkelijker geheim gehouden kunnen worden.</p>
<p>
Het kan natuurlijk geen kwaad de deur op een kier te houden, zolang we maar
oppassen wie we binnen laten.</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 & GNU te sturen naar <a
href="mailto:gnu@gnu.org"><gnu@gnu.org></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"><webmasters@gnu.org></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">
<web-translators@gnu.org></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"><web-translators@gnu.org></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>
<p>Copyright © 1998 Richard M. Stallman</p>
<p>Deze pagina valt onder de <a rel="license"
href="http://creativecommons.org/licenses/by-nd/3.0/us/deed.nl">Creative
Commons Attribution-NoDerivs 3.0 United States 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: 2015/02/09 21:03:02 $
<!-- timestamp end -->
</p>
</div>
</div>
</body>
</html>
|
