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
|
#use wml::debian::template title="Comparison of Software Licenses"
#use wml::debian::translation-check translation="2bd18a67682540fb7c79d49a858ca9bcfaa704ed"
# Last Translation Update by $Author$
# Last Translation Update at $Date$
<p><strong>******Dit document is in ontwikkeling*******</strong>
<p>Mensen die zich in de Open Source gemeenschap bevinden, ontwikkelen
vaak een uitgesproken mening over licenties. Beginners maken zich er meestal
niet z druk om omdat zij zich meer bezig houden met het afmaken van een
bepaalde taak en zij de implicaties niet overzien
van de keuze van software met een bepaalde licentie (waarschijnlijk zijn
er sowieso niet veel mensen die de nuances van licentievoorwaarden
begrijpen maar geen uitgesproken mening hebben over dat soort zaken).
<p>In de loop van de jaren heeft een aantal licenties de overhand
gekregen, omdat deze de auteurs van programmatuur de soort controle
geven over hun creaties die de meeste ontwikkelaars willen. Het komt
echter nog steeds vaak voor dat een bepaald softwarepakket gene
zichtbaar copyright heeft of een unieke licentie heeft die door de
auteur zelf is bedacht. Dit laatste kan erg vervelend zijn voor
distributeurs van programmatuur (zowel online als de menen die Cd's maken)
omdat veel van deze licenties <a href="#mistakes">veelvoorkomende
fouten</a> bevatten waardoor de software moeilijk te distribueren is.
<p>Hieronder volgt een lijst van vaak gebruikte Vrije (of Open)
softwarelicenties en enkele voor- en nadelen van hen.
Alleen de punten die voor de discussie relevant zijn worden hier
getoond. Ook zijn er veel punten opgenomen onder de noemer
"GOED/SLECHT"; dit zijn punten die zowel goed als slecht kunnen
uitvallen, afhankelijk van uw standpunt.
<ul>
<li>De <a href="https://www.gnu.org/">GNU General Public License (GPL)</a>.
<br>
<b>SAMENVATTING:</b> de broncode moet beschikbaar worden gemaakt;
het programma mag worden verkocht; afgeleide werken moeten
dezelfde licentie gebruiken
<br>
<b>GOED:</b>
Er zijn goede redenen waarom dit de meestgebruikte licentie is voor
Vrije (Open) Software. Het zorgt ervoor dat de rechten van de
ontwikkelaars van het programma goed worden beschermd en de
beschikbaarheid van e broncode garandeert dat de gebruikers zich
geen zorgen hoeven te maken over het ontbreken van ondersteuning in
de toekomst.
<br>
<b>GOED/SLECHT:</b>
Programma's die zijn verspreid onder de GPL kunnen niet worden
opgenomen in commerciële software. Of dit een slecht punt is of
niet hangt af van uw standpunt. Mensen die commerciële software
ontwikkelen voelen zich soms gefrustreerd als er een oplossing
beschikbaar is die niet kan worden gebruikt vanwege een conflict in
de licentievoorwaarden. Natuurlijk is er niets wat hen ervan
weerhoudt om de auteur te benaderen en te kijken of ze een versie
met andere licentievoorwaarden kunnen kopen.
De meeste mensen die software verspreiden onder e GPL, vinden deze
restrictie niet slecht omdat het anderen toestaat om de software te
gebruiken en te verbeteren, terwijl het (voor alle praktische
toepassingen) voorkomt dat anderen zonder hun toestemming geld
verdienen aan hun harde werk.
<li>Artistic License
<a href="http://language.perl.com/misc/Artistic.html">http://language.perl.com/misc/Artistic.html</a>.
<br>
<b>SAMENVATTING:</b>
<br>
<b>GOED:</b>
<br>
<b>SLECHT:</b>
<li><a href="https://opensource.org/licenses/BSD-3-Clause">BSD licentie</a>.
<br>
<b>SAMENVATTING:</b> Zowel binaries als de broncode moeten de
licentie bevatten; in reclame moeten de ontwikkelaars worden
genoemd.
<br>
<b>GOED/SLECHT:</b>
Bedrijven die willen dat een programma algemeen beschikbaar is
(mogelijk gratis) zonder de broncode vrij te geven, gebruiken vaak
deze licentie. Een goed voorbeeld is een bedrijf die een driver
voor een videokaart wil vrijgeven. Voorvechters van Open Source
zouden eigenlijk liever willen dat het bedrijf de specificaties van
hun hardware zouden vrijgeven. Als de ontwikkeling van drivers voor
XFree86 als indicatie wordt genomen, worden de beste drivers
geschreven als de broncode beschikbaar is.
Door trage, propriëtaire drivers met veel bugs te verspreiden, maken
bedrijven alleen maar slechte reclame voor hun producten. Ze kunnen
zich ook ontwikkelingskosten besparen door anderen de driver voor
hen te laten ontwikkelen.
<br>
<b>GOED/SLECHT:</b> Iedereen mag de broncode bewerken, en het
resultaat verspreiden zonder de veranderingen vrij te geven. Of u
dit een goed of juist een slecht punt vindt, is een kwestie van
persoonlijke voorkeur.
</ul>
<hr>
<p><a name="mistakes">Een aantal veel voorkomende vergissingen in
zelfgeschreven licenties </a>:
<ul>
<li>Het niet toestaan, of restricties aanbrengen op de verkoop (met
winstoogmerk) van de software. Dit maakt het lastig om de software
op een CD te distribueren. Een veelgemaakte fout is is het gebruik
van termen die niet goed zijn gedefinieerd, zoals 'redelijke
kosten'. Het is beter om simpelweg een van bovenstaande licenties
te gebruiken omdat zij hetzelfde doel bereiken zonder zulke vage
begrippen te gebruiken. Bijvoorbeeld, door iedereen toe te staan de
software te distribueren, zorgt de GPL ervoor dat, door normale
marktwerking, de kosten laag blijven. Als iemand een CD probeert te
verkopen met een hoge winstmarge, zal het niet lang duren voor een
concurrent opstaat die de CD voor een lagere rijd aanbiedt.<br>
NB: de Artistic License gebruikt ook de term 'Reasonable copying
fee' (redelijke vergoeding voor kopiëren), maar kwalificeert deze
term in een poging deze minder vaag te maken.
<li>Het niet toestaan om aangepaste versies van de software te
verspreiden. Dit hindert de distributie van de software door
bepaalde groepen. Bijvoorbeeld, omdat Debian voorgecompileerde
software verspreidt, is het vaak nodig om de broncode aan te passen
om het programma te laten compileren of om het te laten voldoen aan
de <a href="ftp://tsx-11.mit.edu/pub/linux/docs/linux-standards/fsstnd/">\
FSSTND</a>. Door dit te doen, mogen we de programmatuur echter niet
verspreiden.
<li>Vereisen dat alle veranderingen aan de programmatuur worden gemeld
aan de auteur. Hoewel het een hoed idee is om veranderingen en
verbeteringen te melden aan de auteur zodat ze wijder kunnen worden
verspreid, kan het vereisen hiervan problemen veroorzaken. Hoeveel
mensen weten waar ze over 5 jaar zijn? Verander het liever in
'Rapporteer veranderingen aan de software aub aan de auteur'. De
meeste mensen zullen dit doen.<br>
Deze clausule wordt vaak opgenomen om te voorkomen dat er zich
afsplitsingen van het project kunnen ontwikkelen. De geschiedenis
heeft echter laten zien dat zolang de ontwikkeling van de
oorspronkelijke code niet wordt opgehouden, afsplitsingen alleen
lukken als een andere kracht de splitsing aanwakkert.
<li>Verklaren dat de software zich in het publieke domein bevindt, maar
dan extra beperkingen toevoegen (zoals het niet toestaan van verkoop met
winstoogmerk). Iets zit ofwel in het publieke domein of niet — er
is geen tussenweg. Zulke licentie zijn betekenisloos en waarschijnlijk
zijn de extra condities niet rechtsgeldig.
</ul>
|
