Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

An update to the Timescale license

blog.timescale.com

Post reply on HN
Print view View original

121–130 of 210 posts

Re: An update to the Timescale license

#121

Post by [deleted] »

rabidrat wrote: post #90
rectang wrote: post #78

Earlier quoted context omitted.

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

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

[deleted]

Re: An update to the Timescale license

#122

Post by wmf »

cycloptic wrote: post #104
mfreed wrote: post #79

Earlier quoted context omitted.

My own perspective is that companies should probably stop saying that "if only Amazon would contribute back the occasional patch, everything would be fine." If much of the future is cloud, then getting the hyper-scalars to contribute occasional patches doesn't solve the problem of competition. That's reflected in our post: Some may ask, “Why create a new license - why not just compete with public clouds by just provi…

Can you honestly say this license is trying to solve for the same problem, rather than just carving a niche for your own business at the expense of other businesses, e.g. other startups who might be able to offer a better service contract to the public cloud vendors? Because it's hard for me to imagine it differently the way these are worded. This is my main problem with this type of licenses, none of them really see…

It looks like public cloud providers (really mostly AWS) will never ever contribute enough to upstream to support full-time upstream development teams and no one has enough leverage to change that situation. Given that reality, the only solution is what Timescale has come up with.

Re: An update to the Timescale license

#123

Post by danShumway »

rabidrat wrote: post #90
rectang wrote: post #78

Earlier quoted context omitted.

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

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

> 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, you have to let us call ourselves the same as you."

Source Available has been a term for a really long time, and its generally understood what it means, and plenty of people use the term with plenty of good will. This shouldn't be a controversy, it's such a straightforward, easy concession. There's nothing wrong with being Source Available.

So why do we need to come up with a new term that describes the freedoms we've been consistently preaching for decades just because a couple of for-profit companies want the good will that we've generated? This isn't language evolving over time, it's people outside the community trying to decide how we're allowed to define ourselves within in the community.

Yes, language is descriptive, but that doesn't mean you can just redefine anything you want any time you want. Even more than that, the fact that language is descriptive does not mean it's a bad thing for communities to try and publicize and preserve the descriptive language that already exists. Open Source advocates are hardliners on this issue specifically because we recognize that language is descriptive, and that our ability to preserve the meaning of the words that describe our community is dependent on us taking the time to educate and correct people who are genericizing those terms.

Re: An update to the Timescale license

#124

Post by mindcrime »

GordonS wrote: post #102
mindcrime wrote: post #92

Earlier quoted context omitted.

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

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

It's really the general case that I'm interested in. Understanding and dealing with different licenses doesn't necessarily scale well, which is exactly why license proliferation is a Bad Thing.

For those people who use Timescale and really like it, and are willing to read and understand this license and then use it, I say "Great!" But in general I find license proliferation to be undesirable and would generally encourage organizations to use standard licenses.

Re: An update to the Timescale license

#125

Post by cercatrova »

lillecarl wrote: post #107
boogies wrote: post #100

Earlier quoted context omitted.

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?

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.

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.

Re: An update to the Timescale license

#126

Post by cercatrova »

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.

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

#127

Post by cycloptic »

wmf wrote: post #122
cycloptic wrote: post #104

Earlier quoted context omitted.

Can you honestly say this license is trying to solve for the same problem, rather than just carving a niche for your own business at the expense of other businesses, e.g. other startups who might be able to offer a better service contract to the public cloud vendors? Because it's hard for me to imagine it differently the way these are worded. This is my main problem with this type of licenses, none of them really see…

It looks like public cloud providers (really mostly AWS) will never ever contribute enough to upstream to support full-time upstream development teams and no one has enough leverage to change that situation. Given that reality, the only solution is what Timescale has come up with.

I know, I get that, but long-term this seems like non-solution that won't actually do anything. It just ties it to their service offering instead of Amazon's. If they decide to sell out to Amazon eventually they'll probably be able to bid the price higher. That's good for them, and if their customers are fine with it, then that's good for them too, but let's not pretend it's something more. I know in current times I certainly wouldn't trust a database with performance/uptime guarantees, where the authors are hiding the implementation from public scrutiny.

If you're going to tell me your company is actually worth a trillion quid and can really compete with AWS then I would see your point, but otherwise I can't see a way that this is going to make the market better for anyone besides the other small fraction of companies that have come up with similar ideas of banning Amazon. (Full disclosure: I'm in the same boat and I personally refuse to purchase any products or services from Amazon, but I acknowledge I'm in the severe minority)

Re: An update to the Timescale license

#128

Post by StopHammoTime »

stavros wrote: post #95
rectang wrote: post #94

Earlier quoted context omitted.

You'd be in good company with Microsoft circa 2001 with their (source-available) Shared Source Initiative, because your argument is the same one that people have been making back then and ever since: that banning field-of-use restrictions imposes too much of a burden on commercial entities. But disallowing such field-of-use restrictions is exactly what makes open source collaboration between otherwise competing compa…

Can you elaborate? What collaboration do you mean?

Uhh, kubernetes would be an immediate example. A massive piece of software that has been adapted into every major cloud provider, with all those cloud providers working on that same piece of software.

While Google may have done it to make their own Cloud offering better, it ultimately has succeeded in saturating the container compute market and with their own success has brought plenty of competition.

Re: An update to the Timescale license

#129

Post by mfreed »

yandie wrote: post #88
mfreed wrote: post #22

Earlier quoted context omitted.

Storing JSON or EAV-format data do not require DDL access, and are commonly deployed in many settings, from product/SaaS analytics, IoT, IT/APM monitoring, and others. That's actually one of the reasons we tried to frame it in terms of interfaces as well. (Thanks for the question/interest!)

Our data is binary with a complex format (protobuf). We have custom logic to merge these data points. I guess this would not be covered by the license then

Not sure I follow?

The parent poster was asking about "well, isn't it an issue with your TSL definition of 'DDL schema access' if you can store data in JSON or EAV so it doesn't have a 'fixed schema'", and my answer is: No, that's fine.

Just like it would be fine for you to store or use binary/blobs/arrays/whatever. We've seen some crazy/cool use cases like developers storing binary 3D lidar data in TimescaleDB.

In fact, with these "right-to-improve" changes, you could even modify the database to embed custom logic inside TimescaleDB to handle your protobuf format (as opposed to UDFs or application code), and it would still be permitted.

Re: An update to the Timescale license

#130

Post by mfreed »

cycloptic wrote: post #127
wmf wrote: post #122

Earlier quoted context omitted.

It looks like public cloud providers (really mostly AWS) will never ever contribute enough to upstream to support full-time upstream development teams and no one has enough leverage to change that situation. Given that reality, the only solution is what Timescale has come up with.

I know, I get that, but long-term this seems like non-solution that won't actually do anything. It just ties it to their service offering instead of Amazon's. If they decide to sell out to Amazon eventually they'll probably be able to bid the price higher. That's good for them, and if their customers are fine with it, then that's good for them too, but let's not pretend it's something more. I know in current times I…

    where the authors are hiding the implementation 
    from public scrutiny
We agree that such visibility is a good thing! All of our source code (both Apache-2 and TSL) has always been public on github:

https://github.com/timescale/timescaledb

Post reply on HN