4 ms·

Are you sure? 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 "Inc

by ericb 5y ago

Are you sure? 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"

akulkarni 5y ago
Yes :-) 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).
- ericb 5y ago
  Right, I'm onboard with your stated intent, and the lovely database, and even sympathetic on the cloud provider threat. 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&height=800&iframe=true&def_id=17-USC-1867087701-364936160&term_occur=999&term_src= https://www.law.cornell.edu/definitions/uscode.php?width=840... In order for the license to be usable, you need to be limitative here.
  - akulkarni 5y ago
    Thanks for the feedback, will pass along :-)
- mst 5y ago
  The issue isn't the DDL vs. DML. 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.
  - akulkarni 5y ago
    Practically speaking, there are already 1000s+ SaaS apps built on TimescaleDB (and using the Timescale License features) But I appreciate the feedback on how we could make our language clearer. Will share with the team!
    - Aeolun 5y ago
      I mean, that’s cool, but maybe a bit problematic if the language of the license means they’re all in violation of it. 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) :/
      - ericb 5y ago
        Right, and we're subject to what's in his mind, which we can't know, and what's in his acquirer's mind, which even he can't know!
    - marcinzm 5y ago
      The issue is likely something like this: 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

by ericb 5y ago

Are you sure? 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"

akulkarni 5y ago

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

ericb 5y ago
Right, I'm onboard with your stated intent, and the lovely database, and even sympathetic on the cloud provider threat. 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&height=800&iframe=true&def_id=17-USC-1867087701-364936160&term_occur=999&term_src= https://www.law.cornell.edu/definitions/uscode.php?width=840... In order for the license to be usable, you need to be limitative here.
- akulkarni 5y ago
  Thanks for the feedback, will pass along :-)
mst 5y ago
The issue isn't the DDL vs. DML. 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.
- akulkarni 5y ago
  Practically speaking, there are already 1000s+ SaaS apps built on TimescaleDB (and using the Timescale License features) But I appreciate the feedback on how we could make our language clearer. Will share with the team!
  - Aeolun 5y ago
    I mean, that’s cool, but maybe a bit problematic if the language of the license means they’re all in violation of it. 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) :/
    - ericb 5y ago
      Right, and we're subject to what's in his mind, which we can't know, and what's in his acquirer's mind, which even he can't know!
  - marcinzm 5y ago
    The issue is likely something like this: 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