Licensing Metadata Is the Hard Part of Music Software
The audio playback is the easy part — rights, splits, territories, and PRO registrations are where the real data model complexity lives
When people imagine building software for musicians, they picture audio players, waveform visualizations, maybe a clean library interface. Those are the visible parts. The hard part is the data you can't hear.
I've spent a significant amount of time working on Composer Catalog, a platform for music composers that manages not just tracks but the licensing metadata that makes those tracks commercially usable. The more I've worked in this space, the more convinced I am that the data model is the actual product — and that most teams underestimate it until they've already built something expensive to undo.
A Track Is Not What You Think
In general software, a "file" is a file. In sync licensing, a track is a legal entity with multiple ownership claims attached to it. Those claims can be fractional, time-limited, territory-specific, and administered by different organizations across different right types.
Even a simple track has:
- Publishing rights — who owns the composition itself, and in what splits
- Master rights — who owns the specific recording
- PRO affiliation — which performing rights organization (ASCAP, BMI, SESAC, etc.) each rights holder is registered with
- PRO registration — whether the work is registered, and under what title
- Publishing deal status — whether the composer has a deal that signs over some or all publishing
Each of these is its own field family, and they interact. An "Is Signed" flag on a track should follow whether a publishing deal exists. An "Is Registered" flag should follow whether the PRO registration number is set. If you hardcode those as checkboxes a composer can flip manually, you'll eventually have data that lies — flags that say "registered" for tracks that were never registered, or "signed" after the deal expired.
This sounds obvious stated directly. It's surprisingly easy to miss when you're focused on shipping the UI.
The Splits Problem
Rights splits are where databases start to fight back.
A composition can have multiple co-writers. Each co-writer has a publishing share. Those shares are supposed to sum to 100%, but the real world doesn't always cooperate — co-publishing deals, sub-publishing arrangements, and administrative deals complicate the arithmetic. Add territory splits (some rights holders only control certain regions), and you're no longer modeling a track. You're modeling a contract.
The naive schema is a writers table with a percentage column. That works until someone has a co-publishing deal in North America but not elsewhere. Now your percentage column needs a territory qualifier. And your validation rule that percentages sum to 100% needs to be applied per-territory, not globally.
This is the kind of thing that feels over-engineered until the first time a music supervisor asks why a track shows up in a library search when it's not cleared for the US market.
Territory Rights Are Genuinely Complicated
Territory handling is the part that breaks most data models built by people who've never worked in music licensing.
Rights are not global by default. A composer might own their work worldwide but have licensed specific territories to publishers. Sub-publishing deals exist specifically to handle this — you sign your UK rights to a UK publisher who works that market while you retain North America. That publisher might also have a sub-publisher in Germany.
The practical implication for software: "can this track be used" is not a yes/no question. It's a question with a territory parameter. Your track model either has to carry that nuance or you ship something that's correct in simple cases and wrong in the cases that matter most.
Most catalog tools I've seen either ignore territory entirely (treating global as the default, which is often wrong) or try to solve it with a flat list of territories per track (which doesn't capture the relationship structure). The right model is closer to a rights grants table with territory as a first-class attribute — which is more work to design, more work to build, and harder to explain to a composer who just wants to add a track.
The PRO Registration Number Field Isn't Optional
One thing that surprised me working on Composer Catalog: the PRO registration number field carries more semantic weight than it appears to.
Sync licensing supervisors use registration numbers to verify works quickly. A track without a PRO registration number is a track that might not be cleared. Whether or not the track is registered, the absence of a number in your system signals incomplete data at exactly the moment a potential placement is on the line.
The registration number also has downstream effects — it should trigger the "Is Registered" status, which affects search filters, which affects whether a track shows up in a "cleared and ready" view. If you design the field as a simple text input with no enforcement, you'll get a catalog full of partially-complete records that nobody can trust.
This is a general lesson that applies to any domain with compliance-adjacent data: fields that look optional often aren't. The optionality is a UI convenience, not a semantic statement about the data's importance.
Why Getting This Wrong Is Expensive
The bad outcome isn't that the software crashes. The bad outcome is that the catalog becomes unusable for commercial purposes — and you only find that out when someone tries to license a track and discovers the data is wrong, incomplete, or ambiguous.
Fixing this after the fact means schema migrations on live data, UI redesigns, and sometimes going back to every catalog entry to fill in fields that didn't exist before. That's a painful conversation to have with users who already uploaded hundreds of tracks under the assumption that the simple model was sufficient.
The better path is to treat the rights model as the core design constraint from the beginning. Not because you need to ship every edge case on day one, but because the schema has to be capable of representing the truth. A schema that can't model co-publishing deals can be extended later, but retrofitting it around existing data is harder than designing for it upfront.
The Data Model Is the Product
There's a version of music catalog software that looks good in demos: clean waveforms, smooth playback, a tidy library view. That version might never handle a real sync licensing deal because the underlying data model can't express what licensing actually requires.
The valuable version is the one where a music supervisor can search for "unencumbered tracks available for North American sync with an ASCAP-registered composer" and get a result they can rely on. That's not an audio engineering problem. It's a data modeling problem.
Composers who use these tools may not think in terms of schemas and relational data. But they know immediately when the software doesn't reflect their actual situation — when the "signed" flag means nothing, when the territory field doesn't exist, when they can't find their registered works in a search because registration status isn't indexed. The software earns trust by being accurate first, and fast second.
Getting the data model right is unglamorous work. It happens before the first line of UI code. It's the kind of work that nobody sees when it's done well — and everyone feels when it wasn't.