Re: is a BSL licensed service acceptable for sysadminy use cases?
+1 On Wed, Jun 9, 2021 at 9:28 PM Kenny Coyle wrote: > > So with the licensing question aside, I realise that there is a desire here > to have log (and/or metric) aggregation services available for KDE services. > > With Akademy happening in a few weeks, should we discuss this in a BoF? I > think there's a lot of scope to look at various platforms that provide very > similar features to Sentry. > > Thanks, > Kenny. > > On Wed, Jun 9, 2021 at 4:21 PM Bhushan Shah wrote: >> >> On Thursday, 27 May, 2021 12:55:01 AM IST Anna “CyberTailor” wrote: >> > So you can use old sentry versions, which are open source. >> >> If you are referring to old snapshot of old sentry version then I would say >> it >> is fairly impossible to use it given using old sentry version would also mean >> that we need to use older API version and it also means older libraries for >> client side (for sending data). It is basically a dep hell which is >> impossible >> to overcome. >> >> With my sysadmin hat on, I would absolutely oppose to having installation of >> 3 >> year old unmaintained software (and its equally outdated dependencies) that >> are guranteed to get no upates whatsover on our servers in productions. >> >> Regards.
Re: is a BSL licensed service acceptable for sysadminy use cases?
So with the licensing question aside, I realise that there is a desire here to have log (and/or metric) aggregation services available for KDE services. With Akademy happening in a few weeks, should we discuss this in a BoF? I think there's a lot of scope to look at various platforms that provide very similar features to Sentry. Thanks, Kenny. On Wed, Jun 9, 2021 at 4:21 PM Bhushan Shah wrote: > On Thursday, 27 May, 2021 12:55:01 AM IST Anna “CyberTailor” wrote: > > So you can use old sentry versions, which are open source. > > If you are referring to old snapshot of old sentry version then I would > say it > is fairly impossible to use it given using old sentry version would also > mean > that we need to use older API version and it also means older libraries > for > client side (for sending data). It is basically a dep hell which is > impossible > to overcome. > > With my sysadmin hat on, I would absolutely oppose to having installation > of 3 > year old unmaintained software (and its equally outdated dependencies) > that > are guranteed to get no upates whatsover on our servers in productions. > > Regards.
Re: is a BSL licensed service acceptable for sysadminy use cases?
On Thursday, 27 May, 2021 12:55:01 AM IST Anna “CyberTailor” wrote: > So you can use old sentry versions, which are open source. If you are referring to old snapshot of old sentry version then I would say it is fairly impossible to use it given using old sentry version would also mean that we need to use older API version and it also means older libraries for client side (for sending data). It is basically a dep hell which is impossible to overcome. With my sysadmin hat on, I would absolutely oppose to having installation of 3 year old unmaintained software (and its equally outdated dependencies) that are guranteed to get no upates whatsover on our servers in productions. Regards. signature.asc Description: This is a digitally signed message part.
Re: is a BSL licensed service acceptable for sysadminy use cases?
On Fri, May 28, 2021 at 12:25 PM Harald Sitter wrote: > > On Fri, May 28, 2021 at 11:43 AM Sune Vuorela wrote: > > > > On 2021-05-26, Anna “CyberTailor” wrote: > > >> After 36 months, the code becomes Apache-2.0 licensed (the conversion > > >> period) > > > > > > So you can use old sentry versions, which are open source. > > > > > > > +1. I think we should support free and open source software. > > I do too. I'm curious though: How does using the 4 year old software > support the software more than using the eventually 4 year old > software? I'd really like an answer to that. HS
Re: is a BSL licensed service acceptable for sysadminy use cases?
On Fri, May 28, 2021 at 12:52 PM Ingo Klöcker wrote: > > On Freitag, 28. Mai 2021 12:36:35 CEST Andrius Štikonas wrote: > > 2021 m. gegužės 28 d., penktadienis 11:25:49 BST Harald Sitter rašė: > > > On Fri, May 28, 2021 at 11:43 AM Sune Vuorela wrote: > > > > On 2021-05-26, Anna “CyberTailor” wrote: > > > > >> After 36 months, the code becomes Apache-2.0 licensed (the conversion > > > > >> period)> > > > > > > > So you can use old sentry versions, which are open source. > > > > > > > > +1. I think we should support free and open source software. > > > > > > I do too. I'm curious though: How does using the 4 year old software > > > support the software more than using the eventually 4 year old > > > software? > > > > By the way, isn't it 3 year old software. That probably doesn't > > fundamentally change the discussion. Although, if you use Debian stable or > > Centos, you probably are using a lot of 3 year old software. (brainfart - the BSL fallback is 4 years, sentry lowered it to 3 ;)) > Sure, but in Debian and Centos security fixes (for officially maintained > packages) are backported. > > Are security fixes backported for the now Apache-2.0 licensed versions of > Sentry? Good question. Does not look like it. It is really just an old release, similar to say KF5.10. The code is there and you could use it but there's zero engineering or support put into it. I mean, why would they, their license offers the same software freedoms (copy, modify, create derivative works, redistribute, use) with the single restriction being that you cannot use the software as a competing commercial offering, making the realistic only benefactors of backport maintenance: competing commercial offerings ;) because they can't use the current release. HS
Re: is a BSL licensed service acceptable for sysadminy use cases?
On Freitag, 28. Mai 2021 12:36:35 CEST Andrius Štikonas wrote: > 2021 m. gegužės 28 d., penktadienis 11:25:49 BST Harald Sitter rašė: > > On Fri, May 28, 2021 at 11:43 AM Sune Vuorela wrote: > > > On 2021-05-26, Anna “CyberTailor” wrote: > > > >> After 36 months, the code becomes Apache-2.0 licensed (the conversion > > > >> period)> > > > > > > So you can use old sentry versions, which are open source. > > > > > > +1. I think we should support free and open source software. > > > > I do too. I'm curious though: How does using the 4 year old software > > support the software more than using the eventually 4 year old > > software? > > By the way, isn't it 3 year old software. That probably doesn't > fundamentally change the discussion. Although, if you use Debian stable or > Centos, you probably are using a lot of 3 year old software. Sure, but in Debian and Centos security fixes (for officially maintained packages) are backported. Are security fixes backported for the now Apache-2.0 licensed versions of Sentry? Regards, Ingo signature.asc Description: This is a digitally signed message part.
Re: is a BSL licensed service acceptable for sysadminy use cases?
2021 m. gegužės 28 d., penktadienis 11:25:49 BST Harald Sitter rašė: > On Fri, May 28, 2021 at 11:43 AM Sune Vuorela wrote: > > > > On 2021-05-26, Anna “CyberTailor” wrote: > > >> After 36 months, the code becomes Apache-2.0 licensed (the conversion > > >> period) > > > > > > So you can use old sentry versions, which are open source. > > > > > > > +1. I think we should support free and open source software. > > I do too. I'm curious though: How does using the 4 year old software > support the software more than using the eventually 4 year old > software? > > HS > By the way, isn't it 3 year old software. That probably doesn't fundamentally change the discussion. Although, if you use Debian stable or Centos, you probably are using a lot of 3 year old software. signature.asc Description: This is a digitally signed message part.
Re: is a BSL licensed service acceptable for sysadminy use cases?
On Fri, May 28, 2021 at 11:43 AM Sune Vuorela wrote: > > On 2021-05-26, Anna “CyberTailor” wrote: > >> After 36 months, the code becomes Apache-2.0 licensed (the conversion > >> period) > > > > So you can use old sentry versions, which are open source. > > > > +1. I think we should support free and open source software. I do too. I'm curious though: How does using the 4 year old software support the software more than using the eventually 4 year old software? HS
Re: is a BSL licensed service acceptable for sysadminy use cases?
On 2021-05-26, Anna “CyberTailor” wrote: >> After 36 months, the code becomes Apache-2.0 licensed (the conversion period) > > So you can use old sentry versions, which are open source. > +1. I think we should support free and open source software. /Sune
Re: is a BSL licensed service acceptable for sysadminy use cases?
On Wed, May 26, 2021 at 11:52 PM Albert Astals Cid wrote: > > El dimecres, 26 de maig de 2021, a les 16:07:14 (CEST), Harald Sitter va > escriure: > > Ahoy ahoy > > > > I do on occasion write behind the scenes micro services for various > > things we need in KDE and usually more specifically neon. It's always > > been a big lament of mine that we don't really have a good way to > > record errors from these services. Gitlab meanwhile has builtin > > support for a piece of software that would allow us to do this: sentry > > [1]. The trouble is that sentry is only kind-of open source [2] and > > consequently there is some concern if we really should use it, even > > though the use case is pretty much exclusively for sysadmin internal > > affairs rather than a service we render to the outside or the wider > > KDE community even. Bhushan and I also looked at similar software but > > found nothing nearly as hot, and of the serviceable stuff I believe > > the best option also had ultimately relied on only kind-of open source > > software (mongodb IIRC). > > > > What's your thoughts on the subject? Can sysadmins use not-quite-free > > software for internal stuff? > > Is this about us writing BSL software or us using BSL software? I think > using, but want to be sure. Yes, just using it. > What's the use case of the software? e.g. geoip.kde.org encounters an error, instead of abort() it catches the error and sends a data blob of metadata of the error to sentry from where gitlab excavates it. I see the error and might decide to do something about it. > How locked in are we into it? Not at all, worst case we can simply live without this particular software. Or use something else, but so far the stuff Bhushan and I tried wasn't terribly convincing. > > c) I do feel for the developers need to turn a profit so most software > > freedom is better than no freedom in my book > > This is a bit of a slippery slope, and makes me a bit sad with it since it > agrees with the "you can't make money with Free Software" argument. I appreciate your point but I would like to hope that my thoughts are a bit more nuanced than that ;) albeit not really what I would like to focus on here. If there's interest we can certainly discuss the pros and cons of the many saas freedom models in general in a thread, because, personally, I am also not sure our stance vis a vis gitlab's model is particularly advantageous either. I do feel that is the sort of topic that is best discussed over a beverage at akademy though. Never the less here's a gist on this particular case: since what they offer is saas, I struggle to see options how to monetize their project outside "hosting" and support. The former of those options would be undermined if a competitor were to run the same product with different branding at half the price. So I guess perhaps your literal "you can't make money with Free Software" is indeed the bottom line here. You can't with the software itself through sales, at least it can be exceptionally difficult. Sans goodwill and donations maybe, but if employee's livelihoods depend on making money I'd not exactly stake my business on monthly goodwill. You can make money surrounding the software through: consulting, support, commercial licensing, additional products built on top, selling ad space, selling out data. Most of these avenues of income aren't available here because of the nature of the product and the potential customers. With all that in mind I find it entirely reasonable to have a license that says that you can't start a competing commercial offer with the saas product code, unless that code is at least 4 years old and thus has been made entirely free (this eventual freedom clause is of course something we have in our corner of the free software world as well ;)). 4 years is a bit on the long side but in the end it doesn't prevent competition it just means that if you want to innovate a product from the code base you'll have to start at a 4 year disadvantage. There now I've gone off on a ramble. Why I feel their case makes sense isn't really important anyway here... unless someone needs swaying in which case I can do some more musings on request :) To clarify the terms perhaps the literal license is "don't make a competing commercial offering with this code + this code automatically becomes apache licensed in 4 years". A just license to my mind. But also most definitely not a free license until the code is 4 years old. HS
Re: is a BSL licensed service acceptable for sysadminy use cases?
> After 36 months, the code becomes Apache-2.0 licensed (the conversion period) So you can use old sentry versions, which are open source.
Re: is a BSL licensed service acceptable for sysadminy use cases?
El dimecres, 26 de maig de 2021, a les 16:07:14 (CEST), Harald Sitter va escriure: > Ahoy ahoy > > I do on occasion write behind the scenes micro services for various > things we need in KDE and usually more specifically neon. It's always > been a big lament of mine that we don't really have a good way to > record errors from these services. Gitlab meanwhile has builtin > support for a piece of software that would allow us to do this: sentry > [1]. The trouble is that sentry is only kind-of open source [2] and > consequently there is some concern if we really should use it, even > though the use case is pretty much exclusively for sysadmin internal > affairs rather than a service we render to the outside or the wider > KDE community even. Bhushan and I also looked at similar software but > found nothing nearly as hot, and of the serviceable stuff I believe > the best option also had ultimately relied on only kind-of open source > software (mongodb IIRC). > > What's your thoughts on the subject? Can sysadmins use not-quite-free > software for internal stuff? Is this about us writing BSL software or us using BSL software? I think using, but want to be sure. What's the use case of the software? How locked in are we into it? > > Personally I would put forward some arguments pro: > > a) we do already on occasion need to run non-free software to > facilitate our work. our windows builders for CI and binary factory > come to mind. I think this is a bit different "obviously" [*] to create Windows software you need to run Windows. > > b) given we want to use this as an extra bit of sugar we'd not rely on > their service for production or anything. if we decide that we don't > like it next week we could conceivably just throw it out the window > again. > > c) I do feel for the developers need to turn a profit so most software > freedom is better than no freedom in my book This is a bit of a slippery slope, and makes me a bit sad with it since it agrees with the "you can't make money with Free Software" argument. Cheers, Albert > > [1] https://invent.kde.org/help/operations/error_tracking > [2] > https://blog.sentry.io/2019/11/06/relicensing-sentry#enter-the-business-source-license-bsl > > HS [*] I know mingw, cross compiling i know
is a BSL licensed service acceptable for sysadminy use cases?
Ahoy ahoy I do on occasion write behind the scenes micro services for various things we need in KDE and usually more specifically neon. It's always been a big lament of mine that we don't really have a good way to record errors from these services. Gitlab meanwhile has builtin support for a piece of software that would allow us to do this: sentry [1]. The trouble is that sentry is only kind-of open source [2] and consequently there is some concern if we really should use it, even though the use case is pretty much exclusively for sysadmin internal affairs rather than a service we render to the outside or the wider KDE community even. Bhushan and I also looked at similar software but found nothing nearly as hot, and of the serviceable stuff I believe the best option also had ultimately relied on only kind-of open source software (mongodb IIRC). What's your thoughts on the subject? Can sysadmins use not-quite-free software for internal stuff? Personally I would put forward some arguments pro: a) we do already on occasion need to run non-free software to facilitate our work. our windows builders for CI and binary factory come to mind. b) given we want to use this as an extra bit of sugar we'd not rely on their service for production or anything. if we decide that we don't like it next week we could conceivably just throw it out the window again. c) I do feel for the developers need to turn a profit so most software freedom is better than no freedom in my book [1] https://invent.kde.org/help/operations/error_tracking [2] https://blog.sentry.io/2019/11/06/relicensing-sentry#enter-the-business-source-license-bsl HS
