Software: Licentieovereenkomsten maatwerk.

Deze post gaat over een voorbeeld van een licentieovereenkomst voor maatwerksoftware. Zowel de opdrachtgever als opdrachtnemer hebben behoefte aan duidelijkheid. Doe je niets dan geldt standaardauteursrecht en dat is niet altijd wenselijk. Als verwachtingen wederzijds niet overeenkomen dan is dat vragen om juridische problemen. Hoe kan je op een makkelijke manier dingen goed afspreken? Ik denk dat onderstaande voor veel organisaties een welkome oplossing is.

Dit artikel is ‘work in progress’… Ik ben uiterst benieuwd naar juridische reacties maar dit lijkt mij een ei van Columbus. Voorlopig als concept gepubliceerd…

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 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.
  • 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.

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.

In de keten

De kans is redelijk 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 B zowel opdrachtgever als ontwikkelaar. De belangen van A en 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.
  • 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).

Geef een reactie

Het e-mailadres wordt niet gepubliceerd. Vereiste velden zijn gemarkeerd met *