Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

An update to the Timescale license

blog.timescale.com

Post reply on HN
Print view View original

141–150 of 210 posts

Re: An update to the Timescale license

#141

Post by copascetic »

jeffffff wrote: post #133
rectang wrote: post #119

Earlier quoted context omitted.

> Saying "our software is free for anyone to do anything they want with, except Amazon to profit from" may not be free in letter, but I certainly see it free in spirit. Some people feel just as strongly about imposing field-of-use restrictions to exclude military entities as you do about excluding "trillion dollar companies". Others feel strongly about excluding all commerical usage. But "Open Source" means no field-…

by that argument copyleft licenses aren't open source either? from a practical perspective this license is strictly more permissive than AGPL in that it only excludes cloud companies rather than all non-OSS companies.

How so? Corporations can use and sell software and run services for money that use copyleft software if they want to if they abide by the terms of the license, and some do, whereas the TSL specifically disallows this. How does AGPL exclude "all non-OSS companies"? These companies are choosing not to use AGPL software; that doesn't make AGPL not an open source license. The AGPL doesn't even require source code publication when run over the network unless you modified the code, so if Timescale were licensed with AGPL, Amazon could directly offer Timescale as a service and not even need to provide a source code download link. AGPL obviously does not exclude other companies from merely using the software in other ways, so I really don't see how the TSL is "strictly more permissive".

Re: An update to the Timescale license

#142

Post by copascetic »

boogies wrote: post #100
rabidrat wrote: post #90

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…

What about the AGPL? Wouldn’t it grant “the right to study the code running on your hardware, the right to make modifications to it, the right to distribute those modifications” and provide protection from FAANG profiting without reciprocating, while being OSI and FSF approved?

If Timescale were AGPL Amazon would be free to just run it as a service for profit and all they need to do is publish their modifications to it, if they make any. Amazon has no problem running all kinds of other open source software for profit, and this is what TSL is specifically designed to prevent.

Re: An update to the Timescale license

#143

Post by lmm »

GordonS wrote: post #99
rectang wrote: post #86

Earlier quoted context omitted.

Companies like TimeScale should call themselves "source available companies" in order to signal that they are offering some degree of access to the source (which is good!) while avoiding some of the by-now well-understood pitfalls of trying to commercialize FOSS offerings.

I disagree. "source available" already has a long established meaning, and one that it far more restrictive than the TSL. The TSL actually lets you do a lot - almost anything, really. It's an open source license (I even used little o's!) that is designed to only prevent cloud providers from selling TimescaleDB as a service.

> I disagree. "source available" already has a long established meaning, and one that it far more restrictive than the TSL.

It doesn't really - it's been used to describe a pretty broad range of licenses. "Source available" means you can read the source but do not have all of the rights you'd get from an open source license. Which is the case for TSL.

Re: An update to the Timescale license

#144

Post by scj »

cercatrova wrote: post #126
GordonS wrote: post #99

Earlier quoted context omitted.

I disagree. "source available" already has a long established meaning, and one that it far more restrictive than the TSL. The TSL actually lets you do a lot - almost anything, really. It's an open source license (I even used little o's!) that is designed to only prevent cloud providers from selling TimescaleDB as a service.

Then you could call it a permissive source available license, or other such verbiage. There's no need to continue to call it "open source in spirit."

"The usage of pork broth in an otherwise vegetarian dish is vegetarian in spirit."

I can't help but wonder if they're using the phrase "open source in spirit" to leech the branding of open source (while ironically treating other companies as leeches).

Re: An update to the Timescale license

#145

Post by detaro »

rectang wrote: post #86
igneo676 wrote: post #80

Earlier quoted context omitted.

My comment was more directed toward the grandparent, which had their own set of comments regarding Open Source software. By and large, I'm happy with the announcement and how you're handling these terms carefully. My only nitpick is the repeated statement of: > a source-available license that was open-source in spirit Which, um, it's not. I understand you're trying to thread a needle here and protect your business bu…

Companies like TimeScale should call themselves "source available companies" in order to signal that they are offering some degree of access to the source (which is good!) while avoiding some of the by-now well-understood pitfalls of trying to commercialize FOSS offerings.

"source available" isn't a great term, since it's relatively strongly associated with "you can look but not touch it" licenses.

A dedicated term probably makes sense. Some other licenses in this space have used terms like "fair licenses".

Re: An update to the Timescale license

#146

Post by cercatrova »

scj wrote: post #144
cercatrova wrote: post #126

Earlier quoted context omitted.

Then you could call it a permissive source available license, or other such verbiage. There's no need to continue to call it "open source in spirit."

"The usage of pork broth in an otherwise vegetarian dish is vegetarian in spirit." I can't help but wonder if they're using the phrase "open source in spirit" to leech the branding of open source (while ironically treating other companies as leeches).

That's exactly why they're doing it. They want to have their cake and eat it too.

Re: An update to the Timescale license

#147

Post by hardwaresofton »

> Rights previously granted (and still allowed) under Timescale License

> Right to run unmodified TimescaleDB for internal use

> Right to utilize unmodified TimescaleDB to offer a Value Added Service

> Right to distribute unmodified Source and Binaries as part of Value Added Product

> Right to modify TimescaleDB for internal development and testing, and subsequently upstream modifications to Timescale

Do you can still run modified (or unmodified) "community edition" timescale in an SaaS configuration right?

Also it sounds like you can actually run unmodified TimeScaleDB (Timescale license w/ all the enterprise features) as long as you add some value (is easy setup value? Do I need to like automatically shard or something on top of it?)...

Am I misunderstanding? I'd love to run a postgres aaS provider for fun someday and I'd like to use timescale as one of the supported addons.

Re: An update to the Timescale license

#148

Post by xyzzy_plugh »

doctor_eval wrote: post #118

I’m not much of a fan of AWS, but when Amazon takes a “free as in speech AND beer” product and turns it into SaaS, that’s pretty much the expected outcome since (a) the license allows it and (b) companies exist to make money. Why would Amazon spend more than necessary to create this service? It’s not that they’re intrinsically evil for doing this; it’s literally how the rules are written. If you want to change that w…

> In any case, I think that any academic discussion of the definition of “open” needs to take into account the paradox that perhaps, by requiring dogmatic adherence to the definition of “open”, we cause the world to be more closed. Which is, I think, not what we want.

Thank you for putting this so succinctly.

Re: An update to the Timescale license

#149

Post by xyzzy_plugh »

mfreed wrote: post #25
snarkypixel wrote: post #23

A bit of a side question, but how slow would it be if we were to query the data without using a time-based approach? I.e. "select * from obj where parent_id = " --> Imagine we had billions of obj and a few thousands matching "parent_id" added randomly during the last 5-10 years. Would there be an index on "parent_id" or would it need to read every hypertable for such a query? Basically, I'm trying to understand if Ti…

Internally, a hypertable "partitions" data into 1+ dimensions, typically always by time, but also by other dimensions (esp. for multi-node). Each of these partitions are called a "chunk" (and are actually Postgres tables within the DB). You can also define arbitrary indexes on a hypertable; practically, these index definitions get "pushed down" to all chunks, so an index is built on each chunk. Queries have two-stage…

I haven't read all your docs exhaustively, but how do you solve joining your parallelized query results without running into spill problems? Or rather, how do you solve for spill?

Once your hypertables balloon to large sizes, you may be able to store handily across many Postgres instances, but collating the sub-queries will be costly. Spilling to e.g. S3 is a potential solution, but brings with it a new bag of problems, not to mention cost.

Re: An update to the Timescale license

#150

Post by ramses0 »

mfreed wrote: post #75
igneo676 wrote: post #61

Earlier quoted context omitted.

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.

Appreciate the sentiment. We try pretty hard to be careful to not describe the Timescale Licensed code as Open Source, and typically refer to it as "source available". Of course, a big portion of our code is licensed under Apache 2, which clearly does qualify. From the Timescale License, for example: https://www.timescale.com/legal/licenses#section-0-backgroun... Thanks!

If it matters or not... as an unaffected person, but an open source + license nerd, I like the outcome of what you've done. (and yes... "open source in spirit" seems like your hearts are in the right place).

When you're talking about the licenses I think it's great that you've introduced the talking points of "right to repair/improve" ... that's something which is guaranteed via DFSG (b/c you can do what you want with it), but it's great to see it called out as a more fundamental concept expressed in "non-legalese".

You're also looking at "protections" which could be called out as: "the protection from $CLOUD_PROVIDER taking our work and using it to strangle our company and the people who made it" ... probably with a different wording though.

Have you considered writing down a set of principles / protections which you could rally other businesses around as well? Something like the DFSG guidelines, but organized around protecting potential revenue streams?

What would it look like if you had another option / logo on the creative commons license picker? (ie: "$NO + $CLOUD + $MONEY")... https://creativecommons.org/choose/

What would your "Timescale Monetizeable Source Available Guidelines" look like, and could they be expressed as snappily as you've expresed "Right to Repair" and "Right to Improve"?

Post reply on HN