I disagree. The free software criteria were defined as they are for a reason. AWS and other cloud vendors are taking advantage, but that is not a good reason to give up on the ideals of the movement. I would be much more comfortable contributing to timescaledb if the license had a date at which it expired to AGPL or some other OSI/DFSG/fourfreedoms license.
The expiry clause is interesting, but I'm not sure it matters in practice. Not many people want to use code several years out of date instead of the current version just because of practically no additional freedoms. Except maybe a potential competitor. I'd be happier to have a reversion to an OSI license if the product stops being maintained or gets acquired and shutdown. That's always a risk with young companies.
I am mainly looking to prevent the timescale corp. from coasting off of their long past work. In such a scenario, the several years out of date code would not be that much different from the current version, because income for timescale would not have been spent on meaningful improvements.
Another benefit is as a check to the timescale corp. in case they start acting up. In such a case, a large contributor or user might pick up maintenance of an old version and start porting it to newer postgresql versions as leverage. Users of TimescaleDB could be reassured that timescale will not abuse them through the licensing situation because there is some backup plan.
Your legal ability to apply patches to the software you run to better suit your needs, and in extreme cases to fork and continue development if the maintainers can't or won't accommodate your usecase. It's kind of the entire point of the open source movement.
The spirit of free software is very much alive in this decision, methinks.
From the text of the Timescale License, 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". Further along, in section 2.2, the following prohibition is laid out: "You agree not to, except as expressly permitted in Section 2.1(d), prepare Derivative Works of any TSL Licensed Software"
That removes the freedom to run your own modifications in production. Pretty incompatible with the spirit of free software.
Personally, I don't have a problem with this, and think it encourages users to upstream their changes.
Not really, and not as much. Not really because one cannot begin using their own changes unless and until the upstreaming process concludes successfully. Not as much because, unlike with open-source licenses, one does not get to keep their copyright.
One of the important reasons I personally use and support open-source is the freedom to not only inspect (which the TSL provides) but to also not have to ask someone else and wait on them to make any changes I need to the software I use. The restriction against production use prevents that.
One of the important reasons I personally don't mind contributing to open-source, is the fact that I get to retain my rights.
> This is only for the parts of the code that are licensed under the Timescale license (most code is not).
This is a moot point because without the parts that are TSL licensed, we'd not be having this discussion.
This was largely my assessment, as well. And the motive behind the work that led to Parity (https://paritylicense.com).