An update to the Timescale license • Hacker News Board

Re: An update to the Timescale license

#181

Post by slashdev » Fri, Sep 25, 2020, 2:06 PM UTC

rectang wrote: post #164

slashdev wrote: post #159

Earlier quoted context omitted.

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 Sou…

I don't see it is a picking a fight at all, and I'm petty sure that's counter to their intentions. I really don't get why some people get upset here. Nobody is saying it is OSI open source. But it's the next closest thing, so a comparison is natural and effective communication.

Re: An update to the Timescale license

#182

Post by kdtsh » Fri, Sep 25, 2020, 2:17 PM UTC

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 significantly to make it more restrictive then we end up in a tough spot. A constant sticking point of Cassandra is that it's Apache Cassandra - it's very unlikely the license is ever going to become more restrictive, since it's owned by the ASF. This looks like a great development though, and I'm warming even more to further exploring Timescale.

Something I'm still trying to understand: does not allowing database-as-a-service just mean that you can't have, say, an application which abstracts away the details of implementing a Timescale database (e.g. you input some kind of configuration file which describes the details of your deployment) without violating the TSL? Are you still allowed to leverage Timescale in your SaaS?

Re: An update to the Timescale license

#183

Post by sroussey » Fri, Sep 25, 2020, 2:48 PM UTC

rectang wrote: post #119

stavros wrote: post #93

Earlier quoted context omitted.

I would tend to agree. 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. I fear we're letting perfect be the enemy of the good here, and letting the FOSS ecosystem wither and lose incalculable value by letting trillion-dollar corporations exploit the hard work of people for free. If the choice is betwe…

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

> But "Open Source" means no field-of-use restrictions — so although any of you are free to craft your own licenses excluding X, Y, or Z, you don't get to call those licenses "Open Source".

Sounds like public domain. What’s the difference between the two then?

Re: An update to the Timescale license

#184

Post by [deleted] » Fri, Sep 25, 2020, 3:34 PM UTC

ericb wrote: post #153

danShumway wrote: post #123

Earlier quoted context omitted.

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

> Well, "we" in the Open Source movement decided that it means not restricting what users do with their code. The "GPL" is way more onerous. You see, one can only be truly unrestricted by being restricted into taking certain actions. Nothing Orwellian to see here.

[deleted]

Re: An update to the Timescale license

#185

Post by dragonwriter » Fri, Sep 25, 2020, 3:44 PM UTC

slashdev wrote: post #181

rectang wrote: post #164

Earlier quoted context omitted.

> 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 Sou…

I don't see it is a picking a fight at all, and I'm petty sure that's counter to their intentions. I really don't get why some people get upset here. Nobody is saying it is OSI open source. But it's the next closest thing, so a comparison is natural and effective communication.

> But it's the next closest thing

That's not meaningful; there's a reason why the FSF and OSI have very similar criteria that end up being essentially identical in practical application; the value associated with F/OSS isn't on a smooth continuum that varies with proximity to those definitions, there's a very sharp cliff near the edge and this is outside of it.

That other actors are free to commercially exploit, including offering SaaS versions without restriction, the software is a major benefit against vendor lock-in for users, even if they have no desire to exercise that freedom directly, and has important effects on building a diverse, invested community around a piece of software. Restricting this to allow rent extraction, while not unethical (outside of, e.g., the ideological framework of the idealistic Free Software community, as opposed to the F/OSS for pragmatic reasons communiry) in the same way other proprietary-licensed commercial software is not unethical, does not even approximate the value of F/OSS.

Vendors can keep having proprietary rent-protection licenses, they just need to stop trying to convince the Open Source community that they are somehow pragmatically equivalent to Open Source. They aren't, even approximately, and critically that is the entire reason that vendors choose them, so they need to stop the dishonest sales pitches.

Re: An update to the Timescale license

#186

Post by _msw_ » Fri, Sep 25, 2020, 3:51 PM UTC

tormeh wrote: post #135

cercatrova wrote: post #125

Earlier quoted context omitted.

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 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 generally useful, not only of benefit or interest to AWS), PRs are sent. For example: https://github.com/prestosql/presto/pulls?q=is%3Apr+author%3...

Practically speaking, it is difficult to maintain a development branch of any software project with sufficient change velocity if you have a goal of continuing to integrate improvements from the upstream version.

Re: An update to the Timescale license

#187

Post by dragonwriter » Fri, Sep 25, 2020, 3:56 PM UTC

slashdev wrote: 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…

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

Re: An update to the Timescale license

#188

Post by dragonwriter » Fri, Sep 25, 2020, 4:01 PM UTC

thayne wrote: post #165

danShumway wrote: post #123

Earlier quoted context omitted.

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

No, it's not. It's entire purpose is protecting the copyright owners ability it extract rents against others who might offer competing services, which is exactly the spirit of traditional proprietary licensing, and exactly opposed to the value proposition of Free/Open Source Software.

The terms might be superficially similar to some F/OSS licenses, but the reason it fails to meet the OSI or FSF definitions is precisely that it's spirit is diametrically opposed to F/OSS

Re: An update to the Timescale license

#189

Post by dragonwriter » Fri, Sep 25, 2020, 4:06 PM UTC

sroussey wrote: post #183

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

> But "Open Source" means no field-of-use restrictions — so although any of you are free to craft your own licenses excluding X, Y, or Z, you don't get to call those licenses "Open Source". Sounds like public domain. What’s the difference between the two then?

> Sounds like public domain. What’s the difference between the two then?

Public domain, other than by copyright expiration or (in the US) federal government creation is actually not clearly possible to create in a legally unambiguous way in many regimes with automatic copyright and no direct provision for unilateral transfer to the public domain; the most permissive open source licenses approximate it while providing better legal clarity.

Open source licenses often seek to protect the originator from liability they might otherwise incur from chain-of-commerce relationships, making it safer for them to make the software available without fee, and to prevent misattribution of origin. Other open source licenses, while not having field of use limits, seek to assure that derivatives are also offered on similarly-free terms. There's quite a variety, within the bounds of certain essential guarantees that are central to the common value proposition.

Re: An update to the Timescale license

#190

Post by dragonwriter » Fri, Sep 25, 2020, 4:12 PM UTC

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.

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

The established meaning is “any non-F/OSS licenses that nevertheless provides free access to source code, which may or may not also provide some usage rights”

TSL is exactly that.

There might be some utility to a name for a new subcategory of source available, but it's not meaningfully similar to open source since it remains, ultimately, a traditional, rent-protection proprietary license. The fact that current market conditions give a very particular rent-extracting opportunity that the vendor wants to protect and the vendor focussed rent protection where the most value is...is not unusual, even if the exact current valuable rent-extraction opportunity is different than it was even a few years ago.