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.
I found it surprising that the slide in the article uses Calibri, a typeface that wasn’t publicly available at the time. The original discussion confirms that the slide in the article is a recreation of the original one:
> The slide in the article has the same text, but is a recreation of the original (The Calibri typeface used wasn't part of PowerPoint until 2007).
> The original slide can be seen in the full report linked in the article:
which is even better than what Bootstrap provides since you get type safety for component props (and more opportunities for customization than what Bootstrap allows)
Type safety is good, but the class soup inside the components is just abysmal. And honestly, more often than not I see it spilling out of the components and onto the page layouts.
Design tokens are the one Tailwind feature I genuinely like. Everything else – kill it with fire. Just use whatever scoped CSS your stack does (<style> in Svelte/Vue, Emotion in React?).
class soup is what tailwind is. It's terrible because is just abbreviations of css attributes which you still need to know because you'll inevitably fiddle around devtools trying things out.
The only "smart" thing about it is leaning strongly on using rem.
how can it spill out onto the page? it's inline css. The (rare) inline selectors target only descendants.
Truth is that it's winning over because it works best with LLMs. Inline soup works better than looking for styling on different files in the context of the project, so here we are.
> how can it spill out onto the page? it's inline css.
Because people are lazy and don’t make a component for everything. And some people are even lazier and don’t make UI components at all. I’ve seen a project where there was a Button component and that’s it. Well, that was vibe coded probably so makes sense.
> Inline soup works better than looking for styling on different files in the context of the project, so here we are.
Only if you have a separate .css. If you do UI components with [insert your favourite CSS-in-JS solution], it stays in the same file. Maybe the proximity to markup within the file is important?
But no, Tailwind has been rising in popularity long before LLMs came along.
[I'm assuming styled-components was the preferred css-in-js solution until recently]
> If you do UI components with [insert your favourite CSS-in-JS solution], it stays in the same file.
I mean you can but "best practice" all around has been to put them separate and that's reflected in the majority of github repos in the training data of the LLMs.
> Maybe the proximity to markup within the file is important?
that's my assumption, yes. Seems to me LLMs work best when they output the relevant tokens right there with the markup instead of referencing some previous tokens even if relatively close.
styled components was the recommended solution in popular UI libraries like React MUI up until 2023 when chatgpt came out. Tailwind REALLY blew up with LLMs.
Yeah, I mean, with either Tailwind or styled-components you want to contain them to “UI components” – e.g. <Button> or <Navbar>. You could mix in some logic, and you’re right, looks like many styled-components folks will split it into two files then – but honestly I would just do in one.
Personally, I’m a Svelte fan, and I think they got it right – you just write <style> in your component and that’s it. I think Vue works in a similar way, too.
> Truth is that it's winning over because it works best with LLMs. Inline soup works better than looking for styling on different files in the context of the project, so here we are.
I saw this on another recent tailwind thread and I’m not sure I agree. LLM might be helping adoption, but I’ve been seeing and using tailwind for years without really going near LLM coding
> If you already updated for the Critical Security Vulnerability last week, you will need to update again.
> If you updated to 19.0.2, 19.1.3, and 19.2.2, these are incomplete and you will need to update again.
https://react.dev/blog/2025/12/11/denial-of-service-and-sour...