7 ms·

wow, this is super interesting, but i can't say i'm surprised by this move. the landscape has really evolved over the last few years for companies trying to bu

by nopzor 6y ago

wow, this is super interesting, but i can't say i'm surprised by this move. the landscape has really evolved over the last few years for companies trying to build a business around open source. at grafana labs we are closely following these developments, and are constantly wrestling with decisions around what is best for our own licensing strategy. all of our peers (eg. mongodb, elastic, redis, confluent, cockroach, timescale, etc etc) have recently made moves to prevent being disintermediated by the cloud vendors. it's become the new normal. interesting times.

npiit 6y ago
I thought Grafana was doing great with its managed offerings. Personally I'd prefer you consider BSL before SSPL since it's usually clearer to most people.
- nopzor 6y ago
  at grafana labs, we are still pretty torn on what our go forward licensing regime should be. bsl is interesting, but license proliferation and familiarity is a big factor to consider. now that both elastic and mongo are both using sspl, it is more appealing. i think tsl from timescale is also a great and well thought out license.
  - dhd415 6y ago
    Interesting. I got the impression from the recent announcement that Grafana Labs had something of a revenue sharing model with the new AWS managed offering of Grafana. Given that, I wouldn't think the SSPL restrictions would be as important.
    - nopzor 6y ago
      we do indeed have a partnership with aws around grafana. but the cloud landscape goes beyond aws, and the grafana labs landscape goes beyond grafana itself. it's definitely a nuanced discussion internally.
  - npiit 6y ago
    I like Grafana and I wish you the best. Source-available to me is basically FOSS unless I want a free ride off your hard work.
LukeEF 6y ago
As far as I can tell, Timescale is not like the others, their shift was to make the formerly proprietary enterprise only code source available. Remarkably they went MORE open rather than less (as it the case for all the others). You have to give them respect for approaching things differently.
- dhd415 6y ago
  I don't think it's really that different. Elastic did that same thing about three years ago when they made all of their enterprise-only features source-available (https://www.elastic.co/blog/doubling-down-on-open https://www.elastic.co/blog/doubling-down-on-open). Timescale also made their enterprise features free of charge, but that's a business decision rather than a question of licensing. It's because their revenue model is based completely on their managed cloud offering while Elastic still gets non-trivial revenue from selling their enterprise features to customers who want them.
  - DetroitThrow 6y ago
    Is this an elastic employee throwaway? How is going from a more permissive license to less permissive one "not really that different" than the inverse?!
- mfreed 6y ago
  Thanks for the clarification, Luke. For a bit more background for the HN community: When we initially launched the Timescale License in Dec 2018, we didn't relicense any of our Apache-2 code -- that was and has always remained licensed under the Apache 2 license. Instead, we effectively were "pre-announcing" that some future advanced features (yet to be developed) would instead be released under the Timescale License or under a paid-only commercial license (although still source-available). Fast forward to September 2020 and Timescale 2.0, and we (i) made some aspects of the Timescale License more permissive (e.g., "right to repair", "right to improve"), and (ii) moved all the previously enterprise (paid-only) features to be available for free under the Timescale License. Hope that helps! https://blog.timescale.com/blog/building-open-source-business-in-cloud-era-v2/ https://blog.timescale.com/blog/building-open-source-busines...
yjftsjthsd-h 6y ago
> around what is best for our own licensing strategy As a user (self hosted for internal monitoring): if you must change, please, please make it completely unambiguous what the scope is. I really want to avoid having an argument with my team about whether we're using grafana to "provide our service".
- nopzor 6y ago
  do you feel that the sspl is ambiguous on this point? if so, why?
  - yjftsjthsd-h 6y ago
    After rereading the relevant section a few times, no, I think SSPL is fine for our use. EDIT: I should say for our current primary usecase. It does look like this would make it awkward for us to expose grafana to clients, but that's a narrow case and/or one that I suspect you'd intend to be in-scope for virality.
ecnahc515 6y ago
Ive been interested in the licenses that are restrictive with a time period (eg: 6 months-1 year) after which they become FOSS (Apache2/MIT), eg BSL. I think it's a reasonable approach, but I think the restrictive license still needs to be quite permissive for it to make me happy. I haven't quite found one yet that sat well with me.
valyala 6y ago
> at grafana labs we are closely following these developments, and are constantly wrestling with decisions around what is best for our own licensing strategy. It would be great to see a list of pros and cons for approaches taken by ElasticSearch, MongoDB, TimescaleDB regarding licensing. BTW, we at VictoriaMetrics do not plan to change license for published source code. All the VictoriaMetrics source code is published under Apache 2.0 license [1]. [1] https://github.com/VictoriaMetrics/VictoriaMetrics/blob/master/LICENSE https://github.com/VictoriaMetrics/VictoriaMetrics/blob/mast...

by nopzor 6y ago

npiit 6y ago

I thought Grafana was doing great with its managed offerings. Personally I'd prefer you consider BSL before SSPL since it's usually clearer to most people.

nopzor 6y ago
at grafana labs, we are still pretty torn on what our go forward licensing regime should be. bsl is interesting, but license proliferation and familiarity is a big factor to consider. now that both elastic and mongo are both using sspl, it is more appealing. i think tsl from timescale is also a great and well thought out license.
- dhd415 6y ago
  Interesting. I got the impression from the recent announcement that Grafana Labs had something of a revenue sharing model with the new AWS managed offering of Grafana. Given that, I wouldn't think the SSPL restrictions would be as important.
  - nopzor 6y ago
    we do indeed have a partnership with aws around grafana. but the cloud landscape goes beyond aws, and the grafana labs landscape goes beyond grafana itself. it's definitely a nuanced discussion internally.
- npiit 6y ago
  I like Grafana and I wish you the best. Source-available to me is basically FOSS unless I want a free ride off your hard work.

LukeEF 6y ago

As far as I can tell, Timescale is not like the others, their shift was to make the formerly proprietary enterprise only code source available. Remarkably they went MORE open rather than less (as it the case for all the others). You have to give them respect for approaching things differently.

dhd415 6y ago
I don't think it's really that different. Elastic did that same thing about three years ago when they made all of their enterprise-only features source-available (https://www.elastic.co/blog/doubling-down-on-open https://www.elastic.co/blog/doubling-down-on-open). Timescale also made their enterprise features free of charge, but that's a business decision rather than a question of licensing. It's because their revenue model is based completely on their managed cloud offering while Elastic still gets non-trivial revenue from selling their enterprise features to customers who want them.
- DetroitThrow 6y ago
  Is this an elastic employee throwaway? How is going from a more permissive license to less permissive one "not really that different" than the inverse?!
mfreed 6y ago
Thanks for the clarification, Luke. For a bit more background for the HN community: When we initially launched the Timescale License in Dec 2018, we didn't relicense any of our Apache-2 code -- that was and has always remained licensed under the Apache 2 license. Instead, we effectively were "pre-announcing" that some future advanced features (yet to be developed) would instead be released under the Timescale License or under a paid-only commercial license (although still source-available). Fast forward to September 2020 and Timescale 2.0, and we (i) made some aspects of the Timescale License more permissive (e.g., "right to repair", "right to improve"), and (ii) moved all the previously enterprise (paid-only) features to be available for free under the Timescale License. Hope that helps! https://blog.timescale.com/blog/building-open-source-business-in-cloud-era-v2/ https://blog.timescale.com/blog/building-open-source-busines...

yjftsjthsd-h 6y ago

> around what is best for our own licensing strategy As a user (self hosted for internal monitoring): if you must change, please, please make it completely unambiguous what the scope is. I really want to avoid having an argument with my team about whether we're using grafana to "provide our service".

nopzor 6y ago
do you feel that the sspl is ambiguous on this point? if so, why?
- yjftsjthsd-h 6y ago
  After rereading the relevant section a few times, no, I think SSPL is fine for our use. EDIT: I should say for our current primary usecase. It does look like this would make it awkward for us to expose grafana to clients, but that's a narrow case and/or one that I suspect you'd intend to be in-scope for virality.

ecnahc515 6y ago

Ive been interested in the licenses that are restrictive with a time period (eg: 6 months-1 year) after which they become FOSS (Apache2/MIT), eg BSL. I think it's a reasonable approach, but I think the restrictive license still needs to be quite permissive for it to make me happy. I haven't quite found one yet that sat well with me.

valyala 6y ago

> at grafana labs we are closely following these developments, and are constantly wrestling with decisions around what is best for our own licensing strategy. It would be great to see a list of pros and cons for approaches taken by ElasticSearch, MongoDB, TimescaleDB regarding licensing. BTW, we at VictoriaMetrics do not plan to change license for published source code. All the VictoriaMetrics source code is published under Apache 2.0 license [1]. [1] https://github.com/VictoriaMetrics/VictoriaMetrics/blob/master/LICENSE https://github.com/VictoriaMetrics/VictoriaMetrics/blob/mast...