Ga er maar aanstaan als deskundige: moet die broncode opnieuw geschreven?

| AE 12312 | Ondernemingsvrijheid | 40 reacties

Deskundige vereist voor beoordeling gebrekkige broncode, meldde ITenRecht onlangs. In een automatiseringsgeschil tussen softwareontwikkelaar Capgemini en haar klant Equihold (die de software wilde inzetten bij onder meer FC Barcelona) ontstond discussie over de kwaliteit van de tot dan toe gemaakte broncode. Een mooi voorbeeld van hoe de rechtspraak omgaat met inhoudelijk diepgaande issues. Ik las laatst weer dat rechters moeten leren programmeren omdat ze anders dit soort zaken niet kunnen doen. Onzin, wat mij betreft. Daar heb je deskundigen voor. Maar bij deze zaak denk ik dan wel, blij dat ik die deskundige niet ben.

In 2002 ontwikkelde Equihold een sportapplicatie met de naam 1-2 Focus. Deze applicatie was geschreven in de programmeeromgeving en programmeertaal VB6. In 2004 besloot men deze om te werken naar Microsoft .NET, waarna men in 2005 een raamovereenkomst sloot met Capgemini om het werk te laten doen. Ik zal u de verdere tijdlijn besparen, maar in 2010 eindigde het feest met een brief aan Capgemini met als titel “1-2Focus; developed by Capgemini A Showcase of Bad Practices”.

Wat was er nu precies aan de hand met die broncode? Helaas is dat in het arrest niet in detail te achterhalen. We moeten het doen met uitspraken als

Volgens [B] , een voormalig werknemer van Equihold, heeft de broncode niet de gewenste laagstructuur, bestaat deze uit onnodig veel regels en is deze onsamenhangend. Zijn conclusie is dat de broncode van zo bedroevende kwaliteit is dat het volledig herschrijven daarvan onvermijdelijk is. SQMI is volgens [appellant] een gerenommeerde en onafhankelijke partij die een onderzoeksmethode gebruikt die is ontwikkeld door het Institute for Software Quality (IfSQ). Het rapport SQMI concludeert dat de broncode een hoog aantal ‘defect indicators’ heeft, dat de onderhoudskosten van de software onnodig hoog zijn en dat de software ongeschikt is als platform voor verdere ontwikkeling. Graham Bolton, oprichter van IfSQ en directeur van SQMI, (verder Bolton) voegt daar in een schriftelijke verklaring aan toe dat het verbeteren van de geconstateerde gebreken meerdere jaren in beslag zou nemen, en zelfs meer tijd zou kosten dan het geheel opnieuw schrijven van de applicatie.

Capgemini kon daar echter een ander rapport tegenover stellen dat juist aantoont dat de onderhoudbaarheid marktconform is.

Dan krijg je dus de situatie dat partijen elkaar tegenspreken, en dat je als rechter dan moet vaststellen wat er nu waar is. In een geval als dit is dat erg lastig, allereerst natuurlijk omdat broncode op kwaliteit toetsen sowieso ingewikkeld is (de een z’n ***var is de ander z’n nachtmerrie) maar ten tweede omdat dit om zo’n grote codebase gaat dat er een hele partij werk in gaat zitten. Oh ja, en omdat er natuurlijk niet echt objectieve standaarden zijn om codekwaliteit vast te stellen.

Een belangrijke factor in het geschil was de onderhoudbaarheid: kun je op lange termijn hiermee door, ook (denk ik) met een andere onderhoudspartij dan Capgemini zelf. Bij grote applicaties is langdurig gebruik te verwachten, dan heb je andere verwachtingen qua onderhoud en aanpasbaarheid voor de toekomst dan bij een snelle app voor een event begin volgend jaar.

Dus, ik gooi hem eens in de groep, voor al die IT-ers die denken dat rechters meer verstand van software nodig hebben: hoe zouden jullie bij deze berg aan code objectief vaststellen of de kwaliteit voldoet aan de contractuele eis van ‘high quality software’?

Arnoud

Wat mag ik met snippets van Stack Overflow?

| AE 11706 | Intellectuele rechten | 17 reacties

Een lezer vroeg me:

Zoals vele ontwikkelaars neus ik vaak op Stack Overflow naar oplossingen voor mijn programmeerproblemen. Ik zie dan vaak broncode die de oplossing implementeert, maar ik weet dat ik die niet zomaar mag copypasten in verband met licentieproblemen. Maar wat mag ik dan wel?

Stackoverflow is de bekendste site voor programmeurs om met elkaar tips, ideeën en oplossingen te delen. Meestal gebeurt dat in de vorm van programmeercode (broncode) omdat dat nu eenmaal de meest exacte en directe manier is om aan te geven hoe je in software een bepaald probleem aanpakt. Die oplossingen zijn vaak relatief kort en worden dan ook wel snippets genoemd.

Op software rust auteursrecht. Je mag dus iemands software niet overnemen, ook niet als hij de broncode publiceert of die broncode ergens neerzet waar het de bedoeling is om erover te praten en er naar te kijken. Alleen als er een licentie bij staat, kun je de software gebruiken – binnen de grenzen van de licentie. Helaas zetten maar weinig SO gebruikers expliciet een licentie bij hun snippets.

Bij snippets kun je dan weer wel je afvragen óf er auteursrecht op rust. Er moet wel iets van creativiteit in het werk zitten. Dat kan bij een kort werk, maar zeker bij software is dat geen automatisme. Een snippet die laat zien hoe een API aangeroepen moet worden, zou ik niet creatief noemen. Dat is alleen “kijk hier moet de sessiesleutel, hier zet je parameters zoals kleur en gewicht en dan krijg je een array terug met de actuele voorraad”. Zo’n snippet heeft geen auteursrecht en daarmee mag je natuurlijk doen wat je wil.

Helaas is zodra je boven dergelijke trivialiteiten gaat het al snel onduidelijk. Er zijn geen juridische vuistregels zoals dat tot tien regels code vrij van rechten zijn. Zo werkt auteursrecht gewoon niet. Je moet dan inhoudelijk je afvragen of dit iets creatiefs is of ‘gewoon’ zoals je het zou doen. Dertig regels code met hoe een quicksort werkt zou ik niet creatief noemen (dat is nu eenmaal grofweg een standaard algoritme) maar 5 regels om snel een matrix te scannen is vaak juist héél creatief.

Wat natuurlijk wel altijd mag, is het idéé dat men je communiceert met zo’n snippet overnemen en in eigen code verwerken. Ideeën, principes en algoritmes vallen buiten het auteursrecht en mogen dus vrij worden gebruikt. Dat doe je dan dus door eerst in eigen woorden (of pseudocode) op te schrijven wat er onder die geposte broncode zit, en daarna dat in echte code uit te werken in je eigen applicatie.

Arnoud

Moeten we echt elk jaar de copyrightvermelding in onze broncode updaten?

| AE 9248 | Intellectuele rechten | 23 reacties

Een lezer vroeg me:

Alle broncodes binnen ons bedrijf hebben een copyrightvermelding, als volgt:
Copyright © 2016 $NAAM
THIS SOURCE CODE IS THE UNPUBLISHED AND CONFIDENTIAL PROPERTY OF $NAAM<
AND MAY NOT BE COPIED, MODIFIED OR DISTRIBUTED WITHOUT PRIOR WRITTEN AUTHORIZATION.
(Iets ingekort in verband met leesbaarheid.) Nu moet ik al die notices aanpassen want het is 2017. Kan dat echt niet anders?

Vrijwel alle broncode heeft een copyright notice, maar juridisch is dat eigenlijk nergens voor nodig. Heel formeel bestaat een copyrightvermelding uit drie elementen, in deze volgorde:

  • Het woord "copyright", de afkorting "copr." of het C-in-een-cirkel symbool ©. Allebei is dus eigenlijk dubbelop, en wie "(C)" doet is eigenlijk fout bezig.
  • Het jaar van eerste publicatie van het werk. Als het gaat om een aangepaste versie, dan moeten de jaren van elke wijziging ook worden vermeld. Zo geeft "1985, 1987-1989" bijvoorbeeld aan dat het werk gemaakt is in 1985 met wijzigingen in 1987, 1988 en 1989. Onze vraagsteller hoeft dus niet álle bestanden aan te passen, maar alleen bij de eerste wijziging in 2017 dat jaar toe te voegen.
  • De naam van de auteur. Dit mag een afkorting of pseudoniem zijn, zolang de auteur maar te identificeren is. In dit geval mag de statutaire naam worden gevoerd, of een andere handelsnaam die het bedrijf gebruikt.

Het punt is alleen dat geen enkele wet een copyrightvermelding eist als voorwaarde om auteursrecht te hebben op die software. Auteursrecht ontstaat namelijk enkel door het werk te maken, ongeacht wat er bij staat aan naams- of copyrightvermeldingen.

In de VS was het tot 1978 wél verplicht om zo'n vermelding te doen, anders was je werk niet beschermd. Maar juristen zijn een conservatief stel mensen, en bovendien het stáát heel juridisch dus laten we het maar doen. Cargo culting dus. Hetzelfde geldt voor all rights reserved.

Een naamsvermelding van de rechthebbende is natuurlijk wel zo handig, en een waarschuwing dat zonder licentie deze broncode niet mag worden verspreid kan ook geen kwaad. (Alleen graag zonder hoofdletters, dat leest beter.) Het is dus prima om vanaf nu "Copyright $NAAM" zonder jaartal te doen, dan hoef je er nooit meer aan te komen (tenzij je de auteursrechten verkoopt uiteraard.)

Arnoud

Mag je software reverse engineeren om fouten te vinden?

| AE 8023 | Intellectuele rechten, Security | 31 reacties

Een lezer vroeg me: Is reverse engineering legaal als het doel is om beveiligingslekken te vinden? Jij zei ooit van wel, maar in de wet staat volgens mij dat je alleen mag reverse engineeren om compatibiliteit te realiseren. Oef, dat is lang geleden, maar inderdaad: Alleen die vormen waarmee je compatibiliteit met zelfgeschreven software wilt… Lees verder

Schendt HTC de GPL door broncode vertraagd te publiceren?

| AE 2269 | Intellectuele rechten | 29 reacties

Een lezer wees me (dank!) op een bericht bij Freedom to Tinker waar werd gesignaleerd dat de Android-gebaseerde HTC smartphone Linux draait, maar de broncode maar moeizaam beschikbaar komt. Linux is open source (GPL versie 2) en de broncode moet dus meegeleverd worden (of er moet een schriftelijk aanbod bij zitten waar staat waar je… Lees verder