Comment by PeterisP | Hacker News Reader

Comment by PeterisP | Hacker News Reader

Parent Full thread

The freedom to run the software for any purpose is #1 on the list of software freedoms that would be called open source. No ifs, no buts, no checking whether you qualify - software is free if and only if you can run it for any purpose, everything else comes only after that basic freedom. Various viral conditions only affect the licensing of developer changes (while still not restricting the developers right to make and use these changes), but violations of this condition impose restrictions also on non-developer users on non-modified code.

Timescale license does not provide that, so obviously it's more restrictive than even the most viral of open source licences.

To be specific, the sentence "the customer is prohibited, either contractually or technically, from defining, redefining, or modifying the database schema or other structural aspects of database objects," spits in the face of all the ideals of open source. I can respect your decision to choose such a license, there are understandable practical arguments for that, but I can't respect you calling that open source - if you consider that users should be restricted with what they can do with their data schemas, if you include an explicit anti-user-freedom clause, legally mandating software developers to be hostile to their own users - then at least have the guts to openly say that you are against open source (because of all the valid reasons you have, I'm not denying that, you don't have a duty to be pro-open-source), instead of misleadingly labeling your license as such.

Hi PeterisP, just to avoid any confusion:

The sentence you quote is actually meant to -technically- establish a basis for what it means for somebody to run/offer TimescaleDB as part of a value added service (very much allowed) versus a company like AWS offering TimescaleDB purely as a DBaaS offering (not allowed).

There are many, many thousands of companies that use or embed TimescaleDB as part of their service or product offerings, serving huge numbers of customers. We're extremely supportive of their ability to do so. We have no "enterprise features" that are excluded or held back only to paid users.

What we aren't supportive of is AWS running "TimescaleDB-as-a-Service" as part of AWS RDS. Because we know they do that!

The clause you are quoting helps define some of the legal nuances how we get there, ideally in ways that an engineer would understand. In particular, what it means to be a value added service/product versus just "TimescaleDB-as-a-Service".

The alternative legal formulations of this can be found in, e.g.

- Confluent Community License ("Licensee is not granted the right to, and Licensee shall not, exercise the License for an Excluded Purpose. For purposes of this Agreement, “Excluded Purpose” means making available any software-as-a-service, platform-as-a-service, infrastructure-as-a-service or other similar online service that competes with Confluent products or services that provide the Software.")

- Polyform "Shield" License ("Any purpose is a permitted purpose, except for providing any product that competes with the software or any product the licensor or any of its affiliates provides using the software.") https://polyformproject.org/licenses/shield/1.0.0/

These are all getting to similar places, but just putting more emphasis of the legal definition of "competition", which we thought would frustrate engineers with its vagueness.

> a company like AWS offering TimescaleDB purely as a DBaaS offering (not allowed).

That restriction makes the license not Open Source. Open Source licenses MUST allow anyone to run the software, for any reason, by definition. Even "as-a-Service". It's a perfectly fine restriction to have, but it shouldn't be called an Open Source license.

And we never call it Open Source!

(Timescale engineer here)

For what it's worth, TSL is a great source-available/restrictive-for-clouds license in my opinion, and I'm glad Timescale went the direction of moving from a more restrictive license to a more permissive license rather than the other way around.

While AGPL is a value-add for many, TSL isn't as ambiguous in some regards and provides a lot of nice "we won't sue you for this" clauses for users. Clear communication regarding its FOSS status will only help!

The whole issue arose from the claim that the Timescale license was designed to be less restrictive then the AGPL.

That's why Open Source came up in the first place - pointing out that one of the basic reasons for the Timescale license to exist in the first place is to restrict one of the major reasons Open Source licenses exist.

That only makes sense if you agree with the open source foundation definition of restrictive. I don't. I think the ability to freely link to whatever other software is much more important to most people than the ability to run a *aaS. We never made any claims about open source only our opinion about what restrictive means to us.

That's fine. I wasn't taking a position. I was explaining why people were using Open Source as a comparison.

There were also no claims about whatever definition of restrictive you were using. It was just a short statement that the Timescale license was designed to be less restrictive than the AGPL. You can't really be that surprised when somebody comes along and starts judging it by Open Source standards after that, can you?

That's fair but I was more replying to the OP that said "but it shouldn't be called an Open Source license". The point is we don't call our license Open Source.

Comparisons to Open Source and discussions of the pros and cons of both approaches are, of course, fair.

AGPL license clearly gives you the ability to freely link with whatever software you want. The only requirement is to share it with your customers. Following your logic it could be said that MIT licensed software could not be freely used because it requires preservation of original copyright notice

>That only makes sense if you agree with the open source foundation definition of restrictive.

I think Timescale employees should remember to preface "This is our belief on the definition of restrictive" when describing the license as more open than open source licenses, given much of the community might disagree (sometimes vehemently) about that take.

Or scope it as "less restrictive for most users" or something along those lines.

That may indeed have been more accurate. But this is a HN comment thread after all, we can't capture all subtleties of a very complex debate. :)

Totally fair. My initial comment was a little rushed. :-)

I appreciate this debate, but where do we label the Timescale License as open source?

Incidentally, that clause exists as a clear line for value added products and services. Some companies have a restriction that says, "You can't compete with us." That approach struck us as arbitrarily blurry. We took a clear approach that says DML (inserting, querying data) is permitted, but not DDL (creating tables). Again, this is to clearly restrict TimescaleDB-aaS providers and not other companies building true value added products / services on top (e.g., IoT platforms, SaaS companies).

I apologize, I was sloppy at skimming the licence, it actually does clearly and properly delineate the open source and source-available, describing them appropriately.

Reply on news.ycombinator.com