Advising on technology means understanding it, not just describing it.

The hardest questions in technology law are the ones that cross the line between the legal department and the engineering team. A contract sits on one side. Source code, dependencies, and system architecture sit on the other. Most lawyers are fluent on one side of that line. My work has been learning to read both.

I am a technology lawyer with sixteen years at the intersection of software and commercial law. I graduated in France, holding two master's degrees: in Business and Commercial law and in Tax law, in the civil-law tradition. I am admitted to the Sofia Bar. I hold certifications in cybersecurity and cloud infrastructure, because the fastest way to lose a technology client's confidence is to misunderstand the thing being advised on.

My experience spans both sides of the table: procurement and supplier integration through fourteen acquisitions at IBM, then advising on IT agreements, corporate governance, and cross-border M&A for companies operating throughout Europe. The perspective changes once you have negotiated against your own former positions.

I am increasingly focused on the legal risks beneath software itself: open-source licensing, AI regulation, and the distance between what companies assume about their code and what the law requires. The Beyond the Source Code series follows that work as it develops.

The questions I keep returning to: whether a codebase can survive due diligence, what a licence change does to a contract stack, where AI-generated code sits in copyright, and how security regulation redraws liability between companies. These are the problems this site exists to work through.