API-licentieovereenkomsten opstellen

API’s worden veel gebruikt in de softwarewereld om eenvoudige communicatie tussen applicaties mogelijk te maken. Het aanbieden van een API maakt bredere aanpassing van je bestaande applicatie mogelijk, via integraties van derden. Aan de andere kant kun je ook zelf gebruik maken van externe API’s om te integreren met andere applicaties. Stel de verwachtingen van ontwikkelaars in je API-licentievoorwaarden en analyseer de licentiereikwijdte van eventuele API-voorwaarden van derden.

Quid API?

Een API kan worden beschreven als een interface of communicatieprotocol tussen verschillende delen van een computerprogramma, bedoeld om de implementatie en het onderhoud van software te vereenvoudigen. Een API (application programming interface) kan bedoeld zijn voor een webgebaseerd systeem, besturingssysteem, databasesysteem, computerhardware of softwarebibliotheek. [Applicatieprogrammeerinterface. (SD). 10 13 2020, Wikipedia].

In eenvoudige bewoordingen fungeert het als een interface om eenvoudige communicatie met je applicatie mogelijk te maken. API’s worden in de praktijk veel gebruikt om ontwikkelaars van derden gemakkelijk toegang te geven tot bijvoorbeeld data van een bestaand platform of applicatie om hun eigen applicaties te bouwen of communicatie met bestaande applicaties mogelijk te maken. Een API kan communiceren met lokale software of een cloudapplicatie.

Auteursrecht of niet auteursrechten?

Een nogal saaie vraag is of een API zelf mogelijk beschermd is door auteursrecht? Als dit het geval is, kun je eenvoudig actie ondernemen tegen het kopiëren van je API-code. Dit is echter minder relevant voor praktische API-licenties, omdat de mogelijkheid om voorwaarden te dicteren grotendeels betrekking heeft op het vermogen om toegang tot de API te bieden, in plaats van het auteursrecht. Je kunt bijvoorbeeld toegang tot je API afhankelijk maken van het hebben van een ontwikkelaarsaccount op je systeem.

EU-concept van functinaliteit

Volgens EU-jurisprudentie is alleen een uitdrukking van de computersoftware beschermd door auteursrecht (d.w.z. de code). Verder wordt gespecificeerd dat noch de functionaliteit van een computerprogramma, noch de programmeertaal noch het formaat van databestanden die in een computerprogramma worden gebruikt om bepaalde functies te exploiteren, vormen een vorm van uitdrukking van dat programma en zijn als zodanig niet beschermd door auteursrecht in computerprogramma’s voor de doeleinden van die richtlijn. [EJJ, 2 mei 2012, C-406/10, ECLI:EU:C:2012:259, SAS]. Sommige wetenschappers zouden beweren dat alleen functionaliteit wordt geleverd door een API en daarom niet gerelateerd kan zijn aan intellectuele eigendomslicenties.

Amerikaanse jurisprudentie

In de VS behandelt de zaak Oracle America, Inc. tegen Google Inc specifiek de vraag van auteursrechtinbreuk op een API. Oracle stelde dat Google het auteursrecht op zijn Java API had geschonden door delen van de geïmplementeerde ‘methoden’ te kopiëren, dat wil zeggen de verklaringen, en de algemene structuur van de API (klassen en pakketten) opnieuw over te nemen, maar de implementerende code die Google schreef was heel anders. Zonder verder in details te treden, loopt de zaak momenteel bij het Amerikaanse Hooggerechtshof.

Daarom is er discussie of het leveren van API-functionaliteit kan worden gezien als ‘intellectueel eigendom’ -licentie [‘auteurscontract’], of eerder als een ‘dienstenovereenkomst’ [Work for hire/’aanneming van werk’: “Werk huren is een contract waarbij een partij zich verbindt iets voor de ander te doen, tegen betaling van een tussen hen afgesproken prijs.” (art. 1710 Belgische Burgerlijke Wetboek)] en als zodanig meer lijkt op een SaaS-overeenkomst. Desalniettemin worden deze overeenkomsten doorgaans aangeduid als ‘licenties’.

API-licentieovereenkomsten

Zaken om in gedachten te houden

Overweeg zorgvuldig de scope van de API-licentie; dit omvat of ontwikkelaars alleen de API kunnen bevragen of ook applicaties (website/dienst) kunnen bouwen met jouw API? En zo ja, welke soorten applicaties kunnen worden gebouwd: bijvoorbeeld applicaties uitsluitend voor intern gebruik, applicaties die dienen als tools voor derden maar NIET zakelijke of grootschalige toepassingen, …

Er is een risico dat ontwikkelaars je API gebruiken om applicaties te bouwen die kunnen concurreren met of simpelweg dupliceren. Stel de regels duidelijk uiteen, want ontwikkelaars kunnen op deze informatie vertrouwen voor hun zakelijke beslissingen (en daarmee voor toekomstige inkomsten).

Tot slot kan zo’n derde partij uw informatie/gegevens, beschikbaar via de API, verkeerd weergeven , wat uw reputatie mogelijk schaadt.

Inhoud van een API-licentieovereenkomst

Het doel van een API-overeenkomst is om klanten en/of externe ontwikkelaars het recht te geven om uw API te gebruiken. Dit kan onder meer omvatten:

  • waarbij de verantwoordelijkheden van ontwikkelaars worden beschreven bij het gebruik van de API en met betrekking tot applicaties, ontwikkelt deze zich om te koppelen aan de API
  • grenzen stellen aan welke soorten applicaties ontwikkelaars met de API kunnen bouwen. (Opmerking: rekening houden met mogelijke eisen van het mededingingsrecht)
  • het reguleren van hoe de output (volgorde, lay-out, …) van de door de klant ontwikkelde applicatie, met behulp van de API, moet worden weergegeven
  • waarin wordt beschreven hoe ontwikkelaars toegang hebben tot en gebruik kunnen maken van de API, bijvoorbeeld met een API keny
  • Specificeren hoe zulke ontwikkelaars hun applicaties aan uw klanten kunnen aanbieden . (Bijvoorbeeld via je platform of webwinkel)
  • het reguleren hoe dergelijke ontwikkelaars uw handelsmerken mogen gebruiken om hun applicaties via de API te presenteren. (Of het nu deel uitmaakt van of verwijst naar volledige richtlijnen voor het gebruik van merken.)

IFORI kan u helpen bij het opstellen van uw eigen API-licentieovereenkomst of gerelateerde IT-overeenkomsten. Of bekijk eventuele API-licentievoorwaarden die door derden zijn verstrekt bij het ontwikkelen van je eigen integraties.


Projecten

Belgisch bedrijf (voeding) – Ad interim inhouse counsel (IP/IT/Media)

Lees meer Arrow