Waarom gebruikt eigenlijk niemand de EUPL voor open source SaaS producten?

Bron: Wikipedia

Een lezer vroeg me:

Tegenwoordig is er veel te doen rondom open source versus SaaS-businessmodellen. Diverse bekende projecten zijn overgestapt op de AGPL, die in tegenstelling tot de GPL ook geldt voor gebruik als hosted SaaS dienst. Nu ontdekte ik onlangs dat de EU al jaren een mooie licentie heeft die precies dit doet: de EU Public License. Waarom gebruikt niemand die?
De European Union Public License of EUPL bestaat al sinds 2008, met een aanpassing in 2017. De tekst is in alle Europese talen beschikbaar, en kan door iedereen worden gebruikt.

Een probleem met ‘kleine’ licenties zoals deze is dat als je ze wilt combineren met anders gelicentieerde code, je soms tot elkaar tegensprekende voorwaarden komt. Dat noemen we incompatibiliteit. De EUPL lost dat op door te bepalen dat dan de voorwaarden van de andere licentie voorgaan (mits die genoemd is in de bijlage, zoals de GPL).

Dit wordt wel gelezen als “je mag de EUPL software onder GPL herlicentiëren” maar dat is dus niet waar: je mag GPL-incompatibele bepalingen negeren als je EUPL-software met GPL-software combineert.

Dit raakt met name de SaaS-clausule uit de EUPL. Je mag een EUPL-werk namelijk alleen “aan het publiek mededelen” als je de broncode erbij levert. En onder die term valt ook het als SaaS-dienst aanbieden van het werk. Alleen is die eis incompatibel met de GPL; die koppelt de eis van broncode meeleveren uitsluitend aan het distribueren van de software, dus als download of op een geheugendrager.

Je zou dan zeggen, mooi, ik breid EUPL software uit met GPL software, zie dat de SaaS-eis GPL-incompatibel is dus ik mag die negeren. Maar dat is niet zo. De GPL verbiedt niet het aanbieden van broncode bij een hosted SaaS-gebruik, dus als de EUPL dat eist voor haar broncode dan is dat niet incompatibel. Uit de EUPL FAQ:

The EUPL states that in case the compatibility clause is used legitimately, “Should the Licensee’s obligations under the Compatible Licence conflict with their obligations under this (EUPL) Licence, the obligations of the Compatible Licence shall prevail.” Yes, but other obligations, in particular resulting from the definition of Distribution (Article 1 of the EUPL related to the coverage of Communication to the public or SaaS, like the AGPL) and the obligation to provide access to the source code will persist in addition to those of the Compatible Licence, because none of the compatible licenses are in conflict with the EUPL on these specific points: for example, the GPL does not mandate to provide access to the source code in case the software is performed remotely, but it does not prohibit it.
Ik geef toe: als je zoiets moet uitleggen, is het minder uitnodigend (zeker voor niet-juristen) om mee te werken.

De voornaamste reden waarom de licentie zo weinig populair is, is natuurlijk precies omdat deze zo weinig populair is. De GPL kent iedereen, en de scope daarvan is duidelijk genoeg. Wil je je SaaS-dienst beschermen, dan neem je de AGPL. En anders kijk je wat iedereen om je heen doet, en doe jij dat ook.

Arnoud

2 reacties

  1. Ik vraag me af of zo’n clausule het gewenste effect bereikt. De exacte formulering is:

    Verenigbaarheidsclausule: wanneer de licentiehouder bewerkingen of kopieën ervan verspreidt of mededeelt die zijn gebaseerd op het werk en op een ander werk dat uit hoofde van een verenigbare licentie in licentie is gegeven, kan die verspreiding of mededeling geschieden onder de voorwaarden van deze verenigbare licentie. Voor de toepassing van deze clausule wordt onder „verenigbare licentie” verstaan, de licenties die in het aanhangsel bij deze licentie zijn opgesomd. Indien de verplichtingen van de licentiehouder uit hoofde van de verenigbare licentie in strijd zijn met diens verplichtingen uit hoofde van deze licentie, hebben de verplichtingen van de verenigbare licentie voorrang.
    Je kijkt in je blogartikel naar de tweede zin van deze bepaling, maar het venijn zit volgens mij in de eerste zin.

    Stel nou dat Elasticsearch de EUPL had gehad, en een bedrijf wil ES aanpassen en gebruiken. Een klein bedrijf zou de aanpassingen zelf maken, en is vervolgens gebonden aan de SaaS-bepaling van de EUPL. Een bedrijf als Amazon kan een aanpassing door een derde bedrijf laten ontwikkelen waarbij een stukje GPL-code wordt opgenomen. Het resultaat (ES+aanpassing) kan onder de GPL-licentie aan Amazon worden geleverd op grond van de eerste zin van de verenigbaarheidsclausule. De broncode hoeft dan alleen aan Amazon te worden geleverd. Amazon is daarna niet meer gebonden aan de SaaS-bepaling.

    De originele ES-ontwikkelaar zou in deze situatie weinig aan de EUPL hebben gehad.

  2. Is het niet gewoon een kwestie van dat deze licentie niets nieuws toevoegt en alleen maar zorgt voor nog meer interactie problemen.

    Voor mijn eigen code zou ik het niet eens overwegen. De enige overweging die ik doe is:

    Wil ik dat de code ook gedeeld moet worden bij SaaS: AGPL Wil ik dat de code gedeeld moet worden met de binaries: GPL — Is het een library en wil ik dat tot de library beperken: LGPL Maakt het me niet uit wat mensen met de code doen: MIT/X11 of BSD-3 license

    Allemaal veel gebruikte licenties waarvan de werking en limitaties bekend zijn, met een grote kans dat ze al eens door de rechter getoetst zijn. Waarom zou ik nog verder kijken?

Geef een reactie

Handige HTML: <a href=""> voor hyperlinks, <blockquote> om te citeren, <UL>/<OL> voor lijsten, en <em> en <strong> voor italics en vet.