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

Thanks for drawing attention to Clause 2.1 (d).

The original intent of that clause was to avoid us needing to support modified versions that were deployed to production. (Note: We provide a lot of free support in our 4000+ member Slack channel [0].)

But that clause was written 1.5 years ago, and a lot has changed since then. There’s actually an internal debate right now on whether we need to keep it. So thank you and HN for spurring this discussion!

[0] https://slack.timescale.com/






If you intend to change it to allow running open-sourced changes, you might consider allowing changes submitted to you privately too, for vulnerability reports.

Thanks for the input, will bring it back to the team for discussion.

(Note: I really appreciate getting this kind of feedback openly from the community, so thank you :-)


One possible approach compatible with true software freedom and the usual definition of open source is not to restrict use of modified versions of the code, but instead to use naming to distinguish between the two, and only support the unmodified version.

For example, the code build system could have variables for the name and maybe the logo and other trademark/brand-ish things, and the public codebase could be configured by default to call itself Timescale Community DB or Timescale Custom DB or some other name instead of TimescaleDB. Your private build would simply substitute the json file with those data values and maybe point to logos that aren't in the repo instead of generic ones that are, or something similar to that.

You'd also have the option to use any mixture of trademark law or copyright conditions to restrict the commercial version's name and branding assets.

All of the options I described above are used in reality by various projects out there. For example, the git repository for VS Code OSS has a product.json file with most of the customization points (not all) that MS changes in building their supported VS Code release, TeX and Red Hat apply naming restrictions, and Red Hat also has rules in their support contract.


It's an interesting idea. We'll consider it. Thanks!

Could you not just say "we don't support modified versions"? This seems like throwing the baby out with the bathwater a bit.

It's a dual-edged sword: Not supporting modified versions means that there are potentially unhappy users.

But we also understand the motivation behind wanting to run a modified version.

This is something we are now actively discussing internally.

Thanks!


You could drop it, but require changes to be submitted back or themselves be source available.



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

Search: