Een voormalige IT-ingenieur en advocaat legt de overeenkomsten uit tussen het controleren van contracten en debuggen

De kern van het werk van de zogenaamde ‘bedrijfsadvocaat’ is het controleren en aanpassen van contracten die het bedrijf dagelijks sluit met klanten en zakelijke partners. En deze controles en aanpassingen kunnen alleen adequaat worden uitgevoerd door iemand die zowel bekend is met de wet als met het betreffende vakgebied. Ik zal uitleggen waarom dit zo is.

Echter, de volgende uitleg kan moeilijk te begrijpen zijn voor mensen zonder ervaring in engineering of programmeren. Monolith Law Office is een advocatenkantoor geleid door een voormalig IT-ingenieur met bedrijfsmanagementervaring. Het is strikt genomen gepositioneerd als een artikel dat contractcontrole en -aanpassing uitlegt, gericht op managers met ervaring in engineering of programmeren, vanuit het perspectief van een advocatenkantoor geleid door een voormalig IT-ingenieur en bedrijfsmanager.

En op basis van deze positionering, is het controleren en aanpassen van contracten een taak die vergelijkbaar is met het zogenaamde ‘debuggen’.

1. Wat is een ‘bug’ in de eerste plaats?
2. Wat houdt ‘debuggen’ in?
3. Hoe definieert een contract een algoritme?
4. Wat houdt het aanpassen van een contract in?

In die volgorde, hoewel het voor ingenieurs ‘vanzelfsprekend’ is, zal ik het hieronder uitleggen.

Wat zijn ‘Bugs’ en ‘Debugging’?

Een ‘bug’ is geen ‘PC-storing’

Wanneer we het over een ‘bug’ hebben, kan het zijn dat sommigen van u zich een situatie voorstellen waarin uw PC tijdens het werken rook begint uit te stoten en het scherm vreemde weergaven toont… Echter, een PC doet in principe alleen ‘wat hem verteld wordt’. Dit geldt ook voor het geval dat er een bug optreedt. Met andere woorden, een ‘bug’ is:

• Wanneer de PC doet wat hem verteld wordt, maar
• Voor de gebruiker is deze actie ‘ongepland gedrag’

Dit is het fenomeen dat we bedoelen.

Waarom treden ‘onverwachte gedragingen’ op?

Laten we bijvoorbeeld eens nadenken over de ‘muurdoorbraak’ bug in een Mario-achtig actiespel.

Mario’s sprong is een kwadratische functie. Versnelling, snelheid, coördinaten. Echter, hoewel het een zogenaamde kwadratische functie is, kan je bijvoorbeeld ‘Wat is Y als X=1.76582?’ vragen en X oneindig fijn verdelen, maar in het geval van videogames kan je de tijd niet oneindig fijn verdelen. Dit komt omdat het scherm slechts (bijvoorbeeld) 30 keer per seconde verandert. Daarom, in zekere zin, ‘teleporteert’ Mario 30 keer per seconde.

In dit verband, als we bijvoorbeeld zeggen ‘Als Mario springt en er is een muur in de lucht, dan stuitert hij terug’, dan betekent dit:

1. Mario was in de lucht een moment geleden
2. Het volgende moment bevinden Mario’s coördinaten zich in de muur

Dit is wat er gebeurt.

In dergelijke gevallen kan men oordelen dat ‘Mario tegen een muur in de lucht botste tijdens zijn sprong’. Daarom, als we het in natuurlijke taal zeggen

Als Mario’s coördinaten zich in de muur bevinden, voer dan de terugstuitprocedure uit (※1)

Als je zo’n programma schrijft, kun je de procedure ‘Als Mario springt en er is een muur in de lucht, dan stuitert hij terug’ realiseren.

※1 lijkt correct zolang het op deze manier wordt geschreven. En inderdaad, onder ‘bepaalde omstandigheden’ is deze procedure correct.

Maar als je er goed over nadenkt, kunnen er ook situaties zoals hieronder voorkomen (※2).

In dit geval bestaat er geen moment waarop ‘Mario’s coördinaten zich in de muur bevinden’, en daarom wordt de terugstuitprocedure niet uitgevoerd, en Mario zal door de muur glippen.

Dit is een voorbeeld van een ‘bug’. Zelfs als een ‘muurdoorbraak bug’ optreedt om deze reden, betekent dit niet dat de PC defect is. De PC voert alleen de opgedragen acties uit, en het is de mens die deze acties beoordeelt als ‘onverwacht’ of ‘bug’. En deze ‘bug’ treedt op omdat het algoritme niet geschikt is.

“Het overwegen van ‘onverwachte gedragingen’

Echter, of de bovengenoemde ‘muurdoorbraak’ daadwerkelijk optreedt tijdens het spelen van het spel, is onduidelijk als we er alleen abstract over nadenken. Of een ‘muurdoorbraak’ kan optreden, hangt af van:

• Hoe sterk is Mario’s sprongkracht (beginsnelheid), zijn er items zoals sprongkrachtverhoging?
• Hoe dik is de muur in het dunste geval?

Dit hangt af van deze voorwaarden. Afhankelijk van of situaties zoals ※2 mogelijk zijn onder deze voorwaarden. Als ※2 niet mogelijk is, dan is er geen probleem met het ※1-programma.

Wat houdt ‘debuggen’ in?

Dus, om ‘debuggen’, oftewel het vinden en corrigeren van bugs, uit te voeren, is het nodig om:

1. Te begrijpen wat voor algoritme het programma is (hoewel de bovenstaande opmerking 1 in natuurlijke taal is, is het in werkelijkheid moeilijk om het te begrijpen omdat het programma in een unieke taal is geschreven)
2. Te overwegen onder welke omstandigheden het programma werkt (onderzoek naar springkracht en muurdikte)
3. Te controleren of er geen onverwacht gedrag optreedt

Dit is dus het proces dat nodig is.

Wat houdt het controleren van contracten in?

Het controleren van contracten lijkt op dit proces. Een contract is in de eerste plaats een document dat de rechten en plichten van de betrokken partijen, partij A en B, regelt in het licht van mogelijke toekomstige gebeurtenissen. Het bepaalt hoe beide partijen zullen handelen als gevolg daarvan. In die zin kan het worden gezegd dat het een ‘programma is dat de echte wereld reguleert’. Bijvoorbeeld,

In het geval dat situatie ●● zich voordoet, zal partij A een vergoeding van 1 miljoen yen betalen aan partij B.

Contracten die dergelijke regels stellen, definiëren de voorwaarden en effecten met betrekking tot toekomstige gebeurtenissen.

Het proces van het controleren of er problemen zijn met dit ‘programma dat de echte wereld reguleert’ en het corrigeren van eventuele problemen, is onvermijdelijk vergelijkbaar met ‘debuggen’.

Het volledige algoritme staat niet in het contract

Er is echter een punt in ‘contracten’ dat moeilijk te begrijpen is voor mensen die geen juridische specialisten zijn, maar uiterst belangrijk is. Een contract bepaalt slechts een ‘deel’ van het algoritme dat de partijen reguleert. Met andere woorden, door alleen het contract te lezen, kun je niet het volledige beeld krijgen van hoe jij en de andere partij gereguleerd worden onder welk algoritme.

Stel bijvoorbeeld dat je een tweedehands CD koopt in een winkel. De winkel en de klant sluiten geen ‘koopovereenkomst’, maar als er een kras op de CD zit die niet kan worden afgespeeld op een speler, wil je klagen bij de winkel en verwacht je dat de winkel daarop zal reageren. Dit is niet alleen een kwestie van ‘het is een dienstverlenende sector’, maar theoretisch gezien,

1. Zelfs zonder een contract is er een koopovereenkomst gesloten
2. De Japanse Burgerlijk Wetboek (Burgerlijk Wetboek) bepaalt dat de verkoper aansprakelijk is voor verborgen gebreken bij de verkoop van specifieke goederen zoals tweedehands CD’s
3. Dus, het algoritme dat door het Burgerlijk Wetboek wordt bepaald, loopt tussen de winkel en de klant, en de winkel is aansprakelijk voor verborgen gebreken

Dit is de redenering. En een ‘contract’ overschrijft het algoritme dat door wetten zoals het Burgerlijk Wetboek wordt gedefinieerd. Bijvoorbeeld, als er een contract is tussen de winkel en de klant dat zegt ‘we accepteren geen claims voor enige gebreken in de CD’s na de aankoop’, dan

1. Er is een koopovereenkomst gesloten
2. Het Burgerlijk Wetboek bepaalt dat de verkoper aansprakelijk is voor verborgen gebreken in het contract
3. Echter, volgens de bepalingen van het contract, wordt het principe van 2 overschreven, en de winkel is niet aansprakelijk voor verborgen gebreken

Dit is de conclusie.

Een contract ‘overschrijft’ de principes van het Burgerlijk Wetboek en dergelijke

Dit geldt ook voor contracten die tussen bedrijven worden gesloten, zoals bij systeemontwikkeling. Als er bijvoorbeeld een contract voor systeemontwikkeling op basis van aanneming is gesloten tussen partij A en B,

1. wordt door het sluiten van het betreffende contract duidelijk dat er een aannemingsovereenkomst is gesloten
2. In het geval van een aannemingsovereenkomst ontstaat er volgens de bepalingen van het Burgerlijk Wetboek een garantieverplichting voor gebreken aan de zijde van de aannemer
3. Als er in het contract een bepaling over de garantieverplichting voor gebreken staat, overschrijft die bepaling het principe van het Burgerlijk Wetboek onder 2. Bijvoorbeeld, als er een clausule voor de garantieverplichting voor gebreken voor een langere periode dan het principe van het Burgerlijk Wetboek is opgenomen, wordt die bepaling voor die periode geldig

Dit is de structuur. Met andere woorden, zelfs als er geen specifieke bepaling over de garantieverplichting voor gebreken in het contract staat, ontstaat er een garantieverplichting voor gebreken.

Dit is niet beperkt tot aanneming of systeemontwikkeling, maar is een algemene theorie over alle contracten die bedrijven aangaan, zoals aandelenoverdracht, fondsenwerving met schulden (geldlening), tewerkstelling, aandelenuitgifte, enz.

Daarom kan je door alleen het contract te lezen, niet het volledige ‘algoritme’ dat de relatie tussen de andere partij en je eigen bedrijf regelt, begrijpen. Om het volledige beeld te begrijpen, moet je het ‘standaard algoritme’ begrijpen dat wordt bepaald door wetten zoals het Burgerlijk Wetboek. Een contract is immers slechts iets dat dit ‘standaard algoritme’ overschrijft.

Zonder het kunnen voorzien van toekomstige gebeurtenissen, is ‘debuggen’ onmogelijk

Alleen het begrijpen van een algoritme is niet voldoende om te verifiëren of er geen onverwachte gedragingen zullen optreden met dat algoritme. Net als bij ‘bugs’ in games, is een algoritme een abstract concept. Zonder te kunnen voorzien welke gebeurtenissen in de toekomst kunnen plaatsvinden, is het onmogelijk om te verifiëren of er geen onverwachte gedragingen zullen optreden wanneer dergelijke gebeurtenissen zich voordoen.

Dit is vooral een belangrijk probleem bij nieuwe producten zoals apps of diensten, of nieuwe bedrijfsmodellen. Als je een bedrijf opzet met dergelijke producten of modellen, moet je je afvragen wat er in de toekomst kan gebeuren. Dit is moeilijk te voorspellen zonder kennis van het betreffende veld. Bovendien, in het geval van contracten tussen bedrijven, zowel het andere bedrijf als het eigen bedrijf handelen onder een bepaalde economische rationaliteit. Daarom is een game-theoretische benadering van bedrijfsbeheer nodig om toekomstige gebeurtenissen en het gedrag van de andere partij dat deze veroorzaakt te voorspellen.

Of iets ‘onverwacht’ is, hangt ook af van managementbeslissingen

Net zoals het een mens is, en niet een PC, die bepaalt of een bepaald fenomeen een ‘bug’ is, is het bepalen of een bepaald gevolg van een contract ‘onverwacht’ is, niet alleen een kwestie van puur juridische aangelegenheden, maar ook een kwestie van managementbeslissingen.

Bijvoorbeeld, het kan realistisch zijn dat een algoritme dat ‘volgens de principes van het Burgerlijk Wetboek (Nederlandse Burgerlijk Wetboek)’ werkt, onaanvaardbaar is voor een bepaald bedrijf in een bepaalde sector. Hoewel dit een afwijking is van de eerdere voorbeelden, stelt het Burgerlijk Wetboek bijvoorbeeld dat het standaard algoritme voor quasi-contracten is dat ‘hercontractering door de contractant een contractbreuk vormt’. Maar er kunnen gevallen zijn waarin ‘voor een bepaald bedrijf, een bepaald project van nature onderaannemers zou gebruiken’. In dergelijke gevallen zou het onmogelijk moeten zijn om een contract te accepteren dat hercontractering onmogelijk maakt, namelijk

• Er is niets specifiek vermeld over de mogelijkheid van hercontractering (in dit geval, zoals hierboven vermeld, worden de principes van het Burgerlijk Wetboek toegepast)
• Het is specifiek vermeld dat hercontractering onmogelijk is

Zelfs als dit ‘volgens de principes van het Burgerlijk Wetboek’ is, zou het onmogelijk moeten zijn om zo’n contract te accepteren.

Bovendien is er altijd een risico in het management dat ‘je verantwoordelijk wordt gehouden als een bepaalde gebeurtenis plaatsvindt’. Er bestaat in principe geen contract dat ‘geen risico’ vormt voor het bedrijf. Of je dit risico accepteert of niet, is uiteindelijk een managementbeslissing. Het zijn de managers die deze managementbeslissingen nemen, niet de adviseurs zoals advocaten, maar de adviseurs moeten voldoende informatie verstrekken om de managers in staat te stellen deze managementbeslissingen te nemen,

• Risico’s die niet specifiek hoeven te worden aangegeven
• Risico’s die, indien geaccepteerd, een belangrijke beslissing vormen voor het betreffende bedrijf en die mogelijk een vergadering of iets dergelijks vereisen

moeten met de nodige nuances worden aangegeven. Net als bij consultants in andere velden, is een zekere mate van ‘management’ gevoel ook nodig voor advocaten die contractcontroles uitvoeren om deze ‘nuances’ in te stellen.

Samenvatting

Zoals u ziet, kan het controleren en aanpassen van contracten in grote lijnen worden beschreven als de volgende taken:

1. Begrijpen hoe de principes van het ‘Japanse Burgerlijk Wetboek’ en dergelijke worden overschreven door het contract, en wat het resultaat is in termen van algoritmen
2. Onderzoeken welke gebeurtenissen in de toekomst kunnen plaatsvinden onder deze algoritmen
3. Onderzoeken of er onverwacht gedrag kan optreden

En elk van deze taken is:

1. Een moeilijke taak tenzij uitgevoerd door iemand die de wet begrijpt
2. Een moeilijke taak tenzij uitgevoerd door iemand die de inhoud van het bedrijf begrijpt, zoals de app of webdienst die het contract reguleert, en het bedrijfsmodel
3. Een moeilijke taak tenzij uitgevoerd door iemand die een zekere mate van begrip heeft van het bedrijf en het zakelijk inzicht

Dit is de reden.

Het controleren en aanpassen van contracten is om deze redenen zeer ‘gespecialiseerd’.

Informatie over contractcreatie en -beoordeling door ons kantoor

Als een advocatenkantoor met expertise in IT, internet en bedrijfsleven, biedt Monolis Law Firm diensten zoals het opstellen en beoordelen van verschillende contracten aan onze klanten en cliënten.

Als u geïnteresseerd bent, bekijk dan zeker de details hieronder.

https://monolith.law/contractcreation[ja]