3 ms·

I really appreciate that the linked article uses the phrasing "source-available", the lower case "free", and doesn't use the phrase "open source". Terminology m

I really appreciate that the linked article uses the phrasing "source-available", the lower case "free", and doesn't use the phrase "open source". Terminology matters a lot. For me, a lot of the value in Free software comes from being able to make modifications to the software (either yourself, or by hiring others), and generally being in control of your own "software destiny". With that in mind, I think it's important to call attention to this license's prohibition of running modified versions in production. This prohibition applies regardless of your modifications being distributed (and in fact, later in the license, distribution of modifications is expressly prohibited as well): Clause 2.1 (d): "A license to prepare, compile, and test Derivative Works of the TSL Licensed Software Source Code solely in a Non-Production Environment ... I've often pined for visibility into the source code of proprietary software that I use. I suppose this is a "win" for TimescaleDB in my mind over source-unavailable proprietary software. In the end, however, this license means it's still just proprietary software.

pot8n 6y ago
Again, here comes the self-entitled "This is outrageous and it is a closed source license! Why shouldn't I make money off work that took blood and tears and millions of dollars of many people while they, the actual authors struggle to have dinner at the table from their own work?" comment on HN whenever a company relicenses their FOSS project. This kind of self-entitlement makes startups think twice before going open source in the first place. OSI FOSS licenses do not protect neither the author nor the work. The author can intend the work to be _free_ while others can simply rebrand it and sell it as a closed source product is if it were their own while the author themselves cannot complain or even know. The source-available license is the only way for the author to keep the work somewhat under control from competitors and quick buck parasites.
Reelin 6y ago
I second this. I'm quite puzzled by the apparent dislike for open source ideals expressed elsewhere in the comments here. Licensing is a complex problem and open source isn't some magical solution. It isn't the right model for every usecase out there and that's OK! Pay to play is sometimes the only fair and workable approach from a business perspective, but that doesn't make it open source. There's nothing wrong with that though! Using terminology correctly is important. Timescale gets the terminology right and I appreciate that. (I also think it's awesome that they're releasing this product for free.)
akulkarni 6y ago
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/ https://slack.timescale.com/
- detaro 6y ago
  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.
  - akulkarni 6y ago
    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 :-)
    - jkaplowitz 6y ago
      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.

pot8n 6y ago

Again, here comes the self-entitled "This is outrageous and it is a closed source license! Why shouldn't I make money off work that took blood and tears and millions of dollars of many people while they, the actual authors struggle to have dinner at the table from their own work?" comment on HN whenever a company relicenses their FOSS project. This kind of self-entitlement makes startups think twice before going open source in the first place. OSI FOSS licenses do not protect neither the author nor the work. The author can intend the work to be _free_ while others can simply rebrand it and sell it as a closed source product is if it were their own while the author themselves cannot complain or even know. The source-available license is the only way for the author to keep the work somewhat under control from competitors and quick buck parasites.

Reelin 6y ago

I second this. I'm quite puzzled by the apparent dislike for open source ideals expressed elsewhere in the comments here. Licensing is a complex problem and open source isn't some magical solution. It isn't the right model for every usecase out there and that's OK! Pay to play is sometimes the only fair and workable approach from a business perspective, but that doesn't make it open source. There's nothing wrong with that though! Using terminology correctly is important. Timescale gets the terminology right and I appreciate that. (I also think it's awesome that they're releasing this product for free.)

akulkarni 6y ago

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/ https://slack.timescale.com/

detaro 6y ago
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.
- akulkarni 6y ago
  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 :-)
  - jkaplowitz 6y ago
    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.