Waarom gebruiken SaaS-bouwers niet vaker open source als framework?

Recent blogde ik over SaaS maatwerk en standaarwerk. Daarbij miste nog een invalshoek:

Persoonlijk tracht ik e.e.a. altijd zo te regelen dat zowel de klant als ik (ontwikkelaar) beiden eigenaar zijn van het auteursrecht. Gedeeld eigenaarschap onder bijvoorbeeld de GPL licentie. Het staat mijn klant dan vrij om te doen wat ze willen met de code, het staat mij vrij om met de code te doen wat ik wil en de code kan als Open Source code bijdragen aan het ecosysteem (net zoals ik gebruik heb gemaakt van andermans Open Source code). Het exclusiviteitsbeding vind ik trouwens ook een mooie oplossing voor klanten die wel willen bijdragen aan Open Source, maar bang zijn dat iemand anders er snel met hun ‘unieke idee’ vandoor gaat. Je ziet dit ook wel gebruikt worden bij werken onder een Creative Commons licentie. Ik vind dat wel een elegante oplossing die tijd biedt om de investering terug te verdienen en daarna bijdraagt aan het algemene ecosysteem.

Dit is inderdaad een mooie oplossing die ik er best bij had kunnen zetten. Zeker mkb-ontwikkelaars werken tegenwoordig heel vaak met open source als basis. Allereerst omdat dat erg populair is in de markt, en waarom zou je dan tijd en moeite steken in je eigen framework dat per definitie dan altijd achterloopt? En ten tweede omdat je dan een extra argument naar je klant hebt: bij mij geen lock-in, je kunt altijd weg en er zijn genoeg anderen die dit framework, deze standaardsoftware dus, voor je kunnen onderhouden en uitbreiden.

Bij open source zou maatwerk vaak kwalificeren als “afgeleid werk”, zodat licenties als de GPL dan bepalen dat dergelijk maatwerk ook open source moet worden. Althans, als het wordt gedistribueerd – en daar schort het nog wel eens aan bij SaaS. Een webapplicatie wordt immers niet verspreid, die blijft nu net staan waar hij staat, in het datacenter van de aanbieder. Het is dus mogelijk om gesloten maatwerk bovenop een GPL SaaS applicatie te maken, zolang die maar niet wordt verspreid. Alleen als de licentie de AGPL (Affero GPL) is, dan kan dat niet.

Deze invalshoek stelt voor om niet alleen af te spreken dat het maatwerk GPL wordt, maar ook om het meteen aan het ecosysteem bij te dragen. Daarmee is zowel de klant als de rest van de wereld een leuke feature rijker. Daar staat tegenover dat de concurrent dat dan ook kan gebruiken, maar daar spreek je dan dus exclusiviteit voor af. Maar zoals anderen in de comments al zeiden, het is natuurlijk maar de vraag of de klant betaalt voor exclusiviteit of meer voor als éérste die feature hebben, of anders gezegd een applicatie krijgen die doet wat hij wil in plaats van wat de ontwikkelaar wil.

Ik kreeg in de mail trouwens nog diverse ontwikkelaars die melden dat ze maatwerk gratis aanbieden onder voorwaarde dat de klant het eigendom niet mag hebben. Dat is dus het zuiverste: de hele applicatie blijft bij de ontwikkelaar, die bepaalt wat erin komt maar hij luistert naar zijn klanten en past zijn roadmap aan op basis van gemotiveerde wensen.

(Oh, en diverse juristen wezen me er nog op dat het beter is om auteursrechten op maatwerk te eisen dan exclusiviteit af te spreken. Dat laatste werkt namelijk alleen tegen de ontwikkelaar. Als die in strijd met de afspraak tóch de code uitlevert aan een concurrent, kun je die concurrent niet stoppen. Met de auteursrechten op het maatwerk in de hand kun je dat wel, zelfs als de ontwikkelaar weggevallen is. Dat klopt. Mijn enige opmerking daarbij is dat het lastig is om bij SaaS inbreuk op auteursrechten aan te tonen, omdat je geen toegang hebt tot de software, dus voor mij voelt dit wat theoretisch maar als je het bewijs weet te leveren -wellicht is bewijsbeslag mogelijk, 843a Rv- dan is dit wel slimmer.)

Arnoud

6 reacties

  1. Gedeeld eigendom onder de GPL lijkt me niet zo handig, omdat je dan niet in je eentje de licentievoorwaarden kunt wijzigen. Daar heb je dan telkens al die klanten voor nodig met wie je mede-eigendom hebt afgesproken. Als je later ooit je bedrijf wilt verkopen, dan zouden potentiële kopers wel eens afgeschrikt kunnen worden door een niet wijzigbare GPL licentie die ook hun eigen software gaat raken als ze jouw software en hun eigen software zouden willen integreren. Dus wordt je bedrijf minder gemakkelijk verkoopbaar. Verder kunnen potentiële klanten een probleem hebben met de GPL als ze de software willen kunnen distribueren naar hun klanten. Ook dan is een niet-wijzigbare GPL niet zo handig; je kunt dan niet voor die potentiële klanten een andere licentie afspreken. Dus loop je misschien omzet mis.

    1. De oorspronkelijke auteur kan zijn werk onder de GPL beschikbaar stellen, maar daarnaast ook onder een andere licentie naar zijn keuze aan andere klanten als hem dat zo uitkomt. En het aardige is dat bij verkoop van het bedrijf de daarin rustende auteursrechten op software overgaan op de koper, die vervolgens zelf kan overwegen de licentie GPL te laten of een andere te kiezen danwel te laten ontwerpen.

  2. Kun je niet gewoon je opensource zo schrijven dat je het echte maatwerk als losse plugins er in kunt stoppen? En dan de licentie zo maken dat plugins er niet onder vallen.

    En als een klant dan met iets komt waarvan je denkt ‘dat vinden andere klanten vast ook handig’ dan stop je de basis (als api-uitbreiding of zo) in de opensource applicatie en de klantspecifieke dingen in een plugin die die nieuwe uitbreiding gebruikt, en dan reken je aan de klant alleen het maatwerk gedeelte als extra kosten.

    Op die manier heeft de klant alles wat echt van hem is, gewoon in eigen licentie/eigendom/whatever. Maar als een klant met een goed idee komt wat andere klanten ook willen dan is het een stuk minder duur dan wanneer hij iets wil (waarvan de ontwikkelaar denkt) dat het bij die ene klant blijft.

    1. Dat raakt aan een heel goed punt: wat is nu eigenlijk maatwerk, zeker bij SaaS? In theorie kun je natuurlijk alles wel willen, maar ik zie in de praktijk weinig meer dan API-koppelingen met andere systemen of kleine aanpassingen in het werkproces.

      Het idee van een goede architectuur is natuurlijk de beste manier. Alleen dat kost wel veel tijd en moeite om goed te krijgen, tijd die je ook in verkopen van je oplossing kunt steken. “Dat doen we wel in versie 3”. Precies…

  3. Het is nog maar de vraag of de AGPL in de praktijk afdwingbaar is. Je krijgt de code doorgaans zonder dat je daarvoor een aanbod moet aanvaarden. Je kan dan op basis van de uitzonderingen op het auteursrecht de software gebruiken (artikel 45j Aw). Je komt het auteurswet pas tegen op het monent dat je code wilt gaan verspreiden.

    Wat de GNU community er ook van vind, een module is geen afgeleid werk als daar geen andere code inzit; ook niet als je niets aan de module hebt zonder andere code.

    1. Dit valt mee, het gaat hier om toestemming die lijdt tot een uitzondering op de normale exclusiviteit van de auteur. Er is ook geen impliciete licentie. Als ik een boek koop, of broncode krijg is het impliciet daarin dat ik ook het recht heb om dit in te zien (te lezen). Dit geeft nooit het recht om een afgeleid werk te maken. Uiteraard is het lastiger bij het uitsluitend gebruiken van de aangeboden software, en is het dan afdwingbaar dat de broncode door de saas-aanbieder wordt verstrekt. Dat is echter niet echt interessant, want je kunt diezelfde broncode ook elders (het oorspronkelijke project) verkrijgen. De stok achter de (A)GPL is het afgeleide werk. Dat is een actieve actie die normaal gesproken niet mag behalve als er een expliciete licentie is. De GPL is slechts een algemene licentie voor het maken van dat afgeleide werk. Het is perfect mogelijk om met de auteur een andere licentie af te spreken (als het niet om honderden auteurs gaat – dat wordt lastig). Met andere woorden, je komt auteursrecht al tegen als je een afgeleid werk maakt. De vraag wanneer iets een afgeleid werk is, is een ander probleem. Niet iets dat in algemeenheid kan worden bepaald. Onder EU recht is er een uitsluiting voor APIs (o.a. het SAS arrest), en een volledig onafhankelijke module zou dus eventueel niet onder de GPL vallen. Daarentegen is gebruiksrecht ook niet vanzelfsprekend, en zou het dus wellicht mogelijk zijn om de licentie van het framework te laten vervallen bij een ongelicencieerde module.

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.