I posted below, but an important check really is the definition of the "Value Added Product or Service".

https://www.timescale.com/legal/licenses#section-3-10-value-...

On its face, it sounds like your use case is totally allowed under the TSL (and in fact, since the TSL was initially launched in Dec 2018). We have plenty of users who build commercially-available monitoring products/services on top of TimescaleDB.

Happy to help if you'd like - our engineers are always available in our Slack Channel: https://slack.timescale.com/

UPDATED: Ha! I didn't realize I was responding to the CEO of GitLab. =)

And that is why HN is my favorite part of the net for about a decade now :)

Thanks for the clarification, glad to hear it is allowed.

It seems to me, herein lies the rub. No whether they can call it open source or not. I am sympathetic to Timescale's situation. (I also love their work) But the big problem IMO is this incredibly hard to judge language about "value-added products or services"

It doesn't really matter what is opined outside of the agreement, and from this conversation, it doesn't seem crystal clear one way or another whether Gitlab's use would be considered value-added or not.

So, do you want to be a developer, project-manager, CTO, or CEO who has to determine if your use of TimescaleDB is considered value-added or not?

Also keep in mind, that to really make this determination requires a court case around the specifics of your usage and situation.

And what if they get a SCO Unix style CEO someday?

I hope we can find a better way as developers and technologists to express whether you can use software like this without vague promises that you won't be litigated, or your use case is probably not in violation of the license.

Hi @camkego We tried pretty hard to define a pretty specific definition of "Value Added Service" for TimescaleDB, which is why the license also has some "custom" aspects rather than just having a general clause about "can't be competitive" with us. So the definition is here, and an example of walking through a "test":

https://www.timescale.com/legal/licenses#section-3-10-value-...

    3.10 "Value Added Products or Services" means products or services developed by or for You that utilize (for example, as a back-end function or part of a software stack) all or parts of the Timescale Software to provide time-series database storage and operations in support of larger value-added products or services (for example, an IoT platform or vertical-specific application) with respect to which all of the following are true:

    (i) such value-added products or services are not primarily database storage or operations products or services;

    (ii) such value-added products or services add substantial value of a different nature to the time-series database storage and operations afforded by the Timescale Software and are the key functions upon which such products or services are offered and marketed; and

    (iii) users of such Value Added Products or Services are prohibited, either contractually or technically, from defining, redefining, or modifying the database schema or other structural aspects of database objects, such as through use of the Timescale Data Definition Interfaces, in a Timescale Database utilized by such Value Added Products or Services.

So for the GitLab monitoring service, given my understand from the short description:

1. Is the service other than primarily a database storage service? [Yes]

2. Does it offer substantial value over a database and is it offered/marketed for a key function other than a database? [Yes, it is a monitoring system, not a database system]

3. Are users of the monitoring system prevented from defining schema and accessing database DDL? [Yes]

Of course, we _very much_ welcome feedback how to make it clearer or more explicit. Our goal is _not_ to create uncertainty.

I think that your use-case would be fine.

Most people don't seem to realize that the idea behind this kind of legalese is to prevent companies like amazon from offering something like "elastic timescaledb" which is mostly an operated timescale service, eating TimescaleDB's (the company) revenue stream. Or similar things happening in either Google cloud or Microsoft Azure.

I can't really blame for that.

Also not a lawyer but it appears the bar is that "(2) the customer is prohibited, either contractually or technically, from defining, redefining, or modifying the database schema or other structural aspects of database objects, such as through use of the Timescale Data Definition Interfaces, in a Timescale Database utilized by such Value Added Products or Services."

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.

Storing JSON or EAV-format data do not require DDL access, and are commonly deployed in many settings, from product/SaaS analytics, IoT, IT/APM monitoring, and others.

That's actually one of the reasons we tried to frame it in terms of interfaces as well.

(Thanks for the question/interest!)

Our data is binary with a complex format (protobuf). We have custom logic to merge these data points. I guess this would not be covered by the license then

Not sure I follow?

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.

I would guess that jsonb columns or Entity-Attribute-Value type of schemas are permitted, but if doing something in a grey area it wouldn't hurt to reach out to the company and get permission in writing (or negotiate a license exception.)

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.