An update to the Timescale license • Hacker News Board

Re: An update to the Timescale license

#201

Post by tormeh » Fri, Sep 25, 2020, 9:42 PM UTC

_msw_ wrote: post #186

tormeh wrote: post #135

Earlier quoted context omitted.

The problem is that it is not truly impossible to integrate into a commercial company. It's more that the license practically requires a lawyer to look at exactly how it'll be used and approve that use. AWS certainly does not shy away from hosting AGPL software. It does prevent AWS from taking the code and running with it though, at least not without a shim. A more permissive license can lead to the Athena/Presto sit…

Disclosure: I work at AWS on infrastructure services I am personally currently unaware of any AGPLv3 licensed software in use in an AWS service. That said, I would be skeptical of advice to use AGPLv3 due to any particular organization's current policy on the license. Regarding Presto, work on the service includes changes that should go upstream. For the changes that are appropriate for upstream (e.g., ones that are…

Redis changed from AGPL to Apache 2 with something they called a Commons Clause, then finally to Redis Source Available License because of cloud providers. Don't really know exactly which event triggered the change, though. I suppose it could have been GCP or Azure instead of AWS. Regardless, AGPL is far less restrictive than people claim it is. It is a particularly strict version of the GPL, but given proper legal review it is unproblematic to use commercially, which cuts both ways as Redis found out.

I think there's a serious amount of FUD around it. I suppose it's because of how rare it is. With more usage, it would probably bee seen as less dangerous.

Re: An update to the Timescale license

#202

Post by boogies » Fri, Sep 25, 2020, 10:32 PM UTC

tormeh wrote: post #201

_msw_ wrote: post #186

Earlier quoted context omitted.

Disclosure: I work at AWS on infrastructure services I am personally currently unaware of any AGPLv3 licensed software in use in an AWS service. That said, I would be skeptical of advice to use AGPLv3 due to any particular organization's current policy on the license. Regarding Presto, work on the service includes changes that should go upstream. For the changes that are appropriate for upstream (e.g., ones that are…

Redis changed from AGPL to Apache 2 with something they called a Commons Clause, then finally to Redis Source Available License because of cloud providers. Don't really know exactly which event triggered the change, though. I suppose it could have been GCP or Azure instead of AWS. Regardless, AGPL is far less restrictive than people claim it is. It is a particularly strict version of the GPL, but given proper legal r…

I agree that there’s a serious amount of FUD around it. I think it’s at least in part because it proliferating could seriously harm Alphabet’s ability to freely grab people’s code to incorporate in their consumer products (YouTube, G Suite, etc.) without reciprocating, and they’ve been careful to semi-subtly spread the FUD (ie. publish https://opensource.google/docs/using/agpl-policy/). https://drewdevault.com/2020/07/27/Anti-AGPL-propaganda.html

Re: An update to the Timescale license

#203

Post by mfreed » Sat, Sep 26, 2020, 12:13 AM UTC

camkego wrote: post #173

sytse wrote: post #137

Earlier quoted context omitted.

Thanks for the clarification, glad to hear it is allowed.

It seems to me, herein lies the rub. No whether they can call it open source or not. I am sympathetic to Timescale's situation. (I also love their work) But the big problem IMO is this incredibly hard to judge language about "value-added products or services" It doesn't really matter what is opined outside of the agreement, and from this conversation, it doesn't seem crystal clear one way or another whether Gitlab's…

Hi @camkego We tried pretty hard to define a pretty specific definition of "Value Added Service" for TimescaleDB, which is why the license also has some "custom" aspects rather than just having a general clause about "can't be competitive" with us. So the definition is here, and an example of walking through a "test":

https://www.timescale.com/legal/licenses#section-3-10-value-...

    3.10 "Value Added Products or Services" means products or services developed by or for You that utilize (for example, as a back-end function or part of a software stack) all or parts of the Timescale Software to provide time-series database storage and operations in support of larger value-added products or services (for example, an IoT platform or vertical-specific application) with respect to which all of the following are true:

    (i) such value-added products or services are not primarily database storage or operations products or services;

    (ii) such value-added products or services add substantial value of a different nature to the time-series database storage and operations afforded by the Timescale Software and are the key functions upon which such products or services are offered and marketed; and

    (iii) users of such Value Added Products or Services are prohibited, either contractually or technically, from defining, redefining, or modifying the database schema or other structural aspects of database objects, such as through use of the Timescale Data Definition Interfaces, in a Timescale Database utilized by such Value Added Products or Services.

So for the GitLab monitoring service, given my understand from the short description:

1. Is the service other than primarily a database storage service? [Yes]

2. Does it offer substantial value over a database and is it offered/marketed for a key function other than a database? [Yes, it is a monitoring system, not a database system]

3. Are users of the monitoring system prevented from defining schema and accessing database DDL? [Yes]

Of course, we _very much_ welcome feedback how to make it clearer or more explicit. Our goal is _not_ to create uncertainty.

Re: An update to the Timescale license

#204

Post by mfreed » Sat, Sep 26, 2020, 12:44 AM UTC

yjftsjthsd-h wrote: post #91

ivalm wrote: post #87

Earlier quoted context omitted.

Timescaledb the company wants to make money from their managed service, thus they are protecting it from competition. That’s fine. They are not true open source but that’s fine too.

Agreed. I don't mind companies selling proprietary software. I do mind companies trying to claim that they're offering open source software when they're actually offering source-available software. With the Apache2 version, Timescale actually appears to be doing both, but I can't find a description of the differences so I can't comment very well; I assume they're doing open core. Which, again, is fine as long as you…

Yes, our offering is of the "open core" nature, although our non-open-source code is covered under the Timescale License (source available, free). For most "open core" companies, this latter part is instead closed-source and paid, hence this terminology also leads to confusion :)

Anyway, here's the link to license pointers in github, and you can find all code there:

https://github.com/timescale/timescaledb/blob/master/LICENSE

    Source code in this repository is variously licensed under the Apache License Version 2.0, an Apache compatible license, or the Timescale License.

    All source code should have information at the beginning of its respective file which specifies its licensing information.

    * Outside of the "tsl" directory, source code in a given file is licensed under the Apache License Version 2.0, unless otherwise noted (e.g., an Apache-compatible license).

    * Within the "tsl" folder, source code in a given file is licensed under the Timescale License, unless otherwise noted.

    When built, separate shared object files are generated for the Apache-licensed source code and the Timescale-licensed source code. The shared object binaries that contain `-tsl` in their name are licensed under the Timescale License.

Re: An update to the Timescale license

#205

Post by dragonwriter » Sat, Sep 26, 2020, 2:13 AM UTC

rbjorklin wrote: post #41

est31 wrote: post #34

Earlier quoted context omitted.

> No right to distribute modified Source Still seems like a serious issue to me.

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

Yes, it is necessary to prevent the core purpose of open source.

Which is fine, proprietary licenses are a valid option. Just don’t pretend it's almost open source. It's a source-available proprietary license designed to prevent the kind of exclusionary rent-extraction whose absence is central to the value proposition of open source.

Re: An update to the Timescale license

#206

Post by _msw_ » Sat, Sep 26, 2020, 2:17 AM UTC

JoshTriplett wrote: post #193

_msw_ wrote: post #167

Earlier quoted context omitted.

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

I'm not suggesting it could trivially become an OSI-approved license. Rather, I think it's much closer in spirit than something like the Timescale or "Commons Clause" or similar licenses, that blatantly discriminate against fields of endeavor (OSD 6) by design. The SSPL, by contrast, is a copyleft license that has a much stronger copyleft than the AGPL. It may potentially be overstepping the intent of what the OSD me…

To me it violates the spirit of OSD9.

Re: An update to the Timescale license

#207

Post by JoshTriplett » Sat, Sep 26, 2020, 6:50 AM UTC

_msw_ wrote: post #206

JoshTriplett wrote: post #193

Earlier quoted context omitted.

I'm not suggesting it could trivially become an OSI-approved license. Rather, I think it's much closer in spirit than something like the Timescale or "Commons Clause" or similar licenses, that blatantly discriminate against fields of endeavor (OSD 6) by design. The SSPL, by contrast, is a copyleft license that has a much stronger copyleft than the AGPL. It may potentially be overstepping the intent of what the OSD me…

To me it violates the spirit of OSD9.

Ah, got it.

I personally feel like the spirit of OSD9 is primarily about not affecting unrelated programs. I think it'd be reasonable to affect related programs. I think the current version of SSPL oversteps wildly in that regard, but I feel like it could be pared back to something that would be consistent with what I'd consider to be the spirit of OSD9 (and the rest of the OSD), while still doing what it seems like the SSPL is trying to do.

In doing so, I'd focus on "such that a user could run an instance of the service using the Service Source Code you make available", and drop all the specific service examples in favor of something like "any software you have made the Program depend on, such that the Program lacks some functionality compared to your service if that software is not present (even if you have made the Program support running without that functionality)". That would be broader than the comparable boundary of the AGPL, but much narrower than the current SSPL, insofar as it would only cover things the Program has been modified to depend on, rather than surrounding hosting infrastructure.

In any case, I don't think it very likely that MongoDB would be willing to make such changes, but if they did, I think it'd be possible to arrive at a license that would pass the OSD.

Re: An update to the Timescale license

#208

Post by _msw_ » Sat, Sep 26, 2020, 7:21 AM UTC

tormeh wrote: post #201

_msw_ wrote: post #186

Earlier quoted context omitted.

Disclosure: I work at AWS on infrastructure services I am personally currently unaware of any AGPLv3 licensed software in use in an AWS service. That said, I would be skeptical of advice to use AGPLv3 due to any particular organization's current policy on the license. Regarding Presto, work on the service includes changes that should go upstream. For the changes that are appropriate for upstream (e.g., ones that are…

Redis changed from AGPL to Apache 2 with something they called a Commons Clause, then finally to Redis Source Available License because of cloud providers. Don't really know exactly which event triggered the change, though. I suppose it could have been GCP or Azure instead of AWS. Regardless, AGPL is far less restrictive than people claim it is. It is a particularly strict version of the GPL, but given proper legal r…

The core Redis code (originally announced on this site in 2009 [1], before Garantia Data started in 2011, or became Redis Labs in 2014) has always been BSD licensed. Only extensions from Redis Labs (e.g., Redis look) were licensed under AGPL, and changed to Commons Clause / Redis Source Available License. Those extensions were never part of an AWS cloud service.

Re: An update to the Timescale license

#209

Post by _msw_ » Sat, Sep 26, 2020, 7:24 AM UTC

boogies wrote: post #202

tormeh wrote: post #201

Earlier quoted context omitted.

Redis changed from AGPL to Apache 2 with something they called a Commons Clause, then finally to Redis Source Available License because of cloud providers. Don't really know exactly which event triggered the change, though. I suppose it could have been GCP or Azure instead of AWS. Regardless, AGPL is far less restrictive than people claim it is. It is a particularly strict version of the GPL, but given proper legal r…

I agree that there’s a serious amount of FUD around it. I think it’s at least in part because it proliferating could seriously harm Alphabet’s ability to freely grab people’s code to incorporate in their consumer products (YouTube, G Suite, etc.) without reciprocating, and they’ve been careful to semi-subtly spread the FUD (ie. publish https://opensource.google/docs/using/agpl-policy/ ). https://drewdevault.com/2020/…

Re: An update to the Timescale license

#210

Post by drpebcak » Sat, Sep 26, 2020, 8:55 AM UTC

kdtsh wrote: post #182

I've been thinking very hard about introducing Timescale as a replacement for Cassandra in an application which is starting to show its age (when it was first built in the early 2010s, Cassandra was the only player in the game - but Cassandra never was a great time-series database). One thing which has made me wary of Timescale is the source-available license - which is great and all, but if the license changes signi…

The distinction they try to make is whether or not timescale is a ‘value added’ thing or not. You can’t provide a customer with a hosted timescaledb for them to use as the service, but you can provide a dashboard that stores data in timescale.