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="Jämförelse mellan programvarulicenser"
#use wml::debian::translation-check translation="2bd18a67682540fb7c79d49a858ca9bcfaa704ed"
<P><STRONG>
******Detta dokument är under utveckling*******
</STRONG>
<P>Folk som sysslar med fri programvara har en benägenhet att utveckla
väldigt starka åsikter om licenser.
Nybörjare oroar sig inte så mycket för dem eftersom de huvudsakligen vill
göra den arbetsuppgift de sysslar med färdig, och inte förstår de långvariga
konsekvenser valet av en programvarulicens framför en annan kan innebära
(det är osäkert om det finns några av de som förstår detaljerna i de olika
licenserna och som inte har starka åsikter i ämnet).
<P>Genom åren har ett antal licenser fått framskjutande ställningar eftersom
de ger programvaruförfattaren den sorts kontroll över sina verk
utvecklarna önskar, men det är fortfarande vanligt med programvara som inte
har någon synlig licens, eller som innehåller en unik licens skriven av
författaren.
Det sistnämnda kan vara väldigt besvärligt för programvarudistributörer
(både direktuppkopplade och för dem som tillverkar cd-skivor) då många
av dessa licenser innehåller <a href="#mistakes">vanliga misstag</a>
vilket gör programvaran svår att distribuera.
<P>Nedan följer en lista över vanliga fria (öppna) programvarulicenser och
några bra och dåliga sidor hos var och en av dem.
Bara de detaljer i licenserna som är relevanta för diskussionen visas.
Dessutom finns flera av detaljerna angivna under rubriken "BRA/DÅLIGA",
vilket innebär att det antingen är bra eller dåligt, beroende på din
egen synvinkel.
<UL>
<LI>The <A HREF="https://www.gnu.org/">GNU General Public License (GPL)</A>.
<BR><B>SAMMANFATTNING:</B>
källkoden måste göras tillgänglig;
programvaran får säljas;
härledda verk måste använda samma licens
<BR><B>BRA:</B>
Det är på goda grunder som detta är den mest använda licensen för fri
(öppen) programvara.
Den skyddar på ett bra sätt rättigheterna hos programvaruutvecklarna
och tillgängligheten för källkod garanterar att användarna inte behöver
oroa sig för att förlora framtida support.
<BR><B>BRA/DÅLIGT:</B>
Programvara som släppts under GPL kan inte användas i kommersiell
programvara.
Huruvida detta verkligen är en dålig sak beror på din egen synvinkel.
Folk som utvecklar kommersiell programvara får ofta en känsla av vanmakt
när en lösning finns tillgänglig, men som inte kan användas på grund
av licenskonflikter.
Naturligtvis finns det ingenting som hindrar dem från att kontakta
författaren och se om de kan köpa en version som använder en annan licens.
De flesta som släpper programvara under GPL anser inte dessa begränsningar
som dåliga, eftersom den tillåter andra att använda och förbättra
programvaran, samtidigt som den (praktiskt taget) hindrar andra från att
tjäna pengar på deras hårda arbete utan deras tillstånd.
<LI>Artistic License
<A HREF="http://language.perl.com/misc/Artistic.html">http://language.perl.com/misc/Artistic.html</A>.
<BR><B>SAMMANFATTNING:</B>
<BR><B>BRA:</B>
<BR><B>DÅLIGT:</B>
<LI><A HREF="https://opensource.org/licenses/BSD-3-Clause">BSD-licens</A>.
<BR><B>SAMMANFATTNING:</B>
Binärer och källkod måste innehålla licensen;
annonsering måste ge erkännande till de utvecklare som listas i licensen
<BR><B>BRA/DÅLIGT:</B>
Företag som vill att en körbar fil ska vara allmänt tillgäng
(möjligtvis gratis) utan att släppa källkoden gillar ofta denna licens.
Ett bra exempel på detta är ett företag som vill släppa en drivrutin för
ett grafikkort.
Förespråkare av fri programvara skulle föredra att företaget ändå
släppte maskinvaruspecifikationerna.
Utvecklingen av drivrutiner för XFree86 tyder på att de bästa
drivrutinerna är dem som skrivs med källkoden tillgänglig, och att
företag bara får sina produkter att framstå i en dålig dager genom
att enbart släppa slutna drivrutiner som är långsamma och innehåller fel.
Företagen kan dessutom spara in på utvecklingskostnader genom att låta andra
utveckla drivrutiner åt dem.
<BR><B>BRA/DÅLIGT:</B>
Vem som helst kan ta källkoden, modifiera den, och släppa resultatet utan
släppa ändringarna.
Om du anser detta vara bra eller dåligt är upp till dig.
</UL>
<HR>
<P><A name="mistakes">Några vanliga misstag i egentillverkade licenser</A>:
<UL>
<LI>Att antingen inte tillåta, eller begränsa försäljning av programvaran
i vinstsyfte, något som gör det svårt att distribuera programvaran
på cd.
Folk gör ofta misstaget att använda termer som inte är väldefinierade,
såsom "skälig kostnad".
Det är bättre att använda en av licenserna ovan, eftersom de åstadkommer
samma sak utan att falla tillbaka på sådana fraser.
GPL håller, till exempel, priserna nere då den tillåter vem som helst
att distribuera programvaran, genom att de vanliga marknadskrafterna
utnyttjas.
Om någon säljer en cd med en hög vinstmarginal tar det inte lång tid
innan konkurrenter kommer in på marknaden och säljer den till ett lägre
pris.
<BR>
Observera: Artistic License använder termen "skälig kopieringskostnad"
("reasonable copying fee"), men definierar termen i ett försök att göra
den mindre vag.
<LI>Inte tillåta distribution av modifierade versioner av programvaran.
Detta förhindrar distribution av programvaran av vissa grupper.
Ett exempel på detta är Debian som distribuerar kompilerad
programvara, vilket ofta gör det nödvändigt att modifiera källkoden
för att göra det möjligt för den att kompilera, eller för att rätta sig
efter
<A HREF="ftp://tsx-11.mit.edu/pub/linux/docs/linux-standards/fsstnd/">FSSTND</A>.
Men genom att göra detta, skulle vi då inte vara tillåtna att distribuera
programvaran.
<LI>Kräva att alla förändringar rapporteras till författaren.
Trots att det är en bra idé att rapportera förändringar/förbättringar till
författaren så att de kan distribueras vidare kan det uppstå problem
om det görs till ett krav.
Hur många vet var de kommer att vara om fem år?
Att helt enkelt ändra det till "förändringar av programvaran bör
rapporteras till författaren" räcker; de flesta kommer ändå att göra det.
<BR>
Denna klausul inkluderas oftast för att förhindra att nya
utvecklingsgrenar framkommer.
Historien har dock visat att så länge som utvecklingen av originalkoden
inte stannar av så kommer inte förgreningar att lyckas såvida det inte
finns någon annan kraft som genomdriver delningen.
<LI>Ange att programvaran är allmän egendom ("public domain"), men sedan
lägga till inskräkningar (såsom att inte tillåta försäljning i
vinstsyfte).
Någonting är antingen allmän egendom, eller så är det inte det – det finns
inget mellanting.
Licenser av denna typ är meningslösa och de extra inskränkningarna kommer
knappast att godkännas av en domstol.
</UL>
|
