This file does not contain the terms of service of Slack. Rather, it contains the software licenses of third-party code that is embedded in Chromium, which in turn is embedded in the Slack app. Every dependency has its own license, which is why the file is so big (800× Apache-2.0, 237× MIT, 59× LGPL, and so on).
This is BSD Licence Hell, and for about 10 years I've being doing what miniscule part I can do to ameliorate it. Debian people are trying to do their parts, too.
That's how it is done in debian packages. The full text of each license is only mentioned once and given an identifier which is then used to link the license to the relevant copyright statements.
The worst companies to work for are bad at differentiating risk especially ones that entertain the most remote legal risks. It seems to happen more with legal risks than security or technology risks.
I think it might be the case that licenses often include the authors’ names in the “this code is copyright of so-and-so” (as you can see, I Am Not A Lawyer) section, which might be considered part of the text of the license, thereby making it a requirement to include the full license text for each dependency.
It’s usually done in MIT-like licenses, which are quite short.
But I’d argue that replacing it with
Copyright (c) 207X Jonathan Fenimore
Licensed MIT, see the license text below
or even
Copyright (c) 207X Jonathan Fenimore
SPDX-License-Identifier: MIT
should be enough, but IANAL too.
---
In longer licenses like GPL or Apache, you are not supposed to change any copyright statement placeholders. For example, there’s this line in the GPL text:
Copyright (C) <year> <name of author>
But it’s a part of the “How to Apply These Terms to Your New Programs” section. You are supposed to copy it into your code and fill it out there instead.
---
Or they could just compress the license amalgamation! I think it would be a bit bigger but pretty reasonable, and their lawyers should be happy with this arrangement.
Not sure why Apple doesn't offer a compressed filesystem :p it makes writes a bit slower when compression fails, but otherwise the savings in I/O time often makes up for the increased processing on read and write.
My first computer had a 10MB HDD.
* I could program with it comfortably (e.g. Turbo Pascal).
* I could play with it (Civ, Day of the Tentacle with a few tricks, ...)
* I could run a office suite.
* I could communicate via mail and newsgroups
In short: all problems back than could be solved at home.
And yeah, I know that barely anybody cares _how utterly_ wasteful software has become.
But think of the dEvElopEr exPeRienCe! They may have to slow down on the rate they are shitting things out to actually learn a native system/UI toolkit, or, gasp, write it a few different times for different environments! Thats gonna affect some bonuses for sure.
We need to return to a world where we primarily own things, not rent them. If the software executable can be thought of as a machine, we should be able to own the version/instance of it we purchased the license for. We may not own the intellectual property, but we should have enough ownership to install it on a personal cloud computer we own and run it until such time we need to upgrade it.
According to https://zulip.com/plans/#self-hosted, the only things you get by upgrading from free self-hosted (which is absolutely offered) to paid self-hosted is to remove the limits on mobile notifications, which is a service that Zulip as an organization has to run and which therefore has an inherent cost, plus access to various forms of customer support.
Explicitly mentioned is that all Zulip features are included in the free plan.
The self-hosted offering is notably described as 100% open source software in the tab heading above all the plans, paid or free. https://zulip.com/help/zulip-cloud-or-self-hosting confirms this interpretation. It’s as owned as any other open source software. https://zulip.com/self-hosting/ even confirms that the self-hosted offering is the same software as Zulip Cloud.
The mobile push notification service is also open source and can be self-hosted for free, although this requires recompiling the mobile apps with a different secret and distributing the modified apps to the desired mobile clients. Zulip has no way around this due to Google and Apple’s push notification security models.
You could certainly propose it to them (especially with a PR that includes code), or patch it into your local copy if they decline. I wouldn’t be surprised if Google wouldn’t allow that in the Play Store-compiled version of the app, but I don’t know.
Yeah, I think it’s quite common to have a “Google Play version” and an “F-Droid version” with different implementations behind build flags. Not sure if it’s required though – I can see some UnifiedPush providers in the Play Store, at least.
You aren’t wrong. Up until a couple of weeks ago it was $299. Once. Forever. That was the whole idea. Very cool that they open sourced it. MIT license too.
honestly the slack app store and it’s ridiculous policies makes publishing apps completely unworthy of the time investment. after having published numerous apps across dozens of marketplaces, I would advise everyone to avoid apps.slack.com at all costs. slack is beyond the maximum bloat threshold in virtually every aspect imaginable, TOS and licensing most especially. build elsewhere
If you mean for individuals, it's because that's what their job uses. If you mean for the companies deciding to use Slack, it's because most companies significantly prefer to pay someone for a supported product than use a free product which they have to have their own staff support.
Because it actually works pretty well most of the time. I'm not sure where you get "barely works" from, but that's not remotely my experience or the experience of anyone I know. And of course, network effects are strong so that keeps people using it even through the occasional hiccups.
As for how it got its foothold, it comes down to having an easier onboarding than the solutions it competed with. With Mumble (or Ventrilo, etc) someone has to pay for a server. Then you have to download the client, get the host and port to connect to, enter credentials, and so on. Repeat for every server you might join. With Discord, once your account is set up you just click on a link and join the server. You don't even have to use the client if you don't want; you can join from the browser just fine. I don't think the friction of using previous solutions was actually bad, but it was enough to give Discord an edge even without the integrated chat+voice angle (which is something that those other programs never did and still don't do).
> I'm not sure where you get "barely works" from, but that's not remotely my experience or the experience of anyone I know.
Alright, I'm exaggerating but I've never had as many problems with such a popular app of that class. I'm literally locked out right now due to a known bug (confirmed by support) and this isn't even the first time. Then there were months when recording voice notes (of all things) didn't work on Android. So many other little random things. If YouTube or something behaved that way I'd be shocked. It's a ghetto in comparison.
Yeah, I get what you're saying about friction. I'm complaining as someone who's fine with Signal and IRC, so not the target audience. Someone else also mentioned that the performance may have been better early on as well. I find that hard to believe but I'll trust ya'll for now.
That's wild to me. I'm mostly not a fan of browser-based tools, and I was apprehensive of Discord calling things "servers" when they're clearly not (if they lie about that then what else?), but it's been rock-solid for me and for several friend groups for ~6 years. We don't use any particularly fancy features (chat, voice, streaming, various settings changes on all of those, etc), but we use a mix of clients/web/mobile-web, and out of all of us there was exactly one issue in that time (a few weeks were incompatible with a particularly esoteric browser, fixed not long after I reported it).
When I installed matrix, I thought it was an example of FOSS UI being crummy. Then I found out they were actually doing a good job of emulating discord.
Because when Discord released it had less impact on game performance than any of the other solutions at the time. And these days it’s still great, so only a fantastic solution will be able to replace it. But maybe in a few more years of enshitification it will be easier for something new to be better than it.
This file does not contain the terms of service of Slack. Rather, it contains the software licenses of third-party code that is embedded in Chromium, which in turn is embedded in the Slack app. Every dependency has its own license, which is why the file is so big (800× Apache-2.0, 237× MIT, 59× LGPL, and so on).
This is BSD Licence Hell, and for about 10 years I've being doing what miniscule part I can do to ameliorate it. Debian people are trying to do their parts, too.
* https://debian.org/doc/packaging-manuals/copyright-format/1....
Why can't it deduplicate matching licenses?
That's how it is done in debian packages. The full text of each license is only mentioned once and given an identifier which is then used to link the license to the relevant copyright statements.
For example: https://salsa.debian.org/debian/highlight/-/blob/94ee6559155...
The legal department doesn't want to take that chance.
Lawyers can make mistakes, but to REALLY mess things up, you need lawyers, plus some engineers that take the lawyers too seriously.
The worst companies to work for are bad at differentiating risk especially ones that entertain the most remote legal risks. It seems to happen more with legal risks than security or technology risks.
That goes true of basically every hard core expert. They might be wildly smart in their domain… and that is it.
I think it might be the case that licenses often include the authors’ names in the “this code is copyright of so-and-so” (as you can see, I Am Not A Lawyer) section, which might be considered part of the text of the license, thereby making it a requirement to include the full license text for each dependency.
It’s usually done in MIT-like licenses, which are quite short.
But I’d argue that replacing it with
or even should be enough, but IANAL too.---
In longer licenses like GPL or Apache, you are not supposed to change any copyright statement placeholders. For example, there’s this line in the GPL text:
But it’s a part of the “How to Apply These Terms to Your New Programs” section. You are supposed to copy it into your code and fill it out there instead.---
Or they could just compress the license amalgamation! I think it would be a bit bigger but pretty reasonable, and their lawyers should be happy with this arrangement.
Are you sure it doesn't*?
* When we treat different versions of say, the MIT license, with different names and copyright years inserted, as different licenses.
I have to imagine the file would compress extremely well though... I'm more curious why they don't use compression.
Not sure why Apple doesn't offer a compressed filesystem :p it makes writes a bit slower when compression fails, but otherwise the savings in I/O time often makes up for the increased processing on read and write.
I imagine it does precisely that when gzipped for distribution.
Title of this post is blatantly misleading for using the singular 'license'.
My first computer had a 10MB HDD. * I could program with it comfortably (e.g. Turbo Pascal). * I could play with it (Civ, Day of the Tentacle with a few tricks, ...) * I could run a office suite. * I could communicate via mail and newsgroups
In short: all problems back than could be solved at home.
And yeah, I know that barely anybody cares _how utterly_ wasteful software has become.
But think of the dEvElopEr exPeRienCe! They may have to slow down on the rate they are shitting things out to actually learn a native system/UI toolkit, or, gasp, write it a few different times for different environments! Thats gonna affect some bonuses for sure.
We need to return to a world where we primarily own things, not rent them. If the software executable can be thought of as a machine, we should be able to own the version/instance of it we purchased the license for. We may not own the intellectual property, but we should have enough ownership to install it on a personal cloud computer we own and run it until such time we need to upgrade it.
> … personal cloud computer we own
I can only read this as an oxymoron
https://zulip.com/ is a pretty excellent chat program that can be self-hosted
Zulip self-hosted is billed monthly. Still a form of rent. You don't own the version you bought perpetually.
According to https://zulip.com/plans/#self-hosted, the only things you get by upgrading from free self-hosted (which is absolutely offered) to paid self-hosted is to remove the limits on mobile notifications, which is a service that Zulip as an organization has to run and which therefore has an inherent cost, plus access to various forms of customer support.
Explicitly mentioned is that all Zulip features are included in the free plan.
The self-hosted offering is notably described as 100% open source software in the tab heading above all the plans, paid or free. https://zulip.com/help/zulip-cloud-or-self-hosting confirms this interpretation. It’s as owned as any other open source software. https://zulip.com/self-hosting/ even confirms that the self-hosted offering is the same software as Zulip Cloud.
The mobile push notification service is also open source and can be self-hosted for free, although this requires recompiling the mobile apps with a different secret and distributing the modified apps to the desired mobile clients. Zulip has no way around this due to Google and Apple’s push notification security models.
Can they use https://unifiedpush.org/ on Android (as an option, not insread of FCM)?
You could certainly propose it to them (especially with a PR that includes code), or patch it into your local copy if they decline. I wouldn’t be surprised if Google wouldn’t allow that in the Play Store-compiled version of the app, but I don’t know.
Yeah, I think it’s quite common to have a “Google Play version” and an “F-Droid version” with different implementations behind build flags. Not sure if it’s required though – I can see some UnifiedPush providers in the Play Store, at least.
As I said, I don’t know whether Google minds UnifiedPush or not. Maybe they don’t.
Buy Campfire instead? https://once.com/campfire
It’s free and under MIT (though no too long ago this wasn’t the case)
Yeah, I see you're right. I had in my head it was around a $200 fee?
You aren’t wrong. Up until a couple of weeks ago it was $299. Once. Forever. That was the whole idea. Very cool that they open sourced it. MIT license too.
https://x.com/dhh/status/1963675999012552970
https://github.com/basecamp/once-campfire
299USD. It became free merely two weeks ago.
https://nitter.net/dhh/status/1963675999012552970
Campfire needs 64GB RAM for 10,000 users, that surprises me, I would think we could get to 10k users with far less RAM.
well it is rails
An alternative to look into, https://element.io/ using Matrix, especially if encryption is preferred.
And we provide these apps with data and collaboration we rely on for our business or clubs day-to-day?
Time to rethink.
honestly the slack app store and it’s ridiculous policies makes publishing apps completely unworthy of the time investment. after having published numerous apps across dozens of marketplaces, I would advise everyone to avoid apps.slack.com at all costs. slack is beyond the maximum bloat threshold in virtually every aspect imaginable, TOS and licensing most especially. build elsewhere
This is simply downstream of open source working as intended. It's also not a problem, and also there's no good solution.
> It's also not a problem, and also there's no good solution.
I have worked with people who have this attitude and I wonder how they're doing these days.
I hope they haven't ran into any problems they cannot simply dismiss as not problems that don't have solutions.
I can't really understand the point of using Slack. There's so many free alternatives.
If you mean for individuals, it's because that's what their job uses. If you mean for the companies deciding to use Slack, it's because most companies significantly prefer to pay someone for a supported product than use a free product which they have to have their own staff support.
Someone also explain to me how gamers of all people can live with Discord when the thing barely works.
Because it actually works pretty well most of the time. I'm not sure where you get "barely works" from, but that's not remotely my experience or the experience of anyone I know. And of course, network effects are strong so that keeps people using it even through the occasional hiccups.
As for how it got its foothold, it comes down to having an easier onboarding than the solutions it competed with. With Mumble (or Ventrilo, etc) someone has to pay for a server. Then you have to download the client, get the host and port to connect to, enter credentials, and so on. Repeat for every server you might join. With Discord, once your account is set up you just click on a link and join the server. You don't even have to use the client if you don't want; you can join from the browser just fine. I don't think the friction of using previous solutions was actually bad, but it was enough to give Discord an edge even without the integrated chat+voice angle (which is something that those other programs never did and still don't do).
> I'm not sure where you get "barely works" from, but that's not remotely my experience or the experience of anyone I know.
Alright, I'm exaggerating but I've never had as many problems with such a popular app of that class. I'm literally locked out right now due to a known bug (confirmed by support) and this isn't even the first time. Then there were months when recording voice notes (of all things) didn't work on Android. So many other little random things. If YouTube or something behaved that way I'd be shocked. It's a ghetto in comparison.
Yeah, I get what you're saying about friction. I'm complaining as someone who's fine with Signal and IRC, so not the target audience. Someone else also mentioned that the performance may have been better early on as well. I find that hard to believe but I'll trust ya'll for now.
That's wild to me. I'm mostly not a fan of browser-based tools, and I was apprehensive of Discord calling things "servers" when they're clearly not (if they lie about that then what else?), but it's been rock-solid for me and for several friend groups for ~6 years. We don't use any particularly fancy features (chat, voice, streaming, various settings changes on all of those, etc), but we use a mix of clients/web/mobile-web, and out of all of us there was exactly one issue in that time (a few weeks were incompatible with a particularly esoteric browser, fixed not long after I reported it).
When I installed matrix, I thought it was an example of FOSS UI being crummy. Then I found out they were actually doing a good job of emulating discord.
Discord is much, much more user friendly than Matrix!
Except that Matrix is a protocol.
Because when Discord released it had less impact on game performance than any of the other solutions at the time. And these days it’s still great, so only a fantastic solution will be able to replace it. But maybe in a few more years of enshitification it will be easier for something new to be better than it.
Wait until you find out both Ukrainian and Russian military were using Discord to communicate
Wait until you find out that the interim prime minister of Nepal was elected on Discord
Would you happen to have a stack ranked list of favorites off the top of your head?
One throat to choke... is why. Enterprise grade sales and support.