As far as I understand it, MIT only requires you to include the attribution next to the binary so ias you guessed next to the source code on the server.

However, the js shipped to clients is usually minified and transformed which means it may count as "compiled" and thus the same rules as for binaries would apply.

Cases like these are the reason why the AGPL exists.

> Cases like these are the reason why the AGPL exists

Exactly. Not sure why they Ghost doesn't use AGPL. Still, it would have been kind of fair from Substack to approach this more open and collaboratively...

If I use some MIT licensed dependency to power a service at work, I don't beg permission from the maintainers first

While agree that it would be nice from the Substack to give credit to Ghost, they are not required to do.

It's unfair to complain about Substack doing exactly what they are explicitly allowed to do by the company that released Ghost under that specific licence that they choose to.

Yes I agree it's unfair to complain, and I don't think Ghost is complaining (at least I don't see complaints from what John tweeted). It's more about "giving credit where credit's due" I think...

Because AGPL probably would have made it a no-go for substack to use. They seem to genuinely want to collaborate: https://twitter.com/JohnONolan/status/1602330416643702784

Why would AGPL have made it a no-go for Substack? Also, it looks like Ghost wants to collab but there's nothing from Substack in the Twitter thread you linekd?

IANAL but I think integrating AGPL code would affect the license of the rest of the codebase too: Substack would be forced to release the rest of their codebase as AGPL too. This is why AGPL is considered a "viral" license.

> Ghost wants to collab but there's nothing from Substack

Substack doesn't have to "collaborate" do they?

Because AGPL infects their entire service. You'll be hard pressed to find any commercial service adopting AGPL projects. Even the GPLv3 is often immiscible with commercial services. At least GPLv3 can be contained to only part of your stack.

Minified versions of most JS libraries include a copyright notice as a top or bottom comment. How hard is it to respect this basic requirement?

Hey, Substack CTO here. We actually link directly to the jsdeliver CDN to use the files that get built for distribution in the sodo-search npm library. We make no modifications to the files (including not minifying them anymore than they are). The files actually do have a link at the top to the license file, which is hosted in the same directory on jsdeliver.

> The files actually do have a link at the top to the license file

That's not actually the license for the file; it's the license for the resources it includes. The license for the file is available elsewhere but is not directly linked. See my comment at https://news.ycombinator.com/item?id=33959622

understood

Quite hard. Isn't the whole point of the minification to remove non functional parts to make the size smaller?

Not really hard... for one there's a convention of putting an exclamation point at the start of comments that should survive the minification/compilation process, for this very purpose.

Not hard at all. A couple of comments won't make any difference. Here's the minified version of one of react components for example:

https://unpkg.com/[email protected]/umd/react.production.min.js

I highly doubt you can count minified as "compiled" Minification is a form of compression. Compilation is a form of conversion from a high level to a lower level interpretation and that is fundamentally different.

But then again I'm not a lawyer :)

The intent is for attribution to be kept with the code. If your minifier removes the attribution you’re likely in violation.

And the minifier’s job is to remove things like comments which is right where the attribution is likely to be.

Now if a third party thing like a cloudflare CDN were minifyer for you and removed it then who violated the license?

There is an informal standard in which copyright notices are annotated with a leading "/*!” to let minifiers know that they should be preserved.

See https://stackoverflow.com/questions/11248363/the-purpose-of-...

If the CDN is just a part of your architecture that you voluntarily setup then you’re likely the one violating. Even if not the CDN very likely has an indemnification clause in their contract which would shift that liability back to you.

Hey, Substack CTO here. We actually don't minify or modify the files in question at all and simply link to the versions hosted on the public jsdelivr CDN (which includes a link to the license right at the top of the file)

First off: weird take, and one that would be unlikely to hold up. But secondly: what is that supposed to matter, anyway? That is, why are you litigating the definition of the word "compiled"? No finding, whether for or against your argument, would have any bearing on questions about compliance with the terms of the MIT license, so the word's definition and its significance is null. It's a total red herring and a distraction to bring up in any discussion on the topic.

I figure compilation is a big tent and this counts, but imagine

--rename-properties WARNING: renaming properties requires deeper analysis, considered compilation in the US

The way I do it in my SaaS app is there is an "attributions" page. On it I have a list of all OSS software I've used in both frontend and backend.

I like it - though it'd be hard to resist aliasing /attributions.txt to /lawyers.txt ...

Unfortunately a mention in the "attributions" page won't pay the OSS developers' rent.

If you want people who use the software you develop to pay you to use it, you should not release your software under an open source license.

You probably already knew this, I don't mean to point out the obvious. I am just confused by your comment, and others like it that frequently come up on HN these days. People saying or implying that there is something unfair about using open source software under the license terms that its developers have chosen to release it.

It's more acknowledgement than is required to use most OSS.

If the OSS developers want to generate revenue, there are plenty of paths they can follow.

> For a SaaS app, wouldn't that copyright attribution be on the server side (hidden to the end user)?

I agree and my take on this is based on the way compilers generate binaries. I would not expect a compiler to inject random copyright notices in sdtout, for example. Ghost, in this case, is acting like "compiler" and the HTML can be thought of as the "output" akin to a binary generated by a traditional compiler. The MIT license (and similarly permissive ones) do not dictate software usage and thus it's output is not required to have any attribution, only source code.

Hey, Substack CTO here. We're actually not using Ghost's platform and have instead built a theming API that is compatible with third-party themes that are built for Ghost. The one piece of code that the theme uses that's developed by Ghost is the open source search library used on the frontend. In this case the theme links directly to the files that Ghost has distributed on jsdelivr via npm

Ah you may find it interesting, the GPL3 license actually does prescribe showing copyright notices in stdout [1].

> If the program does terminal interaction, make it output a short notice like this when it starts in an interactive mode ...

> The hypothetical commands `show w' and `show c' should show the appropriate parts of the General Public License. Of course, your program's commands might be different; for a GUI interface, you would use an “about box”.

This is to say it is not entire unusual to have copyright notices in output.

[1] https://www.gnu.org/licenses/gpl-3.0.en.html

Bear in mind these are suggestions, not part of the terms and conditions of the license itself.

This feels silly. Not a single one of my userland tools does this, but they are clearly all GNU...

Note the “interactive mode” - this means like starting an editor or nslookup kind of thing.

Less is interactive, and does no such thing.

I mean, I get it. This will be nigh impossible to codify, such that there will be reasons things can and cannot work in certain situations. This line of attack here, though, is feeling overly forced and would actually sway me to never use such licensed stuff. And I'm pretty heavy on the open source support.

Yeah it's clearly a "recommendation" and people seem to use it pretty sanely.

bash doesn't do it even if you start a subshell. I know I've seen the NO WARRANTY message flash on my screen but darned if I can find a gnu program that does it by default.

Would be nice if upstream Ghost made this easier for users. I just checked my blog and it has a default footer with a link "powered by ghost", they could just as easily have a link to the license.

> For a SaaS app, wouldn't that copyright attribution be on the server side, where the code is (hidden from the end user)?

I'm curious about this because the end user's browser is where the (copied) code is run, not on the server. That's why they need to hot-load additional code from Ghost's CDN, rather than doing so on build servers.

I think I'm safe just having a .txt file you can somehow discover and read from the same server that hosts the website. But in order to do what feels right, I always put it into an "About" section somewhere.

They are shipping Ghost client side javascript. That should have the mentioned notice on it.

Hey Substack CTO here. We actually don't host, modify, or minify the client side library in question. We link directly to the jsdelivr CDN for it and the distributed files from there have a license link at the top