Juridische aspecten van openbron software
Openbron software heeft in heel wat bedrijven al een centrale plaats ingenomen. Net zoals bij het gebruik van propriëtaire software spelen er echter ook heel wat juridische aspecten mee. Hoe rechtszeker bent u wanneer u openbron software gebruikt? En hoe zit het met garanties? Riskeert u bovendien niet te afhankelijk te worden van één ontwikkelaar? Wij zochten het voor u uit.
Openbron is natuurlijk een ruim begrip. Om de term duidelijk af te lijnen, heeft de organisatie Open Source Initiative (OSI) een "open source definition" gepubliceerd. Openbron betekent immers niet enkel dat men toegang heeft tot de broncode, maar ook dat de licentie aan een tiental voorwaarden voldoet. De meest ingeburgerde openbronlicenties zijn GPL, LGPL, BSD en MPL. Daarvan wordt de GPL of General Public License veruit het vaakst gebruikt.
Een bekende eigenschap van GPL is het copyleftprincipe: wanneer je GPL-software wijzigt en die aangepaste versie verspreidt, ben je verplicht om de broncode daarvan onder dezelfde voorwaarden vrij te geven. Dat wordt ook wel eens omschreven als het "virale" aspect van de GPL. Er mogen bovendien geen extra beperkingen opgelegd worden naast de voorwaarden in de GPL. Dat zorgt ervoor dat niet alle andere licenties compatibel zijn, bijvoorbeeld de CDDL (Common Development and Distribution License) waaronder Sun zijn besturingssysteem OpenSolaris verspreidt.
Verder zijn er een aantal varianten van GPL, zoals de LGPL (Lesser General Public License) die speciaal gericht is op softwarebibliotheken, of de AGPL (Affero General Public License) voor application service providers. GPL kreeg twee jaar geleden een update tot versie 3 met aanpassingen in verband met softwarepatenten en DRM: zo geeft GPLv3 de gebruiker van de software het recht om technologische beschermingsmaatregelen zoals DRM te verwijderen of te omzeilen.
Wie software of afgeleide werken echter onder de Berkeley Software Distribution (BSD)-licentie verspreidt, hoeft de broncode niet vrij te geven. Dat is dan ook de reden waarom Apple zijn besturingssysteem Mac OS X op FreeBSD gebaseerd heeft. Een licentie die het midden houdt tussen GPL en BSD is de MPL (Mozilla Public License), die onder andere gebruikt wordt door Firefox. Net zoals bij GPL moet afgeleide code van de software onder dezelfde licentie vrijgegeven worden. Maar parallel aan BSD zijn ontwikkelaars van propriëtaire software niet verplicht om al hun code vrij te geven als ze die bouwen op basis van MPL-software.
Naast die veel gebruikte openbronlicenties zijn er nog een zestigtal andere licenties die het Open Source Initiative aanvaardt, elk met hun eigen specifieke bepalingen. Belangrijk om weten is dat het louter gebruiken van openbron software niemand kan verplichten om code vrij te geven. De verplichtingen gelden enkel als u de software verspreidt. Dat betekent ook dat als u intern in uw organisatie openbron software gebruikt en er aanpassingen aan doet, u de broncode van uw aanpassingen niet hoeft vrij te geven. Dat geldt zelfs als het bedrijf een externe partij inhuurt om exclusief aan de software te werken.
Beperkte aansprakelijkheid
Alle openbronlicenties bepalen dat de software "as is" verspreid wordt, dus elke waarborg uitsluit en de auteur van alle aansprakelijkheid vrijstelt voor directe of indirecte schade die uit het gebruik van de software voortkomt. Zich volledig ontdoen van aansprakelijkheid is onder het Belgisch recht echter niet mogelijk als dat de verbintenis volledig uitholt, aldus Ywein Van den Brande, advocaat en informaticus gespecialiseerd in ICT-recht: "Het is niet mogelijk om je software als gebruiksklaar product voor te stellen met een aantal eigenschappen, en je tegelijkertijd van alle aansprakelijkheid te onttrekken als de software niet aan die eigenschappen zou voldoen. Een hobbyist die op zijn zolderkamer wat software in elkaar steekt zonder enige pretentie op professioneel gebruik, kan er daarentegen nog mee wegkomen." In de praktijk vragen professionele distributeurs van openbron software een vergoeding voor extra waarborgen, meestal samen met een supportcontract.
Een bedrijf dat openbron software verspreidt als onderdeel van een professionele service, kan dus beter niet op de "as is"-clausule vertrouwen. "Software kan nu eenmaal schade veroorzaken, en een rechter heeft bij zo’n extreme clausule slechts twee keuzes: hij kan je tot een volledige schadevergoeding veroordelen of niet", aldus Van den Brande. Een goede methode om zich tegen dergelijke rechtszaken te wapenen, is volgens hem een getrapt systeem: "Je neemt in de voorwaarden bijvoorbeeld op dat je niet aansprakelijk bent voor onrechtstreekse schade, en voor rechtstreekse schade tot herstel in natura of als dat niet mogelijk is tot een bepaald maximumbedrag. Met zo’n getrapt systeem geef je de rechter een hele waaier aan mogelijkheden voor zijn uitspraak. Zo plaats je jezelf ook in een sterkere onderhandelingspositie, omdat de tegenpartij niet zo gemakkelijk zal gokken op een extreme uitspraak."
Openbron policy
Sommige bedrijven staan nog weigerachtig tegenover het aanvaarden van openbron componenten in software die ze aankopen bij een dienstverlener. Volgens Van den Brande moet men bij de keuze voor openbron software echter altijd het bijbehorende gebrek aan garanties en intellectuele eigendom afwegen tegen de lagere licentiekosten en flexibelere toegang tot de broncode: "Dat is een keuze die natuurlijk van het bedrijfsmodel afhangt. Is de software bijvoorbeeld een doel of een middel? Wat wil je ermee doen en welke rechten en garanties heb je daarvoor nodig? Als de software echt een troef is van de deal die u met een dienstverlener aangaat, dan kunnen openbron componenten inderdaad een dealbreaker vormen. Maar vaak is de software gewoon een middel om tot een bepaald doel te komen, en veel bedrijven begrijpen dat ze de software niet volledig moeten bezitten om dat bedrijfsdoel te behalen. Soms is het gewoon handig om bestaande code over te nemen. Waarom het wiel opnieuw willen uitvinden?"
Onderzoeker Benjamin Docquir van de ULB vertelde daarom eerder dit jaar tijdens de Profoss-conferentie over juridische aspecten van openbron software dat elk bedrijf een openbron policy zou moeten hebben. Wat moet daar concreet instaan? Allereerst een lijst met zwarte, grijze en witte licenties voor de ontwikkelaars en subcontractors. Zij moeten ook instructies krijgen voor het bewaren van relevante documentatie en over hoe ze aan het juridische departement toestemming vragen voor het gebruik van software onder een bepaalde licentie. Er moeten ook regels opgesteld worden om bij te houden welke code gebruikt en gewijzigd is, en het bedrijf moet in de policy duidelijk maken wat het doet met bijdragen van de gebruikersgemeenschap. Om een overzicht te krijgen van welke openbronlicenties er allemaal in complexe software aanwezig zijn, bestaan er overigens tools zoals FOSSology.
De grillen van ontwikkelaars
Een niet te onderschatten aspect van openbron software is dat de continuïteit niet altijd gewaarborgd is. Gebruikt u software die slechts door een kleine groep of zelfs door één persoon gecontroleerd wordt, dan maakt dat u kwetsbaar voor de grillen van de ontwikkelaar(s). Dat werd enkele maanden geleden duidelijk toen Bruno Lowagie, de maker van openbron software iText, aankondigde dat hij aan de licentie een clausule zou toevoegen die het gebruik van zijn software door de Belgische overheid zou verbieden. Zijn motivatie? Een meningsverschil met de RSVZ die hem omwille van zijn advertentie-inkomsten via AdSense (waarop hij wel belastingen betaald had) zonder zijn medeweten en post factum als zelfstandige beschouwde.
Lowagie is ondertussen afgestapt van zijn idee van een "Belgian restriction". Die extra clausule zou perfect legaal zijn, maar gaat in tegen de open source definition die bepaalt dat openbron software geen specifiek toepassingsgebied mag discrimineren. Bovendien kan een auteur zich op basis van zijn morele rechten ook zonder specifieke clausule in de licentie verzetten tegen het gebruik van zijn software door een bepaalde partij. Voorwaarde is wel dat hij kan aantonen dat zijn reputatie door dat gebruik wordt aangetast. Van den Brande legt uit: "Als een kerncentrale je software gebruikt terwijl je zelf antinucleair bent, dan maak je een behoorlijke kans om een verbod te kunnen afdwingen. Morele rechten worden wel getemperd om te voorkomen dat er misbruik van gemaakt wordt. De Belgische overheid op basis van uw morele rechten verbieden om uw software te gebruiken als gevolg van een persoonlijke vete met een overheidsinstelling en niet omwille van het gebruik van de software, ligt niet voor de hand."
Lowagie heeft echter wel besloten om een extra voorwaarde aan de licentie Affero GPL van iText 2.2.0 toe te voegen, zegt hij: "Ik wil daarmee vermijden dat iText gebruikt wordt in GPL-toepassingen, en vervolgens door een dual-licensing systeem ‘verkocht’ wordt aan derden zonder dat iText daar een cent van ziet. Zo zijn er een aantal grote bedrijven die projecten voor de Belgische overheid uitvoeren en iText gebruiken zonder dat ze daarvoor een commerciële licentie aankopen. Die bedrijven verdienen best wel een aardige cent op de kap van iText." Aangezien iText ook onder de MPL verspreid wordt, blijft commercieel gebruik onder de voorwaarden van de MPL wel nog mogelijk. En wie het niet eens is met de richting die Lowagie uitgaat in de AGPL-versie, kan uiteraard de code forken, wat ook een oplossing kan zijn als hij er ooit de brui aan geeft. Volgens de iText-ontwikkelaar is forken in de praktijk echter niet haalbaar: "Als ik ermee stop, verdwijnt iText. Ik zie niet direct iemand anders zo’n arbeidsintensief project overnemen zonder dat daar een vergoeding tegenover staat."
Zelfs bij een groot openbronproject dat schijnbaar meer dan een éénmansinitiatief is, loont het de moeite om te kijken of het zijn zaken wel op orde heeft. Als het project geen juridische structuur zoals een stichting of bedrijf achter zich heeft, dan kan één persoon het hele project immers nog altijd gijzelen. In de zomer werd dat duidelijk bij CentOS, de openbron kloon van Red Hat Enterprise Linux. Oprichter Lance Davis had al sinds april 2008 niets meer van zich laten horen. Op zich zou dat niet zo’n probleem zijn, ware het niet dat de domeinnaam, het IRC-kanaal en de financiën van CentOS volledig in zijn handen lagen. Pas na een publieke noodkreet van de andere CentOS-ontwikkelaars kwam Davis weer tevoorschijn en werd er een regeling getroffen. De hele saga heeft het imago van CentOS als ‘enterprise Linux’ geen goed gedaan.
