Vergelijking van softwarelicenties
******Dit document is in ontwikkeling*******
Mensen die zich in de gemeenschap van Open Software bevinden, ontwikkelen vaak een uitgesproken mening over licenties. Beginners maken zich er meestal niet zo druk om omdat zij zich meer bezig houden met het afmaken van een bepaalde taak en zij de implicaties niet overzien van de keuze voor een bepaalde softwarelicentie boven een andere (waarschijnlijk zijn er sowieso niet veel mensen die de nuances van licentievoorwaarden begrijpen en toch geen uitgesproken mening hebben over dat soort zaken).
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 geen 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 veelvoorkomende fouten bevatten waardoor de software moeilijk te distribueren is.
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.
- De GNU General Public License (GPL).
SAMENVATTING: de broncode moet beschikbaar worden gemaakt; het programma mag worden verkocht; afgeleide werken moeten dezelfde licentie gebruiken
GOED: 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 de broncode garandeert dat de gebruikers zich geen zorgen hoeven te maken over het ontbreken van ondersteuning in de toekomst.
GOED/SLECHT: 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 de 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. - Artistic License
http://language.perl.com/misc/Artistic.html.
SAMENVATTING:
GOED:
SLECHT: - BSD-licentie.
SAMENVATTING: Zowel de uitvoerbare programma's als de broncode moeten de licentie bevatten; in reclame moeten de in de licentie vermelde ontwikkelaars worden genoemd.
GOED/SLECHT: 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 dat een stuurprogramma voor een videokaart wil uitbrengen. Voorvechters van Open Source zouden eigenlijk liever willen dat het bedrijf de specificaties van hun hardware zouden vrijgeven. Als de ontwikkeling van stuurprogramma's voor XFree86 als indicatie wordt genomen, worden de beste stuurprogramma's geschreven als de broncode beschikbaar is. Door trage, gepatenteerde stuurprogramma's met veel bugs te verspreiden, maken bedrijven alleen maar slechte reclame voor hun producten. Ze kunnen zich ook ontwikkelingskosten besparen door anderen het stuurprogramma voor hen te laten ontwikkelen.
GOED/SLECHT: 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.
Een aantal veel voorkomende vergissingen bij zelfgeschreven licenties :
- 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 verspreiden. 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 verspreiden, zorgt de GPL ervoor dat door de 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 prijs aanbiedt.
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. - Het niet toestaan om aangepaste versies van de software te verspreiden. Dit hindert de distributie van de software door bepaalde groepen. Bijvoorbeeld, omdat Debian vooraf gecompileerde 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 FSSTND. Door dit te doen, mogen we de programmatuur echter niet verspreiden.
- 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 a.u.b. aan de auteur'. De
meeste mensen zullen dit doen.
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. - 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.