Hoe open source compliant gebruiken?

Het gebruik van open source biedt enorme mogelijkheden aan developers. Maar in de praktijk zien we dat software developers vaak de verschillende open source licenties niet kennen en er dus ook geen aandacht aan besteden. Het resultaat is dat soms IP wordt overdragen aan de opdrachtgever op code die eigenlijk ook terug moet gedeeld worden met de community. In deze blog gaan we in op de verschillende open source licenties die er zijn en geven we een aantal concrete tips mee.

Open source en closed source

Bij het ontwikkelen van software valt de broncode ofwel onder ‘closed source’ ofwel onder ‘open source’. Bij ‘closed source’ wordt de ontwikkelde software afgeschermd tegen ongeoorloofde toegang, kopieën of wijzigingen van de broncode bijvoorbeeld om de intellectuele rechten van de ontwikkelaar te beschermen.

Bij ‘open source’ beslissen softwareontwikkelaars om de gecreëerde broncode openbaar te maken waardoor andere softwareontwikkelaars de code kunnen hergebruiken en/of aanpassen voor het maken van een eigen programma of applicatie.

Op het eerste zicht lijkt open source vrijblijvend, maar niets is minder waar. Vele open source code is onderworpen aan verschillende voorwaarden en beperkingen, afhankelijk van het type open- source licentie dat van toepassing is.

Types open source licenties

De verschillende open source licenties kunnen onderverdeeld worden in 2 categorieën: copyleft licenties en permissive licenties.

Het doel van copyleft licenties is het behouden van de vrije beschikbaarheid van software. Bij deze licenties moeten afgeleide werken ook onder dezelfde licentie worden gepubliceerd, waardoor ze vrij en open blijven.

Dit is een overzicht van de belangrijkste copyleft licenties:


GPL: General Public License
AGPL: Affero GPL
LGPL: Lesser General Public License
EPL: Eclipse Public License
MPL: Mozilla Public License
Strong copy leftUltra strong copy leftWeak copy leftWeak copy- leftWeak copy- left

Applicaties (niet-SaaS)

Applicaties en SaaS

Bibliotheken (packages)

Bibliotheken (packages) of gehele applicaties


Bestanden
Mag code gebruiken, wijzigen en verdelen.

Gevolgen:

Code die je gebuikt en wijzigt met GPL License moet je terug vrijgeven onder GPL.

Niet alleen de wijzigingen in de broncode maar ook alle andere eigen broncode die de GPL broncode importeert, moet worden vrijgegeven onder GPL.

Alle belangrijke wijzigingen vermelden die zijn aangebracht aan de oorspronkelijke GPL broncode.

Gevolgen:

Idem GPL.


Gevolgen:

De LGPL broncode mag je gebruiken of importeren in je eigen broncode zonder dat je je eigen broncode moet vrijgeven.

Indien je de LGPL broncode wijzigt, moet je deze broncode wel vrijgeven onder LGPL.


Gevolgen:

Je mag EPL broncode gebruiken in eigen broncode zonder dat je je eigen broncode moet vrijgeven onder EPL licentie.

Toevoegingen aan de originele EPL broncode moet je niet vrijgeven onder EPL Licentie, op voorwaarde dat het een aparte module is los van het originele werk.

Afgeleide werk (= creatie die grote delen bevat van een EPL broncode) moet je wel vrijgeven onder EPL Licentie.


Gevolgen:

Het is mogelijk om broncode te wijzigen en te gebruiken in closed source en/ of eigen software, zolang alle MPL broncode in aparte bestanden wordt gehouden en deze bestanden worden verspreid.



Bij permissive licenties is het toegestaan dat software geïntegreerd wordt in bijvoorbeeld closed source projecten zonder de verplichting om de broncode van die afgeleide werken vrij te geven.

Dit is een overzicht van de belangrijkste permissive licenties:

Apache License
MIT License
BSD License
Unlicensed
Code wijzigen, distribueren en gebruiken, zelfs in closed source projecten.

Gevolgen:

Gebruikte ongewijzigde Apache broncode moet onder Apache licentie worden vrijgegeven.

Gebruik van de software op eigen risico indien er schade ontstaat


Gevolgen:

De eigen broncode moet niet worden vrijgegeven onder MIT Licentie.

De MIT licentie moet worden opgenomen in alle kopieën of substantiële delen van de software.

Gebruik van de software op eigen risico indien er schade ontstaat.


Gevolgen:

De eigen broncode moet niet worden vrijgegeven onder BSD Licentie.

De BSD licentie moet worden opgenomen in alle kopieën of substantiële delen van de software.


Gevolgen:

Het gebruik van de broncode is niet onderworpen aan voorwaarden.



Praktische tips

Afhankelijk van welke open source licenties je gebruikt ben je verplicht om al dan niet de code opnieuw te delen met de community. Werk je samen met sofware developers, maak dan goeie afspraken over welke open source je developers mogen gebruiken of bepaal minstens welk proces ze moeten volgen wanneer ze beroep willen doen op open source. Je wil absoluut vermijden dat ze code gebruiken met een GPL of AGPL licentie als je producten bouwt in opdracht van klanten waarbij je de IP volledig overdraagt. Of nog: wanneer je zelf een product bouwt dat je op termijn eventueel in licentie wil geven.

Daarnaast is het erg belangrijk voor compliance doeleinden om een inventaris bij te houden van de gebruikte code per project. Op die manier bewaar je het overzicht en kan je enigszins controleren of er geen code werd gebruikt waar een AGPL of GPL licentie aan vasthangt.

Vragen over de juridische implicaties van het gebruik van open source of hoe je dit best in de praktijk aanpakt? 

Auteurs: Deborah Mualaba en Freekje De Vidts

Hoe open source compliant gebruiken?

{{ popup_title }}

{{ popup_close_text }}

x