Hacker News new | past | comments | ask | show | jobs | submit login

I appreciate the discussion here, and as mentioned elsewhere, this has been good motivation for us to revisit this clause in the Timescale License, as a bit has changed since we released it in 2018.

That said, I think a lot of this discussion misattributes the frequency of behaviors. For example, I bet the percentage of organizations that modify the source code of open-source databases like MySQL or Postgres before using them production is some tiny tiny fraction of 1%. While on the other hand, a huge fraction of TimescaleDB users (and MySQL/PG users) use it to build external-facing services and products that they in turn sell to their customers. So it was especially important to us that folks felt confident in their ability to use TimescaleDB in commercial settings.

Anyway, thanks for the thoughts.




I agree with the thoughts on discussion and appreciate that you are taking the time to answer this thread!

Just to clarify: while the percentage of those who exercise this particular freedom (modifying the source and then using it in production) is probably very very small, it is an important freedom to have for a much bigger part of customers. It is an insurance policy that gives users confidence that Timescale Corp will not become user hostile - or if it does, it is still possible to make critical security fixes until a more permanent solution is found.

But I do understand it is difficult to find a solution that would please everyone. I am very curious if you will manage to find a more generic solution to this problem. :) Good luck!


> modify the source code ... before using them production

The freedom-to-modify-and-use and the right-to-repair argument are not restricted to "before using them in production".




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: