The issue is the 'such as', which reads to me as indicating that providing an API endpoint that can add fields would also be a way of letting the customer modify the database schema and therefore covered.
Which means that building a SaaS app backed by timescale that has any level of customisation exposed to the user appears to be prohibited.
This seems a rather stronger level of prohibition than stopping people directly competing with you, and would suggest that if it's intended it would help to make it more explicit, and if it isn't then an explicit statement of that would be worth adding.
But I appreciate the feedback on how we could make our language clearer. Will share with the team!
a) Oracle buys TimescaleDB
b) Oracle sues any of 1000+ SaaS apps that have decent revenue and they can identify
c) The other 900 suddenly have massive due diligence issues even if not sued
I understand from your perspective this whole discussion probably looks silly, because you know what’s in your mind.
There are just too many stories of this blowing up in someone’s face (mostly due to legal, not due to actual enforcement) :/
My interpretation doesn't hinge on the DDL/DML question. If what you said is your intent, the legal language used is wrong and you should fix it. Consider this a bug report. Here's a source!
https://www.law.cornell.edu/definitions/uscode.php?width=840...
In order for the license to be usable, you need to be limitative here.
It was a little cumbersome to list every DDL SQL command, which why it uses that language. But that is the intent.
If you have a specific question, happy to answer it here (or offline)
Also, we used this language deliberately to provide more clarity. DDL vs DML is a pretty clear line to most developers who use TimescaleDB (vs some other companies who use language like, "you can't compete with us" etc).