Multi-node TimescaleDB is now free

You are either severely misunderstanding or misrepresenting the FAQ that you quoted. It's simply clarifying that copy-left and permissive licenses are both compatible with the meaning of the term open source (ie they're disjoint subsets).

Regarding the "please only used approved licenses bit" - you've again missed the point. There is an effectively infinite set of possible licenses which satisfy the meaning of the term "open source" as it is currently used. The OSI is merely pointing out that it will make everyone's lives easier if developers try their best to use one of the licenses that already exists.

Licensing is a complex topic and not everyone is a lawyer or can afford to consult one (particularly for hobby and volunteer projects). If every project out there used a unique license it would be a complete nightmare. For that reason, it's better for everyone if at least some minimal attempt is made to use a well established license whenever possible.

> The OSI includes GPLv3, which is certainly not "free" for a ton of commercial uses.

Incorrect. Commercial customers are free to use, modify, and redistribute just like everyone else. They can even sell a product based on it - they just can't keep any changes they might make closed source if they do so.

> the value of any "Open Source Definition" is severely diluted for any considerable purpose

Not at all. The meaning is quite clear - I'm either free to use, modify, and redistribute it or I'm not. That's it.

Take a look at some of the approved licenses - for example AGPL, GPL, MPL, and MIT. In _all_ cases I'm free to modify and redistribute. In some cases I might be required to make my changes available, but never am I barred from making use as I see fit. Source available is simply not the same thing.

> I do not see value in pedantry around the term "open source", those words are so plain and ordinary that gluing any tertiary meaning to them is foolish. It's as subjective as "good code".

The fact that you see it as subjective is the misunderstanding that I refer to. It is _not_ subjective, but convincing others that it is can sometimes confer monetary benefits. This is precisely why such pedantry exists in great quantity surrounding the topic.

I don't really want to debate with you here, and if anything I feel like the points you are hammering on just fortify my stance that this topic is a waste of breath.

> The OSI is merely pointing out that it will make everyone's lives easier if developers try their best to use one of the licenses that already exists

Maybe, maybe not! Perhaps existing licenses are not sufficient. I doubt we'll be using the same licenses in 100 years. I bet there are better licenses waiting to be authored -- maybe TFA's license is the future?

> > The OSI includes GPLv3, which is certainly not "free" for a ton of commercial uses. > > Incorrect. Commercial customers are free to use, modify, and redistribute just like everyone else. They can even sell a product based on it - they just can't keep any changes they might make closed source if they do so.

Look, I live in the real world. If I link to a GPLv3 library in my product, I have to release all of my source code. This is potentially a pretty big burden on a lot of folks. Sure, there's a lot of legal FUD, but unfortunately, while FUD, has a very real impact. Lawyers won't sign off on a lot of this stuff.

> Take a look at some of the approved licenses - for example AGPL, GPL, MPL, and MIT. In _all_ cases I'm free to modify and redistribute. In some cases I might be required to make my changes available, but never am I barred from making use as I see fit. Source available is simply not the same thing.

AGPL is defacto banned at most companies, such as Google, which has this to say[0]:

> The license places restrictions on software used over a network which are extremely difficult for Google to comply with. Using AGPL software requires that anything it links to must also be licensed under the AGPL. Even if you think you aren’t linking to anything important, it still presents a huge risk to Google because of how integrated much of our code is. The risks heavily outweigh the benefits.

Gee, that sure sounds "open" to me.

Grouping AGPL and MIT in the same bucket is borderline harmful -- they're wildly different! This is what I mean when I say the term "open source" is a fuzzy descriptor. You can't have a fuzzy descriptor and then complain about things which don't fit your worldview. That's what the OSI basically does in a nutshell with their "Open Source Definition".

> It is _not_ subjective, but convincing others that it is can sometimes confer monetary benefits. This is precisely why such pedantry exists in great quantity surrounding the topic.

I agree we shouldn't accept anyone abusing the term for profit. At the same time, I don't think it's appropriate to conflate themes of "encumbered" or "burdensome" or "infectious" with the word "open" -- that is just as misleading and confers a different set of benefits that are not universally appreciated.

And one final thing: Just because I disagree with OSI's terminology doesn't make me incorrect. Statements like that come off as abrasive and trend towards a hostile, gatekeeping tone. The term you're looking for is "I disagree". It's easy to interpret your worldview as very small. If I polled a group of random software developers about what open source meant to them, I would be surprised if any of them referenced the OSI definition. Most developers would, sadly, conclude "stuff on github".

[0]: https://opensource.google/docs/using/agpl-policy/

Could you not just say "we don't support modified versions"? This seems like throwing the baby out with the bathwater a bit.

One possible approach compatible with true software freedom and the usual definition of open source is not to restrict use of modified versions of the code, but instead to use naming to distinguish between the two, and only support the unmodified version.

For example, the code build system could have variables for the name and maybe the logo and other trademark/brand-ish things, and the public codebase could be configured by default to call itself Timescale Community DB or Timescale Custom DB or some other name instead of TimescaleDB. Your private build would simply substitute the json file with those data values and maybe point to logos that aren't in the repo instead of generic ones that are, or something similar to that.

You'd also have the option to use any mixture of trademark law or copyright conditions to restrict the commercial version's name and branding assets.

All of the options I described above are used in reality by various projects out there. For example, the git repository for VS Code OSS has a product.json file with most of the customization points (not all) that MS changes in building their supported VS Code release, TeX and Red Hat apply naming restrictions, and Red Hat also has rules in their support contract.

Ahh, right, I thought I was misremembering but couldn't quite place how, thanks.