That's actually one of the reasons we tried to frame it in terms of interfaces as well.
(Thanks for the question/interest!)
The parent poster was asking about "well, isn't it an issue with your TSL definition of 'DDL schema access' if you can store data in JSON or EAV so it doesn't have a 'fixed schema'", and my answer is: No, that's fine.
Just like it would be fine for you to store or use binary/blobs/arrays/whatever. We've seen some crazy/cool use cases like developers storing binary 3D lidar data in TimescaleDB.
In fact, with these "right-to-improve" changes, you could even modify the database to embed custom logic inside TimescaleDB to handle your protobuf format (as opposed to UDFs or application code), and it would still be permitted.
Or just pay for their managed service, you probably don't want to be fiddling around with hosting the database yourself. At least everywhere I've worked we used RDS for precisely that reason.
For Timescale this may not be as relevant, but I do wonder how a license like this would be applicable to systems like Salesforce, which allows you to define a schema of custom fields, or for someone using an Entity-Attribute-Value type of schema. What is a database operation - is summing over a dimension a database operation? Where does data end and schema begin? These licenses are entering uncharted territory.