Ilya Shilov Discuss your productContact

Commercial lawyer/Software & IP

Ilya Shilov

I help software teams check the rights to their code before they hand a product to a corporate customer.

  • Open-source components
  • Developer agreements
  • Customer contract
Ilya Shilov
MoscowWorks remotely
Experience
11+ years in commercial law
In-house
8+ years: tech, then life sciences
Deal experience
Licensing, SaaS, OEM/ODM, M&A
Languages
Russian, English

I’ve negotiated software licensing, SaaS and OEM/ODM deals with global tech vendors, structured rights to existing IP and new development, and found a chain-of-title gap in IP due diligence.

§1

Before you hand over your product

A corporate customer may ask who owns your code and what is inside it. I check what you can promise — and what to fix first. That includes the terms of the AI coding tools your team uses.

When this review helps

What you get

  1. 01A short note: what needs a decision before the deal.
  2. 02Confirmed findings with sources — and the important unknowns.
  3. 03Actions for the team: documents, notices, clarifications or code changes.
  4. 04Proposed edits to your customer contract.

Scope

One product, one version, one customer delivery.

Not included

A full code audit, a security review or a guarantee against claims.

Fee

Agreed after a short first call.

§2

What a finding looks like

Illustrative examples, not client matters.

01Open-source componentBefore delivery

Found

A PDF library under AGPL-3.0, changed by your team. The customer’s users reach it over the network.

Why it matters

Section 13 of AGPL-3.0 requires offering those users the Corresponding Source of your modified version — not just a patch.

What to do

Confirm the source-code scope and delivery model. Then meet the licence requirements or replace the component.

Source: GNU AGPL v3, section 13

02Your team’s rightsBefore delivery

Found

A freelancer wrote a key module. The contract covers price and deadlines, but not IP.

Why it matters

Your company may not own that code — or may not be able to prove it.

What to do

Check who holds the rights under the applicable law. Then document the transfer or licence you need.

03Customer contractBefore signing

Found

The draft assigns all IP in the deliverables, “including any pre-existing materials”.

Why it matters

You would give away your reusable modules — and promise rights in third-party code that you cannot assign.

What to do

Separate three things: work made for the customer, your existing materials and third-party components.

Proposed edit · Illustrative excerpt — not a complete contract clause

Struck through = deleted · underlined = added

12.1Supplier assigns to Customer all intellectual property rights in the DeliverablesDeleted: , including any pre-existing materials Added: created specifically for Customer under this Agreement.

Added: 12.2Supplier keeps all rights in its pre-existing materials and grants Customer a non-exclusive licence to use them as part of the Deliverables, on the terms in Schedule 4.

Added: 12.3Third-party and open-source components listed in Annex 3 remain under their own licences.

§3

I publish open-source code myself

  • Open source · Apache-2.0
  • Alpha
  • Runs locally

Veqtor

Ask Claude what changed. Get your counterproposal back in Word.

A local tool for Claude: it reads Word redlines, checks quotes and writes your edits back as real tracked changes. I created it and maintain it.

verify_quotechecks a quote against the text
preflight_editsdry-runs edits before writing
apply_editswrites a new .docx with tracked changes
Contract guides 122 practical guides to English-law contracts, across 18 topics. Read
§4

About

I work on cross-border deals, mostly under English law. I build bilingual templates and negotiation playbooks, and automate document preparation.

Education

Law degree. LL.M. in International Business Law, with distinction.

Writing

Commercial Contracts Decoded — my newsletter on English-law contracts.

Languages

Russian (native), English (C1).

§5

Tell me about your product

A few lines are enough: the product, what the customer asked for, how you deliver it and your deadline. No code or confidential documents yet.

How it works

  1. You send a short, non-confidential description.
  2. I check fit and conflicts. We agree scope, relevant jurisdictions, timing, fee and how files are shared.
  3. You or your technical lead confirm what the customer actually receives.
  4. You get findings, actions and proposed contract edits.

Enquiry

Your customer asks about your code

In a few lines: the product, what the customer asked for, how you deliver it and your deadline. No code or confidential documents yet.

Next: I check fit and conflicts, then we agree scope, jurisdictions, timing and fee.