Erik-

Nog een andere vraag: ik heb in juni een ticket voor een zakelijk evenement gekocht dat in oktober plaatsvindt. Destijds ook een factuur gekregen met 19% BTW. Die BTW heb ik in het betreffende kwartaal als voorbelasting opgegeven. Allemaal zoals het hoort. Nu heeft de organisator inmiddels door dat, omdat het evenement in oktober plaatsvindt, er toch 21% gerekend zal moeten worden. Om aardig te zijn nemen ze die verhoging zelf op zich, dus het totaalbedrag blijft hetzelfde, het bedrag excl. BTW is iets minder, het BTW-bedrag iets meer. Maar, ze hebben dit gedaan door een nieuwe factuur te sturen met hetzelfde factuurnummer, maar met de aangepaste bedragen. In feite vervangen ze dus een bestaande factuur, door een nieuwe factuur aan te maken met hetzelfde nummer (en dezelfde datum, in juni). Voor zover ik weet is dat gewoon fout. Een eenmaal verstuurde factuur veranderd nooit meer. Ze hadden in dit geval een creditfactuur en een nieuwe factuur met een nieuw nummer moeten sturen, toch? Hoe zij hun boekhouding regelen moeten ze in principe zelf weten. Maar, ik wil wel dat die van mij in orde is. Mag ik de factuur die nu in mijn administratie zit, vervangen met de aangepaste? Of ben ik dan net zo fout, en moet ik bij de organisator eisen dat hij dit volgens het boekje doet? Als ik gewoon de factuur mag vervangen in de administratie, heb ik uiteraard iets te weinig voorbelasting opgegeven. Mag ik dat in de volgende aangifte (voor een ander kwartaal dan waarin de factuur viel) gewoon verrekenen? Binnen hetzelfde jaar mag ik gewoon in een latere aangifte verrekenen zolang het om niet meer dan 1000 euro gaat, meen ik mij te herinneren.

Deze situatie is toch expliciet voorzien in art. 52 wet OB? Daaruit lijkt mij ondubbelzinnig dat de prijsafspraak aangepast mag worden door de verkoper.

Maar waaruit bestaat die samenwerking precies? Wat draag jij precies bij? En hoe maak je jouw bijdrage zichtbaar?

Los van wat FB vindt, Like en win is in Nederland gewoon spam die onder het spamverbod valt. Het is een vorm van tell-a-friend, en daar mag, als één van de voorwaarden, geen (kans op) een beloning aan gekoppeld zijn.

Het probleem dat je belasting betaalt over de winst bij een emz is niet te voorkomen (zonder van rechtsvorm te veranderen). Maar, is er ook niet onderscheid te maken voor het meetellen in box 3? Ik meen mij te herinneren dat het eigen vermogen van de emz niet meetelt als vermogen in box 3 voor de ondernemer, mits het eigen vermogen bedoeld is voor de onderneming en dat argument aannemelijk is. Dus als ik met 50K winst 100K eigen vermogen in de emz hou zonder sterke onderbouwing, wordt daar gehakt van gemaakt. Nog erger als ik in december even mijn hele privé-spaarrekening als privé-storting bij het eigen vermogen zet, zodat ik op 1 januari vrijwel geen box 3-vermogen heb. Maar als je concrete investeringen gepland hebt en dat goed kan onderbouwen, is een hoog eigen vermogen misschien wel prima te verantwoorden. Maar ik weet het niet zeker.

Rechtsgeldig? Dat kan talloze betekenissen hebben. Bedoel je of het ten laste te brengen is van de winst? Of je de BTW terug mag vragen? Of je de factuur moet betalen? En ontbreekt jouw BTW-nummer, of dat van de leverancier?

(Wijziging: ik lees scheef, iemand had deze opmerking al gemaakt.)

Dat is in Nederland niet legaal. "Like en win", "retweet en win" of andere vormen van "stuur dit door naar je vrienden en je krijgt een beloning" voldoen niet aan de eisen van de OPTA voor tell-a-friend-systemen. Daar mag geen (kans op) een beloning tegenover staan. Daarnaast klinkt het pakket gewoon als een reclamefolder, voor mij.

Nee, een idee is veel te vaag om te beschermen. Een uitvoering zal waarschijnlijk te beschermen zijn met auteursrecht en misschien met modelrecht, maar dat laatste ken ik eigenlijk helemaal niet. Patenten kunnen helpen bij specifieke vindingen, maar een idee voor een dienst is daarvoor veel te zwak. Voor de rest is dit verhaal dusdanig vaag dat ik er geen touw aan vast kan knopen. Een vaker voorkomend probleem (niet specifiek op dit forum) bij mensen die wel vragen hebben, maar het idee graag geheim willen houden. Dat vind ik zelf jammer, want anders zou je ook misschien nog constructieve feedback op het idee kunnen krijgen.

Right, that sounds like a intra-community transaction. There's a notable difference between VAT not applying to your company or services (vrijgesteld) or VAT applying but resulting in you not having to pay anything. The latter is the case for you: you will still have do all the proper VAT filings. For this sale, you list the correct amount as services provided to companies in other EU countries (question 3b). In addition, you'll need to file a aangifte intracommunautaire prestaties or aangifte ICP, where you list the VAT numbers and total amounts for all transferred VAT. In your case, that would only be a single entry, as you delivered services to only one customer. However, because you transfer the VAT, you will not actually have to pay anything to the tax authority for this particular case, for VAT. There is nothing unusual about that. Also, make sure to follow the guidelines for the invoices: state on the invoice that VAT is transferred, make sure their VAT number is valid, and add their VAT number to the invoice. Income tax has no relation at all to your VAT.

Zelf reken ik het gewoon door - vrijwel al mijn klanten zijn toch ondernemers. T-Mobile heeft wel een interessante aanpak voor het 'rare prijzen'-probleem. Veel prijzen gaan gewoon mee omhoog, maar andere prijzen ronden ze juist mooi af. Dus iets dat nu € 9.95 kost, wordt straks € 9.99. Een verhoging van 0.4%, tegenover 1.68% als je de verhoging gewoon doorrekent. Grootste deel nemen ze dus zelf, om mooie prijzen te krijgen, maar niet alles. Overigens, ik weet niet of dat hier al voorbij gekomen was, maar ik kwam laatst een mooi stukje tegen van Arnoud Engelfriet over of je een overeenkomst mag ontbinden vanwege deze "prijsverhoging". Kort antwoord: nee, artikel 52 van de wet op de omzetbelasting voorziet hier specifiek in.

Dat hangt er helemaal vanaf wat voor platform je voor wil ontwikkelen. Voor webapplicaties is een hostingomgeving handig, maar daar is een heel breed scala in, afhankelijk van wat voor platform je gebruikt, of zelfs alleen html/css/javascript doet. Voor iOS heb je een Mac nodig. Overigens raad ik helemaal niet specifiek aan om met iOS of Mac te beginnen (ik raad het ook niet af), ik noemde het alleen omdat ik daarvoor goede boeken aan kan raden :)

Een lastige vraag, en zeker weet je het pas als je het probeert. Het is voor iedereen anders. Ik ben zelf programmeur, maar heb dat op de "gewone" manier geleerd. Ik denk dat het mogelijk is om heel ver te komen met thuisstudie, maar onderschat niet hoeveel tijd het kost om goed te leren. Hoe minder tijd je er per week/maand/jaar aan besteedt, hoe langer het duurt om het beter onder de knie te krijgen. De meeste programmeurs die ik ken hebben er minstens een paar jaar full-time op zitten, maar meestal flink meer. En dan zijn er nog allerlei verschillende platformen en technieken om mee te werken, hoewel nieuwe dingen oppikken wel steeds makkelijker wordt naar mate je bredere ervaring hebt. En zoals Fvddungen terecht zegt: het gaat niet alleen om een stukje code te kunnen schrijven. Denk ook aan zaken als software-architectuur, analytisch denken en probleemoploossing. Maar het is zeker niet onmogelijk. Ik kan je heel moeilijk helpen met hoe je moet beginnen: voor mij is dat zo lang geleden dat ik mij niet meer in die situatie kan verplaatsen. Mocht je voor iPhone, iPad of Mac OS X aan de slag willen, dan kan ik de boeken van Big Nerd Ranch heel sterk aanraden: dat is ongeveer de standaard in die wereld, en ze hebben ook boeken voor mensen die nog nooit geprogrammeerd hebben. Voor andere platformen heb ik geen idee.

Dat zou je moeten overleggen met de hostingprovider in kwestie. Immers, het kost hen alsnog tijd om het in te stellen. Ik zou zelf (maar ik doe geen hosting) twijfelen of ik hier überhaupt wel aan moet beginnen, want straks heb ik een hoop gedoe met een klant die zelf een deel wil doen maar er eigenlijk niets van snapt. SSLcertificaten.nl (aka Xolphin) zou ik ook aanraden. De handleidingen zijn helder en het aanvragen is snel en eenvoudig, zo eenvoudig als het kan dan. Inderdaad een goede tip dat je het aan moet geven: sommige providers controleren zelfs achteraf of je echt een SSL-website opgebouwd hebt op dat IP. Voor het SSL-certificaat zelf bestaat er niet zoiets als verlenging. Het ene certificaat verloopt, en wordt vervangen door een ander. Vaak kan wel een deel van het controlewerk overgeslagen worden bij een verlenging bij dezelfde partij. Dus het is iets minder werk. En inderdaad, zoals Derek-Jan al zei, je kan ook voor meerdere jaren aanvragen. Tot 10 jaar zelfs bij sommigen. Dat klopt, multi-domein is voor 5 domeinen is eigenlijk altijd duurder dan 5 losse certificaten. Maar bij die laatste optie heb je dus weer 5 IPs nodig. Ik heb startssl een paar keer vaker voorbij zien komen, ik weet niet of er een addertje onder het gras zit. Voor 12 euro per jaar is het bijna niet de moeite om het uit te zoeken :)

Ik kan je niet concreet helpen met de vergelijking, maar ken wel de details van hoe HTTPS/SSL werkt en waarom. Het doel van HTTPS Met HTTPS (dat is HTTP met SSL er omheen) proberen we meestal twee zaken te bereiken: encryptie van de verbinding, zodat een derde die niet kan afluisteren, en verificatie van de website, zodat we zeker weten dat dat de legitieme website van LittleBit is. Als je die laatste stap overslaat, zou het veel minder effectief zijn: je weet dan wel dat de verbinding encryptie gebruikt, maar je weet alsnog niet zeker of jouw gegevens beveiligd naar LittleBit verstuurd, of naar iemand anders (zoals voor kan komen bij een zgn. man in the middle-attack). Er is daarnaast ook nog een mogelijkheid om de gebruiker te authenticeren met zgn. client-certificaten, maar dat wordt maar heel weinig gebruikt. De rol van het certificaat en CAs Het encryptiedeel is, voor onze vragen, relatief eenvoudig. Lastiger is het verifieren van de identiteit van de website. Hoe weet ik immers zeker of een bepaald certificaat echt van LittleBit is, of dat het van iemand anders is die zich voordoet als LittleBit. Daarvoor worden Certificate Authorities (CAs) gebruikt. Dit zijn organisaties die beloven de identiteit van anderen goed te controleren. Browsers en andere SSL-software heeft vaak een lange lijst van certificaten van CAs ingebouwd. Een CA kan vervolgens andere certificaten tekenen om aan te geven dat deze door die CA vertrouwd worden. Stel dat LittleBit een certificaat heeft dat geverifieerd is door Verisign, dan ziet mijn browser dat het certificaat dat de webserver van LittleBit stuurt, via een aantal tussenstappen, getekend is door Verisign. Omdat mijn browser gelooft dat Verisign dat vast goed gecontroleerd heeft, vertrouwt die vervolgens dat die website echt van LittleBit is. In de praktijk doen we deze verificatie op domeinnaam. Als ik de eigenaar ben van littlebit.nl, kan ik naar Verisign gaan en zeggen "ik ben de eigenaar van littlebit.nl, doe mij een certificaat". Verisign zal vervolgens controleren of ik inderdaad de eigenaar ben, en dan mijn certificaat tekenen. De verificatie gebeurt dus op domeinnaam, en niet op IP-adres. Voor sommige certificaten controleert de CA ook mijn identiteit. Er zijn een hondertal CA-certificaten bekend in een gemiddelde browser. Er zijn ook nog talloze resellers - dat is wat hosting providers doen die zelf certificaten aanbieden. Koppeling aan IP-adres Vroeger was het simpel: 1 website had 1 IP-adres. Als je een andere website wilde bouwen, deed je dat op een ander IP-adres. Sinds een lange tijd hebben we de mogelijkheid om meerdere (niet-SSL) websites te hosten op 1 IP-adres. Dat gebeurt met de host-header. Als ik naar littlebit.nl ga, verbindt mijn browser met dat IP-adres. Vervolgens stuurt hij het verzoek voor de juiste URL, en stuurt daarbij in de host-header mee dat ik naar littlebit.nl wilde gaan. Op die manier, ook wel virtual hosting genoemd, kan de webserver dus onderscheiden welke website ik wil zien, ook al draaien er veel websites achter hetzelfde IP-adres. Met SSL is dit echter een probleem. De opzet van de SSL-communicatie gebeurt voordat de browser de kans krijgt om de host-header te sturen, omdat alle HTTP-communicatie binnen de encryptielaag moet vallen. Dus totdat we de SSL-opzet hebben gedaan weten we niet welke website de gebruiker wilde zien, maar we kunnen pas de SSL-opzet doen met het juiste certificaat, als we weten welke website de gebruiker wil zien. Hiervoor zijn een aantal oplossingen. Soms kan je dit oplossen met wildcard-certificaten, als alle websites onder hetzelfde domein vallen. Een andere oplossing is om elke SSL-website op een eigen IP te plaatsen: dan kunnen we immers aan de hand van het IP-adres waarop verbonden wordt, gokken welk certificaat er gebruikt moet worden. Dan zijn er SSL-certificaten waar meerdere domeinnamen in opgenomen kunnen worden. Dit werkt in principe prima, maar heeft als nadeel dat je in één keer een certificaat aan moet vragen met alle namen. Later wijzigen is veel gedoe. Leuk voor twee websites in eigen beheer, maar complete chaos met honderden klanten. De mooiste optie is Server Name Indication (SNI) waarmee de browser toch nog voor de SSL-opzet aan kan geven welke website hij graag wil zien. Dat is hele mooi, want het werkt eenvoudig en goed. Helaas ondersteunen niet alle browsers dit: het werkt niet op IE of Safari op Windows XP, het werkt niet op IE6, Blackberry, of Android 2.x. Korte samenvatting: als je oudere browsers wil ondersteunen, is de enige optie een eigen IP-adres, omdat anders niet "op tijd" te achterhalen is welk certificaat er gebruikt moet worden, omdat de webserver niet weet welke website je probeert te bezoeken. Maar het certificaat is niet permanent gekoppeld aan dat IP. Extended validation Nu ik toch uitgebreid aan het schrijven ben, laten we dan ook even in gaan op extended validation (EV). EV is een vrij nieuw type certificaat. Het wil eigenlijk zeggen dat de CA extra veel moeite heeft gedaan om te bepalen dat jij de eigenaar bent, en wie jij dan precies bent. En daar extra veel voor betaald heeft gekregen. In de meeste browsers verschijnt de naam van de organisatie in een groen balkje, of wordt op een andere manier aangeduid dat het EV is. Of dat de moeite waard is hangt van de gebruikers af, en hoeveel extra vertrouwen die daar aan geven. Er wordt voor niet-EV soms ook onderscheid gemaakt tussen domeinvalidatie en organisatievalidatie, in het eerste geval staan er geen bedrijfsgegevens in het certificaat. In het tweede geval wel, maar dat is zo verstopt dat ik betwijfel of iemand het ooit ziet. Ik zie er geen meerwaarde in. Veiligheid en vervalsen van certificaten Een veel voorkomend misverstand is dat duurdere certificaten de website beter beveiligen. Dat is helaas niet waar. De browser vertrouwt namelijk elk certificaat waarbij de domeinnaam klopt en dat getekend is door een bekende CA. Vorig jaar hebben, door een berg beveiligingsblunders, mensen ongeauthoriseerde SSL-certificaten voor o.a. gmail.com weten te maken door toegang te krijgen tot de CA van Diginotar. Dat is vermoedelijk op kleine schaal gebruikt om SSL-verkeer naar gmail af te luisteren: in plaats van naar de echte gmail wordt je naar een andere geleidt, die alles doorstuurd naar de echte gmail, maar intussen wel af kan luisteren. De neppe heeft gewoon een geldig SSL-certificaat voor gmail.com, getekend door Diginotar, een bekende CA, dus de browser vindt het allemaal prima. Andere websites met een Diginotar-certificaat zijn dan ook helemaal niet onveiliger geworden. Wel is het verstandig om die certificaten niet meer te gebruiken, want na een dergelijk incident verdwijnt het Diginotar-certificaat heel snel uit allerlei browsers. Kortom, het maakt niet per sé uit hoe hip jouw certificaat is: als er één CA in het lijstje van de browsers overtuigd kan worden om een onterecht certificaat uit te geven voor jouw domein, ben je alsnog het haasje. Daarna is het overigens alsnog verre van eenvoudig om verkeer af te luisteren of om te leiden, maar het is wel makkelijker geworden. EV kan je dan wel helpen als klanten oplettend genoeg zijn om te zien dat het nu "gewoon https" is in plaats van EV, maar ik betwijfel of ze dat zien. In gevallen waarbij dit mis gaat wordt soms de hele CA verwijderd, vooral in bijzondere blunders als Diginotar. Soms wordt ook een sub-CA verwijderd, waardoor een specifiek soort certificaat van een CA niet meer vertrouwd wordt. Ook is het mogelijk om individuele certificaten als ongeldig te markeren door ze op een Certificate Revocation List (CRL) te plaatsen, maar ik weet niet hoe effectief dat tegenwoordig is. Self-signed Soms kom je self-signed certificaten tegen. Dat wil zeggen dat het op zich een prima certificaat is, maar dat het niet ondertekend is door een CA. Browsers zullen het dan ook, tenzij jij dat vraagt, niet vertrouwen. Voor de browser is dat niet anders dan een certificaat getekend door een CA die niet bekend is. Andere toepassingen van SSL SSL wordt lang niet alleen bij HTTPS toegepast: ook bij communicatie met mailservers wordt het vaak gebruikt (imaps, pop3s). Daar geldt in principe precies hetzelfde qua certificaten. Wat voor certificaat moet ik nu kopen? In principe voldoet elk certificaat waarvan de CA bekend is in alle browsers. Dat kan vanaf € 12 per jaar, en dat is dan alleen domeinvalidatie: is dit domein echt van jou. Ik zie niet zoveel waarde in organisatievalidatie, EV kan wel meerwaarde bieden door er betrouwbaarder uit te zien. Maar dat gaat dan ook snel naar € 250 per jaar. Die € 12 gaat overigens puur om het laten tekenen van het certificaat door de CA: verwacht niet dat een hosting provider het voor die prijs aanbiedt. Er zit ook wat werk aan vast om de validatie te voltooien, en het moet ingesteld worden op de webserver. En ook aan extra IP-adressen zijn in principe gewoon kosten verbonden voor de hosting provider.

Is verstandig, maar niet verplicht - zie de Robert M.-zaak Robert M. gaat om strafrecht, niet om civiel recht. Ik meen mij te herinneren dat je zelf nooit de sleutels af hoeft te geven, omdat je dan gedwongen zou worden om mee te werken aan je eigen veroordeling. Een derde partij die de sleutels heeft zou wel verplicht zijn om ze af te geven. En dan is er nog het mooie vraagstuk van "nee hoor, ik weet van niets, ik weet die sleutel niet" of "ik ben de sleutel vergeten". Maar, misschien is de wet op dit vlak recent veranderd. Hoe het in civiel recht zit weet ik niet, maar het zou mij niet verbazen als het zou afwijken.

Er vanuit gaande dat het hier om zaken als een facebook-like button gaat, waardoor er dus cookies van facebook geplaatst worden, is een balk niet voldoende. Er moet expliciete toestemming van de gebruiker zijn. Dus totdat ik ergens heb geklikt "ik vind het prima" mag er geen cookie geplaatst zijn. Toestemming kan niet impliciet en niet achteraf. Higherlevel.nl voldoet zelf nu dus ook niet aan de wet. Het klopt dat er inderdaad nog geen handhaving gebeurt voor de cookiewet. Maar hier is de OPTA wel actief mee bezig, door het ontwikkelen van een cookiemonitor die websites scant voor illegale cookies. Dit is technisch gezien vrij triviaal. In het laatste wat ik hierover gelezen heb was het plan om waarschijnlijk eerst te waarschuwen bij overtreding, behalve bij ernstige situaties. Kortom, ik verwacht dus dat de handhaving er wel degelijk aan komt. Goede stap dus om het bij een nieuwe website gelijk goed te doen. Voor bestaande producten is het misschien handiger om wel nog even af te wachten, maar we weten natuurlijk niet hoe lang dat goed gaat. Dat wil overigens niet zeggen dat ik het eens ben met de cookiewet, voor de helderheid.

Voor internet is de oplossing eenvoudig: meerdere abonnementen op verschillende platformen. Dus heb je één abonnement op glasvezel? Neem dan een andere aanbieder op kabel of ADSL als back-up. Bij een volledig andere provider, uiteraard En test dat ook af en toe. Dat vangt niet alles af, want die kabels lopen nogal eens op dezelfde plek, dus een foute graafmachine kan er alsnog een eind aan maken. Een ex-werkgever had daarom een extra glasvezel laten graven die een volledig gescheiden route liep, maar dat wordt wel heel snel heel erg duur. Een andere optie is nog een 3G-modem. Wel veel trager, maar veilig voor de graafmachine. Telefonie is helaas een stukje complexer, omdat je immers hetzelfde telefoonnummer wil behouden. Afhankelijk van waar de storing zich bevindt zou je misschien het telefoonnummer door kunnen schakelen naar een mobiele telefoon. Ik ben verder niet zo bekend met telefonie. Stroom is wel het meest complex. Datacenters hebben vaak dieselgeneratoren staan. Uiteraard meerdere, want dan kan er eentje in onderhoud zijn zonder risico te lopen. Zelf een generator neerzetten is ontzettend duur, en kan ook niet altijd vanwege veiligheid, er moet immers een behoorlijke dieseltank bij. Je kan misschien een tijdelijk container-aggregaat huren, maar ook dat zal niet goedkoop zijn. Kortom, het kan allemaal. Maar hoe beter je het wil, hoe duurder het wordt. De vraag is dus hoeveel schade je op kan lopen en hoe groot de kans is dat dat er iets gebeurd. Op basis daarvan zal je moeten schatten welke maatregelen nuttig zijn. Een extra internetabonnement kan best goedkoop, dat overweeg ik zelfs thuis bijna. Maar de rest wordt toch snel duurder. Nog een andere optie is het risico verzekeren. Maar daar heb ik helemaal geen kaas van gegeten.

Dat klopt. Je mag gewoon alles opnemen wanneer je wil. Hier doe je een gevaarlijke aanname: je gokt dat alles klopt, en leidt dan de privé-opnames af uit het verschil. Maar dat betekent ook dat als er iets niet klopt in de boekhouding, je dat nu verstopt in de privé-opnames. Het is beter om daadwerkelijk te bepalen welke opnames er gebeurd zijn. Als dat inderdaad € 5414 blijkt te zijn, klopt het allemaal. Maar als er eigenlijk maar € 5000 aan privé-opnames waren, is de vraag waar die € 414 gebleven is, en moet je dat uitzoeken. Je betaald bij een eenmanszaak belasting over de winst. Welke privé-opnames of -stortingen gedaan zijn heeft geen invloed op de belastingheffing. Ik weet niet precies wat de reden is dat je de balans en privé-opnames moet opgeven bij de aangifte - mijn beste gok is dat het helpt met het detecteren van fraude of een slechte boekhouding. Maar iemand anders hier weet daar vast meer over.

De liquide middelen zijn de daadwerkelijke liquide middelen. Denk bijvoorbeeld aan het saldo op de bankrekening en in de kas. De winst komt niet terug als balanspost, maar in principe wel in het verschil tussen het eigen vermogen op de balans aan het begin en einde van het jaar. Als alles klopt, is het eigen vermogen aan het eind van het jaar, gelijk aan het EV aan het begin van het jaar, plus de winst, minus de privé-opnames. Maar als dat nou niet klopt, dan weet je dat er ergens een foutje in geslopen is. Misschien ben je een privé-opname vergeten, bijvoorbeeld. Let op dat eigen vermogen vaak niet hetzelfde is als de liquide middelen. Als je bijvoorbeeld € 1000 aan liquide middelen hebt, maar nog een openstaande inkoopfactuur of BTW voor € 500, is het eigen vermogen maar € 500. Andersom telt een vordering (zoals een openstaande verkoopfactuur) niet mee bij de liquide middelen (je hebt het geld immers niet), maar wel voor het eigen vermogen. Dus hoe ziet jouw balans er nu uit? Dat kan je het beste bepalen aan de hand van de feitelijke situatie. Hoeveel geld staat er op de rekening en zit er in de kas? Welke facturen staan er open? Andere schulden of vorderingen? Waarde van eventuele investeringen? Heb je overigens diensten of producten geleverd met BTW? Het valt mij op dat er namelijk geen BTW op de balans terug komt. Als je diensten levert die met BTW, heb je eigenlijk altijd op 1 januari een BTW-schuld: je bent de BTW immers verschuldigd, maar je hebt het nog niet afgedragen.

En de advocaat wil hier € 1200 voor rekenen? Ik denk dat dat best duur is, maar ik heb dit zelf nooit laten doen. Wel moet je helder hebben wat je zelf wil. De tekst zoals die daar nu staat zorgt niet voor de overdracht van auteursrecht, dat staat er immers nergens in. Je krijgt wel een kopie van de broncode, maar mag daar alleen iets mee in de gegeven drie omstandigheden. Is dat wat je wil? Design kan je misschien onder de broncode rekenen, maar ik zou voor de helderheid expliciet benoemen wat er naast de feitelijke code onder die afspraak valt. Niet alleen om jezelf juridisch in te dekken, maar ook omdat het gewoon goed is als beide partijen precies hetzelfde afgesproken denken te hebben.

Hoe ben je dat overeengekomen dan? Dat heb je op schrift staan, lijkt mij. Dus dan ligt de overeenkomst al vast, of niet?

Bedoel je dat de advocaat € 1200 rekent voor het opstellen van het contract? Of dat de andere partij € 1200 wil voor het overdragen? Met het stukje wat je laat zien draag je geen auteursrechten over. Dat staat daar helemaal nergens. Er zijn immers ook allerlei beperkingen, die er niet zouden zijn als het auteursrecht bij jou zou liggen.

Naar ik begreep is het handig om het niet alleen te controleren, maar ook het resultaat van de controle te bewaren. Mocht dan later blijken dat er iets niet klopt, dan kan jij bewijzen dat je die controle hebt uitgevoerd en dat het antwoord goed was. Als je ook je eigen BTW-nummer invoert krijg je ook een uniek consultatienummer bij het resultaat. Het automatisch en betrouwbaar controleren van BTW-nummers bij de bestelling is helaas niet eenvoudig, omdat lang niet alle nummers op alle tijden te controleren zijn. Verschillende landen doen op verschillende tijden regelmatig onderhoud, soms uren lang. Dus dan zou je ook moeten automatiseren dat de bestelling vastgehouden wordt tot het gelukt is om het te controleren. Misschien minder een probleem als er vrijwel alleen tijdens kantooruren wordt besteld. De enige praktische oplossing op dit moment lijkt mij dan ook wat Wouter voorstelt.

Dat vind ik erg kort door de bocht. RAID is vooral mooi voor beschikbaarheid: hoe lang duurt het om van een defecte disk te herstellen. Bij RAID kost dat in principe helemaal geen tijd. Maar, RAID is geen backup. Er zijn talloze fouten waarbij RAID helemaal niet helpt, zowel technisch als menselijk. Als het gaat om de veiligheid van de data kan je beter twee losse disken hebben waarvan je de ene periodiek naar de ander synchroniseert. Helemaal mee eens. Vertrouw nooit op één locatie/oplossing/onderneming. Ik huur bijvoorbeeld enkele servers bij een derde partij die ook backups aanbiedt. Echter, als ik de backup daar bewaar kan het zijn dat zowel de server als de backups verloren gaan. Daarom bewaar ik de backups bij een andere partij op een andere locatie, zodat de kans heel klein is dat ze allebei tegelijk verloren gaan. Voor een goed beleid met dataopslag moet je kijken naar: [*]hoe erg is het als data permanent verloren gaat? [*]hoe snel willen we kunnen herstellen van een uitval van de primaire opslag? [*]hoeveel budget hebben we? [*]zijn er specifieke eisen, zoals "eens gecreëerde data kan nooit veranderen"? Op basis daarvan kan je bepalen welke platformen het meest geschikt zijn. Bij het opslaan van data die je niet kwijt wil raken komt altijd een bepaald risico kijken, de truc is dus om dat risico goed af te wegen met de beschikbare middelen. Om op de concrete vraag terug te komen: ik vind het een leuk idee, maar voor mij niet interessant. Ik heb namelijk maar heel weinig echt belangrijke data, niet meer dan 500 GB in ieder geval.