The phrasing "such as" in "such as through use of the Timescale Data Definition Interfaces" looks to me like it can be interpreted as saying "Including but not limited to"
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).
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.
If I have a table that records timeseries data and then another table that has a customer-provided extensible set of metadata where a customer can define columns and other related tabular data, would that violate the license? The customer doesn't have a direct, like, psql level of access but the API intentionally provides a very similar level of interaction.
Does this qualify as providing Data Definition Interfaces? If none of those additional columns and such appear on tables set up as timescale tables does that make any difference?
The Timescale License only covers the TimescaleDB code. Postgres code continues to be covered by the OSS PostgreSQL License [0].
So putting aside the question about API vs. psql level (again, the Timescale License was drafted to enabled this for "Value Added Services", e.g., where "such value-added products or services are not primarily database storage or operations products or services"), this license wouldn't apply for non-Timescale code.
[Timescale co-founder here]
[0] https://github.com/timescale/timescaledb/blob/master/NOTICE
I appreciate from your POV this probably is silly but for us it’s very helpful to have explicit clarity since investors are questioning and demand certainty. I once had to rewrite https handshakes because a lawyer thought export compliance laws would be violated, so hopefully you understand my trepidation :-)
One other bug report on the license language front, this language could be construed to prohibit uses like Prometheus--unless there's a definition of operations products I missed (possible).
> are not primarily database storage or operations products
Suggested edit:
> are not primarily database storage or *database operations products*
Yes, database is a modifier to both storage and operations: database (storage or operations) products.
It's a good edit; will keep in mind.
(For good reason, we generally just don't like to "update" the text of the license too much, even for minor nits.)
Thanks!
Understood. If you see the other thread regarding the "such as" language, there is a serious edit that you can batch-up and repair to reflect your intentions with this one.
The "such as" language, retains your right to sue anyone for license violations if their API allows any customer action that causes structure changes indirectly, via the DDL, even under the hood (materialized views, too, presumably). That's way way more use cases than just repackaging TSDB as a service. That's a landmine, which when people compare and choose databases, they'd just assume avoid, even if otherwise comfortable with a cloud-protective license. Making this clearer and less onerous probably will probably pay for itself with a wider top-of-funnel for the product with more people more confident in the license.
The "We Clarified It In a Thread on Hacker News Public License" is probably not as ideal as updating the places that need clarification. :-P
Hi Eric, thanks for taking a close look at our license.
I'd like to dispel some misconceptions:
The core of TimescaleDB is Apache2. Advanced features are under the Timescale License.
Regarding this:
That's not correct, and we took pains to clarify that in the license: Strictly speaking, if you provide Data Definition Interfaces (DDL) to customers via a SaaS service (ie you are running a TimescaleDBaaS - which applies to < 0.000001% of all possible users) you are in violation of the license. But otherwise you are fine.If you are looking for more votes of confidence, today there are literally millions of active TimescaleDB instances, including by large companies like Walmart, Comcast, IBM, Cisco, Electronic Arts, Bosch, Samsung, and many many smaller ones. [2]
If you have any other questions, I'm happy to answer them here, or offline (ajay at timescale dot com).
[1] https://www.timescale.com/legal/licenses#section-3-5-timesca...
[2] https://www.timescale.com/