Aandachtspunten bij het gebruik van OSS in softwareontwikkelingsovereenkomsten

Open Source Software (OSS) wordt veel gebruikt in softwareontwikkelingsprojecten als een middel om ontwikkelingskosten en tijd te besparen. Wanneer softwareontwikkeling wordt uitbesteed, kan het voorkomen dat er gebruik wordt gemaakt van OSS, maar wat zijn de aandachtspunten bij het sluiten van een ontwikkelingscontract in dergelijke gevallen?

In dit artikel bespreken we de aandachtspunten bij het gebruik van OSS in softwareontwikkelingscontracten onder Japans recht.

Risico’s van OSS-gebruik bij het uitbesteden van softwareontwikkeling in Japan

Wanneer u een contract aangaat voor het uitbesteden van softwareontwikkeling, moet u adequaat reageren op de risico’s die het gebruik van Open Source Software (OSS) met zich meebrengt. Laten we bekijken welke risico’s dat kunnen zijn.

Verplichting tot openbaarmaking van broncode kan in strijd zijn met NDA’s

Binnen OSS bestaan er copyleft-licenties die, terwijl de OSS-ontwikkelaars hun auteursrechten behouden, gebruikers de vrijheid geven om het werk te kopiëren, wijzigen en redistribueren. Een voorbeeld hiervan is de GNU General Public License (GPL), opgesteld door de Free Software Foundation (FSF).

Wanneer u OSS met een dergelijke copyleft-licentie gebruikt, kan de OSS-licentie vereisen dat u de broncode openbaar maakt. Dit kan leiden tot een verplichting om de broncode van het gehele uitbestede werk openbaar te maken, wat in strijd kan zijn met contractuele geheimhoudingsverplichtingen (NDA’s) of een gesloten commercieel aanbodbeleid. Daarom is het essentieel om de licenties van de gebruikte OSS zorgvuldig te controleren bij het uitbesteden van softwareontwikkeling.

Verplichting tot bijvoegen van auteursrechtvermeldingen en licentiedocumenten

Zelfs bij licenties zoals MIT en Apache is het verplicht om auteursrechtvermeldingen en licentiedocumenten bij te voegen.

Het verzuimen hiervan kan leiden tot een schending van de OSS-licentie, wat kan resulteren in het stopzetten van het gebruik van de software of claims voor schadevergoeding. Bij het leveren van ontwikkelde producten is het noodzakelijk om altijd te zorgen voor het bijvoegen van de bijbehorende documenten.

Speciale voorwaarden zoals gebruikslimieten en licentiecompatibiliteit

Sommige OSS hebben beperkingen op het gebied van gebruikslimieten of licentiecompatibiliteit.

Bijvoorbeeld, de door de EU opgestelde licentie EUPL (European Union Public Licence) staat vervanging door een compatibele licentie toe bij redistributie, maar die compatibele licentie moet wel een van de officieel door EUPL gedefinieerde licenties zijn. Ook bestaan er beperkingen bij de MPL (Mozilla Public License) versie 1.1, opgesteld door de Mozilla Foundation, die het onmogelijk maken om compatibiliteit met andere OSS te behouden.

Bij het selecteren van OSS is het niet alleen noodzakelijk om de inhoud van de licentie te controleren, maar ook om deze af te stemmen op het bedrijfsplan en de verkoopstrategie van het ontwikkelproject om problemen te voorkomen.

Risico op inbreuk op auteursrechten of patentrechten van derden

Zelfs bij OSS kan het voorkomen dat de code inbreuk maakt op auteursrechten of patentrechten van derden. Dit kan bijvoorbeeld het geval zijn bij ongeautoriseerd kopiëren en plakken van code of bij de inmenging van afgeleide werken die niet compatibel zijn met de licentie. Het is noodzakelijk om de softwareontwikkelingspartner niet alleen te laten voldoen aan de licentie, maar ook om een grondig onderzoek naar patentrechten en auteursrechten uit te voeren.

De rollen en verantwoordelijkheden van opdrachtgever en opdrachtnemer moeten duidelijk zijn

In een contract voor softwareontwikkeling kan er een verschil in begrip of verantwoordelijkheidsbereik zijn tussen de opdrachtgever en de opdrachtnemer met betrekking tot OSS.

In het bijzonder, als het niet duidelijk is vastgelegd wie verantwoordelijk is voor het onderzoeken van licenties en het bevestigen van compliance, of wie verantwoordelijk is bij problemen, kan dit leiden tot geschillen in een later stadium.

Voorbeelden van problemen met OSS in Japan

Laten we voorbeelden bekijken van problemen met Open Source Software (OSS) en wat er kan gebeuren als softwareontwikkeling wordt uitbesteed.

Bekende inbreukgevallen binnen en buiten Japan

In het verleden zijn er gevallen geweest waarin bedrijven door schendingen van OSS-licenties betrokken raakten bij rechtszaken en zelfs gedwongen werden om de verzending van producten te stoppen. Bijvoorbeeld, een routerontwikkelingsbedrijf werd aangeklaagd wegens schending van de GPL-licentie en kreeg een verkoopverbod en schadevergoeding opgelegd.

In soortgelijke gevallen waarbij softwareontwikkeling is uitbesteed, kan het bedrijf dat de opdracht heeft gegeven de geleden verliezen door verkoopstops en schadevergoedingen verhalen op de opdrachtnemer.

Gerelateerd artikel: Wat is een OSS-licentieschending? Risico’s en maatregelen die bedrijven moeten kennen, uitgelegd aan de hand van voorbeelden[ja]

Juridische en zakelijke verliezen veroorzaakt door OSS-licentieschendingen

OSS-licentieschendingen leiden niet alleen tot juridische verantwoordelijkheden zoals een verbod op gebruik en schadevergoedingen, maar ook tot zakelijke verliezen zoals reputatieschade en het verlies van klanten. Juridische claims tegen de opdrachtnemer zijn niet altijd voldoende om deze verliezen te dekken, dus het is essentieel om dergelijke schendingen te vermijden.

Essentiële Clausules voor Softwareontwikkelingsovereenkomsten in Japan

Bij het opstellen van een softwareontwikkelingsovereenkomst in Japan, is het belangrijk om rekening te houden met de risico’s van het gebruik van Open Source Software (OSS) en de volgende clausules op te nemen:

Clausule voor de expliciete vermelding en goedkeuring van OSS-gebruik

In de softwareontwikkelingsovereenkomst moet expliciet vermeld worden dat er mogelijk OSS gebruikt zal worden, en voorafgaande goedkeuring van de opdrachtgever verkregen worden.

Wanneer het gebruik van OSS tot problemen kan leiden, is het noodzakelijk om hier in de overeenkomst op voorhand afspraken over te maken. Door duidelijk te specificeren welke OSS en in welke mate gebruikt zal worden in de softwareontwikkelingsovereenkomst, kunnen misverstanden of geschillen tussen opdrachtgever en opdrachtnemer voorkomen worden.

Clausules voor verdeling van verantwoordelijkheden (niet-naleving van het contract, schadevergoeding, etc.)

Het is essentieel om duidelijk te maken hoe de verantwoordelijkheden verdeeld worden in het geval van een licentieovertreding of inbreuk op rechten.

Bijvoorbeeld, als de ontwikkelde software niet de gevraagde functionaliteiten bevat, kan de opdrachtnemer aansprakelijk gesteld worden voor niet-naleving van het contract. Als er sprake is van een licentieovertreding of inbreuk op rechten en er geen afspraken zijn gemaakt over wie verantwoordelijk is, kunnen er geschillen ontstaan tussen opdrachtgever en opdrachtnemer. Het is belangrijk om in de overeenkomst vast te leggen wie aansprakelijk is voor schadevergoeding als de opdrachtnemer OSS zonder toestemming gebruikt, of wat de verantwoordelijkheden zijn als de opdrachtgever OSS heeft aangewezen. Voor meer informatie over niet-naleving van het contract, zie “Wat houdt aansprakelijkheid voor niet-naleving van een systeem- of softwareontwikkelingscontract in? Uitleg over de wijzigingen[ja]“.

Clausules betreffende het onderzoek naar en de naleving van de gebruikte licenties

In de softwareontwikkelingsovereenkomst moet de opdrachtnemer verplicht worden om onderzoek te doen naar en zich te houden aan de licenties van de gebruikte OSS.

Als het gebruik van OSS de oorzaak is van een geschil, en het is niet duidelijk wiens verantwoordelijkheid het is om onderzoek te doen naar en de licenties na te leven, kan dit leiden tot conflicten tussen opdrachtgever en opdrachtnemer. Door in de overeenkomst vast te leggen dat de opdrachtnemer verantwoordelijk is voor het onderzoek en de naleving, kan de verantwoordelijkheid bij eventuele problemen duidelijk worden vastgesteld en kunnen geschillen voorkomen worden. Ook is het verstandig om een informatieplicht op te nemen voor wijzigingen in licenties of kwetsbaarheidsrapporten, zodat de afhandeling na levering soepel verloopt.

Verduidelijking van de reikwijdte van de broncode-openbaarmaking en de vorm van levering

Het is belangrijk om duidelijk te maken welke delen van de broncode geleverd worden en hoe de OSS-onderdelen gescheiden worden van de eigen ontwikkelde onderdelen.

Door duidelijk te maken welke delen van de broncode openbaar gemaakt en geleverd moeten worden, kan men voldoen aan de openbaarmakingsverplichtingen die nodig zijn voor naleving van OSS-licenties en tegelijkertijd de vertrouwelijkheidsverplichtingen in acht nemen, waardoor juridische overtredingen en geschillen voorkomen kunnen worden. In het geval van copyleft kan het bijvoorbeeld nodig zijn om OSS-onderdelen in binaire vorm te leveren, wat praktische oplossingen vereist.

Praktische Maatregelen bij het Gebruik van OSS onder Japans Recht

Wanneer u Open Source Software (OSS) gebruikt bij softwareontwikkeling, zijn er praktische maatregelen nodig zoals het vooraf opstellen van een lijst met geplande OSS en het nauwkeurig beoordelen van licenties, het inrichten van OSS-beheertools en -registers, en het opstellen van OSS-gebruiksbeleid en -richtlijnen.

Vooraf opstellen van een lijst met geplande OSS en het nauwkeurig beoordelen van licenties

Voor aanvang van de softwareontwikkeling is het belangrijk om alle geplande OSS grondig te inventariseren en de licentievoorwaarden nauwkeurig te beoordelen. Dit maakt het mogelijk om potentiële risico’s te voorspellen en maakt het makkelijker om hierop te reageren.

Inrichten van OSS-beheertools en -registers

Bij het gebruik van OSS is het aan te raden om beheertools en registers voor OSS in te voeren om het gebruik van OSS inzichtelijk te maken en te documenteren. Door het creëren van een Software Bill of Materials (SBOM) kunt u snel reageren op eventuele licentiewijzigingen of het ontdekken van kwetsbaarheden.

Opstellen van OSS-gebruiksbeleid en -richtlijnen

Door op bedrijfs- of projectniveau een OSS-gebruiksbeleid te formuleren, kunt u consistente instructies geven aan uitbestedingspartners. Het documenteren van selectiecriteria voor OSS en beleid voor het omgaan met verschillende licenties maakt het makkelijker om tijdens softwareontwikkeling te reageren.

De Noodzaak om een Advocaat te Raadplegen bij Softwareontwikkelingscontracten in Japan

Wanneer u een softwareontwikkelingscontract aangaat dat gebruikmaakt van Open Source Software (OSS) in Japan, is het raadzaam om vooraf een advocaat te raadplegen. Laten we eens kijken welke specifieke voordelen dit kan bieden.

Risicoanalyse en -beheer vanaf de Ontwikkelingsfase

Zoals tot nu toe besproken, brengt softwareontwikkeling met OSS in Japan complexe juridische vraagstukken met zich mee, zoals welke OSS te gebruiken, welke clausules in het contract op te nemen en hoe het controlemechanisme na het contract op te zetten. Door een advocaat te raadplegen, kunt u een passend softwareontwikkelingscontract opstellen.

De Juridische Afdeling Uitbesteden

Grote bedrijven hebben vaak een eigen juridische afdeling die samenwerkt met de ontwikkelingsafdeling. Echter, bij kleinere bedrijven ontbreekt zo’n afdeling vaak. Gezien het zeer moeilijk is om personeel te vinden dat zowel in IT als in recht gespecialiseerd is, biedt het uitbesteden van de juridische afdeling een aanzienlijk voordeel.

Samenvatting: Aandachtspunten bij softwareontwikkelingscontracten die gebruikmaken van OSS in Japan

Wanneer u Open Source Software (OSS) benut in softwareontwikkelingscontracten in Japan, is een nauwkeurig begrip van de licentievoorwaarden en een duidelijke verdeling van verantwoordelijkheden in het contract essentieel. Zorg voor een grondig risicobeheer vanuit technisch, juridisch en zakelijk oogpunt, niet alleen voor het technische gemak, en streef naar een veilig en effectief gebruik van OSS.

Maatregelen van ons kantoor

Monolith Advocatenkantoor is een juridische firma met een hoge mate van specialisatie in IT, en in het bijzonder internetrecht. Wij bieden contractcreatie en -review voor een breed scala aan cliënten, variërend van beursgenoteerde bedrijven in Japan tot startende ondernemingen. Voor meer informatie over het opstellen en beoordelen van contracten, zie het onderstaande artikel.

Expertisegebieden van Monolith Advocatenkantoor: Contractcreatie en -review[ja]