Poetic Licence

Last week's discussion on VI-Control turned into an unintentional seminar on what 'open source' actually means.

Nando Florestan, a composer and developer learning Clojure, read through the draft licence with unusual care and pointed out something I hadn't thought through properly: the anti-rebranding clause made Ooloi proprietary in practice. Forks would have been impossible without my permission. The OSI definition is clear: that's not open source, regardless of intent.

He was right.

The clause came from experience, not malice. Igor Engraver derailed out of my control, and I didn't want that repeated. But open source is a matter of definition, not sentiment. Trademark protects the name 'Ooloi'. Anything beyond that belongs to the commons.

The fix was simple: remove the modification. Pure MPL 2.0, no amendments. Register the trademark properly. Add a clear policy statement confirming that plugins and applications built using Ooloi's APIs aren't derivative works.

Better to discover it before release than after. The conversation forced me to confront what open source actually means for this project: giving up control while retaining integrity.

Why MPL 2.0

The Mozilla Public Licence sits exactly where Ooloi belongs: halfway between the ideological asceticism of GPL and the cheerful anarchy of MIT. File-level copyleft keeps the core collaborative while leaving everything built upon it entirely free.

Reciprocity without coercion.

If someone improves Ooloi's STM transaction coordinator or gRPC layer, those improvements remain in the commons. If someone builds a sophisticated playback system or commercial notation front-end atop Ooloi, they own it completely. That's how platform infrastructure should work.

The 'for the avoidance of doubt' clarification states what's already true: plugins, extensions, and applications using Ooloi's APIs aren't derivative works. This matters because commercial developers won't participate if they need solicitors to interpret 'Larger Work' provisions. The clarification prevents that friction.

The Alternatives Fail

GPL would poison the plugin ecosystem. The FSF's position on plugins-as-derivatives creates legal ambiguity that kills commercial participation. No professional algorithm vendors, no sophisticated commercial tools, no ecosystem.

Apache/MIT/BSD permits enclosure. Someone could fork Ooloi's core into proprietary software, capturing improvements that should remain shared. For infrastructure intended as commons, permissive licences are actually less free.

AGPL extends copyleft to network usage, which would criminalise legitimate commercial deployments: publishers running collaborative servers, institutions hosting multi-user environments, enterprises managing internal infrastructure.

LGPL adds complex compliance requirements without benefits. MPL 2.0's file-level copyleft provides cleaner separation.

The WordPress Parallel

The economics mirror WordPress's evolution. Core CMS functionality became commoditised infrastructure. Commercial value migrated to themes, plugins, hosting, services. Companies like Automattic built substantial businesses while the core improved collaboratively through thousands of contributors.

Ooloi follows similar logic. What legacy notation systems monetise becomes architectural givens:

• Multiple musician collaboration: natural consequence of STM transactions
• Large ensemble support: linear performance scaling  
• High-quality printing: Skija's cross-platform rendering
• Plugin extensibility: safe operations on immutable data

Commercial opportunities shift to where genuine value exists: sophisticated interfaces, professional algorithms, premium workflows, enterprise services. The core handles infrastructure. The plugins handle musical domain knowledge.

The Ultimate Irony

Under MPL 2.0, a product such as Järvenpää Silence Notator 2.0 (purely hypothetical, right?) could theoretically build atop Ooloi while maintaining proprietary differentiation through proprietary plugins and interface. The core infrastructure they'd no longer need to maintain. The competitive advantages they'd demonstrate through superior musical intelligence.

Whether this happens is irrelevant. The goal is proving that functional programming solves long-standing problems, enabling possibilities previously impractical: real-time collaboration without subscription lock-in, parallel processing without performance collapse, plugin extensibility without architectural fragility.

The licence ensures improvements flow back to the commons while permitting commercial innovation.

Practical Implications

For developers evaluating Ooloi:

Building plugins: Licence them however you want. Sell them, give them away, open-source them. No GPL contamination, no AGPL network copyleft. MPL 2.0 applies to Ooloi, not to your work.

Modifying Ooloi's core: File-level copyleft applies. Modified files must remain MPL 2.0. You can still build proprietary applications using modified Ooloi. Just release your modifications to Ooloi's source files.

Commercial deployment: Run SaaS services, embed in proprietary applications, charge what you like. MPL 2.0 requires nothing from you unless you modify core files.

On Integrity

Licensing isn't a legal appendix to the codebase; it's part of the architecture. A distributed system defines its boundaries through protocols. A licence does the same, only in law instead of syntax.

Open source isn't marketing; it's a contract of trust. You keep the code open not because you must, but because integrity demands it. You protect the name not to hoard it, but to prevent confusion.

Ooloi's licence now mirrors its architecture: clear boundaries, open interfaces, and a shared foundation for whatever might be built next.

---