Wat is open source. Open source als een ontwikkelmodel. De open source gemeenschap

Transcriptie

1 Wat is open source door Arnoud Engelfriet Open source is vrijelijk beschikbaar voor iedereen. Omdat het concept van software vrij aanbieden -inclusief broncode- veel mensen vreemd aandoet, zijn er nogal wat mythes en misverstanden rondom open source. Om een paar van die mythes weg te nemen: Open source mag door bedrijven worden gebruikt, en dat gebeurt ook. Het gebruik van open source in een product betekent niet dat automatisch het hele product open source moet worden. Het is toegestaan om geld te vragen voor het verspreiden van open source. Het gebruik van open source als alternatief voor commercieel ontwikkelde software wordt steeds populairder. Open source is hoge kwaliteit, direct beschikbaar en ook nog eens zonder licentiekosten. Een logische keuze dus. En dit geldt niet alleen voor pure software-firma's of adviesbureaus. Ook fabrikanten van elektronica en andere apparaten maken steeds vaker gebruik van open source om grote delen van de functionaliteit daarin te realiseren, om zo sneller met nieuwe producten te kunnen komen. Open source is wel vrij maar geen publiek domein. Ook bij open source horen licenties. De software mag alleen worden gebruikt in overeenstemming met die licenties. Omdat open source voorwaarden nogal af kunnen wijken van "gewone" licenties, is het belangrijk om extra op te letten dat deze voorwaarden worden nageleefd. Open source als een ontwikkelmodel Open source is een ontwikkelmodel voor software waarbij de broncode vrijelijk gedeeld wordt. Iedereen krijgt het recht deze aan te passen en de software in gewijzigde vorm te verspreiden. Het is de bedoeling dat wijzigingen teruggegeven worden aan de oorspronkelijke auteurs, al is dit niet verplicht. Bij dit ontwikkelmodel draait alles om samenwerken. En dit blijkt een zeer succesvolle manier om snel software van hoge kwaliteit te produceren. Alhoewel het model het meest bekend is bij wereldwijde projecten zoals het Linux besturingssysteem of de Apache webserver, kan het ook wel worden gebruikt binnen een bedrijf. Het wordt dan ook wel "Inner Source" genoemd. De open source gemeenschap Open source wordt niet beheerd door een bedrijf, stichting of andere organisatie. Het is een gemeenschap, die bestaat uit een page 1 / 6

2 groot aantal individuen en groepen die bijdragen aan een bepaald project. Een klein deel van deze gemeenschap -de "vrije software" beweging- is politiek actief. Veel open source software ontwikkelaars doen om pragmatische redenen mee en hebben weinig behoefte om deel te nemen aan juridische of politieke discussies. De scheiding tussen deze twee groepen wordt duidelijk zichtbaar als wordt gekeken naar de twee meest prominente organisaties: de Free Software Foundation (FSF) en de Open Source Initiative (OSI). De Free Software Foundation De Free Software Foundation (FSF) is opgericht in 1985 en promoot de rechten van computergebruikers om software te mogen gebruiken, kopiëren, bestuderen, wijzigen en doorgeven. De FSF stimuleert de ontwikkeling van wat zij "vrije software" noemen (vrij in de betekenis van "vrije meningsuiting" en niet zozeer "gratis"). Dit gebeurt vanuit een politieke visie. De FSF vindt dat iedereen het onbeperkte recht moet hebben om software te mogen gebruiken en aan te passen. Beperkingen op dit recht zien zij als moreel verwerpelijk. Software behoort geen eigenaar te hebben. Om dit ideaal te realiseren, heeft Richard Stallman, oprichter van de FSF, de GNU General Public License (GPL) ontwikkeld. Deze licentie bepaalt dat alle GPL software gebruikt, verspreid en aangepast mag worden zonder dat royalties verschuldigd zijn aan de auteurs. Verspreiding van aangepaste of uitgebreide versies mag echter alleen als ook de aanpassingen of uitbreidingen onder de GPL beschikbaar worden gesteld. Deze overervende clausule zorgt ervoor dat vrije software vrij blijft, en bovendien dat ook steeds meer software vrij wordt. Het doel van de FSF is immers ervoor zorgen dat alle software ter wereld vrij zal zijn. De Open Source Initiative De FSF is een politieke organisatie met een harde opstelling richting bedrijven die "onvrije" software gebruiken ("moreel verwerpelijk" is een van hun beleefde uitdrukkingen wat dit betreft). Deze houding, gecombineerd met de -onjuiste- angst dat alle software vrij moet worden als ergens een stukje GPL software gebruikt wordt, heeft bedrijven lang terughoudend gemaakt om de vrije software te gebruiken. In 1998 kondigde het bedrijf Netscape Communications aan dat het de broncode van haar webbrowser vrij beschikbaar zou stellen. Een groep prominente vrije software-ontwikkelaars greep deze kans aan om het ontwikkelmodel te promoten bij bedrijven, en verzon de neutralere term "open source" als omschrijving daarvan. De Open Source Initiative (OSI) werd vervolgens opgericht als een publieke stichting die onder andere licenties certificeert als ze aan bepaalde eisen voldoen. Zulke licenties heten dan officieel "OSI Certified Open Source". Voordelen van open source software Door de vrije beschikbaarheid van de broncode kan iedereen bijdragen aan de verdere ontwikkeling van open source. Veel mensen doen dit dan ook. Dit geeft een continue ontwikkel-cyclus waarmee de software in korte tijd snel wordt uitgebreid en verbeterd. Deze vrije beschikbaarheid is ook een voordeel voor gebruikers. Een gebruiker van open source is niet afhankelijk van de oorspronkelijke auteur om bepaalde verbeteringen of uitbreidingen te realiseren. Hij kan deze gewoon zelf maken. Als de leverancier de ondersteuning stopt, kan de gebruiker de ontwikkeling overnemen of een andere leverancier zoeken. Het feit dat de licentie gratis is, is natuurlijk ook interessant. Risico's van open source software Open source kent enkele unieke risico's vanwege de eveneens unieke licentie-voorwaarden. Voor bedrijven die gewend zijn aan traditionele licenties, kan het duur of lastig zijn om te zorgen dat ze zich eveneens houden aan open source licenties. Het negeren van open source licentie-voorwaarden betekent dat de software zonder geldige licentie wordt gebruikt, wat kan leiden tot een rechtszaak of slechte publiciteit. page 2 / 6

3 Zo is het vaak verplicht om de aanwezigheid van open source te melden in de handleiding van het product. Wie dit pas beseft nadat de handleidingen zijn gedrukt, heeft een probleem. Sommige licenties eisen dat eigen uitbreidingen of verbeteringen aan open source ook als open source worden vrijgegeven. Het bepalen wanneer iets nu precies een uitbreiding is kan een lastige zaak zijn. Veel bedrijven zien deze eisen als een risico en proberen daarom het gebruik van open source zoveel mogelijk te vermijden. Dit is tegenwoordig echter geen realistische optie meer. Het gebruik van open source in commerciële producten wordt steeds populairder. Open source negeren betekent dat een bedrijf zichzelf de toegang ontzegt tot software van hoge kwaliteit zonder licentiekosten. Het gevolg is vertragingen en duurdere producten ten opzichte van de concurrent. Soms is het commercieel simpelweg niet haalbaar om "bij te blijven" bij een open source concurrent voor een zelf ontwikkeld stuk software. De enige optie is dus met de risico's leren omgaan. Uitgangspunten van open source licenties Open source software is vrij beschikbaar voor iedereen, inclusief broncode. De licentie verleent iedereen toestemming om de broncode aan te passen of uit te breiden, bijvoorbeeld om fouten te repareren, om een efficiëntere implementatie te maken of om geheel nieuwe functionaliteit toe te voegen. Ook mag de software, al dan niet in gewijzigde vorm, vrijelijk verspreid worden. De auteur vraagt hier geen geld voor. De software staat gratis beschikbaar op Internet. Sterker nog, iemand die de open source software van een ander verkoopt, mag de opbrengst geheel zelf houden. Geen contract nodig Bij open source licenties is het niet nodig om expliciet een contract te tekenen met de auteur. De software kan legal worden gedownload, en de licentie-voorwaarden zitten bij de software. Wie vervolgens de voorwaarden onaanvaardbaar vindt, hoeft zich er niet aan te houden - maar mag de software dan niet aanpassen of verder verspreiden. Open source licentiecategoriën Er zijn ongeveer 40 verschillende open source licenties met elk hun eigen regels en voorwaarden. Deze kunnen worden onderverdeeld in drie categorieën: Free-for-all ("vrijheid, blijheid") licenties: deze licenties stellen als enige eis dat de auteur(s) worden genoemd. Verder zijn er geen verplichtingen. Voorbeelden zijn de zogeheten BSD en MIT licenties. De Apache webserver wordt bijvoorbeeld onder een dergelijke licentie uitgebracht. Keep-open ("openhouden") licenties: deze licenties eisen dat wijzigingen aan de software ook als open source worden gepubliceerd. Software waarin deze software wordt verwerkt, hoeft daarentegen niet als geheel als open source te worden uitgebracht. Linux-systeembibliotheken en de Firefox webbrowser worden onder dergelijke licenties aangeboden. Share-alike ("samen delen") licenties: deze licenti es eisen dat zowel wijzigingen als uitbreidingen als open source worden gepubliceerd. Het bekendste voorbeeld is de GPL, die bijvoorbeeld van toepassing is op Linux. Een open source licentiepolicy kiezen Het lijkt nu voor de hand te liggen om alleen het gebruik van free-for-all open source toe te staan, en de andere twee vormen buiten te sluiten of aan strenge regels te onderwerpen. Echter, op ongeveer 65% van alle open source is de GPL van toepassing, terwijl slechts ongeveer 15 procent onder een free-for-all licentie beschikbaar is. Wie gebruik wil maken van open source, kan dus niet om share-alike en keep-open licenties heen. Goede regels zijn nodig, maar deze moeten gaan over waar en niet of open source mag worden gebruikt. Interpretatie van licentievoorwaarden Het interpreteren van open source licenties kan lastig zijn. Deze licenties wijken op belangrijke punten af van traditionele, "gesloten" licenties of EULAs. Dit kan voor onverwachte problemen zorgen voor ontwikkelaars of verspreiders wanneer ze page 3 / 6

4 zich pas na verspreiding de consequenties van deze voorwaarde realiseren. Open source licentievoorwaarden hebben bijvoorbeeld vaak de eis dat je gebruik van de software moet melden in de documentatie. Meestal moet zelfs de hele licentie-tekst worden afgedrukt. De broncode moet worden meegeleverd, of op zijn minst worden nagestuurd naar mensen die daar om vragen. En in sommige gevallen moet bepaalde eigen software ook open source gemaakt worden als deze afgeleid is van open source. Licentie-FAQs gebruiken Bij sommige open source licenties is extra uitleg beschikbaar, meestal in de vorm van een FAQ of VVV (veel voorkomende vragen). IBM biedt bijvoorbeeld antwoord op veel gestelde vragen over haar IBM Public License. De FSF doet hetzelfde voor de GPL en heeft bovendien een apart adres ingesteld voor specifieke vragen. Antwoorden uit dergelijke documenten zijn nuttig maar niet zaligmakend. Als de auteur van de software iemand anders is dan de opsteller van de licentie, dan is de interpretatie van de opsteller minder belangrijk dan de interpretatie van de auteur. En alleen die laatste kan uitzonderingen verlenen op de plichten uit de licentie. Soms maakt de auteur zelfs fouten bij de interpretatie van zijn eigen licentie. Een veel voorkomend voorbeeld is "Deze software valt onder de GPL en mag dus niet commercieel gebruikt worden". De GPL staat echter wel degelijk commercieel gebruik toe, zolang de broncode maar wordt meegeleverd en men zich verder ook aan de GPL houdt. Dus wat bedoelde de auteur nu" Gebruikte hij "commercieel" in de zin van "gesloten, zonder broncode mee te leveren" of wilde hij expliciet commercieel gebruik van de software verbieden? Het is daarom verstandig om voorzichtig te zijn bij het interpreteren van open source licentie-voorwaarden. De "geest" van de licentie en de dagelijkse praktijk is vaak belangrijker dan de letterlijke tekst. De belangrijkste licentie-voorwaarden zijn: Naamsvermelding van de auteur Afdrukken van licentievoorwaarden Verspreiden van broncode Geen garanties Naamsvermelding van de auteur In vrijwel alle gevallen is het verplicht om de auteur van de open source software te noemen wanneer diens software wordt gebruikt. Dit zou geen probleem moeten zijn, al is het soms lastig om te achterhalen welke auteurs nu precies genoemd moeten worden of op welke manier. Soms staat dit in de documentatie of op de website. In andere gevallen is een naar een van de auteurs de oplossing. Belangrijk daarbij is wel om de verschillende delen van de software van elkaar te scheiden. Zeg dus niet zomaar "Copyright Joe Hacker" als er een stukje software van Joe Hacker gebruikt wordt. Dat suggereert dat de hele software van hem komt. "Portions copyright Joe Hacker" of zelfs een precieze omschrijving van welke delen is een betere aanpak. De licentie kan eisen stellen aan waar deze naamsvermelding moet gebeuren: in de documentatie, bij het opstartscherm of in een "About" scherm. De laatste twee gevallen zijn natuurlijk lastig als de software wordt gebruikt in een product zonder scherm (bijvoorbeeld embedded software). De auteur vragen om een uitzondering is dan de enige mogelijkheid. Afdrukken van licentievoorwaarden Naast de eis om de naam van de auteur te vermelden, is het in veel gevallen ook verplicht om de tekst van de licentie en de uitsluiting van garantie zelf te reproduceren. Dit mag meestal in de documentatie of handleiding. De tekst moet letterlijk overgenomen worden. Ook hier is het verstandig om deze vooraf te laten gaan door een duidelijke page 4 / 6

5 verklaring dat de licentie alleen betrekking heeft op bepaalde delen en niet op het hele product. "Deze software bevat de ABC bibliotheek geschreven door Joe Hacker. Op deze bibliotheek zijn de volgende voorwaarden van toepassing:" Verspreiden van broncode Open source licenties zoals de GPL eisen dat de broncode van het werk beschikbaar gesteld wordt wanneer het werk wordt verspreid. De eenvoudigste manier om aan deze eis te voldoen is door die broncode te bundelen met de software op de CD ROM. Als de software via een website beschikbaar wordt gesteld, dan is een extra download-link voor de broncode zo gelegd. Wel moet de download van de broncode op de site van de verspreider zelf aangeboden worden. Het is niet genoeg om simpelweg te verwijzen naar de oorspronkelijke lokatie. Als deze immers gesloten wordt, dan wordt niet langer voldaan aan de licentie-eis dat de broncode aangeboden moet worden. Als het niet wenselijk of haalbaar is om de broncode elke keer mee te leveren, dan is er soms een alternatief beschikbaar. Dat hangt echter sterk af van de precieze voorwaarden uit de open source licentie in kwestie. Zo zegt de Mozilla Public License dat het ook toegestaan is om in de documentatie de URL (het webadres) te vermelden waar de broncode kan worden gedownload. De GPL en LGPL bieden een vergelijkbare optie: in plaats van de broncode mag ook een schriftelijk aanbod gedaan worden om iedereen die er om vraagt, broncode op te sturen. Dit aanbod moet minstens drie jaar geldig zijn. Bij deze licenties is het niet voldoende om simpelweg te verwijzen naar een website! Er moet echt een postadres worden genoemd, en de broncode moet dan ook op CD-ROM of vergelijkbaar medium worden opgestuurd. Het vermelden van een webadres kan natuurlijk het aantal verzoeken per post wel verminderen. Geen garanties Vrijwel alle open source software komt zonder enige vorm van garantie. Hooguit wordt er een enkele keer gezegd dat de auteur verklaart dat hij inderdaad de auteur is (en de code dus niet "geleend" heeft van elders). Deze uitsluiting van garantie betekent dat de ontvanger/gebruiker de auteur niet aansprakelijk kan houden voor welke schade dan ook. Uitsluitingen als deze zijn niet uniek voor open source. Wie software koopt in de winkel, kan de leverancier ook zelden aansprakelijk stellen voor schade. Maar wie een bedrijf inhuurt om software te laten ontwikkelen, kan de leverancier normaal wel aansprakelijk stellen voor schade of fouten. En daar wijkt open source dus af van de norm. Herkennen van open source Een klein maar toch significant risico is dat software niet altijd met de juiste licentie-voorwaarden aangeboden wordt. Er zijn gevallen bekend waarin verspreiders "vergaten" de licentie bij te sluiten, of de software op een site plaatsten met de vermelding dat deze vrij van auteursrechten was. Anderen verspreiden de software zonder zich aan de licentie te houden, bijvoorbeeld door de broncode niet mee te leveren. De ontvanger van dergelijke software kan deze dan niet verder verspreiden. Daarnaast kan de licentie van de software worden gewijzigd bij het uitbrengen van een nieuwe versie. Dit moet dus elke keer opnieuw gecontroleerd worden. Als de licentie bijvoorbeeld wijzigt van een eenvoudige BSD licentie naar de GPL, dan moet nu ineens worden voldaan aan de veel uitgebreidere verplichtingen van de GPL. En als laatste, als ontwikkeling van software wordt uitbesteed bij een derde, is er de mogelijkheid dat die leverancier open source in het resultaat verwerkt heeft maar dit niet meldt. In dat geval is de verspreider aansprakelijk voor de schending van de open source licentie. Of dergelijke schade verhaald kan worden op de leverancier, is dan nog maar de vraag. Drie stromingen in open source Open source bestaat in drie hoofdstromingen: de vrijheid, blijheid BSD gemeenschap waar alles mag zonder beperking, de houd mijn code open LGPL/Mozilla gemeenschap en de eerlijk zullen we alles delen GPL gemeenschap. Deze gemeenschappen onderscheiden zich dus door de mate van vrijheid bij het al dan niet open of gesloten houden van de code. Waar de BSD gemeenschap niets eist, vraagt de LGPL/Mozilla gemeenschap om het delen van verbeteringen en de GPL gemeenschap ook om het delen van uitbreidingen. page 5 / 6

6 Powered by TCPDF ( Wat is open source Binnenkort komt er een nieuwe versie van GPL versie 3. Deze is sterk politiek gemotiveerd en kan daarmee een nieuwe stroming creëren. Dat zou er dan wel eens zo uit te kunnen zien: BSD - vrijheid, blijheid voor iedereen, doe maar met de code wat je wilt. Wil iemand zijn verbeteringen niet bijdragen, jammer voor hem. In extreme gevallen laten we Theo de Raadt er wat van zeggen. GPLv2 - gezellig samen goede code ontwikkelen, maar als je er wat mee doet, word je wel geacht je bijdragen met iedereen te delen. En natuurlijk de broncode publiceren als je de code verspreidt, anders laten we Harald Welte of Armijn Hemel op je los. GPLv3 - op de barricaden voor de vrijheid van de gebruiker, en wie de verkeerde dingen doet, is een vijand van het volkde gemeenschap en gaat naast Tivo, Novell en Microsoft in het kolenhok - tenzij hij een debat met RMS wint. De al pragmatische LGPL/Mozilla stroming gaat dan meer samen met de pragmatische GPLv2 stroming, en de meer principiële stroom splitst zich af tot de GPLv3 beweging. Maar de insteek bij GPLv3 vind ik erg negatief, men is tegen van alles en niet zozeer voor iets. Als je niet uitkijkt, kan dat een sfeer oproepen van wij-hebben-gelijk en voor-afwijkende-meningen-is-geen-plaats en dat komt de samenwerking niet ten goede. PDF gegeneerd door ITpedia page 6 / 6