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
|
# Translated by Markku Verkkoniemi on 1999-06-16
#use wml::debian::template title="Ohjelmistolisenssivertailua"
#use wml::debian::translation-check translation="2bd18a67682540fb7c79d49a858ca9bcfaa704ed"
<P><STRONG>******Tämä dokumentti on kehitysvaiheessa*******</STRONG></P>
<P>Vapaiden ohjelmistojen parissa työskentelevillä on taipumus
muodostaa vahvoja mielipiteitä lisenssien suhteen.
Aloittelijat eivät ole niistä yhtä paljon huolissaan,
koska he haluavat saada työn alla olevan tehtävän valmiiksi
eivätkä ymmärrä ohjelmistolisenssin toisen sijasta tehdyn valinnan
aiheuttamia pitkäaikaisvaikutuksia (on epävarmaa, ymmärtävätkö jotkut
eri lisenssien nyansseja ilman vahvoja mielipiteitä
asiasta).
<P>Vuosien varrella jotkut lisenssit ovat saavuttaneet vankan aseman,
koska ne suovat ohjelmistontekijälle mahdollisuuden hallita teoksiaan kuten
kehittäjät haluavat, mutta on edelleen tavallista kohdata ohjelmistoja
ilman minkäänlaista näkyvää tekijänoikeussuojaa tai sellaisia, joiden
ainutkertaisen
lisenssin tekijä on kirjoittanut.
Viimeksimainitusta voi olla paljon harmia ohjelmistojakelijoille
(sekä verkkojakelijoille että CD-valmistajille), koska monet näistä
lisensseistä sisältävät
<a href="#mistakes">yleisiä virheitä</a>, mikä aiheuttaa ohjelmiston
jakelulle hankaluuksia.
<P>Alla on luettelo tavallisista vapaista (avoimista) ohjelmistolisensseistä
hyvine ja huonoine puolineen jokaisessa.
Ainoastaan keskustelulle olennaiset lisenssien yksityiskohdat ovat näkyvissä.
Lisäksi useat yksityiskohdat on kuvattu otsikon "HYVÄÄ/HUONOA" alla,
joka tarkoittaa sitä, että yksityiskohta on joko hyvä tai huono riippuen
näkökulmastasi.
<UL>
<LI><A HREF="https://www.gnu.org/">GNU General Public License (GPL)</A>.
<BR><B>YHTEENVETO:</B>
lähdekoodi tulee olla saatavilla;
ohjelmiston voi myydä;
johdettujen teosten täytyy käyttää samaa lisenssiä
<BR><B>HYVÄÄ:</B>
On hyviä perusteita sille, että tämä on vapaiden (avointen) ohjelmistojen
eniten käyttämä lisenssi.
Se suojaa hyvin ohjelmistonkehittäjien oikeuksia, ja lähdekoodin
saavutettavuus takaa käyttäjille rauhallisen mielen siitä, että he
eivät tule menettämään tukea tulevaisuudessakaan.
<BR><B>HYVÄÄ/HUONOA:</B>
Ohjelmistoa, joka julkistetaan GPL:n alla, ei voi käyttää
omisteisissa ohjelmistoissa.
Onko tämä huono asia, riippuu näkökulmastasi. Ne, jotka kehittävät
omisteisia ohjelmistoja, turhautuvat silloin, kun ratkaisu
on saatavilla, mutta sitä ei voi käyttää lisenssirikkomuksen takia.
Tietenkin mikään ei estä sitä, että he ottaisivat yhteyttä
tekijään ja tutkisivat, olisiko mahdollista ostaa eri lisenssiä
käyttävä versio.
Useimmat, jotka julkaisevat ohjelmistoja GPL:n alla, eivät näe
näitä rajoituksia huonoina, koska se sallii toisten käyttää ja parannella
ohjelmistoa samalla, kun se (käytännössä) estää toisia hankkimasta
rahaa heidän kovan työnsä kustannuksella ilman lupaa.
<LI>Artistic License
<A HREF="http://language.perl.com/misc/Artistic.html">http://language.perl.com/misc/Artistic.html</A>.
<BR><B>YHTEENVETO:</B>
<BR><B>HYVÄÄ:</B>
<BR><B>HUONOA:</B>
<LI><A HREF="https://opensource.org/licenses/BSD-3-Clause">BSD-lisenssi</A>.
<BR><B>YHTEENVETO:</B>
Lisenssin tulee sisältyä binääreihin ja lähdekoodiin;
ilmoituksen tulee tunnustaa kehittäjät, jotka on mainittu lisenssissä.
<BR><B>HYVÄÄ/HUONOA:</B>
Ne yritykset, jotka haluavat suoritettavan ohjelman olevan yleisesti
saatavilla ilman lähdekoodin julkistusta, pitävät usein tästä lisenssistä.
Hyvä esimerkki tästä on yritys, joka haluaa julkaista grafiikkakortin
ajurin.
Vapaiden ohjelmistojen kannattajat edellyttävät vielä, että yritys
julkaisisi laitespesifikaatiot.
Jos XFree86:n laiteajureiden kehitystä voi käyttää viitteenä,
lähdekoodin ollessa
saatavilla kirjoitetaan parhaat ajurit. Yritykset vain
saattavat tuotteensa huonoon valoon julkaisemalla suljettuja
ajureita, jotka ovat hitaita ja sisältävät virheitä.
Lisäksi yritykset pystyvät säästämään kehityskustannuksissaan antamalla
toisten kehittää ajureita niille.
<BR><B>HYVÄÄ/HUONOA:</B>
Kuka tahansa voi hakea lähdekoodin, muokata sitä ja julkistaa
tulokset ilman muutosten julkistusta.
Näetkö tämän huonona vai hyvänä asiana riippuu itsestäsi.
</UL>
<HR>
<P><A NAME="mistakes">Yleisiä virheitä itsekirjoitetuissa lisensseissä</A>:
<UL>
<li>Ohjelmiston myynti voiton tavoittelemiseksi ei ole sallittua
tai sitä rajoitetaan, mikä aiheuttaa vaikeuksia jaettaessa ohjelmistoa
rompuilla.
Ihmiset tekevät usein virheen käyttäessään
käsitteitä, joita ei ole määritelty hyvin, kuten "kohtuullinen kustannus".
On parempi käyttää edellä mainittuja lisenssejä, koska ne saavuttavat saman
ilman epämääräisten sanontojen puutteellisuuksia.
GPL, esimerkiksi, pitää hinnat edullisina, koska se sallii
kenen tahansa jaella ohjelmistoa, ja täten hyödyntää tavallisia
markkinavoimia.
Jos joku myy CD:tä suurella voittomarginaalilla, ei kestä kauan,
ennen kuin kilpailijoita, jotka myyvät halvemmalla hinnalla,
saapuu markkinoille.
<BR>
Huomaa: Artistic License käyttää käsitettä "kohtuullinen kopiointikustannus"
("reasonable copying fee"), mutta määrittelee käsitteen yrittäen tehdä sen
selkeämmäksi.
<LI>Ei sallita ohjelmistosta muokattujen versioiden jakelua.
Tämä vaikeuttaa ohjelmiston jakelua tietyille ryhmille.
Eräs esimerkki tästä on Debian, joka jakelee käännettyjä
ohjelmistoja, mikä edellyttää, että lähtökoodia on muokattava
käännöstä varten tai
<A HREF="ftp://tsx-11.mit.edu/pub/linux/docs/linux-standards/fsstnd/">
FSSTND</A>-standardiin mukauttamiseksi.
Mutta tämän tehtyämme emme siis voisi enää jaella ohjelmistoa.
<LI>Vaaditaan, että kaikista muutoksista raportoidaan tekijälle.
Siitä huolimatta, että on hyvä idea raportoida muutoksista/parannuksista
tekijälle laajemman
jakelun mahdollistamiseksi, voi tästä vaatimuksesta koitua
hankaluuksia.
Kuinka moni tietää sijaintinsa viiden vuoden päästä?
Yksinkertaisesti muuttamalla tämän tekstiksi "ohjelmistomuutoksista
pitäisi raportoida tekijälle" riittää, useimmat tulevat näin
tekemään.
<BR>
Tämä ehto lisätään yleensä uusien kehityshaarojen muodostumisen
estämiseksi.
Historia on kuitenkin osoittanut, että niin kauan kuin alkuperäisen
koodin kehitys jatkuu, ei haaroittuminen onnistu. Jakautumiselle ei riitä
ylläpitävää voimaa.
<LI>Julistetaan, että ohjelmisto on yleisomistuksessa, mutta
sitten lisätään rajoituksia (kuten, että voitontarkoituksessa
ei saa myydä).
Jokin joko on yleisomistuksessa ("public domain") tai sitten ei,
ei ole olemassa välimuotoa.
Tämän tyyppiset lisenssit ovat tarpeettomia, ja lisärajoituksia
tuskin tullaan hyväksymään missään oikeusistuimessa.
</UL>
|
