Licenties zijn altijd een complex onderwerp, en dat is bij opensourcelicenties niet anders. Daarom spraken we met Hans Graux, één van de medeoprichters van het Brusselse advocatenkantoor time. lex en medewerker aan het Interdisciplinaire Centrum voor Recht en Informatica (ICRI) aan de Katholieke Universiteit Leuven. Graux komt in zijn praktijk twee grote groepen cliënten tegen die met vragen over opensourcelicenties zitten.
...

Licenties zijn altijd een complex onderwerp, en dat is bij opensourcelicenties niet anders. Daarom spraken we met Hans Graux, één van de medeoprichters van het Brusselse advocatenkantoor time. lex en medewerker aan het Interdisciplinaire Centrum voor Recht en Informatica (ICRI) aan de Katholieke Universiteit Leuven. Graux komt in zijn praktijk twee grote groepen cliënten tegen die met vragen over opensourcelicenties zitten. Enerzijds zijn er in België veel it-bedrijven die in opdracht maatwerkoplossingen ontwikkelen op basis van opensourcesoftware, zoals websites gebaseerd op Drupal. Het probleem is dat veel opdrachtgevers nog geen rekening houden met speciale aspecten van opensourcesoftware, merkt Graux aan de vragen die hij van cliënten krijgt: "De ontwikkelaars krijgen dan bijvoorbeeld standaardcontracten voorgeschoteld, die vereisen dat ze de volledige eigendomsrechten op hun code overdragen aan de opdrachtgever. Maar als een ontwikkelaar in opdracht een Drupal-module onder de GPL (General Public License) aanpast, moet hij zijn aanpassingen ook onder de GPL vrijgeven, en kan de opdrachtgever dus niet het eigendom opeisen." Zo'n contract moet dan aangepast worden, maar er komt ook wat 'opvoeding' van de opdrachtgever bij kijken, zegt Graux: "Veel bedrijven begrijpen niet dat ze niet alle eigendomsrechten krijgen voor software, terwijl ze wel voor de ontwikkeling ervan betalen." Anderzijds heeft Graux ook vaak te maken met cliënten die zelf een steekje laten vallen. Het gaat dan om bedrijven die software of hardware ontwikkelen en hiervoor bepaalde opensourcesoftware geïntegreerd hebben, maar pas na een aantal jaren merken dat ze eigenlijk niet voldoen aan de licentievoorwaarden. "Zo'n bedrijf stapt dan naar me toe en vraagt wat het moet doen, want mogen ze hun product nog wel verkopen?" Het antwoord op die vraag hangt af van de licentie van de geïntegreerde software. Heeft een werknemer GPL-software geïntegreerd, dan heeft het bedrijf in principe een probleem, want de GPL heeft een virale clausule: als je GPL-software in je eigen software integreert, moet die volledige software onder de GPL vrijgegeven worden. Om dat te vermijden, zijn er twee oplossingen, aldus Graux: "Als de geïntegreerde functionaliteit niet zo belangrijk is, verwijdert het bedrijf het best die software, en anders moet de functionaliteit from scratch herontwikkeld worden. Maar in sommige omstandigheden is de GPL ook geen probleem: bijvoorbeeld als je businessmodel niet afhangt van onbeperkte eigendomsrechten op de software, of als je de software bijvoorbeeld geïntegreerd hebt in back-end software die je niet aan klanten verspreidt maar enkel op je eigen servers draait." De verplichtingen van de GPL zijn immers enkel van toepassing bij het verspreiden van de software. De meeste opensourcelicenties hebben overigens geen virale clausule zoals de GPL, dus dan is het eenvoudiger voor een bedrijf om aan de licentie te voldoen. Heeft het bedrijf bijvoorbeeld software onder de BSD-licentie geïntegreerd, dan moet het enkel de naam van de auteur en de licentie van die software vermelden. Naast de GPL en de BSD-licentie zijn er echter nog honderden andere opensourcelicenties, en die zijn niet allemaal compatibel. "Zo kan het voorkomen dat je een perfect werkend systeem hebt, dat je echter niet mag verspreiden omdat de licenties van verschillende geïntegreerde componenten elkaar uitsluiten," merkt Graux op. Het is daarom belangrijk dat een bedrijf dat opensourcesoftware integreert, altijd goed in kaart brengt welke code in-house ontwikkeld is en welke van buitenshuis komt, en onder welke licenties dat allemaal valt. Gelukkig bestaan er tools die je hiermee helpen, zoals WhiteSource en FOSSology, die Graux zeker aanraadt: "Dat zijn databanken met licentieinformatie over opensourceprojecten, waarmee je kunt scannen welke opensourcesoftware er in je software aanwezig is, onder welke licenties, en welke compatibiliteitsproblemen er zijn. Met zo'n tool kun je heel wat verrassingen vermijden".Koen Vervloesem"VEEL BEDRIJVEN BEGRIJPEN NIET DAT ZE NIET ALLE EIGENDOMS-RECHTEN KRIJGEN VOOR SOFTWARE, TERWIJL ZE WEL VOOR DE ONTWIKKELING ERVAN BETALEN."