Re: The status of freenode (the IRC network used by KDE)
Hi, all! Is there any KDE-wide decision on that? Is there any work done on migration from freenode to libera? I mean, if a KDE-project wants to migrate from freenode to libera, what should it do? Do that individually or wait until the whole organisation does that in a bucket? As far as I can see the following steps are needed: 1) Register the project within libera somehow. There was some form to fill in, but I cannot find it now. 2) Relink the matrix bridge from the old network to the new location. I guess we can register the channel ourselves, but relinking matrix bridge is something out of our control. What should we do for that? On Wed, May 26, 2021 at 9:20 AM Christian Loosli wrote: > Dear KDE community, > > it appears that over night, the now new management of freenode started to > revenge-ban former staff from their servers, therefore I am now unable to > connect to freenode and connect to / help out with KDE there. > > They also post heavily cropped private chatlogs on their blog so that they > push their views. https://freenode.net/news/for-foss > full chat log at the bottom of the mail, since the cropped part was > released > without me being asked, I have to assume it's fine to release the rest as > well. > > In addition to that, former official channels from projects that moved to > a > different place were taken over by the new management. > https://mastodon.sdf.org/@kline/106299403921451814 > https://twitter.com/UndeadDrMcCoy/status/1397400278916386820 > > > I've been asked in a KDE channel by a member on why I suggest moving, so: > yeah, this is it. Seizing official channels you do not represent and > banning > members of the community for no reason other than revenge, even though I > am > obviously biased, I really think this is the kind of place that FLOSS > projects > should abandon. > > On more positive sidenotes: We had a very constructive chat with Matrix > folk > earlier this week and are now building up stuff to allow briding, so > should > KDE want to move over, we'd hopefully soon have a Matrix (and thus also > Telegram) bridge available. > > > Kind regards and thanks for the decade of support on freenode, > > Christian > > > --- > > Full chatlog that got croppedly released by Andrew Lee. > As usual, people are free to make up their own opinion if they have the > full > information, and not just bits and pieces. > > > cat 2021-05-11.log > [19:45:43] Hey there, please join #freenode-board -- this is an > official message sent in my capacity as the owner of Freenode. > Additionally, > if you can please use my gpg key and share with me all of the credentials > of > Freenode. Thank you in advance. Just to be clear, this is an official > message from the ownership of Freenode. > [21:05:30] Hi Fuchs, do you have plans to comply? This is an > official request from the Freenode Board > > cat 2021-05-25.log > [21:15:32] well, good evening, "sole board member and chairman of > freenode" > [21:15:49] I assume that didn't go exactly as you planned when you > unleashed your bloodhounds, and when you called for my resignation > [21:16:20] free tip for next time: money might buy you domains or > assets, but it will never buy you the right people, it will never buy you > true > loyality and, most importantly, it will never buy you a community > [21:16:49] go and build one, with dedication and hard work. Good > luck. > [21:17:54] ? > [21:19:01] Fuchs, you know very well my support for FOSS has > been > strong, what happened here, and why. > [21:19:16] trivial: > [21:19:35] you sent your bloodhound lawyers after a well respected > community member, after _you_ misunderstood blog posts and resignation > letters > [21:19:45] I know christel already corrected you on your gist, > shame > you never updated that > [21:19:57] I assume by now you also know that there never was a > "merger" between OFTC and freenode planned > [21:20:01] You are very incorrect Fuchs. > [21:20:11] Secondly, you sent your mob on me. > [21:20:19] and then you tried to throw out respected members of > the > community, and you replaced them with people that have 0 credibility in > the > FOSS world, in some cases even a negative one > [21:20:21] The same mob you leashed on others and I, now I know > I > was wrong to, protected you. > [21:20:25] I can't believe why you're doing this. > [21:20:33] then you really can't be helped, I guess > [21:20:36] good luck in your reality > [21:20:51] and enjoy the scorched earth and smoking ruins and > ashes > that you inherited, killer of IRC > [21:21:02] Fuchs, you are wrong to speak ill of the new > freenode > volunteers. > [21:21:08] They've done quite a bit for FOSS and are > respectable > people. > [21:21:11] Attack me all you want. > [21:21:17] Not the volunteers. Fair? > [21:21:39] Oh, I don't attack them. The community already has > spoken > on them, I'm rather sure, from the logs I have > [21:21:46] and I don't attack you either > [21:21:52] I exp
Re: The status of freenode (the IRC network used by KDE)
On Wednesday, 26 May 2021 09:56:08 BST Dmitry Kazakov wrote: > Hi, all! > > Is there any KDE-wide decision on that? Is there any work done on migration > from freenode to libera? I mean, if a KDE-project wants to migrate from > freenode to libera, what should it do? Do that individually or wait until > the whole organisation does that in a bucket? > Hi I am one of KDE's IRC group contacts with both freenode and libera As most of you are aware there are serious repercussions happening to communities and channels that publicly state their intention to move therefore doing that would be a bad idea Only a coordinated change would be good for our community. This would obviously be communicated to the community if everything that we need was prepared and ready to happen -- Kenny (Pronouns: he/him)
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
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
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?
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
