18 ms·

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 gatin

by eloff 6y ago

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 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. Until then I expect this kind of almost-FOSS license to become more popular in the future. We're seeing it from many of the recently founded open-source companies in the cloud era.

aloknnikhil 6y ago
And not to mention profiting off of the patches and fixes the maintainers provide and almost never contributing back. I am definitely happy to see attempts to help the creators.
nautilus12 6y ago
Its kind of tricky, in terms of the license how do you end up with that practical limitation? IE how do you distinguish a company thats "too big" (like amazon) to be likely to just be predatorially taking advantage of OSS, vs others.
- eloff 6y ago
  Many new open source companies, like Timescale, Cockroach Labs are going with a managed cloud service offering as their business model. Even RethinkDB pivoted in that direction, although too late in the game for them to survive. So one could make an open-source license specifically reserving that freedom for the creators only. There are probably other business models one could try to protect. The basic idea I think is give as much freedom as possible while also providing some protection for specific use cases that allow the creators to be compensated for their work. It benefits nobody if you create a wild west of freedoms that deny creators a way to finance their work.
- mfreed 6y ago
  Thanks for question. One of the things that Timescale License does (similar with Elastic, Confluent Community, etc.) is to define a "Value Added Service", and basically say you can utilize/distribute the database as part of a SaaS service or product provided that it's a Value Added Service/Product, and basically just isn't offering the (in our case) "TimescaleDB-as-a-Service". Then it becomes a bit of reading the actual definition in the license. In our case: https://www.timescale.com/legal/licenses#section-3-10-value-added-products-or-services https://www.timescale.com/legal/licenses#section-3-10-value-... Unlike the other licenses, we tried to couch part of this definition is specific details that engineers could understand, e.g. "(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 basically one important test would be: if your SaaS service is defining the data schema, indexes, etc., all good. If your users have arbitrary DDL access to the database and do this all themselves, that would "classify" as a "database-as-a-service" offering under this definition.
gigatexal 6y ago
Hopefully the CockroachDB folks are reading this too. The features set behind the enterprise only license seem arbitrary
- foobiekr 6y ago
  These are never arbitrary. They are almost always the result of a lot of internal discussions the outcome of which no one is really happy with.
- sandstrom 6y ago
  Agree, they don't even have backups in the non-enterprise license.
  - ComputerGuru 6y ago
    They don’t have incremental backups. You are of course able to dump the tables, and it’s fully compatible with postgresql export utilities.
sytse 6y ago
This is certainly a great improvement in the license! Kudos to TimescaleDB. I wonder if the new license allows us to offer services on top of TimescaleDB in a multi-tenant setting. GitLab.com has metric monitoring https://docs.gitlab.com/ee/operations/metrics/ https://docs.gitlab.com/ee/operations/metrics/ and we're considering using TimescaleDB to store these. We would not offer direct access to the database. The relevant section in the license https://www.timescale.com/legal/licenses https://www.timescale.com/legal/licenses seems to be the prohibition to "provide any form of software-as-a-service or service offering in which the TSL Licensed Software is offered or made available to third parties to provide time-series database functions or operations, other than as part of Your Value Added Products or Services". I'm not sure if metrics count as time-series database functions or operations.
- mfreed 6y ago
  I posted below, but an important check really is the definition of the "Value Added Product or Service". https://www.timescale.com/legal/licenses#section-3-10-value-added-products-or-services https://www.timescale.com/legal/licenses#section-3-10-value-... On its face, it sounds like your use case is totally allowed under the TSL (and in fact, since the TSL was initially launched in Dec 2018). We have plenty of users who build commercially-available monitoring products/services on top of TimescaleDB. Happy to help if you'd like - our engineers are always available in our Slack Channel: https://slack.timescale.com/ https://slack.timescale.com/ UPDATED: Ha! I didn't realize I was responding to the CEO of GitLab. =)
  - cbaleanu 6y ago
    And that is why HN is my favorite part of the net for about a decade now :)
  - sytse 6y ago
    Thanks for the clarification, glad to hear it is allowed.
    - camkego 6y ago
GordonS 6y ago
Yep, they even quoted some recent HN comments in the article. I have absolutely no doubt that a small but vocal minority will remain unsatisfied. I'm not surprised by this move, as there was barely anything left in the Enterprise license anyway. Personally, I think this is a great move, and one that should in theory leave that vocal minority with very little to actually grumble about.
- EvanAnderson 6y ago
  I likely qualify as "vocal minority". These changes make TimescaleDB something I could entertain using. My concerns related to the "right-to-repair" / "right-to-improve", and with vendor lock-in. These changes address my concerns handily.
Netcob 6y ago
Maybe that's just the natural progression for technologies that are dependencies of other technologies. As a software business you don't want to depend on too many pieces of software (or hardware) that you have little to no control over. Linux is the best example of a solution for that problem - even the tech giants won't bother making their own OS anymore if there is already one out there that they can use and modify. And ISAs (RISC-V) will probably follow that route too. What's interesting though is that businesses seem to be unable to initiate that progress on their own. You need those vocal FOSS people for that, who will tirelessly drag technology towards an ideal we'll never reach... but nobody else will get the ball rolling. FOSS as the basis for entire ecosystems of businesses that would have never existed without it makes total sense, but no business will create it out of thin air. I think this gradual opening up like with TimescaleDB is simply an effect of the wind blowing in that direction. Few will be going full speed, but nobody wants to be left behind.
est31 6y ago
> No right to distribute modified Source Still seems like a serious issue to me.
- rbjorklin 6y ago
  How so? To me it seems like a clause like it is required to protect their business from the "Open Distro for Elasticsearch" scenario.
  - mindcrime 6y ago
    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 the modified source as a "whole" so long as you allow distribution of the patches needed to get to the modified source. I didn't notice at a brief glance where the "new" (or old) Timescale license falls on this point.
    - est31 6y ago
      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.
  - dragonwriter 6y ago
    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.
yjftsjthsd-h 6y ago
> 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?
- xyzzy_plugh 6y ago
  How does AGPL address this?
  - yjftsjthsd-h 6y ago
    The original problem was Amazon "leeching off their software without paying for it". If Amazon shares their changes (as the AGPL requires), then they're contributing, not leeching. If the problem is just that Amazon happens to use a product, or horror of horrors, offer a hosted version... I dunno, I just can't see what the issue is. Is every developer upset about people profiting off their work sending a monthly check to Linus Torvalds for using Linux, Apple for clang and/or GNU for gcc, and the maintainers of their distro of choice? Or is only their software that nobody else is allowed to make money off of?
    - ivalm 6y ago
      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.
      - yjftsjthsd-h 6y ago
        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 don't try and pretend that you're doing something else.
geofft 6y ago
I've been vocal in the past about using an OSI-approved license for one very specific practical reason: it gets you the ability to be packaged for Linux distros etc. that have policies that match the OSI definition (usually by having terms that match the OSI's current definition, not by delegating the decision to the OSI). In my opinion, that's important for adoption - not as important as it used to be in years past, yes, but still important. Even if production users are going to want to run the latest version (or run a commercially-supported binary), the ability to apt-get install something on your laptop to test it has value, as does the ability for other pieces of software in a Linux distro to depend on it. That said, given that they're following a more-or-less "open core" model where there's a clearly FOSS portion (Apache 2) and some non-FOSS extra features on top, I don't think that this is going to be a practical barrier. It looks like the Apache 2 portion of Timescale is substantial enough that you can package it in Linux distros and use it. So in this particular case, I think it doesn't matter whether the rest of it is technically "open source" - it very clearly isn't going to be accepted by Linux distros, and it very clearly is fine for its intended users, and both of those are okay.
- akx 6y ago
  With the release cadence of the current major distros vs the pace at which software is released, it doesn't seem to be worth it to get your stuff in the official repos, to quickly be several major versions behind. You can package debs or rpms for easy install, host them on a server (or set up an apt/rpm repo) just fine even if they're not FOSS.
mindcrime 6y ago
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 dog in this fight, so to speak, as I'm not a user of Timescale. All I'll say is that I hate to see license proliferation in general, and I don't think people should refer to things as "Open Source" if they aren't using an OSI compliant license. To me, if I see a project that's using anything other than a well known, well understood, OSI sanctioned license, I get the heebie-jeebies - because I don't know what the license permits. And I don't want to invest time trying to understand the nuances and ins-and-outs of every random project specific license that comes along. So props to Timescale for making what appear to be improvements to their license. But I'll always advocate using an off-the-shelf license when/where possible. shrug
- fastball 6y ago
  > because I don't know what the license permits That's why you read it...
  - mindcrime 6y ago
    Yes, and then, if I'm smart, spend time and money discussing it with attorneys and/or other experts, who will probably tell me that they don't know either, because there is no body of case law concerning this new and unique "special snowflake" of a license..., etc, etc. Of course I could just "wing it", read through it, and work off my layman's interpretation and hope for the best. Or.. I could choose to stick to well understood and well known licenses that already exist.
    - GordonS 6y ago
      I agree in general that reading licenses as a lay person can be problematic. In this case though, TimescaleDB has blog posts that describe the license in very plain language, and provide clear examples of what you can and can't do - you can basically do anything except provide it as a service. No need to "wing it".
      - 6y ago
hodgesrm 6y ago
> 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 prohibitions in Section 2.2 below, a license to copy and distribute the Timescale Software source code and binaries solely in unmodified standalone form and subject to the terms and conditions of the most current version of this TSL Agreement.
- akulkarni 6y ago
  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-modification https://www.timescale.com/legal/licenses#section-7-2-modific...
  - hodgesrm 6y ago
    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.
ramses0 6y ago
https://people.debian.org/~bap/dfsg-faq.html https://people.debian.org/~bap/dfsg-faq.html https://en.wikipedia.org/wiki/The_Free_Software_Definition#The_Four_Essential_Freedoms_of_Free_Software https://en.wikipedia.org/wiki/The_Free_Software_Definition#T... https://en.wikipedia.org/wiki/Debian_Free_Software_Guidelines#The_guidelines 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 #5 and #6 in the DFSG guidelines. While Mr. Torvalds may have been a much richer man if he prohibited "Linux as a Service", it was the unrestricted freedom given by the GPL which allowed companies like Amazon/AWS to use Linux in the first place.
- igneo676 6y ago
  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.
  - ramses0 6y ago
    (people forget how radical `Copyleft` was at the time of its inception!)
  - mfreed 6y ago
    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-background https://www.timescale.com/legal/licenses#section-0-backgroun... Thanks!
    - igneo676 6y ago
ensignavenger 6y ago
The new Timescale License doesn't only restrict AWS, it restricts anyone not Timescale from offering management services for the Timescale Licensed code. It restricts customers who find that Timescale is unable or unwilling to support them in an agree-able manner from paying some one else to manage it for them. All that is fine and dandy- it is clear that Timescale is open-core, with an Apache-licensed core and proprietary components, just like gitlab and other products. (Timescale is a bit more generous with their proprietary code, though, so that's nice). I will stick with strongly favoring building on open source code, myself, despite this generous offer of no-fee license to use their proprietary software.
- EvanAnderson 6y ago
  > It restricts customers who find that Timescale is unable or unwilling to support them in an agree-able manner from paying some one else to manage it for them. It restricts Customers from going to a Timescale-as-a-Service provider, but I don't see how it restricts the Customer from contracting to have a third-party support the Customer's Timescale installation (or to make changes to the codebase as a work-for-hire). I agree w/ your assessment of their new license insofar as it being proprietary. Their old proprietary license made the product unacceptable for my use, but I am comfortable with the limitations to my rights with the new proprietary license. It has enough "right-to-repair" and ability to avoid vendor lock-in to make me feel comfortable that I could maintain a private fork of my use case was dependent on their software. Edit: My first paragraph was a quick-and-dirty. The child post is absolutely right. The license restricts Customers from providing Timescale-as-a-Service services.
  - doctor_eval 6y ago
    As I understand it, it doesn’t restrict customers from going to a TSAAS provider, it simply means that if you want to provide TSAAS then you need to negotiate a different license from Timescale. The only restriction is that you can’t (necessarily) provide TSAAS for free. To me that’s free as in speech but not free as in beer, and is well within my personal understanding of “free software”. As the saying goes, the right to speech doesn’t imply the right to be heard; likewise, the right to inspect and modify software doesn’t necessarily imply the right to profit from it.
rectang 6y ago
> 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 and almost all of which do the same thing this license does: impose a field-of-use restriction to limit commercial competition. https://en.wikipedia.org/wiki/Source-available_software https://en.wikipedia.org/wiki/Source-available_software By corrupting the term "open source", they are leeching off of the goodwill created by the Open Source movement, and they shouldn't expect people to stop complaining about it until they stop.
- rabidrat 6y ago
  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 charitable work" is horse hockey. I don't care if this is how a hardliner sees it. Linguistics is descriptive, not prescriptive, and this is important enough that I support the migration of "open-source" to include these restrictions. Which, as they point out, affect none of the people using their code, and only the corporations (not people!) who would abuse the goodwill created by the Open Source movement.
  - boogies 6y ago
    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?
    - carlhjerpe 6y ago
      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.
wyldfire 6y ago
> 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 If you're calling your potential licensees leeches, you probably don't have Open Source in mind.
Drdrdrq 6y ago
There is just one tiny little thing missing - the license is not generic. I believe a big driver for success of FOSS licenses is that you don't need a lawyer to use them (either as a user or as developer). We are seeing quite a few businesses using these "Cloud Protection Licenses", but they would all benefit if they agreed on a single, well understood legal document (or at least only a few of them, all generic). I wonder if Commons Clause was just too early?
SquishyPanda23 6y ago
You can't distribute changes to the source code. This is a read-only license. That's both a practical limitation and a serious criticism of a company that markets itself as open source.
mcherm 6y ago
I just want to point out that if Postgres had a similar license then Timescale wouldn't be able to offer their product as a service.
dragonwriter 6y ago
> I'm curious to see if some vocal people here will still not be satisfied with anything short of a OSI-approved FOSS license. It's almost as if the, in practical terms, near-identical standards of the OSI and FSF weren't just picked haphazardly from the air, but actually reflect the result of a thorough and detailed consideration of what features are necessary to unlock the value that OSI pursues mainly from a pragmatic angle and FSF pursues mainly from an ideological angle, and that all the elements of that standard I react in a way that there is a crisp rather than smooth falloff in achieving the sought-after value when not all the criteria are met. > Really the only practical limitation that I can see now is if you're AWS you can't launch a competing service with Timescale Preventing competitive services is the same thing as protecting lock-in and rent extraction. Now, that is a central purpose of copyright and the traditional focus of proprietary licensing, so that’s not a novel focus of licensing at all. It is, however, directly opposed to the central purpose and value of F/OSS to end-users as well as downstream developers, both from a pragmatic/economic and ideological perspective. > That's a glaring short-coming of FOSS licenses No, it's the central purpose and value of F/OSS licenses. It's a shortcoming from the perspective of prospective rentiers, sure, but that's not an incidental side effect unrelated to why F/OSS is sought by those who seek it; freedom from rentiers is the whole point.

by eloff 6y ago

aloknnikhil 6y ago

And not to mention profiting off of the patches and fixes the maintainers provide and almost never contributing back. I am definitely happy to see attempts to help the creators.

nautilus12 6y ago

Its kind of tricky, in terms of the license how do you end up with that practical limitation? IE how do you distinguish a company thats "too big" (like amazon) to be likely to just be predatorially taking advantage of OSS, vs others.

eloff 6y ago
Many new open source companies, like Timescale, Cockroach Labs are going with a managed cloud service offering as their business model. Even RethinkDB pivoted in that direction, although too late in the game for them to survive. So one could make an open-source license specifically reserving that freedom for the creators only. There are probably other business models one could try to protect. The basic idea I think is give as much freedom as possible while also providing some protection for specific use cases that allow the creators to be compensated for their work. It benefits nobody if you create a wild west of freedoms that deny creators a way to finance their work.
mfreed 6y ago
Thanks for question. One of the things that Timescale License does (similar with Elastic, Confluent Community, etc.) is to define a "Value Added Service", and basically say you can utilize/distribute the database as part of a SaaS service or product provided that it's a Value Added Service/Product, and basically just isn't offering the (in our case) "TimescaleDB-as-a-Service". Then it becomes a bit of reading the actual definition in the license. In our case: https://www.timescale.com/legal/licenses#section-3-10-value-added-products-or-services https://www.timescale.com/legal/licenses#section-3-10-value-... Unlike the other licenses, we tried to couch part of this definition is specific details that engineers could understand, e.g. "(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 basically one important test would be: if your SaaS service is defining the data schema, indexes, etc., all good. If your users have arbitrary DDL access to the database and do this all themselves, that would "classify" as a "database-as-a-service" offering under this definition.

gigatexal 6y ago

Hopefully the CockroachDB folks are reading this too. The features set behind the enterprise only license seem arbitrary

foobiekr 6y ago
These are never arbitrary. They are almost always the result of a lot of internal discussions the outcome of which no one is really happy with.
sandstrom 6y ago
Agree, they don't even have backups in the non-enterprise license.
- ComputerGuru 6y ago
  They don’t have incremental backups. You are of course able to dump the tables, and it’s fully compatible with postgresql export utilities.

sytse 6y ago

This is certainly a great improvement in the license! Kudos to TimescaleDB. I wonder if the new license allows us to offer services on top of TimescaleDB in a multi-tenant setting. GitLab.com has metric monitoring https://docs.gitlab.com/ee/operations/metrics/ https://docs.gitlab.com/ee/operations/metrics/ and we're considering using TimescaleDB to store these. We would not offer direct access to the database. The relevant section in the license https://www.timescale.com/legal/licenses https://www.timescale.com/legal/licenses seems to be the prohibition to "provide any form of software-as-a-service or service offering in which the TSL Licensed Software is offered or made available to third parties to provide time-series database functions or operations, other than as part of Your Value Added Products or Services". I'm not sure if metrics count as time-series database functions or operations.

mfreed 6y ago
I posted below, but an important check really is the definition of the "Value Added Product or Service". https://www.timescale.com/legal/licenses#section-3-10-value-added-products-or-services https://www.timescale.com/legal/licenses#section-3-10-value-... On its face, it sounds like your use case is totally allowed under the TSL (and in fact, since the TSL was initially launched in Dec 2018). We have plenty of users who build commercially-available monitoring products/services on top of TimescaleDB. Happy to help if you'd like - our engineers are always available in our Slack Channel: https://slack.timescale.com/ https://slack.timescale.com/ UPDATED: Ha! I didn't realize I was responding to the CEO of GitLab. =)
- cbaleanu 6y ago
  And that is why HN is my favorite part of the net for about a decade now :)
- sytse 6y ago
  Thanks for the clarification, glad to hear it is allowed.
  - camkego 6y ago

GordonS 6y ago

Yep, they even quoted some recent HN comments in the article. I have absolutely no doubt that a small but vocal minority will remain unsatisfied. I'm not surprised by this move, as there was barely anything left in the Enterprise license anyway. Personally, I think this is a great move, and one that should in theory leave that vocal minority with very little to actually grumble about.

EvanAnderson 6y ago
I likely qualify as "vocal minority". These changes make TimescaleDB something I could entertain using. My concerns related to the "right-to-repair" / "right-to-improve", and with vendor lock-in. These changes address my concerns handily.

Netcob 6y ago

Maybe that's just the natural progression for technologies that are dependencies of other technologies. As a software business you don't want to depend on too many pieces of software (or hardware) that you have little to no control over. Linux is the best example of a solution for that problem - even the tech giants won't bother making their own OS anymore if there is already one out there that they can use and modify. And ISAs (RISC-V) will probably follow that route too. What's interesting though is that businesses seem to be unable to initiate that progress on their own. You need those vocal FOSS people for that, who will tirelessly drag technology towards an ideal we'll never reach... but nobody else will get the ball rolling. FOSS as the basis for entire ecosystems of businesses that would have never existed without it makes total sense, but no business will create it out of thin air. I think this gradual opening up like with TimescaleDB is simply an effect of the wind blowing in that direction. Few will be going full speed, but nobody wants to be left behind.

est31 6y ago

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

rbjorklin 6y ago
How so? To me it seems like a clause like it is required to protect their business from the "Open Distro for Elasticsearch" scenario.
- mindcrime 6y ago
  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 the modified source as a "whole" so long as you allow distribution of the patches needed to get to the modified source. I didn't notice at a brief glance where the "new" (or old) Timescale license falls on this point.
  - est31 6y ago
    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.
- dragonwriter 6y ago
  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.

yjftsjthsd-h 6y ago

> 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?

xyzzy_plugh 6y ago
How does AGPL address this?
- yjftsjthsd-h 6y ago
  The original problem was Amazon "leeching off their software without paying for it". If Amazon shares their changes (as the AGPL requires), then they're contributing, not leeching. If the problem is just that Amazon happens to use a product, or horror of horrors, offer a hosted version... I dunno, I just can't see what the issue is. Is every developer upset about people profiting off their work sending a monthly check to Linus Torvalds for using Linux, Apple for clang and/or GNU for gcc, and the maintainers of their distro of choice? Or is only their software that nobody else is allowed to make money off of?
  - ivalm 6y ago
    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.
    - yjftsjthsd-h 6y ago
      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 don't try and pretend that you're doing something else.

geofft 6y ago

I've been vocal in the past about using an OSI-approved license for one very specific practical reason: it gets you the ability to be packaged for Linux distros etc. that have policies that match the OSI definition (usually by having terms that match the OSI's current definition, not by delegating the decision to the OSI). In my opinion, that's important for adoption - not as important as it used to be in years past, yes, but still important. Even if production users are going to want to run the latest version (or run a commercially-supported binary), the ability to apt-get install something on your laptop to test it has value, as does the ability for other pieces of software in a Linux distro to depend on it. That said, given that they're following a more-or-less "open core" model where there's a clearly FOSS portion (Apache 2) and some non-FOSS extra features on top, I don't think that this is going to be a practical barrier. It looks like the Apache 2 portion of Timescale is substantial enough that you can package it in Linux distros and use it. So in this particular case, I think it doesn't matter whether the rest of it is technically "open source" - it very clearly isn't going to be accepted by Linux distros, and it very clearly is fine for its intended users, and both of those are okay.

akx 6y ago
With the release cadence of the current major distros vs the pace at which software is released, it doesn't seem to be worth it to get your stuff in the official repos, to quickly be several major versions behind. You can package debs or rpms for easy install, host them on a server (or set up an apt/rpm repo) just fine even if they're not FOSS.

mindcrime 6y ago

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 dog in this fight, so to speak, as I'm not a user of Timescale. All I'll say is that I hate to see license proliferation in general, and I don't think people should refer to things as "Open Source" if they aren't using an OSI compliant license. To me, if I see a project that's using anything other than a well known, well understood, OSI sanctioned license, I get the heebie-jeebies - because I don't know what the license permits. And I don't want to invest time trying to understand the nuances and ins-and-outs of every random project specific license that comes along. So props to Timescale for making what appear to be improvements to their license. But I'll always advocate using an off-the-shelf license when/where possible. shrug

fastball 6y ago
> because I don't know what the license permits That's why you read it...
- mindcrime 6y ago
  Yes, and then, if I'm smart, spend time and money discussing it with attorneys and/or other experts, who will probably tell me that they don't know either, because there is no body of case law concerning this new and unique "special snowflake" of a license..., etc, etc. Of course I could just "wing it", read through it, and work off my layman's interpretation and hope for the best. Or.. I could choose to stick to well understood and well known licenses that already exist.
  - GordonS 6y ago
    I agree in general that reading licenses as a lay person can be problematic. In this case though, TimescaleDB has blog posts that describe the license in very plain language, and provide clear examples of what you can and can't do - you can basically do anything except provide it as a service. No need to "wing it".
    - 6y ago

hodgesrm 6y ago

> 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 prohibitions in Section 2.2 below, a license to copy and distribute the Timescale Software source code and binaries solely in unmodified standalone form and subject to the terms and conditions of the most current version of this TSL Agreement.

akulkarni 6y ago
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-modification https://www.timescale.com/legal/licenses#section-7-2-modific...
- hodgesrm 6y ago
  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.

ramses0 6y ago

https://people.debian.org/~bap/dfsg-faq.html https://people.debian.org/~bap/dfsg-faq.html https://en.wikipedia.org/wiki/The_Free_Software_Definition#The_Four_Essential_Freedoms_of_Free_Software https://en.wikipedia.org/wiki/The_Free_Software_Definition#T... https://en.wikipedia.org/wiki/Debian_Free_Software_Guidelines#The_guidelines 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 #5 and #6 in the DFSG guidelines. While Mr. Torvalds may have been a much richer man if he prohibited "Linux as a Service", it was the unrestricted freedom given by the GPL which allowed companies like Amazon/AWS to use Linux in the first place.

igneo676 6y ago
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.
- ramses0 6y ago
  (people forget how radical `Copyleft` was at the time of its inception!)
- mfreed 6y ago
  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-background https://www.timescale.com/legal/licenses#section-0-backgroun... Thanks!
  - igneo676 6y ago

ensignavenger 6y ago

The new Timescale License doesn't only restrict AWS, it restricts anyone not Timescale from offering management services for the Timescale Licensed code. It restricts customers who find that Timescale is unable or unwilling to support them in an agree-able manner from paying some one else to manage it for them. All that is fine and dandy- it is clear that Timescale is open-core, with an Apache-licensed core and proprietary components, just like gitlab and other products. (Timescale is a bit more generous with their proprietary code, though, so that's nice). I will stick with strongly favoring building on open source code, myself, despite this generous offer of no-fee license to use their proprietary software.

EvanAnderson 6y ago
> It restricts customers who find that Timescale is unable or unwilling to support them in an agree-able manner from paying some one else to manage it for them. It restricts Customers from going to a Timescale-as-a-Service provider, but I don't see how it restricts the Customer from contracting to have a third-party support the Customer's Timescale installation (or to make changes to the codebase as a work-for-hire). I agree w/ your assessment of their new license insofar as it being proprietary. Their old proprietary license made the product unacceptable for my use, but I am comfortable with the limitations to my rights with the new proprietary license. It has enough "right-to-repair" and ability to avoid vendor lock-in to make me feel comfortable that I could maintain a private fork of my use case was dependent on their software. Edit: My first paragraph was a quick-and-dirty. The child post is absolutely right. The license restricts Customers from providing Timescale-as-a-Service services.
- doctor_eval 6y ago
  As I understand it, it doesn’t restrict customers from going to a TSAAS provider, it simply means that if you want to provide TSAAS then you need to negotiate a different license from Timescale. The only restriction is that you can’t (necessarily) provide TSAAS for free. To me that’s free as in speech but not free as in beer, and is well within my personal understanding of “free software”. As the saying goes, the right to speech doesn’t imply the right to be heard; likewise, the right to inspect and modify software doesn’t necessarily imply the right to profit from it.

rectang 6y ago

> 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 and almost all of which do the same thing this license does: impose a field-of-use restriction to limit commercial competition. https://en.wikipedia.org/wiki/Source-available_software https://en.wikipedia.org/wiki/Source-available_software By corrupting the term "open source", they are leeching off of the goodwill created by the Open Source movement, and they shouldn't expect people to stop complaining about it until they stop.

rabidrat 6y ago
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 charitable work" is horse hockey. I don't care if this is how a hardliner sees it. Linguistics is descriptive, not prescriptive, and this is important enough that I support the migration of "open-source" to include these restrictions. Which, as they point out, affect none of the people using their code, and only the corporations (not people!) who would abuse the goodwill created by the Open Source movement.
- boogies 6y ago
  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?
  - carlhjerpe 6y ago
    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.

wyldfire 6y ago

> 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 If you're calling your potential licensees leeches, you probably don't have Open Source in mind.

Drdrdrq 6y ago

There is just one tiny little thing missing - the license is not generic. I believe a big driver for success of FOSS licenses is that you don't need a lawyer to use them (either as a user or as developer). We are seeing quite a few businesses using these "Cloud Protection Licenses", but they would all benefit if they agreed on a single, well understood legal document (or at least only a few of them, all generic). I wonder if Commons Clause was just too early?

SquishyPanda23 6y ago

You can't distribute changes to the source code. This is a read-only license. That's both a practical limitation and a serious criticism of a company that markets itself as open source.

mcherm 6y ago

I just want to point out that if Postgres had a similar license then Timescale wouldn't be able to offer their product as a service.

dragonwriter 6y ago

> I'm curious to see if some vocal people here will still not be satisfied with anything short of a OSI-approved FOSS license. It's almost as if the, in practical terms, near-identical standards of the OSI and FSF weren't just picked haphazardly from the air, but actually reflect the result of a thorough and detailed consideration of what features are necessary to unlock the value that OSI pursues mainly from a pragmatic angle and FSF pursues mainly from an ideological angle, and that all the elements of that standard I react in a way that there is a crisp rather than smooth falloff in achieving the sought-after value when not all the criteria are met. > Really the only practical limitation that I can see now is if you're AWS you can't launch a competing service with Timescale Preventing competitive services is the same thing as protecting lock-in and rent extraction. Now, that is a central purpose of copyright and the traditional focus of proprietary licensing, so that’s not a novel focus of licensing at all. It is, however, directly opposed to the central purpose and value of F/OSS to end-users as well as downstream developers, both from a pragmatic/economic and ideological perspective. > That's a glaring short-coming of FOSS licenses No, it's the central purpose and value of F/OSS licenses. It's a shortcoming from the perspective of prospective rentiers, sure, but that's not an incidental side effect unrelated to why F/OSS is sought by those who seek it; freedom from rentiers is the whole point.