Veel gebruikte voorwaarden

IT 333

Algemene voorwaarden vaak ten nadele van de consument

Het tijdschrift Bright publiceerde afgelopen vrijdag een onderzoek naar de gebruikersvoorwaarden van enkele bedrijven zoals o.a. Apple, eBay, Facebook, Flickr, Google, Marktplaats en Skype. Hieruit blijkt dat de voorwaarden regelmatig herschreven worden, vaak ten nadele van de consument. Bright stelt dat de voorwaarden in moeilijke juridische taal worden opgeschreven en dat daarom niet duidelijk is wat ze precies inhouden. Bright concludeert kortweg dat door ondertekening van de voorwaarden, de gebruiker afstand doet van al zijn rechten en veel verplichtingen krijgt.

Hierbij de voornaamste conclusies uit het rapport.

1. De voorwaarden worden regelmatig aangepast zonder de gebruiker hierover in te lichten.
2. De aansprakelijkheid van de diensten zelf wordt zoveel mogelijk beperkt.
3. Gekochte applicaties zijn geen eigendom van de gebruiker, deze koopt alleen een licentie voor gebruik, welke kan worden ingetrokken en niet kan worden overgedragen.
4. Garantiemogelijkheden zijn zeer beperkt en er wordt veelvuldig gebruik gemaakt van het koppelen en dataminen van persoonlijke gegevens.
5. Ook wordt privé informatie van gebruikers wordt zonder expliciete toestemming van de gebruiker gebruikt voor financieel gewin en doorgespeeld naar derde partijen waardoor het niet meer controleerbaar is voor de gebruiker.
6. Verder worden vaak de (intellectuele) eigendomsrechten van foto's en video's die de gebruiker uploadt naar de diensten overgeheveld.

Lees het gehele rapport hier (link en pdf).

IT 324

Toepassen van de ARBIT

met dank aan Frank van ’t Geloof, Adriaanse De Meijer Advocaten voor deze bijdrage. Klik voor de pdf hier of lees verder.

De Algemene Rijksvoorwaarden bij IT overeenkomsten (ARBIT) uit 2010 zijn al meerdere malen becommentarieerd. Soms worden ze als tamelijk evenwichtig beschouwd, vooral als ze vergeleken worden met de BiZa modelcontracten die daarvoor gebruikt werden. Soms worden ze echter negatief beoordeeld.

Het is niet zonder meer duidelijk waarvoor de ARBIT nu precies wel en niet zijn bedoeld. Vooral het perspectief van waaruit ze beschouwd worden is van belang bij de beoordeling van de voorwaarden. Daarom wordt hieronder eerst vastgesteld voor welke overeenkomsten de ARBIT toepasbaar zijn. Daarna worden een aantal bepalingen beschouwd binnen het veronderstelde toepassingsgebied.

Toepassingsgebied voor de ARBIT
ARBIT is een acroniem voor “Algemene Rijksvoorwaarden bij IT-overeenkomsten”. Het is dus van toepassing op IT overeenkomsten. Artikel 1 geeft een aantal omschrijvingen van gebruikte begrippen. De definitie van een IT overeenkomst ontbreekt echter. De reikwijdte van de ARBIT is daardoor niet formeel afgebakend. In de toelichting staat hierover:

De ARBIT zijn vooral bedoeld voor modale IT-inkopen door de overheid en niet zozeer voor grote en bijzondere IT-projecten. Dat neemt niet weg dat ze ook dan als uitgangspunt voor het opzetten van een meer specifieke contractuele relatie met de IT markt kunnen dienen. Vanwege de flexibiliteit van de Overeenkomst kan deze veelal ook gebruikt worden bij de inzet van specifieke IT-producten en diensten zoals bijvoorbeeld webhosting of SaaS (software as a service). Een zorgvuldige specifieke omschrijving van zo’n nieuw product of dienst moet dan worden opgenomen in artikel 2 van de Overeenkomst. Daarna kunnen de ARBIT, die zoveel mogelijk techniekonafhankelijk zijn geschreven, ook daarop in beginsel gewoon van toepassing worden verklaard. De combinatie van ARBIT en Overeenkomst kan daarmee een solide basis vormen voor IT -contractering in de komende jaren. Overigens worden dergelijke specifieke IT-diensten vooralsnog niet beschouwd als ‘commodities’ waarvoor de ARBIT in de eerste plaats zijn bedoeld (zie de Algemene inleiding van deze Toelichting). Mocht uit evaluaties van de ARBIT blijken dat dergelijke thema’s hier toch meer specifiek aandacht verdienen, dan zal dat op een later tijdstip alsnog gebeuren.”

 [… ] Voor afwijkingen van de ARBIT of het al dan niet (mede) van toepassing verklaren van andere (algemene) voorwaarden kan slechts in uitzonderingssituaties aanleiding bestaan. Meestal verdient het echter ook dan aanbeveling om de ARBIT wel naast en ter aanvulling op die andere algemene voorwaarden van toepassing te verklaren.[……] [accent toegevoegd]

Uit bovenstaande blijkt dat de ARBIT bedoeld zijn voor ‘commodity’-achtige IT diensten en producten. SaaS diensten (Software as a Service, ofwel ‘cloud computing’) vallen daar vooralsnog niet onder, evenals grote en bijzondere projecten. Om meer te kunnen zeggen over wat in deze context ‘grote en bijzonder projecten’ zijn, moeten de ARBIT nader inhoudelijk worden beschouwd. De ARBIT bestaan uit een algemeen deel en vier specifieke delen. De bedoeling is dat steeds alle delen van toepassing worden verklaard. Het derde deel met bijzondere bepalingen is voor ‘opdrachten’. Daaronder vallen onder meer:
• adviesdiensten
• ontwikkeling maatwerkprogrammatuur
• leiding geven aan IT projecten.
Kennelijk gaan de opstellers van de ARBIT ervan uit dat adviesdiensten commodities kunnen zijn. Dat ligt op het eerste gezicht niet voor de hand. Een commodity is een eenvormig massaproduct, met een voorspelbare inhoud. Advies is alleen nuttig als van tevoren niet bekend is wat de inhoud van het advies is. Hieronder is uitgewerkt hoe deze twee schijnbaar tegenstrijdige begrippen inwerken op de toepasbaarheid va de ARBIT. Daaruit volgt tevens wat moet worden verstaan onder ‘IT projecten’ waaraan in bovenstaande opsomming leiding gegeven kan worden.

Wat in de automatiseringsbranche onder ‘adviesdiensten’ wordt verstaan varieert sterk van aard. Vaak worden dienstverleners die werk uitvoeren ten behoeve van een klant ’consultants’ genoemd. Bijvoorbeeld programmeurs en systeemanalisten. Strikt genomen zijn dat geen adviseurs. Zij nemen wel beslissingen voor de klant op uitvoerend niveau, maar adviseren de klant daar niet over. Toch is het gebruikelijk dit wel als adviesdiensten aan te merken. Met wat goede wil kunnen deze diensten als “adviesdiensten met een commodity-karakter” worden gezien. Daar tegenover staan bijvoorbeeld adviezen waarin strategische scenario’s voor operationele bedrijfsvoering van een onderneming voor de komende tien jaar worden afgewogen. De operationele organisatie van veel ondernemingen hangt sterk af van automatiseringsmogelijkheden. In gevallen als dit betreft het ook zuiver adviezen, want de klant wint deze adviezen in om zelf een goede beslissing te kunnen nemen. Deze adviezen zijn complex en uniek, en dus geen commodity.

Adviesdiensten maken niet zelden een integraal onderdeel uit van automatiseringsprojecten. Als de opdrachtgever tijdens het project keuzes moet maken naar aanleiding van adviesdiensten, kunnen die keuzes zijn bedrijfsvoering en het project beïnvloeden. Projecten waarin dat aan de orde is, lenen zich niet voor toepassing van de ARBIT. De ARBIT laten nauwelijks ruimte voor een verantwoordelijkheidsverdeling die recht doet aan de belangrijke rol die een opdrachtgever speelt in dergelijke projecten. Een professioneel leverancier aanvaardt geen aansprakelijkheid voor projectverantwoordelijkheden van de klant.

Artikel 55 is het derde en laatste artikel dat onder het hoofdje ‘adviesdiensten’ staat, en bepaalt dat de relevante fasen van een project in de overeenkomst moeten worden benoemd, evenals de fatale termijn per fase. Het begrip ‘fatale termijn ‘ betekent dat overschrijding ervan automatisch leidt tot verzuim van de leverancier. Dat geeft de opdrachtgever bevoegdheden tot het verhalen van schade en het opschorten en ontbinden van de overeenkomst. Hieruit volgt dat projecten waarvan de op te leveren prestatie volledig kan worden beschreven, waardoor een leverancier bij de uitvoering onafhankelijk is van de opdrachtgever, op deze basis kunnen worden uitgevoerd. Voor projecten die afhankelijk zijn van de opdrachtgever is deze bepaling ongeschikt. Artikel 55 kan dus alleen werken voor ‘commodity’ IT overeenkomsten, en is zo een voorbeeld van een bepaling die het toepassingsgebied van de ARBIT impliceert.

Enkele artikelen uit de ARBIT nader beschouwd
De ARBIT worden hierna beschouwd binnen het kader waarvoor ze bedoeld zijn. Onderstaande analyses gaan er van uit dat sprake is van IT overeenkomsten voor goederen en diensten waarvan de inhoud vooraf volledig is bepaald.

Onderzoeksplicht
Artikel 4 legt de leverancier een onderzoeksplicht op. De opdrachtgever hoeft volgens dit artikel alleen informatie aan de leverancier te verstrekken. Het commune contractenrecht voorziet in een genuanceerde balans van wederzijdse onderzoeksplichten bij het aangaan van overeenkomsten. De ARBIT sluiten deze onderzoeksplicht van de opdrachtgever niet uit. De opdrachtgever houdt dus een onderzoeksplicht. Een voorbeeldje: Een ministerie bestelt 10 PC’s, en krijgt die geleverd. Bij een poging deze PC’s als servers in te zetten, blijkt dat ze daarvoor niet geschikt zijn. Hier geldt een eigen onderzoeksplicht van het ministerie, of de ARBIT nu gelden of niet. Anders ligt dat als een welomschreven servercapaciteit gevraagd zou zijn. Dan moet de leverancier eerst punten die niet helemaal duidelijk zijn navragen, en daarna een geschikte aanbieding doen. Als de aanbieding niet aan blijkt te sluiten bij het gevraagde, is dat de verantwoordelijkheid van de leverancier. Dat is zo, of de ARBIT van toepassing zijn of niet. Het artikel verheldert wellicht de verwachtingen van het Rijk, maar heeft juridisch niet veel effect.

Vervangen van personeel
In de artikelen 5 en 22 krijgt de opdrachtgever een vergaande bevoegdheid in te grijpen op een project door vervanging van personeel te verlangen. Daarvoor moet wel een reden zijn. Als achteraf blijkt dat voor een dergelijke ingreep geen goede reden bestond, dan moet de leverancier dat aantonen, en hij moet bewijzen dat door dat ongerechtvaardigde ingrijpen meerkosten en vertragingen zijn ontstaan. Van een opdrachtgever die direct ingrijpt op de wijze waarop een uitbestede dienst wordt uitgevoerd, zou op zijn minst verwacht mogen worden dat deze zelf actief verantwoording aflegt voor zijn ingrijpen. De ARBIT regelen dat niet de ingrijpende opdrachtgever iets hoeft te verantwoorden, maar dat de leverancier moet aantonen dat het ingrijpen niet te verantwoorden was, iets wat buitengewoon lastig zal zijn. De leverancier wordt hiermee in een kwetsbare positie gebracht.

Intellectuele eigendom
Artikel 8 voorziet er kort gezegd in dat de intellectuele eigendom van speciaal voor de opdrachtgever gemaakte software bij die opdrachtgever ligt. Voor leveranciers is dat natuurlijk niet altijd even plezierig, maar het is duidelijk.

Het artikel gaat diep in op het feit dat persoonlijkheidsrechten bij de opdrachtgever moeten komen te liggen. Voor auteursrecht gerelateerde persoonlijkheidsrechten kan dit, maar voor octrooirecht gerelateerde persoonlijkheidsrechten is deze bepaling nietig (art 14 ROW). De leverancier moet zorgen dat zijn personeel bij voorbaat afstand doet van persoonlijkheidsrechten, en daar zelf ook bij voorbaat afstand van doen. De ARBIT bepaalt daarover dat de opdrachtnemer bij voorbaat een onherroepelijke volmacht verstrekt aan de opdrachtgever. In de huidige stand van het recht wordt een dergelijke bepaling in algemene voorwaarden vermoed onredelijk bezwarend te zijn. Persoonlijkheidsrechten zullen bij softwareontwikkeling niet snel een dispuut opleveren, maar het is toch jammer dat de overheid bepalingen opneemt die deels nietig en deels normaal gesproken als onredelijk worden beschouwd.

Garanties
Artikel 12 verlangt garanties van de leverancier. Deze lijken binnen het toepassingsgebied niet onredelijk, en zijn deels verzekerbaar. De garantie van vijf jaar onderhoud is iets om even goed op te letten. Voor levering van bijvoorbeeld smartphones lijkt mij dat vijf jaar wel erg lang is. Een leverancier moet dan goed opletten deze termijn in de overeenkomst expliciet te verkorten.

Gebruiksrechten
De bijzondere bepalingen gebruiksrechten betreffen voorwaarden bij de aanschaf van programmatuur. Het is de vraag of standaardsoftware werkelijk onder deze voorwaarden aangeschaft kan worden. Het is niet gebruikelijk dat een leverancier van standaard software onderhandelt over de te verstrekken gebruiksrechten. Een standaardsoftwareleverancier zal niet graag aan versieregels van een klant gebonden zijn. Voor iedere klant zou dan een ander ontwikkelbeleid gevoerd moeten worden. Het voordeel van standaardsoftware is juist dat de leverancier een eigen eenduidig ontwikkelbeleid hanteert, waar alle klanten baat bij hebben. Men zou verwachten dat een Rijksoverheid juist geen zaken zou willen doen met een standaardsoftwareleverancier die zijn versiebeleid en ontwikkelingsstrategie afstemt op de wensen van één klant.

Hersteltermijnen
Met betrekking tot de oplevering van maatwerkprogrammatuur is in artikel 58.6 bepaald dat, als er gebreken worden geconstateerd bij de acceptatietest, die binnen een door de opdrachtgever vast te stellen redelijke termijn opgelost moeten worden. Als dat niet lukt mag de opdrachtgever zelf voor correctie zorgen op kosten van de leverancier. Deze bepaling levert een wat onevenwichtige situatie op. Wat voor de opdrachtgever een redelijke termijn lijkt, kan voor degene die het moet realiseren een onmogelijke termijn zijn. Voor de opdrachtnemer zal het echter niet eenvoudig zijn aan te tonen dat de door de opdrachtgever gestelde termijn onredelijk is. Dat betekent dat de opdrachtnemer bij een fout tijdens de oplevering de controle kwijt is. Het laten oplossen van fouten door een derde, in bij die derde vooraf onbekende programmatuur, zal vaak duur zijn. De situatie kan op eenvoudige wijze verbeterd worden, namelijk door te verlangen dat de opdrachtgever een motiveringsplicht krijgt bij het stellen van een termijn als hier bedoeld.

Tweede oplevering moet foutloos
Het recht om de overeenkomst te ontbinden als bij de tweede test nog steeds fouten geconstateerd worden, is een erg rigoureus middel. Zelfs bij uitgesproken degelijk testen kan een matig ingewikkeld stuk programmatuur in een tweede acceptatietest nog gemakkelijk fouten bevatten. Bijvoorbeeld: een systeem bevat 20 parameters met gemiddeld 4 verschillende waarden. Dat levert 4 tot de macht 20 combinaties op, wat 1600 miljard combinaties oplevert. Van een dergelijk matig complex systeem zijn niet alle combinaties uit te testen. Temeer niet, omdat als een fout hersteld wordt, in beginsel alle combinaties opnieuw getest moeten worden. In dit licht is de algemene regel dat fouten in een tweede test het recht geeft tot ontbinding van de overeenkomst, is in veel gevallen niet redelijk. Een dergelijk recht schept een situatie waarin de opdrachtgever op niet gedwongen is zich redelijk op te stellen. Hoewel er best situaties te bedenken zijn waarin deze bepaling redelijk is, is dat bij maatwerkontwikkeling vaak niet het geval. Leveranciers dienen er dus alert op te zijn hierover in de overeenkomst zelf het nodige op te nemen, en opdrachtgevers dienen er bedacht op te zijn dat een zorgvuldig leverancier dit zal verlangen.

Jaarlijkse controle
Volgens de bijzondere bepalingen over onderhoud moet de opdrachtnemer minstens één keer per jaar controleren of de geleverde prestatie goed functioneert. Bij applicaties waarbij disfunctioneren niet onmiddellijk opgemerkt wordt, wil je waarschijnlijk vaker controleren dan één keer per jaar, terwijl in andere gevallen een periodieke controle gewoon niet nuttig is. Partijen doen er beiden verstandig aan erop te letten afspraken hierover standaard in de overeenkomst op te nemen.

Fatale termijnen
Opdrachtnemers moeten zich bij het sluiten van een overeenkomst bewust zijn dat artikel 76.2 bepaalt dat Functiehersteltermijnen en Reactietijden gelden als fatale termijnen. Zij moeten dus niet lichtvaardig afgesproken worden. Als een opdrachtnemer niet zeker is die termijnen en tijden te realiseren, dan moet hij ze niet afspreken.

Onderhoud bevat innovatief onderhoud
Artikel 82 bevat een opmerkelijke formulering: als de opdrachtgever dat wenst, omvat het onderhoud ook innovatief onderhoud. Artikel 84 werkt de inhoud van innovatief onderhoud nader uit: Onder de ARBIT bestaat een standaard onderhoudsovereenkomst tevens uit nieuwe versies. Bij pakketsoftware is dat gebruikelijk, maar bij maatwerksoftware niet. Deze artikelen leggen de opdrachtnemer van maatwerk op dat hij onder het onderhoudscontracten nieuwe versies moet ontwikkelen als de opdrachtgever dat wenst. Dat dit als ‘onderhoud’ is aangemerkt, valt moeilijk te begrijpen. Immers, innovatief onderhoud op maatwerk is kostbaar. Het is alleen gewenst als daarvoor een uitgesproken reden bestaat, en zou om die redenen expliciet afgesproken moeten worden. Vooral de leverancier moet er alert op zijn prijsafspraken hierover specifiek te regelen in de overeenkomst. Doet hij dat niet, dan kan hij in de toekomst onverwacht substantieel meer verplichtingen onder het onderhoudscontract blijken te hebben dan hij verwachtte.

Overigens is het maar de vraag of de verplichting nieuwe versies te leveren op maatwerksoftware geen kernbeding betreft, en daardoor geen algemene voorwaarde is, maar in de overeenkomst ze3lf moet zijn opgenomen. Het zal in een onderhoudscontract in veel gevallen de hoofdprestatie zijn die de leverancier moet leveren. Als in de overeenkomst niets verder is opgenomen, en de opdrachtgever zou een beroep willen doen op deze bepaling, dan zal al snel onenigheid ontstaan over wat wel en niet onder het begrip innovatief onderhoud moet worden verstaan in een specifiek geval.

Samenvatting
De ARBIT zijn voor het grootste deel prima toepasbaar op ‘commodity’ IT diensten en producten. De ARBIT zijn niet bedoeld en niet geschikt voor een project waarin de opdrachtgever het project inhoudelijk sterk beïnvloedt. Dat is bijvoorbeeld het geval bij veel zakelijke automatiseringsprojecten. Toepassing van de ARBIT in dergelijke gevallen zal het risico op een mislukt project vergroten door de verstorende werking van de ARBIT op een evenwichtige verdeling van verantwoordelijkheden tussen opdrachtgever en leverancier.

Binnen de categorie IT overeenkomsten waarvoor de ARBIT bedoeld zijn, zijn enkele kanttekeningen te maken bij de ARBIT. Een aanbestedende instantie dient alert te zijn dat leveranciers onderstaande punten in de relevante gevallen onderkennen en ter discussie stellen. Doet een leverancier dat niet, dan kan dat aanleiding zijn vraagtekens bij de professionaliteit van die leverancier te zetten.

De kracht van standaardsoftware zit hem in de mogelijkheid voor veel klanten tegelijk software te ontwikkelen en gestandaardiseerd uit te brengen. De ARBIT regelen het versiebeheer van standaardsoftwareleveranciers. Een opdrachtgever moet zich ernstig afvragen of hij een standaardsoftwareleverancier wil die de kern van zijn bedrijfsvoering, namelijk het versiebeheer van zijn software, aanpast aan één klant, omdat die klant dat verlangt in zijn inkoopvoorwaarden. In beginsel is dat geen goed idee.

De leverancier wordt door de ARBIT op twee manieren in een kwetsbare positie voor willekeur van een opdrachtgever gebracht. De eerste is dat de opdrachtgever personeel van de opdrachtnemer kan doen vervangen, zonder daarvoor zelf consequenties te hoeven dragen. Een deugdelijke verantwoording door de opdrachtgever voor een dergelijk ingrijpen zou op zijn plaats zijn. De tweede is dat de opdrachtgever de overeenkomst mag ontbinden als in een tweede acceptatietest nog fouten gevonden worden. Bij maatwerkontwikkeling van enige omvang zal deze bevoegdheid bijna zeker ontstaan, ongeachte de kwaliteit van de leverancier. De opdrachtgever mag daardoor dergelijke overeenkomsten vaak in een laat stadium ontbinden, met behoud van recht op schadevergoeding. Het gevolg van ontbinding voor de opdrachtnemer is dat hij alle ontvangen vergoedingen onder de overeenkomst moet terugbetalen, plus eventuele schadevergoeding. Een professionele opdrachtnemer zal een dergelijk risico niet accepteren.

De toepasbaarheid van een aantal bepalingen in de ARBIT is sterk afhankelijk van de aard van de in te kopen producten of diensten. Dit geldt voor de garantieperiode van vijf jaar, dat onderhoud per definitie inhoudt dat de geleverde prestatie één keer per jaar door de leverancier moet worden gecontroleerd, en dat innovatief onderhoud standaard binnen het begrip ‘onderhoud’ valt. Zowel opdrachtgevers als leveranciers moeten er alert op zijn deze punten altijd in de overeenkomst zelf te regelen. Gebeurt dat niet, dan kunnen de ARBIT ongewenste situaties in het leven roepen, en, vooral voor leveranciers, ook onverwachte verplichtingen.

Conclusie
De ARBIT zijn alleen bedoeld voor IT producten en diensten waarvan het resultaat vooraf in detail bekend is. Voor diensten waarbij dat niet het geval is, moeten zijn niet worden toegepast. Als dat wel gebeurt, roept dat voor de opdrachtgever serieuze risico’s in het leven. De kans op een succes zal afnemen door de mismatch tussen verantwoordelijkheden en aansprakelijkheden. Een leverancier die in een dergelijk geval de ARBIT accepteert, verdient enige argwaan.

Binnen het toepassingsgebied bevatten de ARBIT een aantal bepalingen waar vooral de leveranciers iedere keer bij stil moeten staan. Zo nodig moeten zij ervoor zorgen dat die bepalingen in de overeenkomst genuanceerd worden. Opdrachtgevers doen er goed aan leveranciers die dat nalaten met reserves te beschouwen, omdat dergelijk nalaten niet van een professionele houding getuigt.

ARBIT-voorwaarden: klik hier 

IT 285

Pleegt Google inbreuk op GPLv2 licentie met ‘bionische’ software?

met dank aan Wouter Dammers, SOLV voor deze bijdrage (red. hyperlinks volgen vanavond). Sinds enige tijd wordt op Amerikaanse techblogs gediscussieerd over een vermeende inbreuk op de GPLv2 licentie door Google. Google zou de zogenaamde Glibc library hebben gebruikt ten behoeve van de ontwikkeling van een eigen library voor haar Android platform.

De Glibc library wordt in de Linux kernel gebruikt om de interface te verzogen tussen applicaties en de kernel. Op deze Glibc library zou volgens professor Raymond Nimmer de GNU General Public License version 2 (“GPLv2”) van toepassing zijn – zoals op de hele Linux kernel. Deze veel gebruikte open source licentie staat het onder meer toe om – kort gezegd – de broncode te kopiëren en te wijzigen. Gewijzigde code en – simpel gezegd – werken gebaseerd op de library mogen enkel worden verspreid indien deze vrij beschikbaar worden gesteld (onder dezelfde GPLv2 voorwaarden). Daardoor kunnen ook applicaties die gebruik maken van GPLv2-code besmet raken. Ratio hiervan is dat GPLv2-code vrij beschikbaar moet blijven – óók als het gebruikt wordt in proprietary software.

Sinds enige tijd wordt op Amerikaanse techblogs gediscussieerd over een vermeende inbreuk op de GPLv2 licentie door Google. Google zou de zogenaamde Glibc library hebben gebruikt ten behoeve van de ontwikkeling van een eigen library voor haar Android platform.

De Glibc library wordt in de Linux kernel gebruikt om de interface te verzogen tussen applicaties en de kernel. Op deze Glibc library zou volgens professor Raymond Nimmer de GNU General Public License version 2 (“GPLv2”) van toepassing zijn – zoals op de hele Linux kernel. Deze veel gebruikte open source licentie staat het onder meer toe om – kort gezegd – de broncode te kopiëren en te wijzigen. Gewijzigde code en – simpel gezegd – werken gebaseerd op de library mogen enkel worden verspreid indien deze vrij beschikbaar worden gesteld (onder dezelfde GPLv2 voorwaarden). Daardoor kunnen ook applicaties die gebruik maken van GPLv2-code besmet raken. Ratio hiervan is dat GPLv2-code vrij beschikbaar moet blijven – óók als het gebruikt wordt in proprietary software.

Volgens Nimmer zou Google de Glibc library hebben gekopieerd en hebben ontdaan van comments en bepaalde code. De nieuw gevormde “Bionic” library zou enkel nog gegevens bevatten die applicaties vertellen hoe ze met de kernel kunnen worden gebruikt. Google heeft de Bionic library vervolgens in licentie gegeven onder de minder strikte Apache licentie. 

Op de techblogs rijst de vraag of Google hiermee de GPLv2 schendt. Professor Nimmer en IE advocaat Naughton menen van wel: de Bionic library zou een zogenaamd derivative work vormen van de Glibc library. Daardoor zou de GPLv2 ook van toepassing zijn op de Bionic library. Gevolg daarvan zou zijn dat ook Android applicaties ‘besmet’ raken met de GPLv2.
Volgens velen slaan Nimmer en Naughton de plank mis. Zo heeft Linus Torvalds, auteursrechthebbende op de Linux kernel, ten aanzien van de Linux kernel een toevoeging gemaakt op de GPLv2:

“This copyright does not cover user programs that use kernel services by normal system calls—this is merely considered normal use of the kernel, and does not fall under the heading of ‘derived work’.”

Met andere woorden: applicaties die normaal gebruik maken van de kernel zouden niet besmet worden door de GPLv2. Dat zou betekenen dat ook al zou de GPLv2 van toepassing zou zijn op de Bionic library, dan nog zouden Android applicaties daardoor niet besmet raken.

Daarnaast is Glibc niet enkel beschikbaar onder de GPLv2, maar ook onder de minder strikte LGPLv2. Tussen alle hypotheses en feitelijke discussies door, blijft de vraag staan of – in het geval de GPLv2 van toepassing is op Glibc – de GPLv2 überhaupt wel van toepassing is op de Bionic library. Volgens Google zou de Glibc ontdaan zijn van alle auteursrechtelijk relevante inhoud: de gestripte library zou enkel nog feitelijke gegevens bevatten.

In de open source community gaan stemmen op dat header files (lees: de overgebleven bestanden) sowieso niet auteursrechtelijk beschermd zijn. Of dat het geval is, is echter geen uitgemaakte zaak. In de beruchte Amerikaanse zaak SCO / IBM zou deze vraag behandeld worden – zij het niet dat aan die vraag niet is toegekomen omdat SCO nooit de auteursrechten bleek te hebben.

Naar Nederlands recht lijkt het me te kort door de bocht om te stellen dat deze header files niet auteursrechtelijk beschermd zijn. De header files zouden dan als feitelijke gegevens moeten worden aangemerkt.  Feitelijke gegevens an sich zijn niet auteursrechtelijk beschermd. Maar: onder omstandigheden kan het zo zijn dat een verzameling of selectie van feitelijke gegevens wel voor auteursrechtelijke bescherming in aanmerking kan komen (vgl. Rb. Utrecht 16 maart 2007, IEF 3718 Technip / Goosens). Of daar ook in dit geval sprake van is, is onduidelijk. Mocht het tot een rechtszaak komen dan zou dit voor deze specifieke situatie moeten worden beoordeeld.

Lees meer hierover: fosspatents.blogspot.com ; theregister.co.uk en linux.slashdot.org

IT 118

Arbit in strijd met Europees Recht?

In de Automatisering Gids is discussie gevoerd over de vraag of de nieuwe ARBIT-voorwaarden wel of niet strijdig zijn met Europees recht. " Ook bij modale IT-inkopen zullen deze voorwaarden niet zonder aanpassingen door een jurist met ICT- en aanbestedingskennis inzetbaar zijn. Het rücksichtslos inzetten van deze voorwaarden kan (helaas) tot strijdigheid met de Europese aanbestedingsregels leiden", zo concluderen Carolien Jobse en Marina Berghuijs. Onzin volgens 'mister ARBIT' Ruud Leether, die en passant opmerkt:  "Natuurlijk staat, als bij iedere andere set van algemene voorwaarden, in de ARBIT het belang van de gebruiker voorop."

Lees het artikel van Carolien Jobse en Marina Berghuijs hier.

Lees de reactie van Ruud Leether hier.

IT 1

De nieuwe ICT~Office Voorwaarden

ICT~Office is de Nederlandse brancheorganisatie voor bedrijven in de IT-, Telecom en Officesector. ICT~Office is onder meer voorgekomen uit FENIT, de vroegere branchevereniging van IT-ondernemingen. Binnen de Nederlandse ICT-sector zijn de FENIT-voorwaarden een begrip. Gebaseerd op de COSSO-voorwaarden werden de FENIT-voorwaarden in 1994 geïntroduceerd als dé leveringsvoorwaarden van de IT-industrie. In 2003 werden de voorwaarden herzien (hierna: “FENIT-Voorwaarden 2003”). Ruim vijf jaar later vindt ICT~Office het tijd om de voorwaarden weer eens aan te passen. Op 22 januari 2009 zijn de vernieuwde voorwaarden (hierna: “de ICT~Office Voorwaarden”) geïntroduceerd. Lees hier het complete artikel. Met dank aan: Polo G. van der Putt en Hidde J. Koenraad, Vondst Advocaten

IT 30

Algemene verkoopvoorwaarden Nederland ICT/ICT~Office

Versie Nederland ICT voorwaarden 2014
Pdf-download hier (tegen betaling)

Versie ICT~Office-voorwaarden 2009
ICT~Office-voorwaarden 2009 Nederlands; ICT~Office Terms and Conditions 2009 in English

Module algemeen ; General module in English
Module 1 Licentie voor programmatuur ; Software License in English
Module 2 Ontwikkeling van programmatuur (Development of software in English)
Module 3 Onderhoud van programmatuur (Maintenance of software in English)
Module 4 Application service provision, software as a service en computerservice (Application service provision, software as a service and computer service in English)
Module 5 Ontwikkeling en onderhoud van een website (Development and maintenance of a website in English)
Module 6 Webhosting (Webhosting in English)
Module 7 Detacheringsdiensten (Secondment services in English)
Module 8 Opleidingen en trainingen (Courses and training programmes in English)
Module 9 Advisering, consultancy en projectmanagement (Advice, consultancy and project management in English)
Module 10 Overige diensten (Other services in English)
Module 11 Verkoop van ICT-, telecommunicatie- en kantoorapparatuur en andere zaken (Sale of ICT, telecommunication and office equipment and other items in English)
Module 12 Verhuur van ICT-, telecommunicatie- en kantoorapparatuur (Renting out ICT, telecommunication and office equipment in English)
Module 13 Onderhoud van ICT-, telecommunicatie- en kantoorapparatuur (Maintenance of ICT, telecommunication and office equipment in English)
Module 14 Toegang tot internet (Internet access in English)
Module 15 Telecommunicatiediensten (Telecommunication services in English)
Module 16 Financiering en leasing (Financing and leasing of ICT in English)

Oude versies
COSSO 1993
COSSO 1990
COSSO 1986

FENIT 2003 Nederlands
FENIT 2003 Engels

FENIT 1994 Nederlands
FENIT 1994 Engels
FENIT 1994 Duits

ICT Telecom 2001

Kantoortechnologie 2005
Kantoortechnologie 2001

VIFKA 1991
VIFKA 1991 afnemer-wederverkoper
VIFKA 1991 diensten en onderhoud
VIFKA 1991 programmatuur

De hele set Nederland ICT / ICT~Office-voorwaarden in één pdf alsmede onbeschermde pdfjes zijn hier (tegen betaling) te bestellen. Met dank aan Tycho de Graaf, NautaDutilh en Annechien ten Kate, Nederland ICT.

IT 28

Algemene inkoopvoorwaarden overheid

Huidige versies
De ARBIT-2016 geldt met ingang van 4 oktober 2016 (nieuw)
1. Algemene Rijksvoorwaarden bij IT-overeenkomst 2016 (ARBIT-2016)
2. Algemene Rijksinkoopvoorwaarden 2016 (ARIV-2016)
3. Algemene Rijksvoorwaarden voor het Verstrekken van Opdrachten tot het verrichten van Diensten(ARVODI-2016)

Eerdere versies
Met de ARBIT-2014 is de ARBIT aangepast aan de Aanbestedingswet 2012 en de daarop gebaseerde voorschriften van de Gids Proportionaliteit. De ARBIT-2014 geldt met ingang van 5 april 2014 (nieuw).
1. Algemene Rijksvoorwaarden bij IT‑overeenkomsten 2014 - ARBIT-2014 (voorwaardentekst & meezendversie)
2. Modelovereenkomst ARBIT
3. Model Raamovereenkomst ARBIT
4. Model Nadere overeenkomst bij de Raamovereenkomst ARBIT

De ARBIT zijn bedoeld voor het inkopen van ICT-producten en diensten (oud)
1. Algemene rijksvoorwaarden bij IT-overeenkomsten (ARBIT-2010) met toelichting; ARBIT-2010 in English and explanatory notes 
2. ARBIT aanpassing i.v.m. open source
3. Model overeenkomst ARBIT 2011 met toelichting; Model contract ARBIT 2011 in English with explanatory notes
4. Model raamovereenkomst ARBIT 2011 met toelichting; Model framework agreement ARBIT 2011 in English with explanatory notes
5. Model nadere overeenkomst bij raamovereenkomst ARBIT 2011 met toelichting; Model call-off contract under ARBIT 2011 in English with explanatory notes

De ARIV en ARVODI zijn bedoeld voor andersoortige inkopen.
1. Algemene Rijksinkoopvoorwaarden (ARIV-2011), toelichtingextra docsARIV-2011 in English
2. Algemene Rijksvoorwaarden voor het verstrekken van opdrachten tot het verrichten van Diensten (ARVODI-2011); extra docs; ARVODI-2011 in English; explanatory notes in English

Oude versies ICT-producten en diensten

De BiZa-contracten waren bedoeld voor het inkopen van ICT-producten en diensten.

Offerte-aanvraag

Ontwikkelingsovereenkomst maatwerkprogrammatuur
Overeenkomst tot beschikbaarstelling van standaard programmatuur
Overeenkomst tot beschikbaarstelling van standaard programmatuur met maatwerkaanpassingen
Onderhoudsovereenkomst programmatuur

Mantelovereenkomst beperkte dienstverlening
Werkopdracht bij mantelovereenkomst beperkte dienstverlening
Mantelovereenkomst dienstverlening
Nadere overeenkomst dienstverlening

Exploitatie-overeenkomst gegevensverwerking

Koopovereenkomst apparatuur
Huurovereenkomst apparatuur
Mantelovereenkomst koop apparatuur
Nadere overeenkomst koop apparatuur
Mantelovereenkomst onderhoud apparatuur
Nadere overeenkomst onderhoud apparatuur

Oude versies andersoortige inkopen

De ARIV en ARVODI waren bedoeld voor andersoortige inkopen.
Algemene rijksinkoopvoorwaarden (ARIV-2008, Wijziging betalingstermijn ARIV-2008, ARIV-2008 in English)
(Algemene rijksinkoopvoorwaarden (ARIV-2004 ingetrokken))
(Algemene Rijksvoorwaarden voor het verstrekken van opdrachten tot het verrichten van Diensten (ARVODI-2004 ingetrokken))

Algemene Rijksvoorwaarden voor het verstrekken van opdrachten tot het verrichten van Diensten (ARVODI-2008), Wijziging betalingstermijn ARVODI-2008, ARVODI-2008 in English)

Met dank aan Tycho de Graaf, NautaDutilh (en Reinout Rinzema, Feer Verkade, Joop Janssen, BZK en Kluwer)