Je kunt broncode verkopen als het auteursrecht aantoonbaar bij je bureau ligt: arbeidsovereenkomsten voor werk van werknemers, overdrachtsaktes van zzp’ers en klantcontracten zonder overdracht. De koper wordt eigenaar via een schriftelijke overeenkomst en een akte (artikel 2 lid 3 Auteurswet). Daarna is de code van de koper: je bureau mag hem alleen nog gebruiken als je een licentie terug afspreekt.
Verkopen loont vooral voor code die je zelf niet meer inzet, zoals een stilgelegd product of een tool die je hebt vervangen. Code die je zelf blijft gebruiken, kun je beter in licentie geven.
Wanneer verkoop je en wanneer geef je in licentie?
| Verkoop | Licentie | |
|---|---|---|
| Wat gaat over | Het auteursrecht | Een gebruiksrecht |
| Opbrengst | Eén keer, meestal hoger | Per licentie, kan vaker |
| Mag je de code zelf nog gebruiken | Alleen met licentie terug | Ja |
| Vorm | Schriftelijk plus akte | Exclusief schriftelijk, niet-exclusief vormvrij |
| Past bij | Stilgelegde producten, code buiten je kernwerk | Componenten en tools die je zelf gebruikt |
Welke code kun je verkopen?
Alleen code uit de stapel ‘duidelijk van het bureau’:
- Geschreven door werknemers in dienst (artikel 7 Auteurswet), of door zzp’ers die schriftelijk hebben overgedragen.
- Niet overgedragen aan een klant.
- Zonder klantdata, sleutels, wachtwoorden of klantspecifieke logica.
Weet je het niet zeker, begin dan bij wie is eigenaar van de code.
Wat controleert een koper?
Een serieuze koper doet een due diligence op de code. Reken op deze vragen:
- Eigendomsketen. Wie heeft eraan gewerkt? Zijn alle zzp’ers en onderaannemers gedekt met een overdracht? Een gat hier drukt de prijs of blokkeert de deal.
- Open source. Welke componenten zitten erin en onder welke licentie? Permissieve licenties zoals MIT zijn meestal geen probleem. Copyleft-licenties zoals GPL kunnen voorwaarden opleggen aan hoe de koper de code mag verspreiden.
- Kwaliteit. Tests, documentatie, een commitgeschiedenis die laat zien hoe de code is gegroeid, een build die werkt op een schone machine.
- Geheimen en data. Sleutels in oude commits, testdata met echte persoonsgegevens, klantnamen in comments. Schoon dit op voordat iemand het ziet.
- Afhankelijkheden van je bureau. Interne services, privé-packages, infrastructuur die alleen bij jou draait. Een koper wil code die zonder jou werkt.
Hoe bereid je een verkoop voor?
- Kies de repo. Begin met één, liefst iets dat werkt en een duidelijk doel heeft.
- Check de eigendom. Contracten en overdrachtsaktes bij elkaar zoeken. Ontbreekt er een, vraag die alsnog op.
- Schoon op. Klantdata, sleutels en klantnamen eruit. Herschrijf de geschiedenis als er geheimen in oude commits staan.
- Maak een licentieoverzicht. Elk open source pakket met zijn licentie.
- Schrijf een korte README. Wat doet het, hoe draai je het, wat is de stack.
- Laat het waarderen. Met een waardering in de hand onderhandel je anders.
Wat staat er in de koopovereenkomst?
- Precieze omschrijving van wat overgaat: repo’s, versies, documentatie, eventueel domeinnamen of merken.
- De overdracht van het auteursrecht, met de bevoegdheden expliciet genoemd, en de akte van levering.
- Een eventuele licentie terug voor je bureau.
- Garanties over eigendom en over open source, met een plafond op de aansprakelijkheid.
- Overdracht van kennis: hoeveel uur ondersteuning na de verkoop, tegen welk tarief.
- Prijs en betaling, eventueel in termijnen of met een deel afhankelijk van gebruik.
Hoe wordt de opbrengst belast?
Verkoopt een bv code, dan valt de winst onder de vennootschapsbelasting (Wet Vpb 1969). Heeft je bv de software zelf ontwikkeld met een S&O-verklaring, dan kan de verkoopwinst volgens RVO onder de innovatiebox vallen.
Wat is de code waard?
De prijs hangt af van wie de koper is en wat het hem bespaart:
- hij hoeft de code niet zelf te bouwen;
- hij is maanden eerder op de markt.
Bandbreedtes en de factoren die de waarde bepalen, staan op wat is code waard.