Mag mijn webhoster ons cms schrappen volgend jaar?

| AE 12249 | Ondernemingsvrijheid | 23 reacties

Een lezer vroeg me:

Onze websitebouwer en hosting bedrijf stapt over op een ander (en volgens hun veiliger) cms systeem. Het cms dat we nu gebruiken zal per 1 juli bevroren worden en per 1 januari daarna offline gehaald worden. Kunnen zij dat eenzijdig zeggen? Dit geeft ons enorme kosten, onder meer 5000 euro voor de migratie van alle content en verdubbeling van de maandelijkse kosten.
Het voelt natuurlijk nogal vervelend om over te moeten naar een nieuw systeem terwijl het huidige nog prima lijkt te werken. Maar onderhoud van software is duur, met name als de software steeds ouder wordt. Ik begrijp de stap van de websitebouwer/hoster dus wel.

Ik moet zeggen dat ik in dit geval de gegunde termijnen (een dik half jaar nog alles kunnen doen en daarna nog zes maanden gebruiken zonder aanpassingen in het cms) best schappelijk vind. Ik krijg deze vraag vaker maar dan zijn de termijnen eerder in weken uitgedrukt. Een periode van dik een jaar om te migreren naar een andere leverancier voelt best redelijk, en dat maakt dat ik eigenlijk geen juridisch argument tegen kan bedenken.

Ja, als er in de voorwaarden of SLA zou staan dat de software nog een aantal jaren mee moet kunnen natuurlijk. Maar ik ken geen leverancier die zichzelf zo hard vast gaat pinnen zonder behoorlijke vergoeding. Of als heel recent het contract is vernieuwd voor een paar jaar en het cms een belangrijk deel van de dienst is. Maar dat is vrij uitzonderlijk.

Arnoud

Open source met verspreidingsverbod

| AE 4714 | Intellectuele rechten | 50 reacties

Interessante vraag vorige week bij mijn blog over “van wie is dat CMS”:

Hoe zit het met een constructie waarin de ontwikkelaar jou enerzijds het CMS onder de LGPL beschikbaar stelt en jij je er vervolgens contractueel op vastlegt het niet te verspreiden op last van een fikse boete? Waarbij de boete vervalt bij faillisement van de leverancier.

Dit is een creatieve poging om een soort van escrowregeling op te zetten. Het idee is dan dat je bij faillissement een LGPL opensourcelicentie krijgt, zodat je toch door kunt blijven werken met die software.

Alleen: het gaat niet werken.

De LGPL is in feite gewoon een licentiecontract (ja, een contract) en contracten kunnen door een curator worden gepasseerd. Dus of je nu een speciale escrowclausule in je ‘gewone’ licentie opneemt of zo’n LGPL-met-boete-constructie hanteert, het verliest zijn waarde zodra de leverancier failliet is.

De constructie deed me denken aan de term open source escrow. Dit komt erop neer dat de escrowagent de broncode in escrow houdt en uitbrengt onder een open source licentie zodra bekend is dat de leverancier failliet gaat (of met zijn bedrijfsvoering stopt om andere redenen). Dat kan dus, maar alleen als de agent de auteursrechten heeft.

Zouden mensen hier behoefte aan hebben? En zou het überhaupt werken, een stukje propriëtaire software die ineens open source wordt? Wie heeft zin daaraan te gaan werken?

Arnoud

Van wie is die website (met CMS)

| AE 4705 | Intellectuele rechten, Iusmentis | 68 reacties

Weer een regelmatig terugkerende kwestie: mensen laten een website bouwen, denken daar eigenaar van te zijn maar er blijkt een door de sitebouwer zelf ontwikkeld CMS achter te liggen. En artikel 18.3 van diens algemene voorwaarden bepaalt dat het eigendom daarvan “ten alle tijde” (sic) bij hem ligt. Ja, dat is rechtsgeldig ondanks die taalfout.

Hoofdregel uit het auteursrecht is dat degene die een werk maakt, de rechten daarop heeft. Ook als deze in opdracht werkt, hét grote misverstand bij online auteursrechten (oké, naast “het staat op internet en is dus vrij van rechten”). Als je dus een site laat bouwen, is die niet van jou. De site is van de ontwikkelaar en hij staat jou toe deze te gebruiken voor het doel dat in de offerte is benoemd, meer niet.

Natuurlijk kun je daar andere afspraken over maken in het contract. Een zin als “het (intellectueel) eigendom van de site ligt bij Klant” is genoeg, mits de passage ondertekend wordt en duidelijk is om welke site het gaat.

Dan is er nog één probleem: het contentmanagementsysteem oftewel CMS waarmee de site is gebouwd. Er zijn bergen opensourcecontentmanagementsystemen (zie plaatje) waarmee dit zou kunnen, maar menig ontwikkelbedrijf voelt de onbedwingbare neiging om toch zelf een CMS te bouwen. Goed, dat mag, maar het gevolg is wél dat je als klant alsnog vastzit aan dat ontwikkelbedrijf. Je zou haast gaan denken dat ze het erom doen.

De eigendom van het CMS opeisen kan, maar dan moet je wel een aparte bijzin opnemen “inclusief het achterliggende CMS” in die zin die ik daarnet noemde. Maar of de ontwikkelaar daarmee akkoord gaat, betwijfel ik. Hij kan dan immers het CMS aan niemand anders meer beschikbaar stellen. Mogelijk komt ie zelfs in de problemen met bestaande klanten die het CMS al gebruiken (hoewel dat op zich prima te regelen is met een licentie terug).

Dit probleem voorkomen kan maar op één manier: vooraf vragen met welk CMS de site gebouwd gaat worden en hoe het zit met eigendom daarvan. En dat behoort net zo’n logische vraag te worden als de verborgen gebreken bij huizen.

Arnoud