Een licentieovereenkomst voor software is het contract waarin je bureau een ander toestemming geeft om software te gebruiken, terwijl het auteursrecht bij je bureau blijft. Er staan vijf dingen in die je nooit weglaat: welke software, wat de licentienemer mag, exclusief of niet, hoe lang, en wat het kost.
In Nederland regelt de Auteurswet de basis. De maker of zijn rechtverkrijgende kan een licentie verlenen (artikel 2 lid 2 Auteurswet).
Een exclusieve licentie moet schriftelijk worden aangegaan (artikel 2 lid 3 Auteurswet), een niet-exclusieve licentie heeft geen vormvereiste. Wat je wel en niet kunt verbieden, staat in de artikelen 45i tot en met 45m.
Wanneer heb je een licentieovereenkomst nodig?
Zodra je code die van je bureau is aan iemand anders laat gebruiken zonder het auteursrecht over te dragen. In de praktijk gaat het om drie situaties:
- Je verkoopt een product. Een plug-in, een module, een SaaS. Elke klant krijgt dezelfde niet-exclusieve licentie.
- Je geeft broncode in licentie aan één bedrijf. Een bestaande module, een interne tool, een platform dat je voor meerdere klanten hebt hergebruikt.
- Je houdt het IE na een klantproject. De klant krijgt een licentie op wat je gebouwd hebt, jij houdt de code en mag hem elders gebruiken.
Voor de eerste situatie volstaan vaak standaardvoorwaarden. Bij de tweede en derde onderhandel je per deal, en dan wil je een eigen overeenkomst. Wat een softwarelicentie in het algemeen is, staat op softwarelicentie.
Welke artikelen horen in een licentieovereenkomst voor software?
Dit is de opbouw die bij een broncodelicentie werkt. Bij een productlicentie vallen sommige artikelen korter uit.
| Artikel | Wat je vastlegt |
|---|---|
| Definities | Wat ‘Software’, ‘Broncode’, ‘Updates’ en ‘Toepassing’ betekenen |
| Licentieverlening | Exclusief of niet, voor welk gebied, welke branche, welke periode |
| Toegestaan gebruik | Gebruiken, aanpassen, inbouwen in eigen producten, aan eigen klanten leveren |
| Beperkingen | Geen sublicenties, geen doorverkoop als losse code, geen concurrerend product |
| Levering | Repo, commit-hash of versie, documentatie, overdrachtsmoment |
| Vergoeding | Eenmalig, per jaar, per gebruiker of als royalty, met betaaltermijn |
| Onderhoud en updates | Inbegrepen, apart te kopen, of niet |
| Open source | Lijst van componenten en hun licenties, als bijlage |
| Garanties | Dat je bureau de rechten heeft, en wat je over werking belooft |
| Aansprakelijkheid | Maximum, uitsluiting van gevolgschade |
| Duur en einde | Opzegging, ontbinding bij wanbetaling, wat er met de code gebeurt na afloop |
| Recht en forum | Nederlands recht, bevoegde rechter of arbitrage |
Twee artikelen bepalen of de deal later standhoudt: de licentieverlening en de garantie over de rechten. Daar gaan de volgende secties over.
Hoe omschrijf je wat de licentienemer mag?
Zo precies mogelijk. Een licentienemer krijgt wat er staat, en bij twijfel wordt het een discussie over wat partijen bedoelden. Noem de handelingen één voor één:
- De software gebruiken in de eigen organisatie.
- De broncode aanpassen en uitbreiden.
- De software inbouwen in een eigen product.
- Dat product leveren aan eigen klanten, alleen in uitvoerbare vorm of ook met broncode.
- Sublicenties geven, en aan wie.
Zet erbij wat expliciet niet mag. Een veelgebruikte grens: de licentienemer mag de code inbouwen, maar mag hem niet als losse bibliotheek of als concurrerend product verkopen.
Wat kun je in een licentie niet verbieden?
De Auteurswet geeft wie de software rechtmatig gebruikt een paar rechten die je in de overeenkomst niet kunt wegschrijven:
- Laden, in beeld brengen en fouten verbeteren kun je niet bij overeenkomst verbieden (artikel 45j Auteurswet).
- Een reservekopie maken mag als dat nodig is voor het beoogde gebruik (artikel 45k Auteurswet).
- Waarnemen, bestuderen en testen van de werking mag wie de software mag gebruiken (artikel 45l Auteurswet).
- Decompileren voor interoperabiliteit mag onder strikte voorwaarden, en de verkregen informatie mag niet worden gebruikt voor een programma dat in wezen gelijk is (artikel 45m Auteurswet).
De Europese softwarerichtlijn maakt elk beding nietig dat ingaat tegen de reservekopie, het bestuderen en testen of het decompileren voor interoperabiliteit (artikel 8 Richtlijn 2009/24/EG). Schrijf de beperkingen in je licentie dus rond deze rechten heen.
Welke garantie geef je over de rechten?
De licentienemer wil horen dat je bureau de rechten heeft en dat niemand anders er later aanspraak op maakt. Dat is redelijk, en het is ook de garantie die je het makkelijkst kunt schenden zonder het te weten.
Geef de garantie alleen als je dossier compleet is:
- arbeidsovereenkomsten van de ontwikkelaars die eraan werkten (de werkgever geldt als maker, artikel 7 Auteurswet);
- schriftelijke overdrachtsovereenkomsten en aktes van elke zzp’er (artikel 2 lid 3 Auteurswet);
- het klantcontract, waaruit blijkt dat het IE niet aan de klant is overgedragen;
- een lijst van open source componenten met hun licenties.
Ontbreekt er iets, regel het dan eerst. Een akte van een zzp’er kun je achteraf nog laten tekenen. Een clausule die zegt ‘voor zover licentiegever bekend’ helpt je weinig als een koper due diligence doet.
Algemene voorwaarden of een eigen overeenkomst?
Veel bureaus werken met algemene voorwaarden, vaak de NLdigital Voorwaarden. Die bevatten een licentieregeling voor wat je levert. Voor een losse broncodelicentie zijn ze meestal te algemeen.
| Algemene voorwaarden | Eigen licentieovereenkomst | |
|---|---|---|
| Past bij | Standaardproduct, veel klanten | Broncodelicentie, één bedrijf |
| Exclusiviteit | Meestal niet geregeld | Per deal afgesproken |
| Vergoeding | Staat in de offerte | Staat in de overeenkomst zelf |
| Risico | Vernietigbaar als je ze niet goed ter hand stelt | Geen informatieplicht, partijen tekenen de tekst |
Gebruik je algemene voorwaarden, stel ze dan voor of bij het sluiten ter hand of stuur ze elektronisch mee (artikel 6:234 BW). Een rechtspersoon die zijn jaarrekening openbaar maakt, of een bedrijf waar 50 of meer mensen werken, kan zich niet op deze vernietigingsgronden beroepen (artikel 6:235 BW). Een kleine klant zonder openbare jaarrekening wel.
Hoe spreek je de vergoeding af?
Er zijn vier gangbare vormen. Je kunt ze combineren.
| Vorm | Werkt goed bij |
|---|---|
| Eenmalige licentiefee | Broncodelicentie op een vaste versie |
| Jaarlijkse fee | Licentie met updates en support |
| Per gebruiker of installatie | Productlicentie |
| Royalty op omzet | Licentienemer bouwt het in een eigen product |
Royalty’s uit software die je bv zelf heeft ontwikkeld, kunnen onder de innovatiebox vallen (Wet Vpb 1969, art. 12b en verder), mits er een S&O-verklaring voor het ontwikkelwerk is. Wat de code in de markt waard is, lees je op wat is code waard.
Wat gebeurt er met de licentie als een van beide partijen stopt?
Leg vast wat er gebeurt na opzegging of ontbinding. Beide kanten willen op drie punten zekerheid:
- of de licentienemer de software mag blijven gebruiken in producten die al bij klanten draaien;
- of de broncode wordt teruggegeven of vernietigd, en wie dat bevestigt;
- welke betalingen na het einde nog openstaan.
Voor de licentienemer speelt het omgekeerde risico: dat jouw bureau verdwijnt. Daarvoor bestaat broncode-escrow. Vraagt een licentienemer erom, dan is dat een teken dat hij de deal serieus neemt.
Waar begin je?
- Kies de code die je in licentie wilt geven en controleer het eigendomsdossier.
- Haal klantdata, sleutels en klantnamen uit de repo.
- Maak de lijst van open source componenten. GPL-code kan je licentie beperken, zie MIT en GPL licentie.
- Bepaal exclusief of niet-exclusief, en de grenzen.
- Laat de code waarderen voordat je een prijs noemt.
- Laat de overeenkomst door een jurist nakijken voordat je tekent.