Live data from Hacker News

An update to the Timescale license

blog.timescale.com

61–70 of 210 posts

Re: An update to the Timescale license

#61
post #56
post #2

It would seem these folks listened to the criticism of their Timescale License here on HN and took it to heart. Right to repair, right to improve, and the gating of enterprise features were the only serious criticisms, and they've been addressed. I tip my metaphorical hat to them. I'm curious to see if some vocal people here will still not be satisfied with anything short of a OSI-approved FOSS license. Really the on…

https://people.debian.org/~bap/dfsg-faq.html https://en.wikipedia.org/wiki/The_Free_Software_Definition#T... https://en.wikipedia.org/wiki/Debian_Free_Software_Guideline... The litmus test has always been: "while you may not want your software used in a weapon of mass destruction (or other purpose you don't agree with), it is not free software / open source unless it can be used for that purpose" ... those are items…

This. It boils down to "words mean things". They're fine being firmly on the side of proprietary-with-some-preservation-of-rights; it is _their_ code after all. Their customers get to decide what level of rights they're happy with putting up with.

They're not Open Source. They're not Free Software. Being part of those communities requires following the norms of those communities.

Re: An update to the Timescale license

#62
This move makes sense; I am trying to think about the implications of this specific license long term, and it seems it strikes a balance between protecting the company from AWS, Azure and GCP, while at the same time offering a relatively straightforward framework for their customers and, down the road, for 3rd party vendors.

If they succeed, this could be the blueprint for many other companies in a similar situation.

Keep up the good work!

Re: An update to the Timescale license

#63

You gotta hand it to them - Mike & Ajay are fantastic at writing blog posts. Either it's all them, or they have someone helping them, but either way the content is really top-notch. Seems like table-stakes for anyone including the dev community when building databases these days.

Aww, thanks =) We are good co-editors for each other!

We have a fun and long co-founder history, actually, going back >20 years. So lots of experience doing so!

Re: An update to the Timescale license

#64
> These licenses attempt to maintain an open-source spirit

No they’re not. Open source licenses are in the open source spirit.

Source available licenses are not.

Free software is free to use for any purpose. If your software comes with nonfree restrictions, it is not only not free software, it is not in the spirit of free software.

This is just more anticompetitive behavior from those that mistakenly believe that IP is property to be guarded with the machinery of the state (and the associated threat of violence for transgressions) to back them up.

Your software either is free to use for all purposes, or it is not. If it’s the latter, why the fake and misleading “in the spirit” posturing? Make a decision and be proud of it instead of pretending you’re something you’re not.

Re: An update to the Timescale license

#65

Earlier quoted context omitted.

How so? To me it seems like a clause like it is required to protect their business from the "Open Distro for Elasticsearch" scenario.

I mean... that's fine if that's what their business requires. It just isn't open source. It's "source available" or "shared source" or something. And there's nothing wrong with that, as long as everybody is up-front about what it is. Edit: to qualify what I just said... I obviously only mean that IF their license doesn't also allow distribution of patch files. You can be OSI compliant and not allow distribution of th…

Yeah it's perfectly fine that they make a product under this license, as going full closed source would be perfectly fine as well. But it's not open source.

Re: An update to the Timescale license

#66
post #56

Earlier quoted context omitted.

https://people.debian.org/~bap/dfsg-faq.html https://en.wikipedia.org/wiki/The_Free_Software_Definition#T... https://en.wikipedia.org/wiki/Debian_Free_Software_Guideline... The litmus test has always been: "while you may not want your software used in a weapon of mass destruction (or other purpose you don't agree with), it is not free software / open source unless it can be used for that purpose" ... those are items…

This. It boils down to "words mean things". They're fine being firmly on the side of proprietary-with-some-preservation-of-rights; it is _their_ code after all. Their customers get to decide what level of rights they're happy with putting up with. They're not Open Source. They're not Free Software. Being part of those communities requires following the norms of those communities.

(people forget how radical `Copyleft` was at the time of its inception!)

Re: An update to the Timescale license

#67
post #48

Earlier quoted context omitted.

> Really the only practical limitation that I can see now is if you're AWS you can't launch a competing service with Timescale by leeching off their software without paying for it. That's a glaring short-coming of FOSS licenses that really should be addressed Then use AGPL?

The AGPL allows Amazon to offer a competing service. It just needs to be open-source. But the cloud vendor's efforts aren't typically with the software itself -- they often run the open-source version unmodified -- but rather with the operations and systems around the software. Mongo's SSPL was trying to block this case by forcing folks to open-source all their surrounding infra (which likely AWS would never do), but…

The SSPL has at least some hope of potentially being a viable FOSS license; the disagreements around that license were around details and implementation, not necessarily critical unfixable issues. Something like the Timescale license fundamentally can never be a FOSS license.

Re: An update to the Timescale license

#68

Earlier quoted context omitted.

> I'm curious to see if some vocal people here will still not be satisfied with anything short of a OSI-approved FOSS license. Don't forget that Timescale can alter the terms of their license at any time. That's the material difference from an OSI-approved license. Here's the relevant term of the TSL Agreement. Emphasis mine: > (c) Distribution of Source Code or Binaries in Standalone Form. Subject to the prohibition…

Not really. Modifications only apply to next versions, doesn't change to prior versions: The modified agreement shall govern any new version of the TSL Licensed Software (and all its constituent source code and binaries) that is officially released as a complete version release by Timescale on or after such Posted Date. https://www.timescale.com/legal/licenses#section-7-2-modific...

Thanks, I was looking for that and could not find it.

The point remains that there's nothing to protect users from changes in licenses like the TSL. It's possible with FOSS licenses provided you own all copyrights but much less likely.

Re: An update to the Timescale license

#69
post #32

Earlier quoted context omitted.

Azure Postgres offers the Apache-2 Edition of TimescaleDB, not the Community Edition (which the TSL applies to). Same with DigitalOcean, Rackspace, Scaleways, Alibaba, etc. So they can continue to offer the Apache-2 Edition, but could not before, and still can't, offer the Community Edition. Community is where a lot of our more advanced features lie: multi-node, columnar compression, continuous and real-time aggregat…

fwiw, I've spent 10 minutes scouring the timescale.com but I can't find any information about the difference between the Apache-2 Edition or the Community edition. Links from your GitHub readme suggest that such information used to be there, but now it's all "cloud" vs "software" - if I choose "software", which of the two editions do I get? I assume this is still a WIP since the recent licensing / business model chan…

The "Software" column of product page [0], which I assume you are referring to, corresponds to our Community Edition, as least from a feature-set edition.

But thanks for the feedback. Always a balance between making things easily understandable and too much "in the weeds." We used to separately show "Community" and "Apache-2" on our feature matrix on product page, but frankly, it was too confusing / too much information for visitors that were just coming to TimescaleDB for the first time. Especially given that the vast, vast majority of deployments are indeed the Community edition.

For a detailed comparison, our docs should explicitly label all community features as "Community Edition". Otherwise, they are Apache-2. For example, see the labelling with compression [1], continuous aggregates [2], etc.

And we continue to provide binary packages for the Apache-2 edition of the TimescaleDB, which you can similarly find through our installation instructions (eg [3]).

[0] https://www.timescale.com/products

[1] https://docs.timescale.com/latest/api#compression

[2] https://docs.timescale.com/latest/api#continuous-aggregates

[3] https://docs.timescale.com/latest/getting-started/installati... ("apt-get timescaledb-oss-postgresql-12")

Re: An update to the Timescale license

#70
post #48

Earlier quoted context omitted.

> Really the only practical limitation that I can see now is if you're AWS you can't launch a competing service with Timescale by leeching off their software without paying for it. That's a glaring short-coming of FOSS licenses that really should be addressed Then use AGPL?

The AGPL allows Amazon to offer a competing service. It just needs to be open-source. But the cloud vendor's efforts aren't typically with the software itself -- they often run the open-source version unmodified -- but rather with the operations and systems around the software. Mongo's SSPL was trying to block this case by forcing folks to open-source all their surrounding infra (which likely AWS would never do), but…

> The AGPL allows Amazon to offer a competing service. It just needs to be open-source.

Sure, but if the problem is "leeching off their software without paying for it", then being obligated to share their changes should fix the "leeching" bit. I mean, is Amazon leeching off Linux by shipping it on all their devices?

Post reply on HN