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
|
#use wml::debian::template title="Sammenligning av programvarelisenser"
#use wml::debian::translation-check translation="a2d057aa44562ddcc643379de20b7fc2c0c7f9e4" maintainer="Hans F. Nordhaug"
# Oversatt til norsk av Tor Slettnes <tor@slett.net>
# Oppdateres av Hans F. Nordhaug <hansfn@gmail.com>
<p><strong>*** Dette dokumentet er under utvikling ***</strong></p>
<p>De som har vært rundt Åpen Programvare har en tendens til å
utvikle veldig sterke meninger om lisenser. Begynnere bryr seg
ikke så mye om dem siden de er mer opptatte av å gjøre ferdig
oppgavene de har foran seg, og forstår ikke langtidseffektene av å
velge programvare med én lisens over en annen (det tviles at det
fins mange som forstår nyansene rundt linsensering og ikke har
sterke meninger om temaet).</p>
<p>Gjennom årene har et antall lisenser sprunget opp i forgrunnen,
ettersom de gir programvareforfatterne den type kontroll over
skapningene sine som de fleste utviklerne ønsker. Det er fortsatt
vanlig å finne programvare som ikke har noen
kopirettighetserklæring synlig eller innehholder et særegen lisens
utviklet av forfatteren. Det siste kan være ganske irriterende
for leverandører av programvare (både på Internettet og for folk
som lager cd-er), siden mange av disse lisensene inneholder
<a href="#mistakes">vanlige feil</a> som gjør programvaren vanskelig
å videreformidle.</p>
<p>Det som følger er en liste over vanlige lisenser for fri (åpen)
programvare og noen gode og dårlige egenskaper med hver av dem.
Bare de punktene i lisensen som er forbundet med diskusjonen er
vist. I tillegg er mange av egenskapene listet under overskriften
"BRA/DÅRLIG". Disse er egenskaper som kan være enten bra eller
dårlig alt etter hvordan du ser på det.</p>
<ul>
<li>
<a href="https://www.gnu.org/">The GNU General Public License
(GPL)</a>.<br>
<b>SAMMENDRAG:</b> kildekoden må gjøres tilgjengelig;
programvaren kan selges; nedstammet arbeid må bruke den samme
lisensen.<br>
<b>BRA:</b> Det er god grunn til at dette er den mest brukte
lisensen for fri (åpen) Programvare. Den gjør et god innsats
av å beskytte rettighetene til programvareutviklere, og
tilgjengeligheten til kildekode garanterer at brukere ikke
trenger bekymre seg om å miste støtte i framtiden.<br>
<b>BRA/DÅRLIG:</b> Programvare utgitt på GPL kan ikke blandes
inn i komersiell programvare. Om dette er en bra eller dårlig
sak kommer an på synspunktet ditt. Folk som utvikler
komersiell programvare blir ofte frustrert når det fins en
tilgjengelig løsning som ikke kan brukes på grunn av
konflikter i lisenseringen. Selvfølgelig er det ingenting i
veien for at de kan kontakte forfatteren og se om de kan kjøpe
en versjon under en annen lisens. De fleste som utgir
programvare under GPL ser ikke på disse restriksjonene som
dårlige, fordi den tillater andre å bruke og forbedre
programvaren, samtidig som den forhindrer (for praktiske
formål) andre fra å tjene penger på det harde arbeidet deres
uten tillatelse.
</li>
<li>
<a href="http://language.perl.com/misc/Artistic.html">Artistic License</a>.<br>
<b>SAMMENDRAG:</b><br>
<b>BRA:</b><br>
<b>DÅRLIG:</b>
</li>
<li><a href="https://opensource.org/licenses/BSD-3-Clause">Lisens på BSD-stil</A>.<br>
<b>SAMMENDRAG:</b>Binære filer og kildekode må beskrive
lisensen; annonseringer må anerkjenne utviklerne listet i
lisensen.<br>
<b>BRA/DÅRLIG:</b> Firmaer som vil utgi et kjørbart program
for allmen tilgang (muligens gratis) uten å utgi kildekoden
liker ofte denne lisensen. Et godt eksempel er en bedrift som
som vil utgi et grensesnitt til et grafikk-kort. Forfektere
av åpen kildekode foretrekker at bedriften likevel utgir
spesifikasjoner for maskinvaren. Om utviklingen av
maskinvare-grensensittene for XFree86 er et tegn, er de beste
driverutinene de som er skrevet med kildekoden tilgjengelig.
Bedrifter viser bare produktene sine fram i et dårlig lys når
de utgir innelukkede driverutiner som er sene og feilfylte.
De kan også spare på utviklingskostnader ved å la andre
utvikle grensesnittene for seg.<br>
<b>BRA/DÅRLIG:</b> Hvem som helst kan ta kildekoden, endre
den, og utgi resultatet uten å utgi endringene. Om du syns
dette er bra eller dårlig er opp til deg.
</li>
</ul>
<HR>
<p><a name="mistakes">Noen vanlige feil i selvskrevne
lisenser</a>:</p>
<ul>
<li>
Enten ikke tillate, eller begrense salg av programvaren med
fortjeneste. Dette gjør det vanskelig å formidle programvaren
på cd. Folk gjør ofte den tabben å bruke uttrykk som ikke er
veldefinert, slik som "rimelig pris". Det er bedre å rett og
slett bruke en av de lisensene nevnt ovenfor, siden de oppnår
det samme uten å ty til slike fraser. For eksempel, ved å la
hvem som helst formidle programvaren, holder GPL kostnadene
nede med de vanlige markedskreftene. Dersom noen selger en cd
med høy fortjenestemargin, vil det ikke være lenge før
konkurrenter komme inn på markedet og selge for en lavere
pris.<br>
Merk: Artistic License (Kunsterisk Lisens) bruker uttrykket
"Reasonable copying fee" (Rimelig kopigebyr), men kvalifiserer
uttrykket i et forsøk på å gjøre det mindre vagt.
</li>
<li>
Ikke tillate formidling av modifiserte versjoner av
programvaren. Dette forhindrer visse grupper fra å
distribuere programvaren. For eksempel, siden Debian utgir
ferdigbygd programvare, er det ofte nødvending å endre
kildekoden for å få den bygd eller gjøre den i samsvar med
<a href="ftp://tsx-11.mit.edu/pub/linux/docs/linux-standards/fsstnd/">FSSTND</a>.
Men ved å gjøre dette, er vi nå ikke tillatt å formidle
den.
</li>
<li>
Forlange at alle endringene på programvaren skal rapporteres
til forfatteren. Selv om det er en god idé å rapportere
endringer og forbedringer til forfatteren slik at de kan bli
mer utbredt, kan det føre til problemer å kreve dette. Hvor
mange personer vet hvor de kommer til å være om 5 år? Skift
bare til "Endringer på programvaren bør rapporteres til
forfatteren". De fleste vil.<br>
Denne klausulen er vanligvis inkludert for å forhindre
avgreininger fra å bli utviklet. Historien viser dog at så
lenge utviklingen av den orginale koden ikke stopper, vil
slike avgreininger bare lykkes om en annen kraft driver
gjennom bruddet.
</li>
<li>
Si at programvaren er i allmen eie (public domain), men
deretter legge til begrensninger (slik som å ikke tillate salg
for forjeneste). Enten er noe i allmen eie, eller så er det
ikke - det fins ingen mellomting. Slike lisenser er
meningsløse, og det er sannsynlig at de tillagte
begrensningene ikke ville holdt i en rettsak.
</li>
</ul>
|
