Software as a Service: waar Open Source Software ophoudt open te zijn?

(Deze opinie heb ik samen met Maurits Westerik geschreven en is gepubliceerd in het Tijdschrift voor Internetrecht 2008/6) 

 1. Inleiding

Over Open Source Software (OSS) bestaan nog steeds veel misverstanden. Een van die misverstanden betreft de veronderstelde verplichting dat ontwikkelaars de broncode van door hen aangepaste OSS software moeten delen met de andere gebruikers (‘share-alike’). Het is dit misverstand dat er toe heeft geleid dat veel bedrijven vrezen dat zij, door te investeren in OSS, de facto hun R&D geld op straat gooien.

Die zorg is niet altijd terecht. Veel OSS licenties kennen deze zogeheten share-alike verplichting namelijk niet. Daarbij kan door middel van Software as a Service (SaaS) dienstverlening de meeste OSS zonder al te veel moeite worden gebruikt als ware het ‘closed source’ software.

In deze bijdrage bespreken de auteurs kort de share-alike bepaling zoals die in verschillende OSS licenties wordt gebruikt om daarna te laten zien hoe de veelgebruikte SaaS-route bewandeld kan worden om de strengere share-alike clausules te omzeilen.

2. OSS en de share-alike bepaling

Het openstellen van de broncode ligt in zekere zin ten grondslag aan de gedachte van “open source” software. De veel gebruikte Open Source definitie van het Open Source Initiative (OSI) noemt het als een van de tien vereisten waaraan een licentie moet voldoen voordat het officieel Open Source mag heten.[1] Gebruikers zijn verplicht bij het verspreiden van de software ook de broncode mee te leveren of in ieder geval aan te bieden. Het uitgangspunt van OSS-licenties is dus dat de broncode van de gelicentieerde software openlijk en vrijelijk beschikbaar moet zijn voor iedereen die er gebruik van wil maken.

Sommige OSS-licenties kennen daarnaast zeer nadrukkelijk een share-alike bepaling: de verplichting om ook eventuele aangepaste versies van de broncode weer vrijelijk ter beschikking te stellen aan derden. Een goed voorbeeld van een dergelijke OSS-licentie is de bekende (en veelgebruikte) General Public License (GPL)[2], onder welke licentie onder meer de Linux-kernel wordt verspreid.

Volgens de opstellers van dergelijke share-alike-licenties (ook wel copyleft OSS-licenties genoemd) is “vrije software”[3] niet zonder verplichtingen: in ruil voor jouw eigen vrije gebruik van de software moet je zelf ook je steentje bijdragen aan de beschikbaarheid van de broncode, namelijk door jouw eigen aanpassingen aan de OSS weer ‘open te stellen’ voor anderen.

Het is dit ‘virale effect’ dat maakt dat sommige partijen huiverig zijn om te investeren in OSS. Het past niet in het businessmodel van veel software-ontwikkelaars om hun investeringen op deze wijze zomaar weg te geven. Tegelijkertijd hebben ook veel IT-afnemers aarzelingen. Zij schrikken terug voor de risico’s van het vrijgeven van de investeringen die door de interne (of externe) IT-afdeling zijn gedaan in het verder ontwikkelen of aanpassen van de broncode. De angst bestaat, al dan niet terecht, dat de concurrentie zomaar een ‘free ride’ krijgt aangeboden. Toch is er een methode om deze share-alike bepalingen buiten werking te stellen.

3. SaaS

Software as a Service (SaaS) is een software-implementatiemodel waarbij een dienstverlener als host een applicatie over het Internet aanbiedt aan gebruikers. Dit betekent dus dat de software niet op de computer van de gebruiker staat, maar alleen op de servers van de dienstverlener is geïnstalleerd. Voorbeelden zijn de meeste webmail-diensten (Gmail, Hotmail), veel Wiki’s, maar natuurlijk ook zakelijke softwaredienstverleners zoals Salesforce.com.

Anders dan soms wel wordt aangenomen[4] is het SaaS-implementatiemodel geen nieuw concept. Het bestond al voor de dot.com crash van 2001 in de vorm van het Application Service Provider (ASP) model, maar het idee zelf is zelfs al tientallen jaren oud. Echter, pas de laatste jaren zijn alle benodigde ingrediënten (zoals bandbreedte, aangepaste server-architectuur, betrouwbare verbindingen en een acceptatiegraad) in voldoende mate aanwezig om ook software op grotere schaal succesvol als een dienst te kunnen aanbieden.

De schattingen over de aanwezigheid en groei van SaaS lopen flink uiteen, maar duidelijk is dat SaaS een commercieel interessant alternatief biedt voor de traditionele vormen van IT-dienstverlening.

Dat is ook niet vreemd. Zowel voor de softwareleverancier als de gebruiker kent SaaS een aantal voordelen. SaaS biedt de leverancier volledige controle over de software-versies die door de gebruikers worden gebruikt en welke veranderingen (zoals patches, instellingen en gebruiksrechten) worden doorgevoerd. Naast de efficiency die hiermee kan worden bereikt, betekent dit ook dat dienstverlening aan de klant simpel ‘tailor made’ kan worden gemaakt én uitsluitend door deze aanbieder kan plaatsvinden. Daarmee wordt een continue stroom aan inkomsten gegenereerd. Verder biedt SaaS bescherming tegen decompilatie en dus een betere bescherming van het intellectuele eigendom van de rechthebbende op de software: de software staat uitsluitend bij deze leverancier op de server en kan dus niet gemakkelijk door onbevoegden worden gedecompileerd en gebruikt.

Ook voor de gebruiker brengt SaaS belangrijke voordelen mee. Doordat de software niet meer op de computer van de gebruiker staat en behoeft te worden onderhouden, kan SaaS voor de gebruiker de kosten verlagen die hij anders moet maken voor onderhoud, hardware en support. Daarnaast worden de kosten een doorlopende post in plaats van een min of meer eenmalige (upfront) investering of een jaarlijkse licentievergoeding.

4. SaaS en OSS – Algemeen

Vanuit de traditioneel ‘OSS-huiverige’ hoek van bedrijven die hun eigen verbeteringen aan OS-software liever niet willen delen met de gemeenschap, wordt nu met aandacht naar SaaS gekeken. SaaS lijkt een succesvol businessmodel te zijn en OSS heeft zich inmiddels met succesvolle producten zoals Linux, Apache en Java bewezen als een commercieel waardevol product. Zou het dan niet mogelijk zijn om het SaaS-model op zo’n manier in te zetten dat men wel de ‘lusten’ van OSS heeft maar dat de ‘lasten’ van de share-alike bepalingen buiten de deur kunnen worden gehouden?

Wij zullen hier verdedigen dat dit inderdaad mogelijk blijkt te zijn. Afhankelijk van de toepasselijke OSS-licentie kan een onderneming aan wie software onder een OSS-licentie is verstrekt, deze software (laten) wijzigen en de gewijzigde versie vervolgens als een SaaS-dienst aanbieden, zonder verplicht te zijn de broncode van de gewijzigde versie aan derden ter beschikking te stellen, zelfs indien er share-alike bepalingen in de OSS-licentie zijn opgenomen.

Voorop moet worden gesteld dat het merendeel van de OSS-licenties ruime mogelijkheden biedt om vrijelijk gebruik te kunnen maken van OSS. Voor sommige licenties geldt overigens dat deze geschreven zijn voordat het volle potentieel van SaaS (of het ASP-model) zichtbaar was. Een belangrijk voorbeeld daarvan is de GPL v2 die in juni 1991 werd gepubliceerd.

Andere licenties zijn principieel ‘gemakkelijk’ op dit gebied. Voorbeelden van deze zogeheten ‘permissive’ OSS-licenties (ook wel ‘non-copyleft’ licenties genoemd) zijn de Massachusetts Institute of Technology (MIT) en de Berkeley Software Distribution (BSD) licenties. Deze licenties bieden de gebruikers/ontwikkelaars bewust de mogelijkheid om met de onder deze licenties verkregen software (min of meer) te doen en laten wat deze gebruikers maar willen.

Zo kunnen gebruikers er voor kiezen om software te ontwikkelen op basis van bijvoorbeeld bestaande BSD-software en het nieuw ontstane werk weer ter beschikking te stellen op grond van een licentie naar eigen keuze. Het ‘virale effect’ dat de copyleft OSS-licenties kenmerkt, doet zich bij deze licenties niet voor.

5. SaaS en de GPLv3 en de AGPLv3

‘SaaS als sluipweg’ is dus met name interessant voor de gebruiker die graag exclusief wenst voort te bouwen op software die is gelicentieerd onder een copyleft OSS-licentie.

Bij twee recente copyleft OSS-licenties is bij het opstellen actief nagedacht over SaaS-gebruik, te weten de GPL versie 3 (GPL v3 – juni 2007) en de Affero GPL v3 (AGPL v3 – november 2007).

Zowel de GPL v3 als de AGPL v3 is onder de hoede van de Free Software Federation (FSF) opgesteld. Ondanks sterke overeenkomsten tussen de beide licenties zijn bij het opstellen tegenovergestelde keuzes over SaaS gemaakt.

Het is mogelijk om software onder de GPL v3 te gebruiken voor het aanbieden van SaaS-diensten zonder dat de verplichting bestaat om de aangepaste broncode vrij te geven. De verplichting om broncode van een gewijzigd werk aan de gebruikers van dat werk te leveren, treedt volgens deze licentie pas in werking als die gewijzigde versie ook wordt “Overgebracht” (“conveyed”), aldus artikel 6 GPL v3.[5]

Het “Overbrengen” van een werk in de zin van GPL v3 betekent elke vorm van “Verspreiden” (kort gezegd elke auteursrechtelijk relevante handeling) dat andere partijen in staat stelt om kopieën te maken of te ontvangen. Echter, in artikel 0 GPL v3 wordt bij deze definitie van Overbrengen een uitzondering gemaakt: de enkele interactie met een gebruiker door middel van een computernetwerk zonder verplaatsing van een kopie, geldt niet als Overbrengen. [6]

Met andere woorden, onder de GPL v3 is het toegestaan om de software te compileren en zelfs openbaar te maken in de zin van de (Nederlandse) Auteurswet, zonder share-alike verplichting.

Dit lijkt lijnrecht in te gaan tegen de idealistische ideeën die door de FSF worden uitgedragen. De verplichting om de broncode van een gewijzigde versie van software onder de GPL v3 ter beschikking te stellen is zelfs een van de meest in het oog springende voorwaarden van de GPL-licenties.

Onder de GPL v3 is er dus toch bewust voor gekozen de SaaS-route expliciet toe te staan. De achtergrond van deze merkwaardige situatie is een sterk staaltje van OSS-compromis-politiek. Deze ‘SaaS-uitzondering’ stond namelijk niet in een eerder concept van de GPL v3. Sterker nog, men wilde juist de SaaS-route afsluiten. Bij het opstellen van de GPL v3 waren echter ook veel partijen betrokken die uit bedrijfsmatig oogpunt behoefte hadden aan de bestaande SaaS-sluiproute.

Bedacht moet worden dat vele grote software-producenten en talloze web start-ups OSS gebruiken en dat veel webapplicaties zijn gebaseerd op OSS. Kennelijk hadden deze SaaS-gerichte partijen de meerderheid bij de besluitvorming rond dit deel van de GPL v3. Had de FSF de originele anti-SaaS-clausule ondanks de weerstand doorgedrukt, dan was GPL-software wellicht een stuk minder aantrekkelijk geworden voor ontwikkelaars met meer commerciële (bij)bedoelingen.[7]

Het resultaat is dus dat SaaS-diensten expliciet uitgezonderd worden van de share-alike bepaling. Dit gegeven biedt ruime mogelijkheden. Relatief goedkoop en snel kan zo op exclusieve basis worden voortgebouwd op bestaande software.

Deze SaaS-route kan daarbij binnen een concern behulpzaam zijn bij het wegnemen van onzekerheid. In veel concerns is de IT-afdeling in een aparte vennootschap ondergebracht of is in zijn geheel uitbesteed aan externe IT-dienstverleners. Als deze IT-afdeling een aangepast programma onder de GPL v3 binnen de hele groep van ondernemingen wenst te verspreiden, is het momenteel niet helemaal duidelijk of dit nu betekent dat het programma wordt ‘Overgebracht’ en dus aan alle moeder- en zusterbedrijven (en mogelijk ook aan derden) een kopie van de broncode moet worden gegeven. Deze brede verspreiding van de broncode is meestal om uiteenlopende redenen niet wenselijk (denk onder meer aan versie-management, security en vertrouwelijkheid). Met SaaS bestaat dus geen verplichting om de broncode van een dergelijk aangepast programma vrij te geven.

Zoals gezegd heeft de FSF ook de AGPL v3 opgesteld, die ook wel de Affero GPL v3 wordt genoemd en voortborduurt op de oorspronkelijke Affero licentie. De AGPL v3 sluit – net als zijn voorganger – de “SaaS als sluipweg” uitdrukkelijk af. De opstellers van de oorsponkelijke Affero licentie waren namelijk van mening dat men SaaS niet anders moest behandelen dan een ‘gewone’ openbaarmaking en dus ook bij een SaaS openbaarmaking de aangepaste broncode vrijelijk aan derden ter beschikking dient te worden gesteld.[8]

Met andere woorden: de verplichting om de broncode te delen treedt onder de AGPL v3 in werking door het enkele verschaffen van toegang (“accessing the service”). Zo wordt “Saas als sluipweg” dus effectief afgesneden.

6. Conclusie

Veel OSS-licenties kunnen of willen niets doen aan het exclusieve gebruik dat SaaS-aanbieders maken van OSS. Dit gegeven biedt natuurlijk mogelijkheden voor de zakelijke gebruiker. Een bedrijf dat de vruchten van eigen softwareontwikkeling intern wenst te houden kan dat dus ook met OSS doen. Men moet dan wel de basissoftware secuur selecteren op SaaS-vriendelijke OSS-licenties en de aangepaste software vervolgens enkel als SaaS aanbieden.

Het is de vraag of deze SaaS-route op de lange termijn niet een probleem zal gaan vormen voor de OSS-gemeenschap. Als SaaS immers als fenomeen blijft groeien en bedrijven vrijelijk putten uit de beschikbare OSS zonder iets terug geven aan de OSS-gemeenschap, dan zou de bereidheid om te doneren aan deze gemeenschap wel eens langzaamaan af kunnen nemen. Het is niet ondenkbaar dat een nieuwe generatie OSS-licenties om deze reden wel eens heel wat minder SaaS-vriendelijk zou kunnen zijn.


 [1] Zie http://opensource-definition.org/docs/definition.html

[2] Deze licentie is in de originele Engelse versie te vinden op www.fsf.org/licensing/licenses/gpl-3.0.html en in het Nederlands op http://www.gnu.org/licenses/translations.html.

[3] In de OSS gemeenschap wordt met “free software” nadrukkelijk “vrije” en niet noodzakelijkerwijs “gratis” software bedoeld.

[4] Zie bijvoorbeeld het artikel “Progress ziet vooruitgang in SaaS” van Rolf Zaal van 28 oktober 2008 in de Automatiseringsgids (http://www.automatiseringgids.nl/).

[5] “You may convey a covered work in object code form under the terms of sections 4 [identieke kopieen] and 5 [gewijzigde versies], provided that you also convey the machine-readable Corresponding Source under the terms of this License, (…)”

[6] “Mere interaction with a user through a computer network, with no transfer of a copy, is not conveying.”

[7]   Nadat deze interne strijd gestreden was, gaf de FSF zelf het volgende als verklaring:

“We have made this decision [om SaaS specifiek uit te zonderen -auteurs] in the face of irreconcilable views from different parts of our community. (…) Free software vendors allied to these users joined in their objections, as did a number of free software developers arguing on ethical as well as practical grounds.” (Zie de toelichting op het derde GPL-concept, pagina 30, gplv3.fsf.org/gpl3-dd3-rationale.pdf)

[8] Dit standpunt is in de AGPLv3 op de volgende wijze terug te vinden:

“Notwithstanding any other provision of this License, if you modify the Program, your modified version must prominently offer all users interacting with it remotely through a computer network (if your version supports such interaction) an opportunity to receive the Corresponding Source of your version by providing access to the Corresponding Source from a network server at no charge, through some standard or customary means of facilitating copying of software.” (zie http://www.fsf.org/licensing/licenses/agpl-3.0.html)

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: