4 ms·

ClickHouse wins on licensing--Apache. The TimeScale licensing approach, the way it is written, perhaps accidentally, has lots of hidden landmines. The TimeScal

by ericb 5y ago

ClickHouse wins on licensing--Apache. The TimeScale licensing approach, the way it is written, perhaps accidentally, has lots of hidden landmines. The TimeScale license slants toward cloud giant defense to the extent that normal use is perilous. For example, timescale can be used for normal data (postgres) as well, so any rules seem to apply to all your data in the database. The free license only usable available if: 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. My read is that if you let a customer do anything that adds a custom field, or table, or database, or trigger, or anything that is "structural" (even in the regular relational stuff) anywhere in your database (metrics or not), you are in violation. There doesn't seem to be a distinction about whether this is "direct" control or not, or whether a setting indirectly adds a trigger. I don't want to be in a courtroom debating whether a new metric is a "structural change!" Now, none of that might be the intent of the license, but you have to go by what it says, not intentions. The sad part of that is, I, and I'm sure many folks, have no interest in starting a database company, but we can't rally timescale because of legal risk. Looks awesome otherwise, though.

akulkarni 5y ago
[Timescale co-founder here] 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: 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. My read is that if you let a customer do anything that adds a custom field, or table, or database, or trigger, or anything that is "structural" (even in the regular relational stuff) anywhere in your database (metrics or not), you are in violation. There doesn't seem to be a distinction about whether this is "direct" control or not, or whether a setting indirectly adds a trigger. I don't want to be in a courtroom debating whether a new metric is a "structural change!" That's not correct, and we took pains to clarify that in the license: 3.5 "Timescale Data Definition Interfaces" means SQL commands and other interfaces of the Timescale Software that can be used to define or modify the database schema and other structural aspects of database objects in a Timescale Database, including Data Definition Language (DDL) commands such as CREATE, DROP, ALTER, TRUNCATE, COMMENT, and RENAME. [0] 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-timescale-data-definition-interfaces https://www.timescale.com/legal/licenses#section-3-5-timesca... [2] https://www.timescale.com/ https://www.timescale.com/
- 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.
goodpoint 5y ago
> ClickHouse wins on licensing--Apache How so? An end user should prefer a database under a license that protect the developer and users from cloudification/proprietization/SaaS
- goodpoint 5y ago
  On top of that, Yandex requires a very aggressive CLA to be signed by contributors: https://yandex.ru/legal/cla/?lang=en https://yandex.ru/legal/cla/?lang=en This worries me and makes me wonder if they are going for the open-source-only-by-name model. [Please reply instead of giving silent dowvotes.]
  - zX41ZdbW 5y ago
    We don't require Yandex CLA: > As an alternative, you can provide DCO instead of CLA. You can find the text of DCO here: https://developercertificate.org/ https://developercertificate.org/ It is enough to read and copy it verbatim to your pull request. > If you don't agree with the CLA and don't want to provide DCO, you still can open a pull request to provide your contributions. https://github.com/ClickHouse/ClickHouse/blob/master/CONTRIBUTING.md https://github.com/ClickHouse/ClickHouse/blob/master/CONTRIB... Anyway, Yandex CLA will be removed in the upcoming days (it should be already removed).

by ericb 5y ago

akulkarni 5y ago

[Timescale co-founder here] 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: 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. My read is that if you let a customer do anything that adds a custom field, or table, or database, or trigger, or anything that is "structural" (even in the regular relational stuff) anywhere in your database (metrics or not), you are in violation. There doesn't seem to be a distinction about whether this is "direct" control or not, or whether a setting indirectly adds a trigger. I don't want to be in a courtroom debating whether a new metric is a "structural change!" That's not correct, and we took pains to clarify that in the license: 3.5 "Timescale Data Definition Interfaces" means SQL commands and other interfaces of the Timescale Software that can be used to define or modify the database schema and other structural aspects of database objects in a Timescale Database, including Data Definition Language (DDL) commands such as CREATE, DROP, ALTER, TRUNCATE, COMMENT, and RENAME. [0] 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-timescale-data-definition-interfaces https://www.timescale.com/legal/licenses#section-3-5-timesca... [2] https://www.timescale.com/ https://www.timescale.com/

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.

goodpoint 5y ago

> ClickHouse wins on licensing--Apache How so? An end user should prefer a database under a license that protect the developer and users from cloudification/proprietization/SaaS

goodpoint 5y ago
On top of that, Yandex requires a very aggressive CLA to be signed by contributors: https://yandex.ru/legal/cla/?lang=en https://yandex.ru/legal/cla/?lang=en This worries me and makes me wonder if they are going for the open-source-only-by-name model. [Please reply instead of giving silent dowvotes.]
- zX41ZdbW 5y ago
  We don't require Yandex CLA: > As an alternative, you can provide DCO instead of CLA. You can find the text of DCO here: https://developercertificate.org/ https://developercertificate.org/ It is enough to read and copy it verbatim to your pull request. > If you don't agree with the CLA and don't want to provide DCO, you still can open a pull request to provide your contributions. https://github.com/ClickHouse/ClickHouse/blob/master/CONTRIBUTING.md https://github.com/ClickHouse/ClickHouse/blob/master/CONTRIB... Anyway, Yandex CLA will be removed in the upcoming days (it should be already removed).