Anno 2020 denken mensen nog steeds dat open source juridisch riskant is

| AE 11972 | Intellectuele rechten | 16 reacties

Via Bert Boerland op Twitter las ik:

Bijzonder lachwekkend (tot tranen toe!) stukje over #opensource (#cms-en) en licenses. Microsoft deed dit truukje (“Fear, Uncertainty and Doubt) zo’n 10 jaar geleden nog, maar is op het rechte pad. Lang geleden dat ik zo’n tenenkrommend stuk over proprietary vs OSS stuk las

Het gaat om dit artikel van geslotensourcecmsmaker Plate (“Meer met multisites”). In de wereld van contentmanagementsystemen is opensource al lang ingeburgerd dacht ik altijd, met Joomla, WordPress en Drupal als bekendste voorbeelden. Maar zo lees ik dan hier “achter het gemak van open source schuilt namelijk een schimmige wereld van licentievoorwaarden.” Ik heb even gecheckt en het artikel is niet uit 2002 en per abuis opnieuw online gezet. Dus eh, wat krijgen we nou.

Toen open source nog een nieuw verschijnsel was in het zakelijk firmament (eind jaren negentig) ontstond meteen discussie over de bijbehorende licentievoorwaarden. Die waren namelijk nogal anders dan het gebruikelijke licentiegeweld: in tegenstelling tot veel moeten betalen en beperkte rechten krijgen zonder aansprakelijkheid voor fouten, stond in opensourcelicenties dat je niet hoefde te betalen, alles mocht maar dat je (althans soms) wel mee moest doen met de opensourcegedachte. Oh en er was geen aansprakelijkheid voor fouten.

Dat “mee moeten doen” gaf de nodige bedrijven juridische zorgen, want die hadden allemaal net tien jaar geleerd dat geld verdienen met softwarelicenties verkopen het grote ding was. En dan zou je dus die software, die broncode gewoon weggeven en anderen alles laten doen daarmee zonder vergoeding? Kon niet waar zijn. De ietwat principiële opstelling van de Free Software Foundation hielp ook niet echt; nadat een stel slimmeriken de zakelijke term “open source” erop plakten en webbrowser Netscape vrijgaven onder zo’n licentie werd het iets makkelijker maar de twijfels bleven.

Die zorg over geheimhouding van je waardevolle software zien we ook meteen in dit artikel terug:

Stel je daarbij voor dat als je een opdracht hebt gegeven om aanvullend maatwerk te laten ontwikkelen op een Joomla platform, waarin een belangrijk deel van een businessproces in is verwerkt, de kans bestaat dat dit maatwerk vrijgegeven moet worden door de ontwikkelaar.

Ik noem dit altijd de IP-reflex: we hebben een stukje software dat we van onszelf zien (en dat noemen we IP) en dús moet dat waardevol zijn en dus geheim gehouden worden. Voor juristen heel normaal, je leert namelijk dat rechten van iemand zijn, en dus te beschermen. Maar de achterliggende zakelijke afweging – de onderliggende waardering – die blijft dan buiten beschouwing.

Zo ook hier: waarom is het waardevol om die businessprocesinformatie geheim te houden? Is het écht voordeliger voor het bedrijf om dat stukje software voor eeuwig in-house te houden, zelf te onderhouden en bij te werken? Wat voor superwaardevol bedrijfsproces heb je dan? Ik ben heel benieuwd.

Dit nog los van het juridische punt dat de GPL (want dat is de Joomla-licentie) helemaal niet eist dat als je maatwerk ontwikkelt, je dit vrij moet geven of terug moet leveren aan de Joomla community. De GPL zegt: wanneer jij maatwerk (voortbouwend op Joomla) levert aan een derde, dan moet die derde het maatwerk onder GPL kunnen gebruiken.

Maar in de meeste gevallen ga je een CMS helemaal niet aan derden leveren. Je installeert het CMS op je eigen server, voegt daar maatwerk aan toe en zet het ding aan. Er is dan geen situatie waarin de GPL enige eisen stelt. Wie een open source CMS inzet, hoeft zich nul zorgen te maken over het vrijgeven van enige maatwerkcode. Echt nul. Ik vind het echt kwalijk dat men anno 2020 nog steeds wat anders beweert.

Oh ja, inbreuk op rechten van derden. Dat zou zomaar kunnen, blijkt dat je Joomla in gebruik hebt en dat je de GPL schendt. Of dat je leverancier dat heeft gedaan. Dan krijg jij de claim. In theorie een probleem maar in de praktijk nog nooit voorgekomen, en ook iets waar je niet meteen een schádeclaim voor krijgt. In de opensourcegemeenschap is compliance het toverwoord: men eist dat je de licentie naleeft, maar naar de rechter voor een gebruiksverbod of schadevergoeding komt niet voor.

Een derde punt dat wordt aangedragen, is de beveiliging. Daar zou je niemand op aan kunnen spreken. En ja dat klopt, opensourcelicenties zeggen dat de makers nergens voor aansprakelijk zijn. Maar veel gesloten licenties zeggen dat ook (ik heb de Plate licentie niet gezien noch de SLA, dus ik weet niet hoe veel aansprakelijkheid zij aanvaarden voor securityfouten), dus in hoeverre dit uniek OSS aan te wrijven is?

Natuurlijk, met geslotensoftwareleveranciers kun je afspraken maken. En vooral: die kun je aansprakelijkheid en een vrijwaring opdringen, dus dan is het geregeld. Dat is de juridische mindset, wij zijn eigenlijk een soort tovenaars: zeg hoe het moet zijn, laat een handtekening zetten en bracchiabindo, we hebben het geregeld.

Ik sprak ooit een inkoper van IBM die bij leveranciers altijd vroeg om volledige aansprakelijkheid en een onbeperkte vrijwaring. Toen ik zei dat hij dat niet kreeg van mijn klant, was zijn reactie “mooi, want wie dat geeft die vertrouw ik voor geen cent”. Want leuk en aardig dat het op papier staat, maar wat is dat papier waard? Kan deze leverancier die kwaliteit leveren, heeft hij de expertise om de veiligheid echt goed op te lossen? Ja, het is hun product dus dan zullen ze het echt snappen. Precies, dat zeiden ze bij Zoom ook.

En dan de uitsmijter: “Het gebruik van closed source software maakt een organisatie minder kwetsbaar voor claims van buitenaf.” Dat is niet mijn ervaring, als je in de rechtspraak kijkt dan zie je eigenlijk alleen zaken tussen closedsourceleveranciers over inbreuk op elkaars licenties of rechten. Opensourcepartijen die procederen, dat komt gewoon niet voor.

Maar ach, leuk he weer eens terug naar hoe men vorig decennium dacht?

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

Plugins voor Joomla: verplicht GPL of toch niet?

| AE 846 | Intellectuele rechten | 2 reacties

Een lezer had een plugin voor het open source content management system Joomla! gemaakt, en vroeg zich af of hij die mocht verkopen zonder de broncode open source te maken. Joomla! is beschikbaar onder de GPL. Een afgeleid werk, dat wil zeggen een aanpassing of uitbreiding, mag je dus alleen ook weer onder de GPL verspreiden. Je mag er best geld voor vragen, maar je moet de broncode meeleveren. Geld vragen heeft niet zo veel zin, want iedereen mag de software weer verspreiden, zelfs gratis.

Maar hoe zit dat met een plugin? De FSF, auteurs van de GPL, vinden niet verrassend dat elke plugin GPL moet worden. De tekst van GPL (v2) zegt echter:

If identifiable sections of [the modified] work are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works.

Een plugin die uitsluitend gebruik maakt van de gewone plugin API zou ik beschouwen als een apart werk. Er zitten geen auteursrechtelijk beschermde stukjes van Joomla zelf in zo’n plugin. Het aanroepen van API calls is technisch noodzakelijk en daarom niet auteursrechtelijk relevant. En in die situatie mag je de plugin los van Joomla! verspreiden op elke manier en onder elke licentie die je goeddunkt.

Wat niet mag, is Joomla! in combinatie met de plugin verspreiden. Maar dat komt niet zo vaak voor, omdat Joomla! een webapplicatie is. Plugins worden eigenlijk altijd los gedownload door mensen die Joomla! al geïnstalleerd hebben. Joomla! zelf heeft hierover nagedacht en concludeert dat :

We’ve also decided that we do not have the authority to publish Joomla! under a version of the GPL that gives exceptions for proprietary extensions. It’s difficult to relicense a GPL’d project, and there is no indication that OSM currently has that ability. Our current understanding is that extensions that aren’t released under the GPL or compatible licenses are non-compliant, and that view is based on the guidance of both the Free Software Foundation and the Software Freedom Law Center.

Op zijn minst zul je dus enige weerstand vanuit de Joomla!-gemeenschap ondervinden als je plugins uitbrengt onder een andere licentie dan de GPL. Echter, gezien het feit dat er heel veel plugins onder een “commercial license” bij Joomla! zelf te vinden zijn, zou ik me daar geen al te grote zorgen over maken.

Zie ook de recente discussie bij Joomla! zelf.

Arnoud