Mag mijn softwareleverancier me een servicecontract in de maag splitsen?

Een lezer vroeg me:

Enkele jaren terug hebben wij een softwarepakket laten maken door een leverancier. Eigenlijk hadden wij daar vanaf het begin geen goed gevoel bij. Alles kostte geld, van een extra feature tot corrigeren van taalfoutjes aan toe.

Een maand geleden kregen we echter een nieuwe aankondiging die voor ons de druppel is: we worden verplicht een servicecontract af te nemen van 1200 euro per jaar, en anders wordt de licentie ingetrokken. We hebben 2 maanden om te beslissen, en in de tussentijd krijgen we bij elke keer opstarten een melding dat dit eraan gaat komen. Kan dat zomaar?

Deze vraag is in het algemeen moeilijk te beantwoorden, omdat het antwoord voor 99% afhangt van het contract. Maar het is denkbaar dat het antwoord “ja, dat kan zomaar” luidt.

Hoofdregel bij software is dat de leverancier alle auteursrechten op de software heeft. Alleen als er schriftelijk (en ondertekend) is gezegd dat de rechten naar de opdrachtgever gaan, heeft de opdrachtgever de rechten. En wanneer de leverancier de rechten heeft, bepaalt hij op welke manier de klant gebruik mag maken van de software. Ja, ook als het maatwerk is.

Het wijzigen van het contract kan alleen als in het contract staat dat de leverancier dat mag doen. Maar vrijwel elk contract bevat zo’n beding, ergens verstopt tussen toepasselijk recht, overmacht en de clausule dat kopjes in het contract niet in de interpretatie van de artikelen mogen worden betrokken (wtf?). Daarmee kan de leverancier dus vrij eenvoudig elke nieuwe licentieconstructie doorvoeren.

Het gaat nogal ver om ineens een servicecontract met hoge extra kosten te introduceren, maar in principe kan het dus wel. Wie zijn softwarelicenties dus niet goed leest, kan tegen dit soort verrassingen aanlopen.

Slimme klanten bedingen dus het eigendom op de software (of kiezen open source) zodat ze dit probleem niet hebben.

Arnoud

17 reacties

  1. @nl-x, als in de koopovereenkomst staat dat de de leverancier de overeenkomst eenzijdig mag wijzigen en hij doet dit ook met een beding waar de klant zich niet aan houdt, dan mag de leverancier de koopovereenkomst ontbinden omdat de klant zich er niet aan houdt. Dit maakt niet uit of het een koopovereenkomst betreft of een andere overeenkomst.

  2. Maatwerk laten maken en daar het eigendom van bedingen? Eenvoudiger gezegd dan gedaan. Sowieso is de prijs voor maatwerk best kostbaar en daarnaast bouwen veel software producenten hun maatwerk projecten bovenop hun bestaande producten zodat er een afhankelijkheid blijft met een generiek product. (Zo ook mijn werkgever.) Je krijgt als klant dan ook niet makkelijk de eigendomsrechten van een maatwerk-product. Wil je de eigenaar worden, dan zul je zelf mensen moeten inhuren en het zelf ontwikkelen. Een ander probleem is dat veel van dit soort bedrijfs-software geschreven worden door software-fabrikanten met specialiteiten in een bepaalde branche. Zo’n bedrijf heeft (als het goed is) diverse vak-specialisten in dienst om de software zo goed mogelijk op te zetten. Okay, het komt ook regelmatig voor dat een software-producent een paar klunzige ontwikkelaars in dienst hebben waardoor het product gebreken vertoont, maar meestal zit er wel enorm veel vakkennis in die producten waardoor het toch vrijwel onmisbaar wordt voor bedrijven. Je kunt wel kijken naar open-source oplossingen maar veel van deze gespecialiseerde bedrijven durven de stap niet aan om hun product als open-source vrij te geven, mede omdat het de consurrentie goed helpt. Je moet dan als bedrijf specialiseren in betere vakkennis en in gerelateerde diensten die aan het product zijn gekoppeld! Diensten die concurrenten dus ook aan kunnen gaan bieden. Maar die vakkennis moet in balans zijn met de ontwikkel-kennis van de programmeurs en software engineers die het bedrijf in dienst heeft om het product te ontwikkelen. Helaas, zowel programmeurs als software engineers als die gespecialiseerde vak-specialisten zijn vrij duur personeel (zeker de ervaren werknemers) waardoor je als bedrijf dus veel personeelskosten hebt die je weer terug moet verdienen met… Tja, met de extra services als je open-source genereert en anders via de licentie-kosten. Kortom, als klant is het niet eenvoudig om het eigendom te bedingen of voor open-source te kiezen als je gespecialiseerde software nodig hebt. Software voor huisartsen-posten, kassa-systemen en financiele adviseurs bijvoorbeeld. Een huisartsen-systeem heeft b.v. een lijst van ziektebeelden en medicijnen nodig die continu bijgewerkt moet worden. Deze updates zijn een dienst die je als bedrijf kunt leveren maar vereist zeer gespecialiseerde vakkennis. Kassa-systemen zijn iets eenvoudiger maar die moeten kunnen communiceren met electronische kassa’s en hun gegevens op een centrale plek verwerken. Die communicatie-protocollen zijn lang niet allemaal standaard en/of openbaar. En de markt voor financiele software-producten? Mijn vakgebied? WOW. Ja, er zijn heel veel eenvoudige zaken zoals het berekenen hoeveel je uiteindelijk betaalt als je geld leent tegen 4.56% rente. Of hoe groot de hypotheek moet zijn als je een huis wilt kopen. Maar als je meer details nodig hebt omdat je als adviseur een product aan wilt bieden dan moet de software kennis hebben van alle maatschappijen, producten en alle voorwaarden die daar weer aan gerelateerd zijn! Informatie die bijna dagelijks verandert! Een dergelijk product als open-source genereren kan, maar die product-informatie aangeleverd krijgen? Dat wordt lastig! En daarnaast, hoe verdien je aan een dergelijk specialistisch product wat een relatief kleine klantenkring heeft?

    Dus nee? Maatwerk krijg je nauwelijks in eigendom. Open-source is veel te zeldzaam voor de speciale gevallen. Blijft over het zelf ontwikkelen van de software en dus ervaren programmeurs in dienst nemen en zien hoe je die kosten weer terugverdient…

  3. @Fred: en dat probleem heb je niet met closed source? Bij open source kun je tenminste nog iemand anders inhuren om de code door te spitten en eventueel veranderen. Bij closed source lukt dat veelal geheel niet.

  4. In house open source software hoef je niet de source van vrij te geven als je deze alleen in house gebruikt. Wat dat betreft is er dus een onterechte angst onder veel bedrijven voor open source.

    Anderzijds lijkt het me gewoon goed oppassen dat je een eeuwig durende licentie verkrijgt die niet kan worden herroepen (helaas muv herroeping door curatoren als ik Arnoud goed heb begrepen).

    Hoogstens kan dan de ontwikkeling en ondersteuning wegvallen, maar dan kan je het in ieder geval blijven gebruiken terwijl je een alternatief laat maken.

  5. Risico off-topic te raken. Ik hoor wel als dat zo is.

    Het gebruik van een auto is op geen enkele manier te koppelen aan het hebben van een onderhoudscontract met een dealer.

    Bij intellectueel eigendom / auteursrecht is dat dus niet hetzelfde. Waarom eigenlijk niet? Het volgt niet de lijn der verwachting… Normaal gesproken ervaar ik het rechtsysteem als iets dat formaliseert wat je redelijkerwijs ook mag verw?chten.

  6. @Sjoerd: En dat doorspitten kost helemaal niets? Zoals Wim ten Brink al meldt: ‘Blijft over het zelf ontwikkelen…’ en die ervaren programmeurs kosten ook klauwen met geldt, dus voor het kostenaspect hoef je het niet te doen. Vooropgesteld dat je als organisatie groot genoeg bent om zelf programmeurs in dienst te hebben.

  7. @Friso: Dat is vooral historisch zo gegroeid. Er is geen fundamentele reden waarom een dealer niet mag zeggen “u krijgt deze auto alleen van mij op basis van een leasecontract waarbij ik elk jaar de prijzen mag aanpassen en uw gebruiksrecht mag beperken”. Maar men is begonnen met de simpele verkoop, zodat iemand die nu zo’n leaseconstructie hanteert zich op een commerci?le achterstand plaatst.

    Bij software is iedereen vanaf het begin gaan werken met beperkte gebruiksrechten gekoppeld aan dure onderhoudscontracten. De auteurswet is rond 1991 aangepast op software, maar verder dan enkele wettelijke gebruiksrechten is dit niet gegaan. Had daar toen gestaan dat je een onvervreemdbaar en eeuwigdurend recht krijgt, dan hadden we software ?cht kunnen kopen.

  8. In house open source software hoef je niet de source van vrij te geven als je deze alleen in house gebruikt.
    Nee, dat is niet waar! Dit hangt af van de open-source licentie die van toepassing is. Er zijn licenties die gewoon zeggen dat je er alles mee mag doen behalve claimen dat je de eigenaar bent. En er zijn licenties die zeggen dat je iedere wijziging moet delen. Het probleem is vooral dat er niet 1 open-source licentie bestaat en veel grote projecten al gauw kunnen bestaan uit open-source onderdelem met ieder een eigen licentie. Een open-source licentie is per definitie niets meer dan het recht om de broncode te mogen inkijken. Daarbovenop kunnen extra rechten komen die de eigenaar van de broncode erop legt via de licentie.

    Anderzijds lijkt het me gewoon goed oppassen dat je een eeuwig durende licentie verkrijgt die niet kan worden herroepen
    Hier is een ander probleem bij, mede dankzij de moderne ontwikkelingen. Veel software fabrikanten zijn aan het experimenteren met Cloud applicaties, waarbij je als gebruiker gewoon toegang krijgt tot een online applicatie. Dergelijke contracten zijn eerder een soort huurcontracten en daar krijg je niet snel eeuwigdurende toegang toe. Vel software-fabrikanten vinden dit interessant omdat klanten dan niets meer kopen maar gewoon abonnees of huurders worden en dus periodiek moeten betalen of anders de toegang ontzegd worden… Leuker wordt het indien je een applicatie koopt die communiceert met een dergelijke Cloud applicatie. Het gebruik van die software op je eigen systeem kan eeuwigdurend zijn en mogelijk zelfs open-source, maar voor de toegang tot de services moet je betalen! En ook dit is zeer interessant voor software-fabrikanten omdat ze dan een grafische interface kunnen maken en desnoods als open-source publiceren, maar de gebruikers moeten desondanks steeds blijven betalen! Mooi voorbeeld zijn de vele MMORPH spelletjes (WOW, Age of Conan, etc) waarbij de software geen cent hoeft te kosten maar waarbij je maandelijks een vast bedrag moet betalen. (Of mogelijk allerlei advertenties moet aanzien…)

    @Arnoud, indien in 1991 al was bepaald dat je eigenaar wordt als je een software product koopt dan was Cloud Computing vast een behoorlijk stuk eerder ontwikkeld! Dat had de groei van Internet-applicaties een enorme boost kunnen geven. Sowieso is het kopen van software niet erg nuttig indien je daarbij geen rechten hebt op updates. Sommige software veroudert enorm snel, zeker in de financiele wereld waar regelgeving continu verandert.

  9. @Wim Wim, volgens mij heb je het niet helemaal begrepen. Open source licenties vereisen alleen maar dat je de broncode meelevert bij het verspreiden van de software. Er staat nergens dat je die code openbaar moet maken.

    En om op die huisartsenpost te rug te komen. De software voor de post in het algemeen kan heel goed open source zijn. Alleen de specifieke ingevoerde data en de dienst van het invoeren zelf zijn heel goed te verhandelen diensten. Daarmee kun je dan ook concureren zodat je als opdrachtgever je niet hoeft te ketenen aan een specifieke leverancier.

  10. @Peter, Open Source geeft standaard alleen het recht om de broncode te mogen inzien! Daarmee krijg je wel de mogelijkheid om aanpassingen aan te brengen, maar daaraan zitten wel weer voorwaarden die bepaald worden door de auteur.

    Ik kan mij voorstellen dat iemand iets als CC-BY-ND (No Derivates) vrijgeeft maar dat zal bijna nooit om broncode gaan. Een dergelijke licentie is ook geen open-source, hoewel het er dan wel op lijkt. Bij broncode zou het dan kunnen gaan om broncode die via een code generator wordt gemaakt, waardoor aanpassingen op de gegenereerde code zeer ongewenst zijn. (Want die worden ongedaan gemaakt bij de volgende keer dat de code wordt gegenereerd.)

    Maar de auteur kan extra voorwaarden opleggen waaronder aanpassingen aangebracht mogen worden. Bijvoorbeeld aanpassingen in de naamgeving van het product, versienummer en wat nog meer. Zo kunnen ze ook eisen dat je de gewijzigde broncode meelevert of beschikbaar stelt met het product, dus ook intern aan alle medewerkers! Niet alle licenties houden rekening met in-house situaties.

    Betreffende huisartsen-posten: de data die hierbij nodig is hoeft niet aan een open standaard te voldoen. En die data hoeft ook niet vrijelijk beschikbaar te zijn. Als open-source ontwikkelaar zul je dan een verzoek moeten indienen voor de data-specificaties zodat je deze in je applicatie kunt inlezen. En hopen dat diegene die de data aanleveren deze definitie niet af en toe aanpassen. Die data heb je nodig om je applicatie waardevol te maken, maar als jij de source vrijgeeft en een ander verdient aan het aanleveren van de data, hoe verdien jij dan wat terug? Wat vaak vergeten wordt: ook open-source ontwikkelaars zijn afhankelijk van een inkomsten-bron en de meeste van hen maken open-source om vervolgens aanverwante diensten en ondersteuning aan te kunnen bieden. Het idee dat open-source door een enkele programmeur in zijn vrije tijd wordt geproduceerd is volkomen verkeerd. Sommige projecten beginnen op die manier maar vroeg of laat wordt het op een professionele manier aangepakt en worden er manieren bedacht om er alsnog mee te kunnen verdienen.

  11. Wij als bedrijfssoftware leverancier en app ontwikkelaar krijgen hier ook vaak mee te maken. Meestal wordt hiervoor een juridisch document opgesteld. Lastige bij het “weggeven” van auteursrecht is dat je bij de volgende klant problemen krijgt als die min of meer dezelfde opdracht voor je heeft…

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.