Live data from Hacker News

An update to the Timescale license

blog.timescale.com

161–170 of 210 posts

Re: An update to the Timescale license

#161

I wish more vendors would move this way. The rise of cloud computing has made it clear that people want to buy services, not software licenses. Too many (DB) vendors keep trying to sell licenses with a heavy sales process, and barely have a working cloud offering while complaining about AWS.

This exactly! All the stuff from Redis, Elastic and others whilst they have terrible 'cloud' offerings, of course I'd rather use Aws, they make it really simple, reliable and don't charge too much, meanwhile none of these have terraform plugins and the price is insane.

Re: An update to the Timescale license

#164
post #78

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. I don't have a problem with the terms of their license. Use whatever license you want — just don't call it "open source" ! From the blog post... This is problematic: > open-source in spirit It ain't. It is firmly in the spirit of "source available" licenses, which have a decades-long history…

I have a different take on this. It is open source in spirit. It has all the same freedoms of an OSI open source license with one restriction that matters to maybe half a dozen companies like AWS. Open source is the closest established concept to compare this to. So to say it's open source in spirit, or similar to open source seems to be a legitimate communication device. That's like trying to describe a nectarine wi…

> how would you communicate it if you worked in their marketing department, if you're being honest?

I'd emphasize that both an "Open Source" offering and a more complete "Permissive Source Available" offering were available. The goal would be to contrast the source-available offering favorably with closed-source proprietary offerings, rather than to invite, needlessly, a possibly unflattering comparison with Open Source.

But how about just not picking a fight with the Open Source community?

The argument over field-of-use restrictions is anything but new, so going in with the notion you're going to either win everybody over or that people are going to quietly roll over is foolish.

The other possibility is that you deliberately pick a fight with the Open Source community for the sake of publicity. Some marketers are cynical enough to do that, but I'm not — and Timescale are not taking a combative approach and don't seem to be either.

But people really ought to know by now that attempting to coopt the term "Open Source" is certain to provoke an infuriated and vocal response. This latest wave has been going on for what, a year or two by now?

Re: An update to the Timescale license

#165

Earlier quoted context omitted.

Hard disagree. The OSI may have "Open Source" in its name, but we decide what "open source" means. And I agree with the 'spirit' of open source, which is based in RMS' inability to replace code on his printer. The right to study the code running on your hardware, the right to make modifications to it, the right to distribute those modifications. This "it's not open-source unless you allow Amazon to profit from your c…

> but we decide what "open source" means Well, "we" in the Open Source movement decided that it means not restricting what users do with their code. I don't understand what's so hard about this. Overwhelmingly, the biggest players in the Open Source ecosystem have consistently been saying, "call it whatever you want, just be clear that you're not the same as us." And the response from a lot of people has been, "no, y…

"Source Available" encompasses a wide gamut of licenses. I think it is fair to say that the new TLS license is closer in spirit to "open source" than the old one, or say Gitlab's enterprise license.

Re: An update to the Timescale license

#166

Earlier quoted context omitted.

The problem with agpl is that no companies want to touch it. It's too restrictive if you ever want to integrate something with your internal proprietary moneymaking code.

Doesn't that accomplish the goal then? Make your project AGPL and with a commercial license, so only you will be able to make it a commercial business as other big cloud companies don't want to touch it.

The problem is that Amazon could still do it, they're just on that scale, while most common companies would shy away as they don't have the Amazon budget for abusing AGPL right.

I hope in the future the Elastic, TimeScale, Confluent and any other "fuck Amazon" license could be merged into one and kind of standardized on as many freedoms as possible, while keeping AWS out of it.

Re: An update to the Timescale license

#167
post #48

Earlier quoted context omitted.

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.

I don't agree, Josh. Certainly not v1 (which, AFAIK, is the only version in use). I doubt v2 could gain broad support either.

Re: An update to the Timescale license

#168

Just curious, what does distributing sourcecode mean? If I fork on github and push a change, am I then distributing sourcecode?

Yes.

That is quite weird, i guess they'd never go after people for doing this "the right way". But it's not nice being in breach of license without ill intent.

Re: An update to the Timescale license

#169
post #49
post #40

Earlier quoted context omitted.

Another side question, please. How does TimescaleDB compare to Clickhouse? Since you mentioned compression, I've been using Clickhouse to store bitemporal data, and have been amazed by its speed and compression levels. Unfortunately it's lacking in terms of relational modeling. Would I get the best of two worlds with TimescaleDB? What are the tradeoffs?

Compression and aggregation performance in TimescaleDB is much worse than ClickHouse - it represents a different tradeoff, you trade relational features for raw speed. TimescaleDB is basically (very) fancy PostgreSQL sharding and row-oriented, while ClickHouse is a column store. Depending on what you need to do, ClickHouse dictionaries and JOINs might be good enough.

There is no technical tradeoff here. PostgreSQL could add a batched, vectorized and JITed execution engine, and ClickHouse could add "relational features". Either one would of course be a significant engineering project, but there is no fundamental breakthrough required. A small matter of programming as they say.

Re: An update to the Timescale license

#170

Earlier quoted context omitted.

Hard disagree. The OSI may have "Open Source" in its name, but we decide what "open source" means. And I agree with the 'spirit' of open source, which is based in RMS' inability to replace code on his printer. The right to study the code running on your hardware, the right to make modifications to it, the right to distribute those modifications. This "it's not open-source unless you allow Amazon to profit from your c…

RMS created Free Software, not Open Source. Open Source is something that the OSI made up.

IIRC OSI didn't make it up. OSI was created to codify the existing use of the term
Post reply on HN