News for hackers. Stuff that matters.
Re:An update to the Timescale license by mfreed on Thursday September 24, 2020 @03:51PM (#24582798)
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-backgroun...

Thanks!

Re:An update to the Timescale license by igneo676 on Thursday September 24, 2020 @04:09PM (#24583018)
My comment was more directed toward the grandparent, which had their own set of comments regarding Open Source software. By and large, I'm happy with the announcement and how you're handling these terms carefully.

My only nitpick is the repeated statement of:

> a source-available license that was open-source in spirit

Which, um, it's not. I understand you're trying to thread a needle here and protect your business but it's not following the "spirit" of the community. You're removing a rather fundamental freedom by introducing your own license. That's rather antithetical to the whole idea of Open Source

Re:An update to the Timescale license by rectang on Thursday September 24, 2020 @04:22PM (#24583157)
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.
Re:An update to the Timescale license by GordonS on Thursday September 24, 2020 @04:55PM (#24583537)
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.

Re:An update to the Timescale license by cercatrova on Thursday September 24, 2020 @06:24PM (#24584372)
Then you could call it a permissive source available license, or other such verbiage. There's no need to continue to call it "open source in spirit."
Re:An update to the Timescale license by scj on Thursday September 24, 2020 @08:54PM (#24585403)
"The usage of pork broth in an otherwise vegetarian dish is vegetarian in spirit."

I can't help but wonder if they're using the phrase "open source in spirit" to leech the branding of open source (while ironically treating other companies as leeches).

Re:An update to the Timescale license by cercatrova on Thursday September 24, 2020 @08:59PM (#24585440)
That's exactly why they're doing it. They want to have their cake and eat it too.
Re:An update to the Timescale license by dragonwriter on Friday September 25, 2020 @12:12PM (#24591324)
> "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.

Re:An update to the Timescale license by lmm on Thursday September 24, 2020 @08:46PM (#24585351)
> I disagree. "source available" already has a long established meaning, and one that it far more restrictive than the TSL.

It doesn't really - it's been used to describe a pretty broad range of licenses. "Source available" means you can read the source but do not have all of the rights you'd get from an open source license. Which is the case for TSL.

Re:An update to the Timescale license by detaro on Thursday September 24, 2020 @08:57PM (#24585424)
"source available" isn't a great term, since it's relatively strongly associated with "you can look but not touch it" licenses.

A dedicated term probably makes sense. Some other licenses in this space have used terms like "fair licenses".

Re:An update to the Timescale license by hitekker on Thursday September 24, 2020 @09:33PM (#24585706)
> it's not following the "spirit" of the community.

Which community are you speaking for here? "Free Software" or "Open Source"? They are separate communities with a long history of rivalry between each other.

https://www.gnu.org/philosophy/open-source-misses-the-point....

https://en.wikipedia.org/w/index.php?title=Open_Source_Initi...

Re:An update to the Timescale license by ramses0 on Thursday September 24, 2020 @09:31PM (#24585687)
If it matters or not... as an unaffected person, but an open source + license nerd, I like the outcome of what you've done. (and yes... "open source in spirit" seems like your hearts are in the right place).

When you're talking about the licenses I think it's great that you've introduced the talking points of "right to repair/improve" ... that's something which is guaranteed via DFSG (b/c you can do what you want with it), but it's great to see it called out as a more fundamental concept expressed in "non-legalese".

You're also looking at "protections" which could be called out as: "the protection from $CLOUD_PROVIDER taking our work and using it to strangle our company and the people who made it" ... probably with a different wording though.

Have you considered writing down a set of principles / protections which you could rally other businesses around as well? Something like the DFSG guidelines, but organized around protecting potential revenue streams?

What would it look like if you had another option / logo on the creative commons license picker? (ie: "$NO + $CLOUD + $MONEY")... https://creativecommons.org/choose/

What would your "Timescale Monetizeable Source Available Guidelines" look like, and could they be expressed as snappily as you've expresed "Right to Repair" and "Right to Improve"?