[shadowwolf007]

So this is a very relevant question and I have been trying to figure out if I need to migrate off timescaledb asap coincidentally over the last 2 weeks (We're pre-production anyway, so it's the time to do so!). Doing so has been super low priority, but since you're 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?

[mfreed]

One clarification to the above discussion -- about whether these restrictions also get applied to "even the regular relational stuff" -- which I think is relevant to you (and parent):

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

[shadowwolf007]

Ok thank you!

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 :-)

[Aeolun]

Just keep these comments handy in case you ever need them in court :P

[ericb]

Not the parent, but great to hear that clarification! By the way, doubt I would complain if Prometheus didn't look impressive. :-)

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*

[mfreed]

Oh, English parsing =)

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!

[ericb]

Oh sorry, said Prometheus above, meant TimeScale is impressive!

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