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

We did consider the Commons Clause when investigating our own licensing approach, but ended up concluding that its definition of "Sell" were actually much vaguer than we felt comfortable with:

  “Sell” ...a product or service whose value derives, entirely or 
  substantially, from the functionality of the Software.
I realize that opinions might differ, though.



But then you have put a limitation on use in production instead of sell? Commons Clause might be (too?) vague, but the concept is imho more fair to end users.

Still, I for one applaud you for this step. We need better non-OSS licenses and it's good to be having this discussion.


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".




Consider applying for YC's Spring batch! Applications are open till Feb 11.

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

Search: