Software: Licentieovereenkomsten maatwerk.

Deze post gaat over een voorbeeld van een licentieovereenkomst voor maatwerksoftware. Maar het kan net zo goed die uitbestede fotosessie of handleiding zijn. Zowel de opdrachtgever als opdrachtnemer hebben behoefte aan duidelijkheid. Doe je niets dan geldt standaardauteursrecht en dat is meestal niet wenselijk. Als verwachtingen wederzijds niet overeenkomen dan is dat vragen om juridische problemen. Hoe kan je op een makkelijke manier dingen goed afspreken?

Onderstaande benadering op basis van de zogenaamde “Harmony CLA” zal voor veel organisaties een welkome oplossing is. Inmiddels heb ik ook enkele juridische reacties gekregen en die zijn positief. We passen het zelf als standaard toe binnen onze organisaties want het is voor veel dingen het ei van Columbus.

Bierviltje? Of juridisch dichttimmeren?

Dit is meteen het dilemma van kleinere bedrijven. Helemaal niets overeenkomen – geen licentieovereenkomst – is een slecht idee. Echter, ook mondelinge afspraken zijn een slecht idee – ervaring met DHL illustreert hoe dit flink kan ontsporen. Twee uitersten blijven dan over: Het bierviltje of een contract van tig bladzijden. Bedrijven zullen met name vallen over de prijzen en onbegrijpelijkheid van pakken papier. Zelfstandige programmeurs verlies je al helemaal hier. We zoeken dus een model, een voorbeeld, van een licentieovereenkomst dat daar tussenin zit en begrijpelijk, duidelijk en kort is en bovendien geen extra kostenlast veroorzaakt. Los daarvan is de vraag wat nu eigenlijk wederzijds gewenst is…

Wederzijdse wensen

Misschien is dit wel het meest complexe onderwerp omdat er zo enorm veel variaties van wensen en verwachtingen mogelijk zijn – de reden om een goede jurist in te schakelen. Daarom de beperking tot één variant. De belangen lijken enorm tegenstrijdig, maar lees vooral verder hoe dit elegant opgelost wordt:

  • Wat is de wens van de ontwikkelaar? De software-ontwikkelaar wil niet gehinderd worden omdat het auteursrecht niet meer bij hem ligt. De ontwikkelaar wil wel de software in licentie geven aan de opdrachtgever onder de voorwaarde dat het auteursrecht van de ontwikkelaar ongewijzigd blijft.
  • Wat is de wens van de opdrachtgever? De opdrachtgever wil alles kunnen doen met de software die hij krijgt, zoals veranderen, geld ermee verdienen, een licentie naar zijn klanten in volledige vrijheid kunnen bepalen. De opdrachtgever wil niet het auteursrecht van de ontwikkelaar aantasten maar wil ook niet dat de ontwikkelaar op een kwade dag voor de deur staat om royalty’s te innen.

Wow! Dat lijkt lastig. De kern is dat de ontwikkelaar het volledige auteursrecht heeft en houdt en dat de licentienemer alles mag doen wat hij wil. Het lijkt haaks op elkaar te staan maar iemand heeft daar al eens over nagedacht…

Harmony CLA

Canonical – verantwoordelijk voor onder andere Ubuntu-Linux – introduceerde in 2010 de zogenaamde “Harmony Contributor License Agreement” – voortvloeiende uit “Project Harmony“.

Het grote verschil met voorheen is dat het auteursrecht niet meer wordt overgedragen aan de opdrachtgever. In plaats daarvan krijgt de opdrachtgever vrijheden, zoals zelf mogen aanpassen en uitrollen, zonder de ontwikkelaar te beknotten.

Dat maakt de Harmony- CLA uitermate aantrekkelijk en breed inzetbaar voor zowel vrije software (open-source) als closed-source-software. Door zowel de belangen van de opdrachtgever als de ontwikkelaar veilig te stellen is het een sympathieke overeenkomst.

Bovendien is de lengte van de juridische tekst beperkt en redelijk goed leesbaar.

Hoe vreemd is de wet en de rechtsgang? Er was eens een restauranteigenaar die een muurtje door een kunstenaar, tegen betaling, liet opleuken. Zonder het in de gaten te hebben kreeg de kunstenaar daarmee rechten op het kunstwerk. Toen de restauranteigenaar vele jaren later het muurtje sloopte had hij het kunstwerk, waar hij geen rechten op had, vernield. Het werd een rechtszaak en de restauranteigenaar verloor. Als de restauranteigenaar de kunstenaar een Harmony CLA had laten opstellen, een kleine moeite, dan was dit allemaal goed geregeld.

In de keten

De kans is groot dat je dit artikel leest omdat je ontwikkelaar of opdrachtgever bent. Ik ben beiden en begin daarom met dat voorbeeld – niet uit onbescheidenheid.

  • Opdrachtgever A wil bij mij (B) iets laten maken. Een deel van dat werk besteed ik vervolgens uit aan ontwikkelaar C. Dat maakt van mij (B) zowel een opdrachtgever als een ontwikkelaar. De belangen van opdrachtgever A en ontwikkelaar C komen daarmee overeen met die van B.
  • Als opdrachtgever A is het interessant om de ontwikkelaar B een Harmony-CLA voor te schotelen.
  • Als ontwikkelaar B en C is het te overwegen om pro-actief de opdrachtgever een Harmony- CLA aan te bieden of erop te wijzen dat je zo zaken wil doen.

Aan de slag

Ga naar http://harmonyagreements.org/ en selecteer “Agreement Selector”. Dit is een voorbeeld:

Op http://www.harmonyagreements.org/guide.html staat een aanvulling op de tekst. Het kan ook zinvol zijn om een gegenereerde CLA door een vertaalservice te halen, “krom Nederlands” leest soms makkelijker dan “Legalese English” 😉

Overwegingen

  • Overweeg om per project met CLA’s te werken.
    • Het nadeel is een complexere administratie.
  • Bedenk dat “ontwikkelaar” meer algemeen een “aanbieder van informatie” is waarmee dus fotografie, illustraties en handleidingen afgedekt zijn.
  • Maak een scheiding tussen maatwerksoftware en shrink-wrap-software – Out Of The Box-, OOTB-software.
    • Voor OOTB-oplossingen wil je waarschijnlijk geen Harmony-CLA hanteren en wel een standaard End User License Agreement (EULA).

Leave a comment