Tag: sla

About sla

Subscribe Feeds

Als je open source als gratis leverancier ziet, dan krijg je dus dit

Geplaatst op in Intellectuele rechten, 25 reacties

Enige ophef op Twitter: OSS-developer Daniel Stenberg kreeg een nogal bars klinkende mail van een gebruiker, die hem als “Maxx Team Partner” aanschreef en graag binnen 24 uur wilde horen hoe zijn bedrijf was ingericht op het afdekken van risico’s rondom de enorme log4j bug van onlangs. “What is the timeline for completing remediation? List the steps, including dates for each.” Eh. Als ik daar leverancier was, zou ik dit niet heel lief vinden. Maar als je enkel iets op internet had gezet?

Het enige logische antwoord is wat Stenberg ook gaf: “I’d be happy to answer all the questions as soon as we have a support contract.” De algemene tip die ik al eerder aanried: OSS drijft op de gedachte van communities. Iedereen helpt elkaar, en daar kan iedereen dus terecht. Maar bedrijven werken met contracten, om zekerheid (althans, de illusie van) te realiseren en om leveranciers bij de nekharen te kunnen grijpen als blijkt dat er iets misging. A throat to choke, extern de schuld neerleggen zeg maar.

Open source licenties zijn natuurlijk contracten, dus als je als bedrijf software van Stenberg installeert (hij maakte onder meer cURL) dan heb je een leveranciersrelatie. Zou je kunnen zeggen als rechtlijnige inkoper. Maar er is dan in het geheel geen sprake van zelfs maar enige inspanningsplicht bij Stenberg, hier is de software en als ‘ie breekt, mag je de stukjes houden. Of zelf aanpassen, zie maar. Dat is de gedachte achter open source: je kunt er zelf mee aan de slag, veel plezier verder.

Ondertussen zijn we denk ik op het punt dat dit geen groot risico meer zou moeten zijn. Veel bedrijven stoppen hun interne pipeline en producten dan ook vol met open source, en ontdekken pas de problemen als er dingen zoals log4j zich voordoen: een kwetsbaarheid in een breed gebruikt stuk software, dat eigenlijk nauwelijks onderhouden wordt omdat die ene aardige man uit Nebraska er niet zo’n zin meer in heeft.

Helaas verbaast het me toch niet dat je zo’n reactie krijgt van een bedrijf dat al jaren gratis die software gebruikt. Het is natuurlijk juridisch complete onzin, je hebt niets te eisen als je geen afspraak over dat onderwerp hebt gemaakt. En zeker waar het gaat om gratis aangeboden software waarbij nadrukkelijk geen enkele verwachting werd gewekt, is dit ook nog eens moreel niet zo netjes. Maar ik snap het wel, dat is nu eenmaal de reflex waar je mee komt als je software van derden gebruikt die lek blijkt te zijn.

Toch zou het goed zijn als organisaties wat vaker op zoek gaan naar mogelijkheden om OSS projecten te sponsoren. Niet perse als dure SLA, maar betalen voor een stuk ontwikkeling voor de toekomst of een preventieve securityscan, het zou geen gek idee zijn. Natuurlijk, daar profiteert de concurrent dan weer van, maar we hebben het hier over software die per definitie geen competitief voordeel geeft, dus of dat nou de ergste reden moet zijn?

Arnoud

Welke responstijd heeft een SaaS-dienst zonder SLA?

Geplaatst op in Ondernemingsvrijheid, 6 reacties

Een lezer vroeg me:

Ik ben een kleine ondernemer en net gestart met een software-as-a-service dienst. Het voelt nog wat vroeg om harde SLA’s aan klanten aan te bieden, maar waar sta ik als dat niet doe? Aan welke getallen zit ik dat vast, hoe bereken je dat?
Een service level agreement of SLA is bedoeld om concrete afspraken te maken tussen een leverancier en afnemer, bijvoorbeeld over beschikbaarheid van een SaaS-dienst of de reactiesnelheid bij problemen of storingen. Dat concrete is handig, omdat je dan geen discussie krijgt over “te laat” of “te langzaam” iets oppakken. Daar staat natuurlijk tegenover dat je dan wel concreet dat getal moet leveren, ook als dat eigenlijk niet past bij je bedrijf. Dus ik snap dat kleine bedrijven dit liever niet doen.

Als je geen expliciete afspraken maakt, dan kom je als hoofdregel uit bij wat de wet de redelijkheid en billijkheid noemt. Je ziet dat ook wel in de algemene voorwaarden van SaaS-diensten: Leverancier zal zich inspannen een redelijk niveau van beschikbaarheid te leveren. Dat is genoeg, het enige is natuurlijk dat je dan bij een klagende klant héle lange discussies kunt krijgen over wat een redelijk niveau is en waarom jouw downtime op dinsdagmiddag 14:30 daar wel of niet onder valt.

Aanvullend geldt daarbij de gewoonte (art. 6:248 lid 1 BW), wat je kunt zien als wat gebruikelijk is in de branche waarin je opereert. Als daar een bepaald percentage gebruikelijk is, dan moet jij dat ook leveren. Ik ken alleen niet echt dergelijke gebruiken in welk deel van de software-as-a-service markt, ik zou juist willen zeggen dat de gewoonte is om zonder SLA alleen zo’n “redelijk inspannen” toezegging te doen.

Het is overigens prima om een getalsmatige toezegging te doen zonder een ding van twintig kantjes dat “Service Level Agreement” heet erbij te leveren. Leverancier zal zich inspannen de beschikbaarheid per maand op 98% of meer te houden. En vaak zie je dat het de klanten niet eens gaat om die beschikbaarheid, maar om andere dingen:

  • Leverancier zal onderhoud beperken tot de nachtelijke uren en/of het weekend.
  • Leverancier zal onderhoud met downtime vooraf aankondigen.
  • Leverancier zal Klant continu op de hoogte houden van de voortgang van het wegnemen van het probleem.
Ik zou als kleine ondernemer dan ook eerder daarvoor kiezen. Je klanten worden een stuk tevredener als ze weten dat jij ze persoonlijk begeleidt en informeert, en echt zelf ook wil dat ‘ie het nu weer doet.

Arnoud

Wat is beter: een hard onderhoudscontract of een stevige garantie?

Geplaatst op in Ondernemingsvrijheid, 3 reacties

Een lezer vroeg me:

Als softwareleverancier in de zakelijke markt werken wij veel met onderhoudscontracten. Ik zie echter vaak klanten die garanties in onze licentie stoppen (althans, dat proberen) en dan zeggen dat dat beter is dan een onderhoudsafspraak. Hoe kijk jij als contractsjurist daar tegenaan?

Herstel onder een garantie is feitelijk hetzelfde als onderhoud, maar juridisch betekent het met name dat de kosten van de werkzaamheden bij de leverancier blijven liggen. Garantie eisen is dus gratis onderhoud verlangen.

De klassieke manier voor ICT-leveranciers om klanten aan zich te binden, is het onderhoudscontract. Software slijt; na verloop van tijd zijn altijd aanpassingen nodig om een en ander werkende te houden. Hetzelfde geldt voor online diensten. De redenen hiervan zijn divers, maar vaak met name te wijten aan vernieuwingen in andere software of diensten en nieuwe inzichten over het gewenste gebruik. Daarnaast worden onderhoudscontracten vaak “voor de zekerheid” genomen, wie wil er immers op een cruciaal moment met een storing zitten waar de leverancier geen onderhoud op komt plegen?

Het grote nadeel van onderhoudscontracten is natuurlijk dat zij geld kosten. Meestal gaat het dan om niet onaanzienlijke bedragen die maandelijks of jaarlijks moeten worden voldaan, en waarbij de klant slechts eens per jaar of zelfs vijf jaar mag opzeggen. Het verbaast dan ook niet dat afnemers hier steeds kritischer naar kijken, met name waar het onderhoud betreft op fouten en onvolkomenheden die eigenlijk gewoon als tekortkoming van de leverancier aangemerkt kunnen worden. In dat geval is het beter om een garantie te eisen dat dergelijke fouten afwezig zijn.

Ik zie het dus als een onderhandelspel dat met name neerkomt op grenzen trekken en kosten verdelen. Welke fouten of problemen zie je als echt tekortkoming, dat had er gewoon niet mogen zijn, en welke zijn gewoon dingen die kunnen gebeuren? Is verbeterde logica het herstel van een fout of een vernieuwde feature? Als een externe koppeling breekt, moet de leverancier dat dan gratis herstellen of juist niet?

Garanties kunnen overigens op diverse wijzen worden ingeperkt. Vaak wordt gekozen voor een beperkte toezegging dat de betreffende fout kosteloos wordt hersteld, hetgeen inhoudt dat er geen aanvullende schadevergoeding mogelijk is.

Arnoud