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
Slimme klanten die de eigendom van software bedingen? Lijkt me eerder naief. Bij sommig maatwerk kan het evt. relevant zijn, maar bij commercial of the shelf?!
Ok, voor COTS is dit niet relevant. Maar ik had het alleen over maatwerksituaties, omdat de vraagsteller daarmee begon (“laten maken”). En bij maatwerk is het w?l belangrijk eigendom te eisen.
Complimenten voor de rake opmerking: “of kiezen open source”.
Dat zouden meer partijen moeten doen!
Staat intrekking van licentie dan niet gelijk aan ontbinding van het koopcontract? Of was het nou zo dat er geen sprake is van koop?
@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.
@Eva Quirinius: En dan maar hopen dat er iemand is die je applicatie blijft ondersteunen en zorgt dat alles gepatcht blijft.
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…
@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.
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.
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.
@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.
@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.
@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.
@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.
@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.
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…
Wij krijgen hier ook steeds vaker mee te maken. Maar,verder: watBas zegt.